Blender import creates invalid mesh

I’m trying to test my game using a recent jME 3.x build (r10946), and I’ve hit some snags related to importing a 3-D model created in Blender. The model in question can be downloaded from https://code.google.com/p/bats-game/source/browse/trunk/assets/Models/blocks/tower/pavement/pavement.blend

assetManager.loadModel() completes without any hint of trouble. However, the resulting Spatial has three geometries instead of the expected two. Furthermore, the third geometry (named “pavement3”) appears to be invalid: its mesh has 12 triangles but only 24 indices. I expect 3 indices for each triangle, not 2, and the mismatch causes an indexing error when I attempt to convert the mesh to create a collision shape.

Is there a workaround for this issue?

12 triangles and 24 indexes doesn’t automatically mean it’s a bad mesh. Some of them could be shared.

How are you converting the mesh to a collision shape. Do you have any other indication (visual perhaps) that the mesh is invalid?

@sgold said: I'm trying to test my game using a recent jME 3.x build (r10946), and I've hit some snags related to importing a 3-D model created in Blender. The model in question can be downloaded from https://code.google.com/p/bats-game/source/browse/trunk/assets/Models/blocks/tower/pavement/pavement.blend

assetManager.loadModel() completes without any hint of trouble. However, the resulting Spatial has three geometries instead of the expected two. Furthermore, the third geometry (named “pavement3”) appears to be invalid: its mesh has 12 triangles but only 24 indices. I expect 3 indices for each triangle, not 2, and the mismatch causes an indexing error when I attempt to convert the mesh to create a collision shape.

Is there a workaround for this issue?

I’m not sure this poblem was solved but I remember something with a signed short datatype leading to negative indices.

Let it print out the index and vertex buffer and check them manually for irregularities, if you find some I bet khaeltras will be happy, if you provide him with a testcase including a incorrect loading model.

@pspeed said: 12 triangles and 24 indexes doesn't automatically mean it's a bad mesh. Some of them could be shared.

How are you converting the mesh to a collision shape. Do you have any other indication (visual perhaps) that the mesh is invalid?

I understand that vertices can be shared between triangles. Indices are the mechanism of that sharing, and I don’t understand how they can be shared. How should software determine the vertices of the 11th triangle in the mesh when there are only 24 entries in the index buffer?

Conversion to a collision shape is being performed by means of com.jme3.bullet.collision.shapes.MeshCollisionShape.createCollisionMesh() which fails in java.nio.Buffer.checkIndex()

When I view the model in SceneComposer, and it looks okay.

@sgold said: I understand that *vertices* can be shared between triangles. Indices are the mechanism of that sharing, and I don't understand how they can be shared. How should software determine the vertices of the 11th triangle in the mesh when there are only 24 entries in the index buffer?

Yes, you’re right. I was reading it wrong.

@Empire Phoenix said: I'm not sure this poblem was solved but I remember something with a signed short datatype leading to negative indices.

Let it print out the index and vertex buffer and check them manually for irregularities, if you find some I bet khaeltras will be happy, if you provide him with a testcase including a incorrect loading model.

The index buffer is very boring, but here it is, for @Kaelthas:
SEVERE: name=pavement3, triangles=12, indices=24
index[0] = 0
index[1] = 1
index[2] = 2
index[3] = 3
index[4] = 4
index[5] = 5
index[6] = 6
index[7] = 7
index[8] = 8
index[9] = 9
index[10] = 10
index[11] = 11
index[12] = 12
index[13] = 13
index[14] = 14
index[15] = 15
index[16] = 16
index[17] = 17
index[18] = 18
index[19] = 19
index[20] = 20
index[21] = 21
index[22] = 22
index[23] = 23

By the way, the problem appears to be a recent one. I’m hoping to pin down which commit introduced it. I’ve confirmed that at r10904 JME imported a valid mesh from my model, but at r10915 it generated an invalid one.

By the way, the problem appears to be a recent one. I'm hoping to pin down which commit introduced it. I've confirmed that at r10904 JME imported a valid mesh from my model, but at r10915 it generated an invalid one.

The problem originated with r10914 (support for line and point type of meshes). I wonder if the Blender plugin believes my model is a line mesh…

What does http://hub.jmonkeyengine.org/javadoc/com/jme3/scene/Mesh.html#getMode() say it is?

1 Like
@pspeed said: What does http://hub.jmonkeyengine.org/javadoc/com/jme3/scene/Mesh.html#getMode() say it is?

Mode.Lines (!)

So now I’m curious how the importer decides whether a mesh is triangles or lines. Or how I can convince it not to create a line mesh. And why createCollisionMesh() doesn’t notice the mode being other than triangles.

@sgold
If you look closely at your mesh, you will notice it has a single line. It is inside the larger of the planes and creates some kind of arc.

Blender can mix line, point and triangle meshes in one node so it can happen, that during modelling, you create a line by mistake and leave it there.
The importer does not decide by its own if it should load your model as line or mesh. It simply follows what is stored inside the blender file.

But this problem occured before.

I think you can do one of the following:

  1. get rid of the line in your model
  2. do not allow the line or point meshes to be passed to the method that creates the collision shape
  3. ask @normen to ignore other geometry modes than triangles in the MeshCollisionShape class :slight_smile:
1 Like
@Kaelthas said: 3. ask @normen to ignore other geometry modes than triangles in the MeshCollisionShape class :)

Then the mesh wouldn’t be used at all as its a line mesh when its in jME

In this case only a small part of the model is a line so it woul work fine.
And if we do not support collisions for line anyway - then at least an exception would not occur.
I think that logging a warning would be fine when line or point mesh is passed.

If user creates a mesh made only of lines - well I belive he or she should not expect objects to collide with it anyway :wink:

Only a triangle mesh can be a collision mesh, I think its pretty simple already.

Using trial-and-error, I located and deleted all the extra edges (those not part of any triangle) in my Blender model, so that’s fixed.

I don’t expect JME to convert extra edges into a collision shape. To avoid throwing a cryptic exception, perhaps the test in line 213 of CollisionShapeFactory.java
should verify that the mesh mode is compatible with the MeshCollisionShape constructor.

@sgold said: Using trial-and-error, I located and deleted all the extra edges (those not part of any triangle) in my Blender model, so that's fixed.

I don’t expect JME to convert extra edges into a collision shape. To avoid throwing a cryptic exception, perhaps the test in line 213 of CollisionShapeFactory.java
should verify that the mesh mode is compatible with the MeshCollisionShape constructor.

Yes, meshes “line mode” is actually younger than the collision shape, I guess a test for the mesh type is a good idea.

Thanks for all the debugging help. Have a great New Year, everyone!

I’ve opened issue #631 to track this issue.

1 Like