Again this was made if you want your game to use simple physics for not going through walls, and doesn’t need to have the full blown Bullet physics. Bullet recreates every triangle in your scene using it’s own triangle objects. So if you have a game like Minecraft, you’re almost doubling the memory usage of your game.
Uh, depends on how you set it up. Making every triangle collision detectable would drive your framerate into the ground so hard that it would threaten to tunnel right through the Earth and end up on the other side.
Usually that’s how some of the static terrain is set up but anything that moves is usually handled with mathematically defined primitive shapes that are super fast and some very simple hull colliders in some cases. At least that’s how I use it.
Again looking at the example of Minecraft, every part of the scene is collidable, and yes that was driving my framerate into the ground and my memory.
If you want to use Bullet that’s cool. It wasn’t working for me.
Hm well if you want a collision system exclusively for a voxel world you essentially have to only do sphere/capsule collision with axis alligned bounding boxes.
I’d have a hashset of all existing blocks in a chunk and check a small radius around an object for them and then do some object.x > block.x and so on checks. This wouldn’t be very good for any free rotating stuff though.
I wonder what @pspeed did in mythruna…
That was an example, my game isn’t a voxel game.
Can we keep to the topic? Either people want this or they don’t. I’m not arguing there are other solutions to different game types. A swept ellipsoid is a common way to solve collision detection and response in games, so I don’t understand the problem.
Yeah, sorry for going on a tangent. This just really bothered me about our bullet some time back and can’t help but rant about it every so often.
This is a usefull addition, especially for eg. mobile games with limited ressources, as bullet can be to heavyweight there.
I just wanted to clarify a common misconception that has come up in this thread. IEEE Floating point rounding is deterministic. You can absolutely have “physics” in lock step on different clients and they don’t go out of sync. Identical bit perfect input results in identical bit perfect output. It is not even all that hard to do and is easier in java than many other langs. Use the strict keyword!
In C/C++ you must force strict IEEE math since x86s have a 80bit temp register that get rounded back to 64bits on a stack pop/push (which can happen at any time with a context switch). But again is still entirely possible.
Games have done this. Most notable is probably Supreme Commander and Forged alliance. I think they even have a gamastra article about it.
Ugh I can’t seem to get it to work reliably when there are multiple triangles to collide against. Especially if the slide planes aren’t perpendicular. Maybe my screenshot will explain better.
The first (top) slide plane makes the sphere go down and right, which basically makes it end up in the floor. Then the floor says you need to move horizontal right (thus going through the top box).
Isn’t collision resolution great? (And by great, I mean a total pain.)
This code looks really good; I’m in the middle of developing a game and have decided that JME’s standard physics is overkill for me, and there doesn’t seem to be any other “simple” physics library. Can I just ask what particular problem this solves, or what features it has over and above standard collision checking?
Like you said it’s meant to be simpler, and better if you want more control over the physics (for either better character movement or maybe networking). I never solved the double collision issue above, and the papers that describe this collision detection don’t even mention the problem. Maybe you can solve it?
- Get picture of me.
So is it a drop-in replacement (-ish) for RigidBodyControl?
No not really. It has a lot less steps. If you look at my Gist above there is an example. Really you just define a collideable ellipsoid and apply velocity to it.
For what it’s worth, writing a simple physics library is drop-dead simple.
v = v + a * t;
p = p + v * t;
That’s physics. Done.
Even simple collision detection and restitution is not hard… if you only want spheres (or spheroids) and if you don’t care about rotational acceleration.
The problem is that as you start adding the “oh, but that’s still simple just not as simple” things… the complexity goes up exponentially.
“I want to support non-spheroids.” = complexity nearly at bullet level
“I want to support rotational acceleration/velocity in 3D space” = complexity nearly at bullet level
Otherwise, the math is only a few lines of code, really.
When I was looking for a “simple” physics library, I was looking for something that handled “simple” gravity (i.e. go down if nothing is in the way), notifies of collisions, and prevents intersection. It can treat everything like a sphere (or whatever’s easiest). And ideally works in the same thread as the main update thread. It can leave out things like rotation, mass, friction, restitution, acceleration, rolling, etc… Know ye of such code?
So while Bullet is pretty featureful you can just use whatever it is you want. Implementing simple gravity is ridiculously easy. As in when you create a rigidbody by default it has gravity and will happily fall endlessly without a floor collision object (For my space game I had to make sure to use setGravity(Vector3f(0,0,0)) to stop gravity from dropping my ships through the floor).
To stop things like rotation look through the forums for examples like here: Lock Z axis - #13 by m4tx
Edit: Basically saying to just use Bullet. It’s fine and not that scary once you follow the tutorials.
Nah, because it’s only like 10 lines of code. Anyone who needs it probably just inserts it where they want.
I’ve used Bullet lots of times for various games, and it works great. I’m writing a multiplayer FPS as the moment though, and it’s overkill for my needs. Such a game is pretty CPU intensive as it is, so I’m trying to streamline it. Also, it sometimes has some problems (e.g. falling through floors) which exponentially multiply the complications when making a network game.