Scene Node Matrix

Does COLLADA standards allow to both camera and geometry instance presence in same node with single/same matrix?


  <library_visual_scenes>
    <visual_scene id="Scene" name="Scene">
      <node id="Camera_001" name="Camera_001" type="NODE">
        <matrix sid="transform">1 0 0 0 0 -4.37114e-8 -1 -20 0 1 -4.37114e-8 0 0 0 0 1</matrix>
        <instance_camera url="#Camera_001-camera"/>
        <instance_geometry url="#Suzanne_001-mesh" name="Suzanne"/>
      </node>
    </visual_scene>
  </library_visual_scenes>

Is this valid?

I’m working on a COLLADA parser and if this is valid then I’ll create a separate matrix for camera instance so there will be two matrix, one for model and one for view

I’ve an approach to fix my issue;

I’ll create a new node for camera with same matrix/transform and apply extra necessary rotation when parsing

Original:


      <node id="Camera_001" name="Camera_001" type="NODE">
        <matrix sid="transform">1 0 0 0 0 -4.37114e-8 -1 -20 0 1 -4.37114e-8 0 0 0 0 1</matrix>
        <instance_camera url="#Camera_001-camera"/>
        <instance_geometry url="#Suzanne_001-mesh" name="Suzanne"/>
      </node>

Converted when parsing:


      <node id="Camera_001" name="Camera_001" type="NODE">
           <node type="NODE">
               <matrix sid="transform">1 0 0 0 0 -4.37114e-8 -1 -20 0 1 -4.37114e-8 0 0 0 0 1</matrix>
               <instance_camera url="#Camera_001-camera"/>
           </node>

           <matrix sid="transform">1 0 0 0 0 -4.37114e-8 -1 -20 0 1 -4.37114e-8 0 0 0 0 1</matrix>
           <instance_geometry url="#Suzanne_001-mesh" name="Suzanne"/>
      </node>

this seems what I need and fixes my problem,
the new node will lost previous id, sid and name this may cause some issues but node.camera = newnode.camera (pointer) probably will fix this

if anyone has better idea I’d like to hear it

It’s valid to have multiple instance_camera and instance_geometry children under the node. They just have to be back-to-back, and in the correct order. Writing parsers by hand is one reason COLLADA has been slow to gain acceptance, and is arguably dead in the water.

I am in need of something like COLLADA–a public 3-D file format–so I’ve been working toward making it a viable technology all of this year, and am trying to reignite interest in it. I am finishing a rewrite of the COLLADA-DOM library right now. It generates correct C++ classes for everything in the schema, and lets you work without regard for ordering. The new version on the way is very slick if you can use C++. There’s also OpenCOLLADA, which isn’t really COLLADA, but something that reads and writes COLLADA files, so it’s a conversion library that you have to learn either by itself, or in addition to COLLADA.

Hi Mick,

thanks for your answer,

I’m writing this library in C99 which is almost finished parsing (except animation and MathML) and writing a viewer/renderer to validate my progress.
My lib supports any coord sys including RH, so I’m converting all transforms (marices, rot, scale, trans…) after parsing node to new coord sys,
All new model transforms converted correctly to new coord sys except camera orientation.
Camera in Z_UP looking toward -Z, but -Z is -Y in Y_UP so I must apply extra rotation for camera after converted transfroms to new coord sys,
because:

If camera[s] and geom[s] exist in same node with same matrix then a big problem occours:

  • I cant rotate transform for camera because the transform is correct for geometry (because it is alreay converted to new coord sys)
  • I cant use directly because camera needs be rotated to old -Z direction to get same view matrix

I solved this by separating camera to new node (make sure all cameras have unique node) and append new rotation element (during parsing) or rotate matrix directly (if only matrix exists). Now everthing looks perfect

Since I’m parsing by exported order it must be work fine, I think

AFAIK OpenCOLLADA also generates C++ classes using COLLADA scheme but it seems very complicated to me
Also I can use C++/C++11 very well but I like C more than C++.

In the FUTURE I may interest in generate C parser for COLLADA XSD, not bad idea, but not for now.

[QUOTE=recpas;41376]My lib supports any coord sys including RH.[/QUOTE] EDIT: I meant including LH

3-D math can be quite complicated. Using C doesn’t generally make it easier :slight_smile: But this isn’t really a problem to do with COLLADA. XML is very complicated. I don’t think C can make it easier. It can only parse strings and things, and that’s just not productive. I mean, maybe it can at least pass type-safe structures around, I don’t know, but it seems like it would be difficult to maintain.

I wrote a 3D Math lib for C, it is fast and easy to use I think, the link is: GitHub - recp/cglm: 📽 Highly Optimized Graphics Math (glm) for C, my COLLADA/glTF library uses this lib

I’m trying to make it easier due to this, I’m writing a renderer before switch to next phases (anim, kinematics…),
Lib looks very nice/neat and will support full COLLADA (including external URL ref, ZAE (compressed DAE) ) and glTF (after COLLADA) specs

Also I’m writing a renderer library top of this lib, for instance users can load COLLADA geometry or all nodes (scene) to OpenGL VAOs with single call, this is actually almost finished
I’m planning to publish my COLLADA lib on Github (or Bitbucket) under MIT or BSD after initial public release

I just meant C is procedural. And it doesn’t have namespaces. So it’s difficult to find your way around a big maze like schema. Same for math, like implementing a vector or matrix library with C. There is an art in writing exported APIs in C for binding purposes. I just don’t know how much of the world still cares about it. It’s usually used for linear programming and other very shallow things that require transparency.

The COLLADA-DOM library has a renderer and things, that I haven’t even looked at. They are just part of the project, but part that had been broken for years on the SF.net hosted repository. Broken because the core-library was made to no longer compile against them. There’s definitely a need for opensource-like quality implementations for COLLADA. If you can do anything good with C, you’ll require C++ wrappers, or only 1 out of 100 programmers will give it a look. Good luck, and please watch COLLADA-DOM over the coming year.

PS: I’m working on an alternative to Blender that will be called Daedalus. It’s not my main interest. But what I am involved with needs support on the art side of things. It’s focus is on art and art preservation. It combines rewrites of COLLADA-DOM and Open Asset Import Library (Assimp.) Presentation wise it’s like a COLLADA/XML browser. Dusting off COLLADA-DOM has been a major job. I thought afterward I could clean up the renderer side of the project, and then maybe parley that into the beginnings of Daedalus, or at least get the DOM library up on two feet. It’s possible you could contribute your work to this effort. It might be just the thing. Daedalus may end up related to Khronos somehow. Name wise they seem like a good fit don’t they? Anyway, Daedalus built the labyrinth. I’m very focused on making working with COLLADA productive. That’s why I value C++ so, since you can use it to feel your way around “the labyrinth,” whereas C can’t help you there.

Thanks for sharing about your project

I wasnt aware of COLLADA-DOM when started this project, I was considering to write C++ wrappers (especially iterators), but currently I dont care a lot about wrappers, I’m focused to finish and implement all (or almost all) specs. Writing wrappers is not to hard, once project has finished wrappers or entirely new C++ lib can be written on top of this.

My actual goal was writing modeling/animation (write with C or some C++) software and I started my journey with writing asset lib and asset viewer / renderer application (asset manager including preservation like yours). My lib is AssetKit (based on COLLADA 1.5 specs) which is sub-lib of actual project[s] and I will publish the lib and maybe will do the same for other libs (not entire app)

Good luck, and please watch COLLADA-DOM over the coming year.

I’ve subscribed to this project on SF, thanks

Just FYI, I finished the last bit of code in the first draft of the COLLADA-DOM rewrite yesterday. I will post in the SF.net forum very soon with a snapshot of the source code. It’s a very ambitious project that does a lot of unique things, that may possibly even never been seen before. It ought to be, it’s taken me months to complete!

No offense, but I bet you’re a young guy right? You’ve got a lot of young guy energy anyway. We’ve all been there. I consider this very basic stone age work, laying the ground work for a public standard for 3-D graphics. For 3-D files and things, there’s not anything that is free of proprietary smells. Autodesk has consolidated everything since COLLADA was first introduced. I think that’s kind of taken the winds out of the sails of the people who began it. But I don’t know if they began it out of love, or if Sony just chose to put them on the project. That’s the problem with big budget commercial software. A loveless relationship is a bad way to write software that is the information substructure for the future of humanity.

BTW: Here (COLLADA Document Object Model (DOM) / Discussion / Open Discussion: 2016: HERE is a download with the sources I've worked on for months now.) is the link, with the updated COLLADA-DOM development snapshots. Hot off the presses. You may’ve received a copy by mail if your SF.net settings did that automatically. If not you can follow my progress by further subscribing to receive Forum posts by email.