Implicit collision shape?

Hi Everyone,



I’m just one step away from building my own physics engine - but I’d rather use jBullet - but I can just use it if there

is a possibility to create an implicit collision shape. I’m currently writing a block based game (yes - like in minecraft) where only

a part of the world is rendered - still I want the complete world to be a solid collision object for jBullet. Because I already

have a model where the whole world is represented (perlin noise + octree) this should be possible - the only question is

if it is possible with jBullet?



Thanks in advance for your answers!



entrusC

What do you mean by implicit collision shape? Did you look at the api at all? The bullet objects incl. collision shapes are completely separate from the scene graph…

it can generate collision shapes which are the same as the mesh, if that’s what you mean.

normen said:
What do you mean by implicit collision shape? Did you look at the api at all? The bullet objects incl. collision shapes are completely separate from the scene graph..


Yes I looked at the API - and yes I know that it is completely separate from the scene graph. Maybe I did not make myself clear: I have a model of about 40 Million 1x1x1 Blocks but I just render about 400.000 of them around the player (like in Minecraft) for performance considerations. Still I want that all 40+ Million Blocks are checked for collision. Right now I'm creating a collision shape from the visible meshes (yes, wezrule, thanks for the hint but I know that already) - but as already said I want to have all blocks considered for collision. Because they are organized in an octree it is quite easy to cut of over 99,99% of them at each physics iteration but only if I can define my own implicit (not on a mesh/box/sphere based) shape. JBullet only needs to ask me which objects to consider for collision. So is there a way to do that?

I know this is a complex matter so maybe still it is not any clearer to you what I mean - if so please just say so - no need for insulting questions like "Did you look at the api at all?" - I just want some help and I know you just wanted to help me :)

PS: This is the game I'm talking about - maybe this makes it any clearer :)

Minecraft does not use box meshes, it uses only a few meshes that are the surface of lots of boxes (look for “voxel” in the forum) and you should do the same if you want to get this running in any performant way.

For the physics part I suggest not making one huge collision shape as everything would have to be computed in the nearphase. Just keep some collisionshapes and rigidbodies handy that you move in place when the player (or anything thats interesting) approaches. Simple forms that often occur on your surface, think like tetris blocks. If something happens in two places that are not interconnected, you also have a chance to use multiple physics spaces in parallel (BulletAppState provides this functionality).

If you really only use blocks you can have much cheaper physics when you create it on your own however I guess, especially when you are more looking for collision checks than physics simulation.

normen said:
Minecraft does not use box meshes, it uses only a few meshes that are the surface of lots of boxes (look for "voxel" in the forum) and you should do the same if you want to get this running in any performant way.
[...]

I know - maybe you should really look at http://moebius.darkblue.de and see how far I already am. I'm not working with boxes of course - I use custom meshes for every sector.

normen said:
[...]
For the physics part I suggest not making one huge collision shape as everything would have to be computed in the nearphase. Just keep some collisionshapes and rigidbodies handy that you move in place when the player (or anything thats interesting) approaches. Simple forms that often occur on your surface, think like tetris blocks. If something happens in two places that are not interconnected, you also have a chance to use multiple physics spaces in parallel (BulletAppState provides this functionality).
If you really only use blocks you can have much cheaper physics when you create it on your own however I guess, especially when you are more looking for collision checks than physics simulation.

Sure - that is what I also concluded. I just wanted to make sure that I'm not missing a possibility to stick with jBullet ... so I guess I will start writing my own block physics engine ;) - thanks for the insight :)

Looks nice, congrats. Really going with blocks only will make it hard for the engine to stick out I guess though. Simply using your existing surfaces as collision shapes for raytracing should be no issue though. You’ll have to check for the performance tradeoff with the size / count of the objects empirically but theres no reason why you shouldn’t be able to use bullet for just ray/volume collision checks or complete physics. I don’t understand what you mean by “creating” or “delivering” the data, you have the data you need if you have a surface mesh already, just create a collision shape from that.

normen said:
Looks nice, congrats. Really going with blocks only will make it hard for the engine to stick out I guess though. Simply using your existing surfaces as collision shapes for raytracing should be no issue though. You'll have to check for the performance tradeoff with the size / count of the objects empirically but theres no reason why you shouldn't be able to use bullet for just ray/volume collision checks or complete physics. I don't understand what you mean by "creating" or "delivering" the data, you have the data you need if you have a surface mesh already, just create a collision shape from that.


That's what I'm already doing. But what I want to do is to have mobs/npcs that are persistent - that means that they explore the world on their own - they don't need any rendering but they need physics simulation and collision handling even in the parts of the map that are not currently materialized/rendered as meshes. Just for the player itself jBullet works quite well :)

As said you can multithread your physics spaces, so make a new one for the npc’s in other places. If that does not work on your hardware you should maybe rethink the strategy here. No game really lets a whole world act itself out, you should probably reduce the processing of areas that are not seen by humans. I was able to achieve about 80-95% accuracy for a space simulation where I would reduce the economy in one star system to an approximation of what would happen if they actually acted it out.

If you really want to do what it sounds like you want to do (that is an large sized world and player count, autonomous AI all over the place and multiplayer) then theres no way around a) a really strong server and b) thinking out how you use your data for things like pathfinding very well. Then theres still no reason not to use bullet physics for the actual physics and collision, the data in the form of vectors etc. will always have to be there and if you don’t just want blocks you won’t create a much more efficient physics and collision engine over night.

The question is how you use what you have, e.g. having like 1000 boxes dangling on ropes all over the place or 10000 balls rolling all over the universe triggered by NPC’s playing in the street… No computer will give you that just like this… What are you actually trying to do when you say “it doesn’t work”?

I don’t say it doesn’t work. Problem is that I’d have to create collision shapes for the not rendered parts of the world for the npcs (and no I won’t allow too many of these “persistent” npcs). But maybe you are right and I should just do that because jBullet is a nice engine and I surely won’t build something like it over night. So every npc needs it’s own BulletAppState?



Still there is another problem which might also be related to how I use jBullet - but I’m unable to relay the creation of a collision shape to another thread. There seems to be a concurrency problem involved that sometimes leads to exceptions deep within the physics engine. Is there a way around that? Right now I’m synchronizing the creation of collision shapes with the main rendering thread - but that has some disadvantages.



And is it possible to simulate the physics space without any rendering? You mentioned earlier that rendering and physic engine were completely separated?

Of course you have to cope with the offscreen-data… It was your premise to do that ^^ Also, you can create collision shapes and rigidbodies just fine on other threads. Adding the actual rigidbodies to the physics space obviously has to be done on the correct thread. Did you seriously ask me if there can be physics spaces without rendering? Anyway yes, thats easily possible, implicitly as well as explicitly xD

Ok - I’ll test that out - thanks for your help :slight_smile: