Page 2 of 2 FirstFirst 12
Results 11 to 15 of 15

Thread: Evaluating Collada for our modeling project

  1. #11
    Junior Member
    Join Date
    Mar 2005
    Location
    Lulea, Sweden
    Posts
    29
    The problem is that you want to store the imported extra attributes directly into your .max .mb or .blend file for later data exchange. So if adding properties is not supported in some cases then we (the developers) have to find other ways of storing the data.

    Some of my ideas:
    Blender allows script links for material and scene objects. This would allow artist to link script files to a node object or to a material. The script file could be in any format and the text file could contain any information the user wants. In any case this text should provide enough information so that when I export I can put extra elements and data where I have decided to put them into the collada document.
    My idea is that the artist create a dummy scene node object (in blender called Empty) and put it in my node hierachy. I can name the node for example "COLLADAExtraData". I then add child nodes that have names that corresponds to the names of the objects (data or instances) that I want to add properties to. These child nodes have scripts links which contains xml text information that should be added as an <extra> element to the very same object that was stated as an ID-reference in the node name.
    When exporting the data I can get the "COLLADAExtraData" node and with that information find its children. Whenever I'm exporting a xml element in my exporter I can see if I encounter an ID match with my dummy nodes and the ID-reference the xml element will have. If I have a match then I add the information in the script link into a <extra> element into the document.
    The "COLLADAExtraData" node will not be exported into the final document since the information here has already been preserved into the document.
    The COLLADA importer then simply creates this node system whenever I encounter an <extra> element.

    That was a bit implementation specific for Blender but other DCC tools can perhaps use the same node system for storing extra data. Even if a link system is missing for nodes there should be some way of storing text information in objects other then nodes.

    To allow artist to add and/or modify extra properties an GUI can be scripted.



    ---

    On a similiar topic most modelling software have features that can be exported into collada but their different content creation philosophies makes it hard to get a perfect data exchange between tools. Maya cannot understand light falloff data and Blender cannot understand polygons with more than 4 vertices. Storing such data between DCC are not hard. It's impossible.
    / Master Tonberry

  2. #12
    Senior Member
    Join Date
    Aug 2004
    Location
    California
    Posts
    771
    Quote Originally Posted by sthomas
    The problem: Two goals of Collada (as I understand it) are that it serve as a data interchange format and that it be extensible so that developers can adapt it to their needs. The key method of extensibility in Collada is the <extra> tag
    Yes. In COLLADA, extension by addition is the purpose of <extra>. Extension by alternative (substitution) is what <technique> is for.
    Quote Originally Posted by sthomas
    but <extra> data isn't interchangeable amongst most of the tools that support Collada. This greatly limits the usefulness of Collada's extensibility.
    This is indeed a problem and the DCC vendors have ask for customers to give them direct feedback to help them prioritize their COLLADA feature support.
    Quote Originally Posted by sthomas
    In the importer requirements section the spec says that anything that requires export also requires import, and that "It must be possible to import all conforming COLLADA data, even if some data is not understood by the tool, and retained for later export." I think this language is somewhat confusing and can be interpreted in a few ways, and that the people writing support tools for Collada aren't totally sure what their responsibilities are with respect to custom data. This has led to the current situation where most tools just ignore <extra> data altogether.
    I think it's more a matter of priorities for the DCC vendors then confusion.

    The wording in the spec comes from a recognition that each DCC tool handles meta data differently. We wanted to make a strong statement that COLLADA requires that import/export to be lossless and that DCC tools should improve their internal architectures (if need be) to comply with that requirement. Representatives of Alias, Discreet, and Softimage all participated and approved of these requirements. It's a matter of time and priority as to which COLLADA features get implemented first and customer feedback is a good way to help them set those priorities.
    Quote Originally Posted by sthomas
    The solution: The requirements specific to custom data should be fleshed out and made clear to provide direction to the tool developers. My suggestions for how exactly to do that:
    Thanks for taking the time to offer suggested improvements!
    Quote Originally Posted by sthomas
    (1) Identify a subset of all the elements that <extra> data can be attached to and require that a conformant Collada tool cleanly import/export that data. I think a good set to start with would be <scene>s, <node>s, and <material>s. Alternatively we could just require that all <extra> data be imported/exported cleanly regardless of what it's attached to, but that would likely place a prohibitively high burden on the tool programmer, especially in cases such as Max and Blender where it's difficult to arbitrarily attach data blocks to scene elements.
    Without making exceptions, the spec. currently requires that all elements be imported/exported faithfully. Perhaps a prioritized list of elements could be added to the requirements to give implementors an idea of the order of importance is?
    Quote Originally Posted by sthomas
    (2) Standardize the <param> types. As of now it just says that a param type "must be understood by the application". That's good but int, float, bool, string, etc should all be standard param types that have a specified string representation. This would make it easier for a tool to provide gui support for <extra> data if it wanted to.
    The <param> element is largely removed in COLLADA 1.4 in favor of <extra> and <technique> because they supply a proper context for extension.
    Quote Originally Posted by sthomas
    (3) Add custom data (<extra>) tests to the conformance test suite.
    Absolutely!

    Thanks,
    Marcus

  3. #13
    Senior Member
    Join Date
    Jan 2006
    Location
    Foster City, CA
    Posts
    540
    Quote Originally Posted by Master Tonberry
    Some of my ideas: ...
    This sounds like it might work. This is similar to what we were going to do for Blender when we were considering writing plugins for it. We were going to drop xml into the text document area of the Blender model. If you could get something going on this I'd be happy to bang on it to try to find bugs.

    Quote Originally Posted by marcus
    We wanted to make a strong statement that COLLADA requires that import/export to be lossless and that DCC tools should improve their internal architectures (if need be) to comply with that requirement. Representatives of Alias, Discreet, and Softimage all participated and approved of these requirements.
    Are you absolutely certain the dcc guys knew they were agreeing to that? I mean, as it currently stands, there's a monstrous gap between what the spec says a Collada tool must do and what the current Collada tools do, with respect to custom data. Perhaps it's solely an issue of priorities as you say, but I don't see any evidence that the dcc tools are moving in the direction of lossless Collada file import/export, e.g. ajclaude: "... our plugin does not try to preserve the entire COLLADA document ...".

    Without making exceptions, the spec. currently requires that all elements be imported/exported faithfully. Perhaps a prioritized list of elements could be added to the requirements to give implementors an idea of the order of importance is?
    Ok, I wasn't totally sure that the spec required full data import/export. If that's the case then I don't think a prioritized list is necessary. What elements get <extra> data support will be decided by the dcc tool architecture rather than any prioritized list we'd come up with.

    The <param> element is largely removed in COLLADA 1.4 in favor of <extra> and <technique> because they supply a proper context for extension.
    Hmm, ok. It's still in the spec and the spec says nothing about it being deprecated.

    The reason <param> is nice is that it provides information about the type of data contained inside. So apps like SoftImage that want to provide a gui for this data can do a better job. A string gets a text box, a bool gets a check box, etc. That doesn't actually require <param> of course... it just requires a standard way of specifying the type of data contained inside the <extra> block.

  4. #14
    Senior Member
    Join Date
    Aug 2004
    Location
    California
    Posts
    771
    Quote Originally Posted by sthomas
    Quote Originally Posted by marcus
    We wanted to make a strong statement that COLLADA requires that import/export to be lossless and that DCC tools should improve their internal architectures (if need be) to comply with that requirement. Representatives of Alias, Discreet, and Softimage all participated and approved of these requirements.
    Are you absolutely certain the dcc guys knew they were agreeing to that? I mean, as it currently stands, there's a monstrous gap between what the spec says a Collada tool must do and what the current Collada tools do, with respect to custom data.
    Yes I'm sure! We have the verbal commitment written into the specification as requirements, but it still takes time and resources to follow through on them by each company.
    Quote Originally Posted by sthomas
    Perhaps it's solely an issue of priorities as you say, but I don't see any evidence that the dcc tools are moving in the direction of lossless Collada file import/export, e.g. ajclaude: "... our plugin does not try to preserve the entire COLLADA document ...".
    COLLADA as an interchange format is everyone's near-term goals I think, with source (i.e. lossless) format support a longer term goal and vision.

    Khronos is working on a conformance test framework this year for COLLADA. Softimage and Autodesk have both expressed the intention of passing their products through this test process. We think the test suite is very important and will help to drive development of COLLADA in DCC and middleware tools.
    Quote Originally Posted by sthomas
    The <param> element is largely removed in COLLADA 1.4 in favor of <extra> and <technique> because they supply a proper context for extension.
    Hmm, ok. It's still in the spec and the spec says nothing about it being deprecated. The reason <param> is nice is that it provides information about the type of data contained inside.
    It's not deprecated. It's just that 1.4 is different enough, due to strong typing in the schema, that 1.3 uses of <param> are largely gone. The meta data associated with weakly typed elements (e.g. <param>) has moved from each and every instance document into the schema, where it belongs. Instance documents will be a little bit smaller as a nice side-effect.
    Quote Originally Posted by sthomas
    So apps like SoftImage that want to provide a gui for this data can do a better job. A string gets a text box, a bool gets a check box, etc. That doesn't actually require <param> of course... it just requires a standard way of specifying the type of data contained inside the <extra> block.
    Exactly! The <extra> element is designed for this usage. It has a type attribute and techniques so that all kinds of information can be added.

  5. #15
    Senior Member
    Join Date
    Jan 2006
    Location
    Foster City, CA
    Posts
    540
    Quote Originally Posted by marcus
    Exactly! The <extra> element is designed for this usage. It has a type attribute and techniques so that all kinds of information can be added.
    Ah, of course. For some reason I thought <extra> didn't have a way of specifying the type of data contained inside, and thus that it was advantageous to use <param>. My mistake.

    Ok, I think that all my questions have been answered, and I want to thank everyone who contributed to the discussion. Due to the current dcc tool limitations with respect to custom data and the lack of Collada support in Lightwave, Collada probably isn't an ideal format for us at the moment. However I'm very encouraged by Collada (the design is remarkably elegant imo), and I do think we'll be adopting it at some point in the future. I hope that I raised awareness of the desirability for custom data persistence in the dcc tools.

    Thanks,
    Steve

Page 2 of 2 FirstFirst 12

Posting Permissions

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