CVS error when running tests: Binary Header doesn't match

Hi



I succesfully compiled the CVS sources with Eclipse Ant.



I followed exactly the steps in the Wiki tutorial to download CVS sources and build with Ant.



But I got the error (below I quoted the Eclispe console output of running TestChooser ->TestFireMilk with Eclipse Ant). This is not the first time I have had that error. Yesterday and friday I have already tryed to use the CVS with a project of mine where I load OBJ files. But got exactly the same error.



So I went back to an earlier CVS I previously stored on my diks, one of the latests still using Java 1.4.2, and everithing worked again.



I run jME on Mac OS X 1.4.6, Java 1.5.0_06.



Buildfile: /Volumes/Uklennugtag/Downloads/cvs/jmecvs/build.xml

Overriding previous definition of reference to classpath

init:

    [echo] jmeKeyStore

compile:

    [copy] Copied 10 empty directories to 7 empty directories under /Volumes/Uklennugtag/Downloads/cvs/jmecvs/build/com

    [javac] Compiling 465 source files to /Volumes/Uklennugtag/Downloads/cvs/jmecvs/build

    [javac] Note: Some input files use unchecked or unsafe operations.

    [javac] Note: Recompile with -Xlint:unchecked for details.

compile-test:

    [javac] Compiling 186 source files to /Volumes/Uklennugtag/Downloads/cvs/jmecvs/build

    [copy] Copying 5 files to /Volumes/Uklennugtag/Downloads/cvs/jmecvs/build/jmetest/data

run-testchooser:

    [java] Composing Test list…

    [java] Searching for Demo classes in “jmetest”.

    [java] 18-giu-2006 20.01.16 com.jme.scene.Node <init>

    [java] INFO: Node created.

    [java] 18-giu-2006 20.04.58 com.jme.app.BaseGame start

    [java] INFO: Application started.

    [java] 18-giu-2006 20.04.58 com.jme.system.PropertiesIO <init>

    [java] INFO: PropertiesIO created

    [java] 18-giu-2006 20.04.58 com.jme.system.PropertiesIO load

    [java] INFO: Read properties

    [java] 18-giu-2006 20.05.00 com.jme.system.lwjgl.LWJGLDisplaySystem <init>

    [java] INFO: LWJGL Display System created.

    [java] 18-giu-2006 20.05.00 com.jme.util.lwjgl.LWJGLTimer <init>

    [java] INFO: Timer resolution: 1000 ticks per second

    [java] 18-giu-2006 20.05.07 com.jme.input.joystick.DummyJoystickInput <init>

    [java] INFO: Joystick support is disabled

    [java] 18-giu-2006 20.05.07 com.jme.system.PropertiesIO save

    [java] INFO: Saved properties

    [java] 18-giu-2006 20.05.07 com.jme.renderer.lwjgl.LWJGLRenderer <init>

    [java] INFO: LWJGLRenderer created. W:  640H: 480

    [java] 18-giu-2006 20.05.08 com.jme.renderer.AbstractCamera <init>

    [java] INFO: Camera created.

    [java] 18-giu-2006 20.05.08 com.jme.scene.Node <init>

    [java] INFO: Node created.

    [java] 18-giu-2006 20.05.08 com.jme.scene.Node <init>

    [java] INFO: Node created.

    [java] 18-giu-2006 20.05.08 com.jme.scene.Node attachChild

    [java] INFO: Child (FPS label) attached to this node (FPS node)

    [java] 18-giu-2006 20.05.08 com.jme.scene.Node <init>

    [java] INFO: Node created.

    [java] 18-giu-2006 20.05.08 com.jme.scene.Node attachChild

    [java] INFO: Child (DM_Base) attached to this node (ms3d file)

    [java] 18-giu-2006 20.05.08 com.jme.scene.Node attachChild

    [java] INFO: Child (DM_Face) attached to this node (ms3d file)

    [java] 18-giu-2006 20.05.10 com.jme.scene.Node <init>

    [java] INFO: Node created.

    [java] java.lang.NullPointerException

    [java] at jmetest.renderer.loader.TestFireMilk.simpleInitGame(Unknown Source)

    [java] at com.jme.app.BaseSimpleGame.initGame(Unknown Source)

    [java] at com.jme.app.BaseGame.start(Unknown Source)

    [java] at jmetest.renderer.loader.TestFireMilk.main(Unknown Source)

    [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

    [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

    [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

    [java] at java.lang.reflect.Method.invoke(Method.java:585)

    [java] at jmetest.TestChooser.start(Unknown Source)

    [java] at jmetest.TestChooser.main(Unknown Source)

    [java] 18-giu-2006 20.05.10 com.jme.app.BaseSimpleGame cleanup

    [java] INFO: Cleaning up resources.

    [java] 18-giu-2006 20.05.10 com.jme.app.BaseGame start

    [java] darn exceptions:Binary Header doesn’t match.  Maybe wrong file?

    [java] INFO: Application ending.

BUILD SUCCESSFUL

Total time: 4 minutes 44 seconds

Fixed in CVS.

Wow!!! You so fast :D.



Thank you very much. I have just tryed the TestFireMilk with success.



But my app still broken…  :cry:



java.io.IOException: Binary Header doesn’t match.  Maybe wrong file?

at com.jmex.model.XMLparser.JmeBinaryReader.readHeader(JmeBinaryReader.java:1272)

at com.jmex.model.XMLparser.JmeBinaryReader.loadBinaryFormat(JmeBinaryReader.java:156)

at com.jmex.model.XMLparser.JmeBinaryReader.loadBinaryFormat(JmeBinaryReader.java:190)

at org.marcofrisan.mmorpg.test.loaders.SimpleLoader.loadModels(SimpleLoader.java:151)

at org.marcofrisan.mmorpg.test.loaders.SimpleLoader.simpleInitGame(SimpleLoader.java:288)

at com.jme.app.BaseSimpleGame.initGame(BaseSimpleGame.java:449)

at com.jme.app.BaseGame.start(BaseGame.java:56)

at org.marcofrisan.mmorpg.test.loaders.SimpleLoader.main(SimpleLoader.java:313)

The converters where changed to convert to the new file format. You need to use the new loader now. See the tests to see how to do that.

Ok, Thank you.



I will try it.

The main change is no longer using JmeBinaryReader to load in models created by the converters. Instead, use BinaryImporter.getInstance().load().

Ok, after a long time with backup, reinstall of the system (not couse of jme but for other reason), resetting whole system and eclipse I finally come back to the code applying the new BinaryImporter as seen in the jmetest.renderer.loader.TestObjJmeWrite.



And it as come out with this new error:



24-giu-2006 1.32.06 com.jme.scene.Node attachChild

INFO: Child (Grid_Grid) attached to this node (obj file)

java.lang.ClassCastException: com.jme.scene.TriMesh

at org.marcofrisan.mmorpg.test.loaders.SimpleLoader.loadModels(SimpleLoader.java:154)

at org.marcofrisan.mmorpg.test.loaders.SimpleLoader.simpleInitGame(SimpleLoader.java:291)

at com.jme.app.BaseSimpleGame.initGame(Unknown Source)

at com.jme.app.BaseGame.start(Unknown Source)

at org.marcofrisan.mmorpg.test.loaders.SimpleLoader.main(SimpleLoader.java:318)




Here is the line responsible for that error:



modelRoot = (Node) BinaryImporter.getInstance().load(new ByteArrayInputStream(baos.toByteArray()));



What is wrong this time?



Of course I have tried to chage modelRoot as a TriMesh Type and casting the BinaryImporter expression to (TriMesh) and everything goes fine.



???



Thanks

You're trying to cast a TriMesh to a Node. Currently when converting, sometimes you get a Node, sometimes a Trimesh (you can find out which you have with instanceof).

The old exporter would add an artificial extra node on top of whatever the model defined, it was nice because you always knew you'd have a node as the top level, but not nice in the fact that it added an extra layer as well as changed the make-up of the model itself. The new method simply saves out the results as it came out of the model, so it might be a Node or a TriMesh depending on the model. If you don't need to operating on the model itself, but just add it to the scene, cast it to a Spatial and attach it.

Thank you for the help :).



But now I have some doubts…



The model I imported was made with Blender and exported with OBJ exporter script of Blender. There is a way to export a model and be sure that it will be loaded in jME as a Node or as a TriMesh?



And, if I use instanceof as suggested by llama, how can I use it?

Like mojo said, you can always cast it to a (Spatial), and then attach it to a Node of your own. That way, it does not matter if it's a TriMesh or a Node. No errors, no worries :slight_smile:



instanceof is a Java operator. It's not specific to jME. I'm sure you can find out how this works in many books and on many websites (Google is your friend here).

llama said:
Like mojo said, you can always cast it to a (Spatial), and then attach it to a Node of your own. That way, it does not matter if it's a TriMesh or a Node. No errors, no worries :)


Yes I know but as said by mojo, Spatial is if I do not need to operate on the model. Instead I need something i can operate with.

instanceof is a Java operator. It's not specific to jME. I'm sure you can find out how this works in many books and on many websites (Google is your friend here).


I gone to search and I think I have understood.

I tested this solution to made the program decide if to use TriMesh or Node, and seamed to work. I loaded the binary into a Spatial.

model = (Spatial)BinaryImporter.getInstance().load(new ByteArrayInputStream(baos.toByteArray()));

than later, after the catch block, i used this if block

if (model instanceof TriMesh) {
System.out.println("modelRoot is a TriMesh.");
modelMesh = (TriMesh)model;
rootNode.attachChild(modelMesh);
} else {
System.out.println("modelRoot is a Node.");
modelRoot = (Node)model;
rootNode.attachChild(modelRoot);
}


Of course modelMesh is a TriMesh and modelRoot a Node.

Do you think it could be a good solution?

Yes… except, again like Mojo cleverly noticed, you don't have to care if it's a TriMesh or a Node, since they are both Spatials, and you can attach Spatials to a Node.



Spatial model = (Spatial)BinaryImporter.getInstance().load(new ByteArrayInputStream(baos.toByteArray()));

rootNode.attachChild(model);

llama said:

Yes.. except, again like Mojo cleverly noticed, you don't have to care if it's a TriMesh or a Node, since they are both Spatials, and you can attach Spatials to a Node.


Thank you.

But if I need to made changes to mesh vertices? I am currently looking to the Spatial  list of methods and fields, and it seams to have no method to access verices vectors.

Like I said, your code seems correct. So you should know how.

Remember too that you can run into the problem of Node vs Mesh just by loading a model that is more complex than a simple, single mesh.  Generally, model use in a game - aside from animation, but even there it can be generalized - is going to be agnostic to the actual contents of the model (plug it in and let it do its work).  If you are building an editor, then I could see where accessing the actual geometric data might be useful, but otherwise…

@llama

Thank you for the confirmation.



@renanse

I need to move vertices. But mine is not an editor just a game.