Currently when loading an animation from xml, the speed and repeat-type values don't get set when importing a spatial controller.
after line 461 in JmeBinaryReader:
} else if (tagName.equals("spatialtransformer")){
SpatialTransformer st=new SpatialTransformer(((Integer)attributes.get("numobjects")).intValue());
objStack.push(st);
}
should be:
} else if (tagName.equals("spatialtransformer")){
SpatialTransformer st=new SpatialTransformer(((Integer)attributes.get("numobjects")).intValue());
processController( st, attributes );
objStack.push(st);
}
Change made locally, will be in cvs in next push. Keep in mind though that this is a deprecated class.
renanse said:
Change made locally, will be in cvs in next push. Keep in mind though that this is a deprecated class.
Is there any replacement for XMLtoBinary which doesn't use JmeBinaryReader?
If not, how useful would the community find one (ie. XmlImporter - XmlExporter)?
Very useful! 
I can't really get Collada to work properly, so something non-deprecated to use with Hevee's exporter would be great. Of course a fully working Blender -> Collada -> jME would be even better, but I'm not even quite sure what needs to be fixed to make that work, importers/exporters have always scared me 
Squid said:
Is there any replacement for XMLtoBinary which doesn't use JmeBinaryReader?
If not, how useful would the community find one (ie. XmlImporter - XmlExporter)?
Mojo is looking into doing such a thing for work. If you do it first, I'm sure he would kiss you or something...
renanse said:
Mojo is looking into doing such a thing for work. If you do it first, I'm sure he would kiss you or something...
WOW! :-o
hehehe
Just in case anyone is still looking here, I think this fix caused an older fix to get lost, as described in this thread where I charmingly jabber at myself for half an hour http://www.jmonkeyengine.com/jmeforum/index.php?topic=4902.0 XD
Is there still an interest in XmlExporter/XmlImporter?
I've got a half-working exporter and need to know if I should continue in the drudgery that is XML.
Also, does anyone know how easy it would be to convert the old XML format to the one generated by the new JmeExporter system? I'm thinking some sort of XML transform? That way, Hevee's Blender exporter could still be used as-is.
So there's a new XML format yet? How does it work?
In simplest terms the format follows the export system as much as possible. For example, each spatial is a unique element, and all attributes are the non-spatial data the spatial contains. It's still got a few bugs but here's a sample:
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE jMonkeyEngine-Scene >
<jME-scene xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="" class="com.jme.scene.Node" name="rootNode" >
<renderStateList class="com.jmex.model.xml.wrapper.SavableArray" size="17" >
<child-3 class="com.jme.scene.state.LightState" twoSidedOn="true" >
<lightList class="com.jmex.model.xml.wrapper.SavableArrayList" >
<child-1 class="com.jme.light.PointLight" enabled="true" >
<ambient class="com.jme.renderer.ColorRGBA" r="0.5" g="0.5" b="0.5" a="1.0" />
<diffuse class="com.jme.renderer.ColorRGBA" r="0.75" g="0.75" b="0.75" a="0.75" />
<specular class="com.jme.renderer.ColorRGBA" r="1.0" g="1.0" b="1.0" a="1.0" />
<location class="com.jme.math.Vector3f" x="100.0" y="100.0" z="100.0" />
</child-1>
</lightList>
</child-3>
<child-7 class="com.jme.scene.state.WireframeState" enabled="false" />
<child-8 class="com.jme.scene.state.ZBufferState" function="3" />
</renderStateList>
<children class="com.jmex.model.xml.wrapper.SavableArrayList" >
<child-1 class="com.jme.scene.shape.Box" name="my box" xExtent="2.0" yExtent="2.0" zExtent="2.0" >
<batchList class="com.jmex.model.xml.wrapper.SavableArrayList" >
<child-1 class="com.jme.scene.batch.TriangleBatch" normBuf="" vertBuf="" texBuf=" [ 1.0 0.0 0.0 0.0 0.0 1.0 1.0 1.0 1.0 0.0 0.0 0.0 0.0 1.0 1.0 1.0 1.0 0.0 0.0 0.0 0.0 1.0 1.0 1.0 1.0 0.0 0.0 0.0 0.0 1.0 1.0 1.0 1.0 0.0 0.0 0.0 0.0 1.0 1.0 1.0 1.0 0.0 0.0 0.0 0.0 1.0 1.0 1.0 ] " indexBuffer="2 1 0 3 2 0 6 5 4 7 6 4 10 9 8 11 10 8 14 13 12 15 14 12 18 17 16 19 18 16 22 21 20 23 22 20 " >
<bound class="com.jme.bounding.BoundingSphere" radius="3.4641113" />
</child-1>
</batchList>
</child-1>
</children>
</jME-scene>
Tell me what you think!
Looks good,But I can see a problem there with appending the index to an array item element's node name, as in "child-1". This is hell for event based parsing, but even more so for navigating a dom tree using standard technologies such as xpath. I suggest elements should have predefined names, and store anything that can change in a concrete instance of a specific element type in attributes, or child element content, such as <child index="3" rather than <child-3.