Results 1 to 6 of 6

Thread: Specification for binary <source> data

  1. #1

    Specification for binary <source> data

    Hi,

    In order to speed-up the loading/saving of complex collada geometries, shouldn't the specification offer alternative binary formats for <source> elements ?
    If the specification enforces the exact binary format, then compatibility would be guaranteed between DCC tools, because each DCC tool would know how to extract the binary data.
    Most of Collada specification could remain ascii. Only <source> elements could reference external binary files.

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

    Re: Specification for binary <source> data

    COLLADA does allow for externalized <source> data. I recommend reading about the <accessor> element in the COLLADA 1.5.0 specification.

    A form of this optimization is implemented in the COLLADA DOM open source project too.

  3. #3

    Re: Specification for binary <source> data

    Really ?
    Do you know the specific C++ class in Collada DOM that does this kind of optimization ?

    Quote Originally Posted by marcus
    A form of this optimization is implemented in the COLLADA DOM open source project too.

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

    Re: Specification for binary <source> data


  5. #5

    Re: Specification for binary <source> data

    That's interesting.

    However, this ".raw" export option is specific to Collada-DOM. How many DCC tools support this option ?

    If there was an "official" .raw (whose format is given in the specification), then binary format could be widely supported by any dcc tool.

    Is it something that will happen in future specifications ?

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

    Re: Specification for binary <source> data

    The COLLADA DOM implementation of ".raw" stems from the capabilities of the <accessor> element, as documented in the specification, and the nature of opaque URI resources. I.e. its the <accessor> that describes the (in this case external) resource that is referenced by a standard URI.

    So that in that sense it is standard COLLADA although I do not have marketing data about other tools that support it.

    A good understanding about URI processing is key. As with any format that is external to COLLADA, and there are many thanks to the numerous image formats, it is up to the URI processor to dereference (i.e. retrieve) the resource. As long as the I/O software has a media type handler to retrieve the data then the <accessor> information provides the mapping from that external storage to the <source> and <input> elements.

Posting Permissions

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