Results 1 to 6 of 6

Thread: daeURI and <InputLocal> schema

  1. #1
    Junior Member
    Join Date
    Jun 2006
    Posts
    4

    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:

    Code :
    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.

  2. #2
    Senior Member
    Join Date
    Aug 2004
    Location
    California
    Posts
    771

    Re: daeURI and <InputLocal> schema

    Quote Originally Posted by take
    Code :
    <accessor count="10" source="file:///testCollada.dae#mesh000-Pos-array" stride="3">
    This is a valid source attribute value that conforms to the type xs:anyURI. The value is an absolute URL with a fragment.
    Quote Originally Posted by take
    I tested this output file using XSI 5.1 Collada importer, but it didn't work.
    Please file a bug against XSI.
    Quote Originally Posted by take
    So I got rid of the "file:///testCollada.dae" from their URI using text editor, it worked fine.
    This implies that XSI only supports URI fragments for the source attribute.
    Quote Originally Posted by take
    Is there the right way to make the daeURI without baseURI( like "file:///testCollada.dae" ) or is this a bug of XSI importer?
    It's a bug in the XSI importer.
    Quote Originally Posted by take
    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.
    I don't understand the question here. What exactly are you referring to when you say "schemas"?

  3. #3
    Junior Member
    Join Date
    Jun 2006
    Posts
    4
    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.

  4. #4
    Senior Member
    Join Date
    Aug 2005
    Location
    California
    Posts
    165
    Quote Originally Posted by Take
    So, How can I create the daeURI instance which implies the "URI fragments"?
    hmmm.. seems like there isn't a way without just hacking it together like this.
    Code :
    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.

    Quote Originally Posted by Take
    Can I use(and output to file)<input> tags, instead of <InputLocal> and <InputLocalOffset> tags, with the Collada DOM 1.4.0?
    How are you creating these elements. are you just saying
    Code :
    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
    Code :
    il->setElementName( "input" );
    after you create the element.

    same goes for inputLocalOffset.

    -Andy

  5. #5
    Junior Member
    Join Date
    Jun 2006
    Posts
    4
    I tried out next code:

    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.

  6. #6
    Senior Member
    Join Date
    Aug 2005
    Location
    California
    Posts
    165
    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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •