BvhTriangleMeshShape NPE

Troubleshooting physics
1

Hi Everyone,



as I’m currently rewriting some core code of moebius I updated my tesselation class to also provide the CollisionShape. What I basically do is create a BvhTriangleMeshShape like this:



[java]

public synchronized CollisionShape getCollisionShape() {

final MeshCollisionShape collisionShape = new MeshCollisionShape();



IndexedMesh bulletMesh = new IndexedMesh();

bulletMesh.triangleIndexBase = ByteBuffer.allocate(this.indexes.size() * 4);

bulletMesh.vertexBase = ByteBuffer.allocate(this.points.size() * 3 * 4);

bulletMesh.numVertices = this.points.size();

bulletMesh.numTriangles = this.indexes.size() / 3;

bulletMesh.vertexStride = 12; //3 vertices x 4 bytes each

bulletMesh.triangleIndexStride = 12; //3 vertices x 4 bytes each



for (Vector3f point : this.points) {

bulletMesh.vertexBase.putFloat(point.x);

bulletMesh.vertexBase.putFloat(point.y);

bulletMesh.vertexBase.putFloat(point.z);

}



for (int i : this.indexes) {

bulletMesh.triangleIndexBase.putInt(i);

}



TriangleIndexVertexArray tiv = new TriangleIndexVertexArray(bulletMesh.numTriangles, bulletMesh.triangleIndexBase, bulletMesh.triangleIndexStride,

bulletMesh.numVertices, bulletMesh.vertexBase, bulletMesh.vertexStride);

BvhTriangleMeshShape cShape = new BvhTriangleMeshShape(tiv, true);

cShape.setLocalScaling(new javax.vecmath.Vector3f(1.0f, 1.0f, 1.0f));

cShape.setMargin(0.0f);



collisionShape.setCShape(cShape);



return collisionShape;

}

[/java]



My Problem now is that calling this method concurrently to the main render/physics loop causes sometimes the following NPE:




Schwerwiegend: Problem while constructing a sector

java.lang.NullPointerException

at com.bulletphysics.collision.shapes.BvhTriangleMeshShape.processAllTriangles(BvhTriangleMeshShape.java:161)

at com.bulletphysics.collision.shapes.TriangleMeshShape.localGetSupportingVertex(TriangleMeshShape.java:71)

at com.bulletphysics.collision.shapes.TriangleMeshShape.recalcLocalAabb(TriangleMeshShape.java:88)

at com.bulletphysics.collision.shapes.BvhTriangleMeshShape.(BvhTriangleMeshShape.java:84)

at com.bulletphysics.collision.shapes.BvhTriangleMeshShape.(BvhTriangleMeshShape.java:63)

at de.darkblue.moebius.model.utils.mesh.MeshBuilder.getCollisionShape(MeshBuilder.java:266)

at de.darkblue.moebius.model.Sector.construct(Sector.java:196)

at de.darkblue.moebius.model.SectorManager.getOrCreateSectorFromCache(SectorManager.java:361)

at de.darkblue.moebius.model.SectorConstructor.run(SectorConstructor.java:34)


But I don't understand why - the Shape has not even been added to the PhysicsSpace - because the method has not returned it yet. So why should there be any NPE at all? If I synchronize the constructor call of BvhTriangleMeshShape the NPE does not occur. Is this maybe related to JStackAlloc's compiletime optimizations?
2

Why do you do this? Use the existing mesh->collision shape conversions.

3
@normen said:
Why do you do this? Use the existing mesh->collision shape conversions.

Good question: I do this because this way I don't have to go the detour over creating a mesh (that uses direct buffers) and then create the CollisionShape from it just to throw the mesh away. I want to keep the footprint for directbuffer low because of the reasons I discussed here in an earlier thread ;). And furthermore I hoped that the NPE that also(!) occured with the existing conversion tools would maybe not happen this way - but it does apparently ...
4

So what happens if you use them?

Edit: And btw, all jbullet code will not work anymore wheno we move to native bullet completely so you should do this anyway.

5
@normen said:
So what happens if you use them?


NPE at the same class and same position of course - because your wrapper class doesn't create the CollisionShape any differently ...


@normen said:
Edit: And btw, all jbullet code will not work anymore wheno we move to native bullet completely so you should do this anyway.


When will you do that? I thought you were in beta now so no more complete API changes, right? Not that I wouldn't prefer native bullet physics just that I didn't know you would replace all the current jbullet physics ...
6
@entrusc said:
NPE at the same class and same position of course - because your wrapper class doesn't create the CollisionShape any differently ...

Well OF COURSE, I could have done it in my head, silly me, I know all the engine code off the top of my head, sorry to bother you. So this means your mesh data is invalid.

@entrusc said:
When will you do that? I thought you were in beta now so no more complete API changes, right? Not that I wouldn't prefer native bullet physics just that I didn't know you would replace all the current jbullet physics ...

There is no API changes, all the jme API stays the same, accessing the jbullet objects directly isn't part of the API thats why I suggest not doing it (as the warnings in the methods you use to access these objects suggest: "internal use only").
7
@normen said:
Well OF COURSE, I could have done it in my head, silly me, I know all the engine code off the top of my head, sorry to bother you. [...]

Sorry I didn't mean to offend you ;) - just sometimes you are so direct in your words that one could get the impression that you really know the code by heart ;)

@normen said:
So this means your mesh data is invalid.

I also concluded that at first - but the data is not invalid and the NPE disappears when I synchronize it. I really think it has something to do with JStackAlloc - but then again it would be a problem of jBullet and not of JME ...

@normen said:
There is no API changes, all the jme API stays the same, accessing the jbullet objects directly isn't part of the API thats why I suggest not doing it (as the warnings in the methods you use to access these objects suggest: "internal use only").

ok. Maybe I really should use the JME converter then ...
8

Do you use any threads? Can you use the mesh you create as a geometry? These errors usually appeared with mesh strips etc. basically anything that isn’t a mesh consisting of triangles.

9

As already stated - yes, I do call it concurrently. But this shouldn’t be a problem as it is not attached to any physics space yet. And yes the mesh is 100% valid - just triangles - no strips or anything …

10

I meant “multiple threads” (for creating the shapes), sorry. Might be you’re right with the (imo unnecessary) stack alloc stuff jezek did. Anyway that and a slew of other things is what makes us leave jbullet behind.

11
@normen said:
I meant "multiple threads" (for creating the shapes), sorry.

No problem: one sector is created by one thread only but async to the rendering/physics loop itself. But only one thread at a time uses one instance of the tesselation class (MeshBuilder).

@normen said:
Might be you're right with the (imo unnecessary) stack alloc stuff jezek did. Anyway that and a slew of other things is what makes us leave jbullet behind.

As far as I read about the stack alloc stuff it uses some bytecode magic to optimize reusage of instances. But I also think that it is quite unnecessary ... and like in this case complicates the debugging enormously ...
12
@entrusc said:
As far as I read about the stack alloc stuff it uses some bytecode magic to optimize reusage of instances. But I also think that it is quite unnecessary ... and like in this case complicates the debugging enormously ...

"Optimizing" like this just keeps the JVM from doing its job properly. Proven in this case by how crappy jbullet performs on android.
13
@normen said:
"Optimizing" like this just keeps the JVM from doing its job properly. Proven in this case by how crappy jbullet performs on android.


I totally agree.