Page 1 of 2 12 LastLast
Results 1 to 10 of 19

Thread: Writing with COLLADA-DOM?

  1. #1
    Junior Member
    Join Date
    Feb 2005
    Posts
    4

    Writing with COLLADA-DOM?

    Hi, my name is Chris Hanson, with 3D Nature. We make the World Construction Set and Visual Nature Studio 3D landscape rendering and animation products. We've kept an eye on COLLADA for a while, since the SIGGraph debut a few years ago, but we've never implemented support for it.

    We've been sort of forced into it at this point because Google Earth adopted COLLADA as their 3D object format in their latest version 4. We have a Google Earth KML exporter as part of our Scene Express add-on.

    We've been looking at COLLADA-DOM library for a couple weeks, trying to get a grasp on how to use it. Frankly, it's scary.

    We have yet to successfully get a simple textured box written out. We're still mired in thousand-line demo programs that are concerned with asset databases and derived templates and lots of seriously deep stuff.

    I'm really concerned that COLLADA-DOM is impractical for most developers to support. Doing anything basic with the library seems so complex that one has little idea where to start. We've implemented uncounted 3D object format readers and writers in my programming lifetime, but never anything as top-heavy as COLLADA.

    Equally worrisome is that each edition of the library seems incompatible with the previous one. The docs even suffer the problem -- we found numerous places where the docs refer to some technique that we later find is deprecated or even removed from the current library.

    Are we missing something here? It seems like COLLADA is a great idea for object interchange between game developers with industrial-strength needs for asset management, shaders, complex bone and constraint requirements and such. For anyone who doesn't have an entire XML-compliant development team to dedicate to it, it sort of looks like an elephant designed by committee.

    At this point, we're looking at just taking some COLLADA sample files and hand-writing the XML ourselves by printf. It would probably make our exporter considerably faster and keep several megabytes of code size off of our application. I'm dreading the day when we need to read COLLADA files.

  2. #2
    Member
    Join Date
    Aug 2004
    Location
    Feeling Software, Montreal, QC, Canada
    Posts
    36
    You should consider FCollada, which is an open-source library created by our company, Feeling Software. It is designed for backward compatibility and is already in use in many applications, including ColladaMaya, ColladaMax, the Feeling Viewer, and Epic's Unreal Engine 3, in addition to several confidential projects for our other customers. It supports import and export, and is generally higher level than the DOM.

    http://www.feelingsoftware.com/content/ ... 3/lang,en/

    There are a few samples available with it, and lots of additional "sample" code in ColladaMaya and ColladaMax.

    We also offer consulting services should you need help with supporting COLLADA in your application.
    Christian Laforte
    President, Feeling Software
    http://www.feelingsoftware.com

  3. #3
    Junior Member
    Join Date
    Feb 2005
    Posts
    4
    We had glanced at FCollada before, but didn't see anything that looked like an object-writng demo, so I wasn't even sure if FCollada was a write or just a reader. The FCollada page didn't really say either, so we moved on to looking at the COLLADA-DOM.

    Is there some sample source anywhere that shows FCollada being used to write something like a cube, start to finish?

    Also, (directed to the larger COLLADA community, not FCollada specifically) what is the purpose of COLLADA-DOM if it's unusably complex? Is anyone using it?

  4. #4
    Member
    Join Date
    Aug 2004
    Location
    Feeling Software, Montreal, QC, Canada
    Posts
    36
    FCollada is evolving quickly. It used to only support import, until about a month ago. ColladaMaya is now using FCollada for export too. We don't have that much sample code, because our primary concern is to make FCollada as powerful as possible for our primary applications and for our paying customers.

    Good luck,

    Christian
    Christian Laforte
    President, Feeling Software
    http://www.feelingsoftware.com

  5. #5
    Senior Member
    Join Date
    Jan 2006
    Location
    Foster City, CA
    Posts
    540
    Quote Originally Posted by Xenon
    Also, (directed to the larger COLLADA community, not FCollada specifically) what is the purpose of COLLADA-DOM if it's unusably complex? Is anyone using it?
    I'm using it. IMO it isn't unusably complex. It is complex, but the complexity is due to all the features it supports and all the little niceties it provides you. Here's some of the stuff you get (these examples are geared toward reading Collada, as I've only written a reader so far):
    • - No manual xml or text parsing at all. For example a <float_array> element maps to an array of C++ float values, without you having to do anything.
      - A complete mapping of every element in Collada to a C++ object. The DOM provides you access to everything in Collada.
      - Automatic reference resolution. I don't have to try to find what element "#myVertices" is referring to. The element being referred-to can even be in a totally separate xml document... the DOM just takes care of these things.
      - The concept of a Collada database to provide efficient query support. Want to loop over all the <mesh> elements in a Collada document but don't feel like finding them all yourself? This is very easy to do with the DOM. I've worked with APIs that don't provide support for this sort of thing, and it's a huge PITA. All information is cached to make the queries very efficient, and great care is taken to ensure that the cache remains synchronized with the actual Collada elements.
      - An integration library to make it easy to convert from Collada to your format/runtime.
    The cost of reducing the complexity of the DOM is sacrificing some of the features mentioned above. All of those features are worthwhile so I don't have a problem with the DOM's level of complexity.

    Having said that, it's the schema that defines Collada and not the DOM. What I mean by that is that it's perfectly valid to use other libraries such as FCollada, or your own custom code, to work with Collada. As long as it conforms to the schema it's valid Collada.

    Quote Originally Posted by Xenon
    I'm really concerned that COLLADA-DOM is impractical for most developers to support. Doing anything basic with the library seems so complex that one has little idea where to start.
    If you have specific questions/issues, feel free to ask. I'm sure someone will help you out. However there is a forum specifically for the Collada DOM, so it might be better to post there.

    Quote Originally Posted by Xenon
    We have yet to successfully get a simple textured box written out.
    If you're still having problems with this I can code up a working example that demonstrates this for you, sometime tonight or tomorrow.

    Quote Originally Posted by Xenon
    Equally worrisome is that each edition of the library seems incompatible with the previous one. The docs even suffer the problem -- we found numerous places where the docs refer to some technique that we later find is deprecated or even removed from the current library.
    I can't speak about the backward compatibility issues, but I definitely agree that there were many inconsistincies between the spec and the schema/DOM, and this was pretty annoying. However 1.4.1 was just released, and every issue/inconsistency I've encountered with the 1.4 spec has been fixed.

  6. #6
    Junior Member
    Join Date
    Feb 2005
    Posts
    4
    I'm not opposed to depth and capability in the COLLADA-DOM, what we found frustrating is that there's really no where for a COLLADA novice to start. Really, we don't want to learn about the amazing powers of the schema and stuff, we just want to add COLLADA support to an existing application. I expect there will be more and more people following down this road as COLLADA becomes more commonplace. I'm thrilled that there might someday be a decent replacement for the mishmash of object interchange via legacy formats like 3DS, OBJ, etc. And don't get me started on FBX...

    Maybe it's just that the COLLADA-DOM project isn't mature to the point where the introductory documentation is there yet. I work on the OSG (OpenSceneGraph) project, and that was an issue we suffered for a long time -- great code, but beginners were lost without a lot of demos.

    I don't want to make somebody go out and hold my hand and write a custom demo for me, but I was hoping such an example was already available. So far I can't find anything that shows how to do a simple task like writing a basic geometry. At the moment we're prototyping a writer that just blasts out xml by printf. Not pretty, but a lot less prep work -- our Google Earth KML exporter works the same way.

    So, opinion survey: Under what circumstances should one use the DOM and where would you recommend FCollada instead?

  7. #7
    Senior Member
    Join Date
    Jan 2006
    Location
    Foster City, CA
    Posts
    540
    I definitely agree that it'd be nice to have more tutorials and introductory documentation. I think the key thing is to make sure you fully understand the spec/schema. If you have your head firmly wrapped around that then the DOM becomes obvious. But yeah, the spec/schema definitely don't count as introductory documentation.

    Also, the DOM programming guide has a brief section on how to create Collada documents from scratch, but it doesn't cover setting up geometry unfortunately. Geometry is pretty complex in Collada due to all the levels of indirection involved. I found that sketching out on a piece of paper the structure of e.g. the <mesh> element helped me understand things more clearly.

    Regarding FCollada vs the DOM, I've never used FCollada so I can't comment, but this topic has been discussed a few times before.

  8. #8
    Junior Member
    Join Date
    Feb 2005
    Posts
    4
    I think we can conclude we have different mindsets on the issue.

    Your goal is to be familiar with all things COLLADA, and that's fine. But you must understand that a large number of COLLADA implementors will not wish to become experts on COLLADA and fully understand the spec and the schema and get their head firmly wrapped around it.

    I would guess that fully understanding the spec/schema could take a single programmer several months, based on our initial forays into it.

    We already support something like 100 different file formats (3d, GIS, etc). Many developers will be in a similar situation where they won't have the time to dedicate to becoming a COLLADA Jedi. They're just tasked to implement support for COLLADA and move on to the next file format in a seemingly endless uphill battle to stay current with the data storage norms du jour.

    Just be aware that not all developers will have the same motivations as you.

  9. #9
    Senior Member
    Join Date
    Jul 2004
    Location
    Santa Clara
    Posts
    356
    In that case it is probable that FCOLLADA is a better choice for you, it should make it easier for you to use COLLADA without having to understand all the details.

    Another solution is not to develop your own exporter/importer, but to contract it to Feeling Software, or other COLLADA Jedi contractors.

    Let's hope that in the future you will have less formats to support and have time to become a COLLADA Jedi and enjoy the power of the DOM


  10. #10
    Senior Member
    Join Date
    Aug 2004
    Location
    California
    Posts
    771
    Quote Originally Posted by sthomas
    However 1.4.1 was just released, and every issue/inconsistency I've encountered with the 1.4 spec has been fixed.
    That's good to hear since we had been working towards achieving that goal!

Page 1 of 2 12 LastLast

Posting Permissions

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