Page 1 of 3 123 LastLast
Results 1 to 10 of 22

Thread: Collada DOM Integration Templates

  1. #1
    Senior Member
    Join Date
    Jan 2006
    Location
    Foster City, CA
    Posts
    540

    Collada DOM Integration Templates

    We're approaching the next release of the Collada DOM, and we're considering taking out the integration templates. They're not particularly useful and I've always recommended that people avoid them. In fact it's somewhat unfortunate that they were ever included in the DOM. If you use these classes, please reply to this post.

  2. #2
    Member
    Join Date
    Dec 2007
    Location
    Costa Rica
    Posts
    42
    I am currently using them to write a Blender Importer, is integration going to be phased out altogether or is there going to be a replacement for it?

  3. #3
    Senior Member
    Join Date
    Jan 2006
    Location
    Foster City, CA
    Posts
    540
    Sorry for taking so long to reply. I've been away on vacation a while.

    The current thought is to remove the integration objects entirely. In fact I've already removed them from the latest code in the svn repo on SourceForge, but that doesn't reflect a final decision or anything; it'd be easy to put them back in.

    The only useful thing the integration templates provide that I'm aware of is the ability to map from a dom* object to your custom object. So if you have an integration class for <node>s, you can easily take a domNode object after loading a document and lookup your corresponding intNode integration object. But it turns out that this is really easy to do yourself. It's really just as easy as using the integration objects was, and allows greater flexibility and control over when things get converted.

    The most common use case for the integration templates is to register your integration objects, load a document (after which your integration objects will be created), then traverse the dom* element hierarchy pulling in the data in your custom integration objects. I've written a sample program (part of the DOM's automated test suite) that demonstrates how you can do the same thing without the integration objects.

    I suggest you take a look at the code in the link. The point I'm trying to make is that the integration objects really weren't all the helpful in writing an importer. What do you think?

    Steve

  4. #4
    Senior Member
    Join Date
    Jan 2006
    Location
    Foster City, CA
    Posts
    540
    I am currently using them to write a Blender Importer
    Is this associated with the importer currently maintained by Illusoft, or is this a completely independent effort?

  5. #5
    Member
    Join Date
    Dec 2007
    Location
    Costa Rica
    Posts
    42
    Quote Originally Posted by sthomas
    I am currently using them to write a Blender Importer
    Is this associated with the importer currently maintained by Illusoft, or is this a completely independent effort?
    It is a completely independent effort, I plan on making it available under a MIT license or similar once it is mature enough, its publicly accessible from my SVN server at http://svn.aeongames.com/svn/BlenderCollada/trunk/.

    If you're wondering why I didn't extended Illusoft's plug in, its because I am not that proficient as a Python programmer and they manually parse the DAE XML using Python's built in expat, I rather not deal with DOM code .

    [nevermind this]
    So, I take it you're taking out the templates but not integration, meaning I would have to implement the integration interface from scratch, may I ask what is it that makes the templates so bad so I can avoid it?
    [/nevermind this]

    Edit: I read only your last post before realizing there was already a previous more extensive one.

    Thanks

  6. #6
    Member
    Join Date
    Dec 2007
    Location
    Costa Rica
    Posts
    42
    Quote Originally Posted by sthomas
    I suggest you take a look at the code in the link. The point I'm trying to make is that the integration objects really weren't all the helpful in writing an importer. What do you think?
    I agree, I started copying over files for pretty much any element I needed, and in the end I had to take out a lot of them and move their code to the topmost parent element (this after I found that I had a mesh object but no vertices in it at the time of processing a skin element).

    Right now I do think I should be able to move everything out of the templates without too much of a problem, the thing I did find useful though was the way you keep references to the application objects in the void* _object property, so no need to look them up or keep a separate database.

    Perhaps a similar property (just a setter and a getter for it) could be added to domElement just to keep the application object and element linked (if there isn't already one there).

  7. #7
    Senior Member
    Join Date
    Jan 2006
    Location
    Foster City, CA
    Posts
    540
    I agree, I started copying over files for pretty much any element I needed, and in the end I had to take out a lot of them and move their code to the topmost parent element (this after I found that I had a mesh object but no vertices in it at the time of processing a skin element).
    That's another weird thing about the integration templates. There's one integration class provided for each Collada element, and it encourages programmers to use an integration class for each element they want to import. Then you end up with a mess of integration classes with complex interdependencies that make initialization difficult.
    Right now I do think I should be able to move everything out of the templates without too much of a problem, the thing I did find useful though was the way you keep references to the application objects in the void* _object property, so no need to look them up or keep a separate database.

    Perhaps a similar property (just a setter and a getter for it) could be added to domElement just to keep the application object and element linked (if there isn't already one there).
    That could be done. A developer would still do the hierarchy traversal and user-object conversion work himself, but he wouldn't have to do the lookup tables. But then object lifetime becomes an issue. Would the application object just be a void*? Then users have to manage object lifetime themselves, and make sure they free up any allocated application objects at the appropriate time. Traditionally the integration objects have always been reference counted, so developers didn't have to think about it. When a developer writes their own lookup table (like I did in the sample program) it's obvious that he has to take care of cleaning up the objects when he's done. Or instead of a void* we might have a pointer to a user-settable daeRefCountedObj in each daeElement. That way users wouldn't need to consider object lifetime, but they'd have to derive all their objects from daeRefCountedObj.

    Writing a lookup table really isn't difficult though, so I'm not sure if it's necessary to have a pointer to a user-object at all.

  8. #8
    Member
    Join Date
    Dec 2007
    Location
    Costa Rica
    Posts
    42
    Quote Originally Posted by sthomas
    Writing a lookup table really isn't difficult though, so I'm not sure if it's necessary to have a pointer to a user-object at all.
    I just think it would be a "nice to have" for the times where you need URIs, for example skins reference geometry objects, it would be nice to do things like (not accurate, but you get the idea):

    localgeomobject* geom = (localgeomobject*) skin->getGeometry()->getUserObject();

    rather than go through a lookup table after you've dealt with the geometry and mesh retrieval, void* does seem a little crude, but it really lets the user make it anything they need, of course, I am not advocating code like:

    domElement->setObject(new localgeom);

    but rather something like say:

    std::vector <localgeom> geoms;
    ...
    localgeom geom;
    /* fill geom */
    geoms.push_back(geom);
    domElement->setObject(&geoms.back())

    so it really works out as a link between the two.

    I am just throwing ideas here.

  9. #9
    Senior Member
    Join Date
    Jan 2006
    Location
    Foster City, CA
    Posts
    540
    In your example, if you change
    Code :
    std::vector <localgeom> geoms;
    to
    Code :
    std::map<domGeometry*, localgeom> geomTable;
    then you basically have the lookup table. Then the line
    Code :
    localgeom* geom = (localgeom*) skin->getGeometry()->getUserObject();
    would instead be
    Code :
    localgeom& geom = geomTable[skin->getGeometry()];
    That doesn't seem any more or less difficult then using a void* pointer embedded with the daeElement.

    But still, I can understand why some people would want to do it with custom data attached to each daeElement. I think I'll put in some setUserData/getUserData methods which just deal with void*s.

  10. #10
    Member
    Join Date
    Dec 2007
    Location
    Costa Rica
    Posts
    42
    You're right, and perhaps I am being too pedantic but what I am really thinking is that the std::map lookup is O(log n) which is very good, but keeping the reference in the object itself is O(1), which is better. There may not be much performance gain there, or there could be a lot, we need benchmarks for that.

    Anyway, I'll just wait to see that the final saying is for the next stable version and change my code accordingly then the time comes.

    Thanks .

Page 1 of 3 123 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
  •