open collada 1.4 files

[rdiankov]

with the new collada-dom 2.4, it is now possible to create a parser for collada 1.4 files reusing the 1.5 parser (should be templated?)

[mkoval]

What exactly does this mean? I'm willing to take a crack at this if it will let qtcoin load COLLADA 1.4 files.

I'm trying to load the same DAE render geometry into both qtcoin (which only supports COLLADA 1.5) and RViz (which only supports COLLADA 1.4). It's a pain to generate twos sets of files that only differ by a version numbers just to satisfy a version compatibility check.

[rdiankov]

i agree!! in the latest collada-dom library, i've already set it up so you can load both 1.4 and 1.5 files from the same library by dividing it into namespaces

ColladaDOM150 ColladaDOM141

(in the past it used to be the compiled shared object only supported one).

i just started a new branch collada14 in openrave for adding collada 1.4 support.

https://github.com/rdiankov/openrave/commit/52b2d95a2c288c922285749c6f3f4858a5ce2cf6

the idea is to compile colladareader.cpp twice: one for 1.5 and one for 1.4 support. Because of gcc'isms i've created two files colladareader141.cpp and colladareader150.cpp that set the right define and include colladareader.cpp. In colladacommon.cpp is where the version checking happens. First we try to open with the 1.5 reader, and if that throws an exception, try with the 1.4 reader.

Where you could definitely help is making colladareader.cpp compile with 1.4 headers. Use the following define to check what version currently compiling with

ifdef OPENRAVE_USING_COLLADA141

good luck!

[mkoval]

I looked into the problem a bit more and actually think it is an unrelated issue with qtcoin.

I'm loading a .kinbody.xml file that references external COLLADA 1.4 geometry (i.e. .dae files) using the <Data> and <Render> tags. In most cases, the render and collision meshes are exactly the same. None of the render geometry shows up in qtcoin. However, collision geometry loads fine and displays correctly if I enable "View > Geometry > Collision Only".

The geometries comprising the KinBody have correct GetRenderFilename(), so this must be an issue with how qtcoin loads COLLADA files. I'll take a look at the source and try to figure out what's going on. Any suggestions?

[mkoval]

It looks like qtcoin only supports loading wrl, iv, and vrml files, judging from this line in item.cpp. I previously had to add stl to this list to get qtcoin to render STL geometry.

Unfortunately, the same trick doesn't work for COLLADA because mySceneInput.openFile throws an error (likely because it doesn't support loaded COLLADA files). I am considering adding another cases that loads the mesh using ReadTriMeshURI and renders it using the same logic as the collision geometry.

Does that make sense?

[rdiankov]

you'll notice that if !bSucceeded, then it will render each geometry using the collision data. So STL files should also be rendered...

[mkoval]

You're right. However, DAE and STL files are still not rendering. :(

It turns out that this is caused by the "quirky" models I describe in #281. We need to attach multiple render-only meshes to a single link. This isn't directly possible because each geometry can only specify one _filenamerender. We hacked around this by generating additional <Geom> entries for the render geometry and assigning them empty collision geometry (a zero-radius sphere). qtcoin is falling back to render that empty geometry.

I'm going to proceed with the fix I described above. In the long term we should switch to using separate geometry groups for render/collision geometry, like you suggested in #281, but they're simply not well enough supported at this point.

[rdiankov]

that's a good point. just be careful since some coin3d versions don't support STL. haven't forgot about #281, the changes should be pretty simple though..

[mkoval]

Is there any way to test at compile time if qtcoin supports STLs? If not, I can fall back on ReadTrimeshURI for STL files as well.

It would be relatively easy to add geometry group support to qtcoin. I'm more nervous about loading geometry groups from a .kinbody.xml file (we don't construct all of our models programmatically). It's doable, but it would leave OpenRAVE in an awkward state where there are two different ways of specifying render geometry.

[rdiankov]

i'm not sure. perhaps the coin3d open function will gracefully fail and we can catch it?

i think it's fine if we take the strategy of prioritizing "render" groups. If a "render" group exists, then any other render flags are ignored. we will have to add the group name to the tag when parsing the xml. you should be able to do do this in src/libopenrave/xmlreaders.cpp GeometryInfoReader class