Savable and importers

We are currently working on making the physics stuff Savable. As physics nodes, joints and geometries cannot be directly instantiated but require e.g. a parent in the constructor I would like to change the following things, to allow accessing field values in LoaderModules:


  • Defer the actual object creation into the readSavableXX(String, XX) methods instead of creating them in the readSavableXX(byte[])
  • BinaryLoaderModule (thus all module classes) need to have an additional method parameter in load - the capsule:

    public Savable load(InputCapsule inputCapsule)


- creating the capsule must happen before load() (as it is passed)

This works smoothly with jME Physics reading the parent field before creating the object.

The only problem that could arise is that circular references can cause infinite loops if the Loader use these (cannot happen with jMEs or physics loaders as they are).

Any objections/improvements?

No answers abviously means no objections? :wink:

Going to change that next week then

I'm all for it. :slight_smile:



darkfrog

ok, that week was a little longer than 7 days . . . I'll commit that now.



Can someone please check those multidimensional arrays/lists as I did not see if these were converted correctly or where they are used.

You do realize that your addition of an id makes every existing .jme file unreadable?  :confused:

What do we need to do to resolve this issue?



java.lang.NullPointerException

at com.jme.util.export.binary.BinaryInputCapsule.resolveIDs(BinaryInputCapsule.java:393)

at com.jme.util.export.binary.BinaryInputCapsule.readSavableArray2D(BinaryInputCapsule.java:408)

at com.jme.util.export.binary.BinaryInputCapsule.readSavableArrayListArray(BinaryInputCapsule.java:461)

BTW, this is from attempting to store data. As Renanse mentioned above all existing assets (hundreds) can no longer be loaded . :’(

renanse said:

You do realize that your addition of an id makes every existing .jme file unreadable?
renanse said:

You do realize that your addition of an id makes every existing .jme file unreadable?

We just seem to be having trouble with the resolveID method (saving out new files produces the posted exception), and loading previously saved models generates an ArrayIndexOutOfBounds exception that contains the resolveID method in the stack trace. Any ideas what could be causing this? We can rollback our local copy, but I'd like to stay current with CVS if at all possible.

hmm, that NPE is easily fixed. Though I'm not able to reproduce it. And I really wonder how it can happen while writing, as the input capsule are only used while reading, aren't they :?



Will now try loading existing .jme . . .

can you post a .jme that does not work? I have only bike.jme and Lesson9 still runs fine.

It caused by a internal networking system. We write out to binary then read it on the other side. So, the read is where the crash occurs. But, I wasn't sure why this would happen… as we just wrote it before the crash.



Unfortunately, we don't have many things we can post, but I'll see if I can find something.

mojomonk said:

Unfortunately, we don't have many things we can post, but I'll see if I can find something.

You could send it my mail (irrisor@dev.java.net preferrably), I will delete it after testing.

Actually, I take that back. All of our static models load fine, we are having problems with our Skinned Nodes (which you don't have, and I can't easily give to you). However, here is the stack trace if it looks like something you've run into before (long shot, I know):



java.lang.IndexOutOfBoundsException: Index: 1842, Size: 4

at java.util.ArrayList.RangeCheck(ArrayList.java:546)

at java.util.ArrayList.get(ArrayList.java:321)

at com.jme.scene.TriMesh.getBatch(TriMesh.java:477)

at com.jme.scene.TriMesh.getBatch(TriMesh.java:1)

at com.nccore.engine.animation.SkinNode.regenInfluenceOffsets(SkinNode.java:379)

at com.nccore.engine.animation.SkinNode.read(SkinNode.java:506)

at com.jme.util.export.binary.BinaryImporter.readObject(BinaryImporter.java:218)

at com.jme.util.export.binary.BinaryInputCapsule.resolveIDs(BinaryInputCapsule.java:397)

at com.jme.util.export.binary.BinaryInputCapsule.readSavableArray(BinaryInputCapsule.java:386)

at com.jme.util.export.binary.BinaryInputCapsule.readSavableArrayList(BinaryInputCapsule.java:452)

at com.jme.scene.Node.read(Node.java:660)

The array it is trying to work with is a two dimensional ArrayList ie ArrayList[][] which should be something like ArrayList[2][2000] but appears to have the sizes mixed up or just wrong?

Does not sound familiar, no. Should it really have thousands of batches? If not that line in regenInfluenceOffsets(SkinNode.java:379) most likely accesses a value that is probably not correctly (re)stored. But I really don't know why this could be caused by the changes to the loading order :?



edit: oh, missed renanses post - reading now

renanse said:

The array it is trying to work with is a two dimensional ArrayList ie ArrayList[][] which should be something like ArrayList[2][2000] but appears to have the sizes mixed up or just wrong?

hmm, that's possible I'll have a look

In BinaryInputCapsule, line 484 of the method readSavableArrayListArray2D should actually read:


ArrayList[][] arrayLists = new ArrayList[savables.length][];



instead of

ArrayList[][] arrayLists = new ArrayList[savables[0].length][];

ah, good you found it. I'd suggest that you also correct it yourself as I can't even test it without writing a test first.