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

Thread: Scene Node Matrix

  1. #1

    Scene Node Matrix

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

    Code :
      <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

  2. #2

    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:
    Code :
          <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:
    Code :
          <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

  3. #3
    Senior Member
    Join Date
    Mar 2016
    Posts
    106
    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.

  4. #4
    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.

  5. #5
    Quote Originally Posted by recpas View Post
    My lib supports any coord sys including RH.
    EDIT: I meant including LH

  6. #6
    Senior Member
    Join Date
    Mar 2016
    Posts
    106
    3-D math can be quite complicated. Using C doesn't generally make it easier 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.

  7. #7
    I wrote a 3D Math lib for C, it is fast and easy to use I think, the link is: https://github.com/recp/cglm, 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

  8. #8
    Senior Member
    Join Date
    Mar 2016
    Posts
    106
    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.

  9. #9
    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)

  10. #10
    Good luck, and please watch COLLADA-DOM over the coming year.
    I've subscribed to this project on SF, thanks

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
  •  
Proudly hosted by Digital Ocean