# Optimizing CompoundCollisionShape

I figured that it would be better to use boxes as it is a simple calculation to determine if a point is in a box or even if a box intersects with another (certainly more simple than checking if a point is inside a mesh of arbitrary shape). Would it be better to use a set of plane colliders in the CompoundCollisionShape? I’d prefer to not have to re-do my meshing code if possible.

I addressed this in the original post:

I have no idea how efficient a compound collision shape is… but made of just boxes, even at the box level, probably 60% of the boxes can never be intersected because they are inside the world. It’s reasonable to consider that the compound collision shape is not intelligently handling these.

A mesh collision shape, on the other hand, is likely optimized in a way similar to how JME optimizes its own meshes for collision calculations. At any rate, even if it had to intersect with every visible quad, this is still a small fraction of the number of boxes it would have to check. Moreover, you won’t get strange glitches as your object partially collides with the inside surfaces of the boxes.

And by the way, for physics collisions, boxes are not a “simple calculation”. Even against a sphere, it has to account for face, edge, and vertex collisions and generate appropriate contact points and normals for those cases. It’s likely enough doing face collision checks, anyway. In my own physics engine, that’s the way I did it as it was the easiest way for me to account for all of the cases… collide with facing sides, pick the best one. (Hopefully bullet is more optimized than that but it’s still not as trivial as you think.)

1 Like

My code is already setup to not add obscured boxes to the map so the inner blocks that are impossible to collide with aren’t an issue. When an object collides with a Box wouldn’t it just do the same calculation it would do for a quad against whatever face of the box it collided with?

I’ll try switching to PlaneCollisionShapes.

Any collision might intersect as many as three faces. It may not know which of the three is the ‘right one’ until it has checked all three.

Also, for physics calculations the contact normals on an edge or a vertex should generally be dependent on the colliding object… ie: they may not be box surface aligned. For example, a sphere colliding with a box corner would prefer a contact normal that pointed towards the center of the sphere. For a capsule, it gets more complicated.

My home-grown physics engine doesn’t deal with this case and instead just has physics glitches. (Though it occurs to me that I might be able to fix this pretty easily as I look at it differently now.)

Well, I just finished implementing planes (via SimplexCollisionShape). It performs slightly worse than the boxes, but it isn’t noticeable unless measured. Do I have any other options than adding the mesh code to the server or writing my own physics engine (mine would probably be a simple fixed rotation fixed speed unrealistic setup)? Perhaps there is a way to combine multiple SimplexCollisionShapes in order to get something that performs on par with a MeshCollisionShape? I know that a MeshCollisionShape performs well as it worked fine when I had player movement calculated on the client.

Well the very least you could try:

GeometryBatch factory out of a chunk.
→ clone
→ remove all buffers and stuff esxcept vertex and index
→ generate mesh collision shape for that.

I guess this would still be multiple times faster at runtime. (at a slightly slower rebuild time)

Compoundshapes in the worst case, perform as good as actual single boxshapes for ALL of the used boxes.

Additional you could physic on client, and do serverside chacks if sensible every time to time, (eg check if inside a box, move to fast, flying ect)

As I said, I want to avoid any sort of mesh generation on the server as if I was going to do it I would have to come up with some sort of polymorphic structure for the client’s textures.

Also, when I make a CompoundCollisionShape out of a set of quads why is it any worse than a MeshCollisionShape made from a mesh made of a bunch of quads?

Minecraft tried doing simple sanity checks on the client, and it didn’t turn out well. Even with additional server-side plugins that are designed to make better sanity checks, there are still plenty of possible exploits.

Because the MeshCollisionShape is optimized.

I mean, you already have direct evidence that it is faster so I’m not sure it does any good to ask why it’s faster. Though, at least in this thread, I haven’t seen that you’ve tested quads yet. I’d expect it to be slower, though. A mesh can make a lot more assumptions about the data (shared edges, shared vertexes, etc.)

So does WOW and i think their checks went pretty ok.

Well just compare the c source code, one can generate a optimized acceleration structure as it assumes non moving blocks, the other can be used for dynamic shapes, and must do worke very tick extra.

I’m mostly curious although I was somewhat hoping to apply the optimizations myself to a CompoundCollisionShape. I did test quads:

You understand that planes are not quads, right? Almost no spatial optimization can be done on planes at all… so effectively you have to check EVERY PLANE.

I understand that. Would it be better to use two triangle colliders for each face just like a mesh is rendered?

I just switched the server to a mesh collider and it performs much better now. Although, for 3.1, I think that improved performance with CompoundCollisionShapes would be a good idea.

We look forward to your patches.

1 Like

And if you are at it, don#t forget to give them http://www.bulletphysics.org/ a push as well, so they know it

1 Like

any reason to not use this?
http://wiki.jmonkeyengine.org/doku.php/jme3:contributions:cubes

despite I believe optimizing compoud collision shapes per se would be awesome!

I like doing things myself. Also, there are some other features of this game that I want to add that are outside the scope of that framework. I intend this to be a real game – not just a Minecraft clone.

1 Like

I can’t seem to find the JBullet source anywhere? JBullet’s website seems to just point to compiled JARs and I don’t want to mess with plain Bullet as my C and C++ aren’t good enough for real contributions. JME3’s JME3-Bullet seems to just be a wrapper on JBullet.

I am looking for it too, it was in the google code svn.
As I read, the end of google code provided an auto-migration of “all” content to github, so… it seems, not all files were migrated and some got deleted…
As soon they restore it from a backup I would like to know too.
For the while I am using `jdgui` but the generated sources doesnt match the lines while debugging, I dont know why… so it didnt help.