Assimp in C# - abnormal number of Meshes by creation of non-existent Meshes with partial data from existing ones

Help
2014-01-17
2014-01-25
  • rbaleksandar

    rbaleksandar - 2014-01-17

    Hi all!

    Currently I'm working on a project in C# that needs Collada support. Assimp (C# version) seems to be the best choice out there so far but it's far from perfect. The <library_nodes/> is missing (it's not stored and maybe not parsed at all; not to mention the fact that parsing 1.5 document that includes 1.5 elements not present in 1.4 results in exceptions so I'm forced to copy portions of my 1.5 version of the document, and pasted+adjust them to the 1.4 version) and since I need it (I need the transformation (translate/rotate) data stored in each node that references some geometry in the <library_geometries>) I decided to add it by creating a new class for a custom AssimpScene called AssimpCustomScene (sadly inheritance of Assimp.Scene seems to be impossible) that additionally parses the above mentioned library with nodes. During testing I discovered a really strange behaviour from Assimp that does not involve any piece of my own code (my AssimpCustomScene contains an Assimp.Scene object and the additional objects for the data I need). So here is the problem - my document (created using OpenRAVE's Collada exporter and narrowed down to 1.4 (deleted for example the <library_kinematics_model>) since OpenRAVE creates 1.5 documents) contains 7 geometries with each (conform with the Collada 1.4/1.5 standards) containing a single mesh so overall I have 7*1=7 meshes. Still Assimp.AssimpContext.ImportFile() returns a scene that contains 10 meshes. After an hour or so of investigating I discovered that Assimp creates some weird mesh-artifacts. For example my third mesh in the document contains 17786 faces. BUT in Assimp this mesh is subdivided for some reason and my third mesh gets 10 faces and my fourth - 17776 (=17786-10). Mind also that this does NOT happen to all meshes! The number of faces "taken away" also seems to be random (I have 3 mesh-artifacts: one with 10, another with 6 and the third with 16 faces; unless we have 10+6=16 I don't see the connection here). Last but not least I have managed to display the Assimp.Scene object using OpenTK. However even though this is working this strange partitioning is a pain because I need the data to be coherent with the document I'm importing.

    Can you please help me. I've looked and keep looking but I cannot see where this behaviour might be coming from. I can only provide part of the XML I'm working with if it's needed.

    Best regards,
    RBA

    PS: It would be nice to make elements' id and reference (if present) visible outside for readonly access. This will help a lot if references are to be analysed and will spare the developer some parsing to gain this information, which is obviously already parsed and used by Assimp internally.

     
    Last edit: rbaleksandar 2014-01-17
  • rbaleksandar

    rbaleksandar - 2014-01-17

    The question with the mesh still remains but after a couple of hours of digging I found out that the exporter of Assimp actually does store the transformation-information for each geometry in the < library_visual_scenes /> in each < visual_scene /> element under the somewhat obscure (for me at least) RootNode. The RootNode contains a Children-list and each Children there (= < node />-element) can contain another such children-list.

     
    Last edit: rbaleksandar 2014-01-17
  • Thomas Ziegenhagen

    You might have noticed that all XML tags are missing from your initial post. So I don't see what your problem is. Assimp is NOT a Collada loader, it's a generic 3D scene loader which happens to support Collada. And as such needs to perform a lot of processing to fit 30+ file formats into a common data structure. For example it needs to split up meshes into groups with a single material each. This is where your additional meshes come from, I'd guess.

    And yes, you can't derive from aiScene. It's a C++ class, so it's probably not suitable to be a base class in C#. And yes, nodes are important. Read them or ignore them at your own peril.

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks