Supporting named node Sequence Markers in addition to "animation_clip" markup
by Matt Summers · in Collada Test · 02/19/2009 (10:36 am) · 3 replies
Given that most of the DTSSDKplus based exporters use a null object named "sequence_name" with custom properties, it would be be nice if the COLLADA pipline supported this as well as this would allow animation to be configured in the 3D App and wouldn't require that you need to edit the XML data manually to add <animation_clip> markup ("StartFrame", "EndFrame" etc).
Here is an example COLLADA markup exported from the XSI via crosswalk. This is a null node named "sequence_visibility" and you can see the custom properties in "XSI_CustomPSet" for the two parameters that I added "StartFrame" and "EndFrame.
I was mostly thinking that if you have to re-edit the XML and mannually after every export from your 3d app to keep adding markup to the COLLADA file, something like this could end up saving a lot of time.
Not all 3d apps support custom properties so the "animation_clip" markup is nice to have, but for the ones that do it would be nice to be able to configure as much as possible in the 3D app which could save a lot of hand editing. Reading custom parameters could apply DTS related settings as well.
Here is an example COLLADA markup exported from the XSI via crosswalk. This is a null node named "sequence_visibility" and you can see the custom properties in "XSI_CustomPSet" for the two parameters that I added "StartFrame" and "EndFrame.
<node id="sequence_visibility"> <translate sid="translation">0.000000 0.000000 0.000000</translate> <rotate sid="rotation_z">0.000000 0.000000 1.000000 0.000000</rotate> <rotate sid="rotation_y">0.000000 1.000000 0.000000 0.000000</rotate> <rotate sid="rotation_x">1.000000 0.000000 0.000000 0.000000</rotate> <scale sid="scale">1.000000 1.000000 1.000000</scale> <extra> <technique profile="XSI"> <SI_Visibility> <xsi_param sid="visibility">TRUE</xsi_param> </SI_Visibility> <XSI_Transform> <xsi_param sid="rotorder">"XYZ" </xsi_param> <xsi_param sid="siscaling">TRUE</xsi_param> <XSI_Limit> <xsi_param sid="parameter">"posx" </xsi_param> <xsi_param sid="minactive">FALSE </xsi_param> <xsi_param sid="minlimit">0.000000 </xsi_param> <xsi_param sid="maxactive">FALSE </xsi_param> <xsi_param sid="maxlimit">0.000000</xsi_param> </XSI_Limit> <XSI_Limit> <xsi_param sid="parameter">"posy" </xsi_param> <xsi_param sid="minactive">FALSE </xsi_param> <xsi_param sid="minlimit">0.000000 </xsi_param> <xsi_param sid="maxactive">FALSE </xsi_param> <xsi_param sid="maxlimit">0.000000</xsi_param> </XSI_Limit> <XSI_Limit> <xsi_param sid="parameter">"posz" </xsi_param> <xsi_param sid="minactive">FALSE </xsi_param> <xsi_param sid="minlimit">0.000000 </xsi_param> <xsi_param sid="maxactive">FALSE </xsi_param> <xsi_param sid="maxlimit">0.000000</xsi_param> </XSI_Limit> <XSI_Limit> <xsi_param sid="parameter">"rotx" </xsi_param> <xsi_param sid="minactive">FALSE </xsi_param> <xsi_param sid="minlimit">0.000000 </xsi_param> <xsi_param sid="maxactive">FALSE </xsi_param> <xsi_param sid="maxlimit">0.000000</xsi_param> </XSI_Limit> <XSI_Limit> <xsi_param sid="parameter">"roty" </xsi_param> <xsi_param sid="minactive">FALSE </xsi_param> <xsi_param sid="minlimit">0.000000 </xsi_param> <xsi_param sid="maxactive">FALSE </xsi_param> <xsi_param sid="maxlimit">0.000000</xsi_param> </XSI_Limit> <XSI_Limit> <xsi_param sid="parameter">"rotz" </xsi_param> <xsi_param sid="minactive">FALSE </xsi_param> <xsi_param sid="minlimit">0.000000 </xsi_param> <xsi_param sid="maxactive">FALSE </xsi_param> <xsi_param sid="maxlimit">0.000000</xsi_param> </XSI_Limit> </XSI_Transform> <SI_Null name="sequence_visibility"> </SI_Null> <XSI_CustomPSet name="CustomPSet"> <propagation>NODE</propagation> <type>customparamset</type> <XSI_Parameter id="startFrame" type="Integer" value="1"/> <XSI_Parameter id="endFrame" type="Integer" value="10"/> <XSI_Parameter id="enableVis" type="Boolean" value="1"/> <XSI_CustomParamInfo name="startFrame"> <xsi_param sid="MinValue">0 </xsi_param> <xsi_param sid="MaxValue">100 </xsi_param> <xsi_param sid="Capabilities"></xsi_param> </XSI_CustomParamInfo> <XSI_CustomParamInfo name="endFrame"> <xsi_param sid="MinValue">0 </xsi_param> <xsi_param sid="MaxValue">100 </xsi_param> <xsi_param sid="Capabilities"></xsi_param> </XSI_CustomParamInfo> <XSI_CustomParamInfo name="enableVis"> <xsi_param sid="MinValue">TRUE </xsi_param> <xsi_param sid="MaxValue">TRUE </xsi_param> <xsi_param sid="Capabilities"></xsi_param> </XSI_CustomParamInfo> </XSI_CustomPSet> </technique> </extra> </node>
I was mostly thinking that if you have to re-edit the XML and mannually after every export from your 3d app to keep adding markup to the COLLADA file, something like this could end up saving a lot of time.
Not all 3d apps support custom properties so the "animation_clip" markup is nice to have, but for the ones that do it would be nice to be able to configure as much as possible in the 3D app which could save a lot of hand editing. Reading custom parameters could apply DTS related settings as well.
About the author
#2
I have been thinking about it over the day and this might be a potential way to deal with the information that is missing from the COLLADA file without having to hand edit the exported COLLADA file every time you export the file.
What if you were to add something to the COLLADA pipeline that is basically the equivalent of the .cfg file that most of the existing DTS exporters use. something like <shape_name>.xml the difference would be that the this new file would contain XML markup that would sit along side the COLLADA .dae file.
When the COLLADA importer first starts up it would merge in the contents of the <shape_name>.xml and then convert the scene to .DTS.
Because of the nature of XML this would open up all kinds of possibilities to provide markup that could modify nodes in the COLLADA XML, add missing ones or remove nodes or other settings from the COLLADA XML markup.
This way you would also be free to export a new COLLADA file without having all of your special configuration overwritten every time and this could also be an interesting way to help combat some of the discrepancies in the files created by some of the existing COLLADA exporters.
02/19/2009 (5:51 pm)
Hello Chris,I have been thinking about it over the day and this might be a potential way to deal with the information that is missing from the COLLADA file without having to hand edit the exported COLLADA file every time you export the file.
What if you were to add something to the COLLADA pipeline that is basically the equivalent of the .cfg file that most of the existing DTS exporters use. something like <shape_name>.xml the difference would be that the this new file would contain XML markup that would sit along side the COLLADA .dae file.
When the COLLADA importer first starts up it would merge in the contents of the <shape_name>.xml and then convert the scene to .DTS.
Because of the nature of XML this would open up all kinds of possibilities to provide markup that could modify nodes in the COLLADA XML, add missing ones or remove nodes or other settings from the COLLADA XML markup.
This way you would also be free to export a new COLLADA file without having all of your special configuration overwritten every time and this could also be an interesting way to help combat some of the discrepancies in the files created by some of the existing COLLADA exporters.
Associate Chris Robertson
I agree completely - in fact, I think the animation_clip markup should be deprecated. The same functionality can be done much more cleanly using TSShapeConstructor for 3d apps that don't support custom properties.
The bastard of course is that each app stores their custom properties in a different way when you export to Collada. You've shown the XSI way, but the ColladaMax exporter does this:
<extra> <technique profile="FCOLLADA"> <user_properties>BB::DIM=128 BB::EQUATOR_STEPS=12 BB::POLAR_STEPS=6 </user_properties> </technique> </extra>It's not difficult to deal with from the loader's point of view, but it means we'd need samples from all of the 3d apps to support them.