When running ColladaConv (from SVN Nov 9 2010) on an OpenCollada 1.2.5 R 673, I get the following error message:
Enter arguments: a10.DAE
Horde3D ColladaConv - 1.0.0 Beta5
Processing MODELS - Path: a10.DAE
Parsing dae asset 'a10.DAE'...
Compiling model data...
Warning: Node with name '' already exists. Node was renamed to '_2'.
Warning: Node with name '' already exists. Node was renamed to '_3'.
Warning: Node with name '' already exists. Node was renamed to '_4'.
Warning: Node with name '' already exists. Node was renamed to '_5'.
Warning: Node with name '' already exists. Node was renamed to '_6'.
Warning: Node with name '' already exists. Node was renamed to '_7'.
Warning: Node with name '' already exists. Node was renamed to '_8'.
Warning: Node with name '' already exists. Node was renamed to '_9'.
Warning: Node with name '' already exists. Node was renamed to '_10'.
Warning: Node with name '' already exists. Node was renamed to '_11'.
Warning: Node with name '' already exists. Node was renamed to '_12'.
Warning: Node with name '' already exists. Node was renamed to '_13'.
Warning: Node with name '' already exists. Node was renamed to '_14'.
Warning: Node with name '' already exists. Node was renamed to '_15'.
Warning: Node with name '' already exists. Node was renamed to '_16'.
Warning: Node with name '' already exists. Node was renamed to '_17'.
Warning: Node with name '' already exists. Node was renamed to '_18'.
Warning: Node with name '' already exists. Node was renamed to '_19'.
Warning: Node with name '' already exists. Node was renamed to '_20'.
Warning: Node with name '' already exists. Node was renamed to '_21'.
Warning: Node with name '' already exists. Node was renamed to '_22'.
Warning: Node with name '' already exists. Node was renamed to '_23'.
Warning: Node with name '' already exists. Node was renamed to '_24'.
Warning: Node with name '' already exists. Node was renamed to '_25'.
Warning: Node with name '' already exists. Node was renamed to '_26'.
Warning: Node with name '' already exists. Node was renamed to '_27'.
Warning: Node with name '' already exists. Node was renamed to '_28'.
Warning: Node with name '' already exists. Node was renamed to '_29'.
Warning: Node with name '' already exists. Node was renamed to '_30'.
Warning: Node with name '' already exists. Node was renamed to '_31'.
Warning: Node with name '' already exists. Node was renamed to '_32'.
Removed 9 degenerated triangles from mesh
Warning: Geometry has zero-length basis vectors
Maybe two faces point in opposite directions and share same vertices
In running the debugger, it appears that the problem is that the DAE file has some meshes with children with empty names. These are the bad meshes that either don't appear in the game engine or are locally translated in space (so appear detached from the model, e.g. hair close to the foot)
Below is an example of the xml from the <library_visual_scenes> <visual_scene id="MaxScene"> section of the dae file:
Code:
<node id="node-rToe" name="rToe">
<instance_controller url="#geom-rToe-skin1">
<skeleton>#node-Bip01_Pelvis</skeleton>
<bind_material>
<technique_common>
<instance_material symbol="Material__60" target="#Material__60-material">
<bind_vertex_input semantic="CHANNEL1" input_semantic="TEXCOORD" input_set="1"/>
</instance_material>
</technique_common>
</bind_material>
</instance_controller>
</node>
<node id="node-eyeL_hi" name="eyeL_hi">
<node>
<matrix>1 0 0 0 0 1 0 0 0 0 1 0.6319538 0 0 0 1</matrix>
<instance_controller url="#geom-eyeL_hi-skin1">
<skeleton>#node-Bip01_Pelvis</skeleton>
<bind_material>
<technique_common>
<instance_material symbol="Material__60" target="#Material__60-material">
<bind_vertex_input semantic="CHANNEL1" input_semantic="TEXCOORD" input_set="1"/>
</instance_material>
</technique_common>
</bind_material>
</instance_controller>
</node>
</node>
<instance_controller url="#geom-rToe-skin1">
<skeleton>#node-Bip01_Pelvis</skeleton>
<bind_material>
<technique_common>
<instance_material symbol="Material__60" target="#Material__60-material">
<bind_vertex_input semantic="CHANNEL1" input_semantic="TEXCOORD" input_set="1"/>
</instance_material>
</technique_common>
</bind_material>
</instance_controller>
</node>
<node id="node-eyeL_hi" name="eyeL_hi">
<node>
<matrix>1 0 0 0 0 1 0 0 0 0 1 0.6319538 0 0 0 1</matrix>
<instance_controller url="#geom-eyeL_hi-skin1">
<skeleton>#node-Bip01_Pelvis</skeleton>
<bind_material>
<technique_common>
<instance_material symbol="Material__60" target="#Material__60-material">
<bind_vertex_input semantic="CHANNEL1" input_semantic="TEXCOORD" input_set="1"/>
</instance_material>
</technique_common>
</bind_material>
</instance_controller>
</node>
</node>
The difference appears to be that the "bad" node, node-eyeL_hi, has a nested <node> xml element
To get a better handle on this, we imported the dae file into 3ds 2010, and opened schematic view.
In that view, the "bad" meshes had "dummy"-type nodes for certain pieces of mesh and not others. These dummy nodes appeared to have all of the data associated with them, while their parent node had only the name identifier. Here's an example for the xml code above
Interestingly, the behavior changes if the rigging for the model is removed (Physique modifier on a biped)
In this case, we still get
Code:
<node id="node-rToe" name="rToe">
<matrix>0.01033462 0 0 -0.0409454 0 0.0109 0 3.76989 0 0 0.01 0.06127039 0 0 0 1</matrix>
<instance_geometry url="#geom-rToe">
<bind_material>
<technique_common>
<instance_material symbol="Material__60" target="#Material__60-material">
<bind_vertex_input semantic="CHANNEL1" input_semantic="TEXCOORD" input_set="1"/>
</instance_material>
</technique_common>
</bind_material>
</instance_geometry>
</node>
<node id="node-eyeL_hi" name="eyeL_hi">
<matrix>1.4 0 0 -0.04008327 0 1.378731 0.2431075 -5.447562 0 -0.2431075 1.378731 25.82601 0 0 0 1</matrix>
<node>
<matrix>1 0 0 0 0 1 0 0 0 0 1 0.6319538 0 0 0 1</matrix>
<instance_geometry url="#geom-eyeL_hi">
<bind_material>
<technique_common>
<instance_material symbol="Material__60" target="#Material__60-material">
<bind_vertex_input semantic="CHANNEL1" input_semantic="TEXCOORD" input_set="1"/>
</instance_material>
</technique_common>
</bind_material>
</instance_geometry>
</node>
</node>
<matrix>0.01033462 0 0 -0.0409454 0 0.0109 0 3.76989 0 0 0.01 0.06127039 0 0 0 1</matrix>
<instance_geometry url="#geom-rToe">
<bind_material>
<technique_common>
<instance_material symbol="Material__60" target="#Material__60-material">
<bind_vertex_input semantic="CHANNEL1" input_semantic="TEXCOORD" input_set="1"/>
</instance_material>
</technique_common>
</bind_material>
</instance_geometry>
</node>
<node id="node-eyeL_hi" name="eyeL_hi">
<matrix>1.4 0 0 -0.04008327 0 1.378731 0.2431075 -5.447562 0 -0.2431075 1.378731 25.82601 0 0 0 1</matrix>
<node>
<matrix>1 0 0 0 0 1 0 0 0 0 1 0.6319538 0 0 0 1</matrix>
<instance_geometry url="#geom-eyeL_hi">
<bind_material>
<technique_common>
<instance_material symbol="Material__60" target="#Material__60-material">
<bind_vertex_input semantic="CHANNEL1" input_semantic="TEXCOORD" input_set="1"/>
</instance_material>
</technique_common>
</bind_material>
</instance_geometry>
</node>
</node>
Now there is still a nested node, but it has its own matrix transform. Also in the engine, the entire model appears without issue (maybe the second matrix transform is a local transform that keeps the model together?)
In 3ds 2010, this unrigged version has the following schematic view (for the same xml):
Now the child node has a name: the same name as the parent. Obviously this throws the same duplicate name error in ColladaConverter, but for different reasons.
Also I should repeat that not all meshes have this parent/dummy structure when reimported into 3ds 2010. Some have it, and some don't (like the rtoe above). When we've "gone back to formula" on our model, and performed this procedure on the original meshes, there are no parent/dummies present. So we're not sure how they came to be there in the first place.
The underlying issue is that the rigged model is not converting properly, and has either missing pieces in the engine or the pieces are translated strangely. It appears that the nodes without the parent/dummy structure are correctly placed, which is why our approach so far has been to eliminate the cause of this parent/dummy structure. However, we could also be chasing a red herring.