Meshes from JmeBinaryReader seem to cause trouble with new cvs changes

I think this is a repeat of the problems with JmeBinaryReader before, where a change in CVS leads to the buffers created in JmeBinaryReader imported meshes being invalid. When creating clod:

java.lang.IndexOutOfBoundsException: 644

at java.nio.DirectFloatBufferU.get(

at com.jme.scene.lod.ClodCreator.reorder(

at com.jme.scene.lod.ClodCreator.<init>(

at com.jme.scene.lod.ClodMesh.create(

at com.jme.scene.lod.ClodMesh.<init>(

at com.jme.scene.lod.ClodMesh.<init>(

at com.jme.scene.lod.AreaClodMesh.<init>(

If I skip the clod, I get this:


at java.nio.Buffer.limit(

at com.jme.renderer.lwjgl.LWJGLRenderer.predrawGeometry(

at com.jme.renderer.lwjgl.LWJGLRenderer.draw(

at com.jme.scene.batch.TriangleBatch.draw(

at com.jme.scene.TriMesh.draw(

at com.jme.scene.Spatial.onDraw(

The code with the problem is one I had trouble with last time:

        if (colors != null) {
            // make sure only the necessary colors are sent through on old cards.
           oldLimit = colors.limit();
            colors.limit(t.getVertexCount() * 3);

Commenting the colors.limit line gives me a few seconds running, with some meshes messed up, others looking fine, then a JVM crash.

So... I'll dig through the binary reader code again, I suspect it's just another buffer thing. Presumably with binary reader being deprecated, no models read using it are checked before CVS changes?

Ok I'm completely confused now. It's JmeBinaryReader that has changed, not other stuff :slight_smile:

Version 1.21 reverted lines 247 and 248 to the old code with zero length buffers, the code in 1.20 had these lines as:

            t.getBatch(0).setTextureBuffer(null, 0);

which seems to fix the issue.

Ah ha!

It seems that the fix got lost when this change was made:

Added that back locally…