daeURI and <InputLocal> schema

Hi

I have two questions about exporting to collada ( with collada DOM 1.4.0 )

First question,

I created a daeURI, which is passed as a domAccessor::setSource()'s argument, and setup it.
As follows:


daeURI uri ;

// pPositionArray is the pointer of domFloat_array and already created.
uri.setElement( pPositionArray ) ; 
uri.resolveURI() ;

pAccessor->setSource( uri ) ;

The result of above code is :

<accessor count=“10” source=“file:///testCollada.dae#mesh000-Pos-array” stride=“3”>

I tested this output file using XSI 5.1 Collada importer, but it didn’t work.
So I got rid of the “file:///testCollada.dae” from their URI using text editor, it worked fine.

Is there the right way to make the daeURI without baseURI( like “file:///testCollada.dae” ) or is this a bug of XSI importer?

Second question,

I am using domInputLocal and domInputLocalOffset to describe <input> schema(the child of <vertices>, <polygons> schema).

But when I use XSI 5.1 Collada Importer, these schemas are ignored. So I replaced them(<InputLocal> and <InputLocalOffset>) with simple <input>.
It worked fine…

In the Collada Specification 1.4.0, there is only the <input> schema’s reference.

Is there the way of using <input> schema when I use the collada DOM 1.4.0? Or should I use the <InputLocal> scehma instead of <input> strictly?

Thanks.

I don’t understand the question here. What exactly are you referring to when you say “schemas”?

Thanks for your reply.

This implies that XSI only supports URI fragments for the source attribute.

So, How can I create the daeURI instance which implies the “URI fragments”?

I don’t understand the question here. What exactly are you referring to when you say “schemas”?

I’m sorry that I misunderstood the meaning of “schema”.
Perhaps I should use “tags” instead of “schema”.

My question is simple.

Can I use(and output to file)<input> tags, instead of <InputLocal> and <InputLocalOffset> tags, with the Collada DOM 1.4.0?

I can’t find the domInput class definition in the 1.4.0. It seems to exist only in the 1.3.0

Regards.

hmmm… seems like there isn’t a way without just hacking it together like this.

daeURI uri ;

// pPositionArray is the pointer of domFloat_array and already created.
uri.setElement( pPositionArray ) ;
uri.resolveURI() ;

char *idString = new char[ strlen( uri.getID() + 2 ) ]; //+1 for # +1 for \0
strcpy( idString, "#" );
strcat( idString, uri.getID() );
pAccessor->getSource().setURI( idString ) ; 

That might do the trick for you.

How are you creating these elements. are you just saying

domInputLocal *il = new domInputLocal();

That wouldn’t be the best way to create elements. you should use the daeElement::create( daeString name ) or daeElement::createAndPlace( daeString name ) functions. It will take care of the element naming for you. But if you don’t want to change your code all you have to do is call

il->setElementName( "input" );

after you create the element.

same goes for inputLocalOffset.

-Andy

I tried out next code:


daeURI uri ;
uri.setElement( pSource ) ;
uri.resolveURI() ;

pInputLocalOffset->getSource().setURI( uri.getOriginalURI() ) ;

It works anyway. Do you think about this code?

And, I prefer using setElementName(). Thanks.

BTW, Is it a bug of XSI Collada Importer that can’t be recognized the <InputLocal> tags?

If so, I will report it with the matter about URI interpretation.

I can’t found the <InputLocal> (and <InputLocalOffset>, <InputGlobal>) reference in the Collada 1.4.0 Specification.

Thanks.

No it is not a bug in XSI.

There is no <inputLocal> element in COLLADA. It is a complex type. The DOM hides that fact from people when they use the appropriate creation methods like daeElement::create and daeElement::createAndPlace. But if you circumvent those methods and just create elements from their constructor you now have to worry about element names.

Elements that are complex types in the schema (ie. <element name=“input” type="inputLocal/> ) need to be named correctly.

-Andy