I have the code pretty much working. Would just need to adapt it to be reusable.
Why I made it: Bullet seems like overkill for just simple games. It’s also very finicky as far as mass, world size, etc.
Bullet also duplicates all the triangles in the scene which wastes memory. I’m not sure how this would compare to bullet as far as CPU usage.
Edit: Okay I’ve got the preliminary code ready
Just add a CollideableEllipsoid to your code, call collideWithWorld and supply it with position, velocity, and the triangles to check.
My example isn’t 100% a swept sphere though. You’d have to get a bounding box that spans the current position and possible destination position.
Main.java shows a simple example.
GetCollidersExample shows another way to get the triangles by using 2 boundingboxes.
Please note there is a bug with ramps I can’t figure out… Maybe you guys can help solve that issue.
Hah, in one case it’s better than bullet since it has elipsoid colliders. JBullet doesn’t support them at all and jme’s native bullet doesn’t have a binding for them afaik.
This could be very useful as their is bug in the version of bullet JME uses that causes the capsule to think it’s stuck on a flat surface. It can worked around but it’s a pain in the arse having to rewrite the pre and post physics ticks when they should work as intended.
Just a side note: bullet supports ellipsoid collisions, our implementation of bullet just doesn’t support it. From what I saw it would be pretty simple to add.
My case was I needed strafe jumping and better control over the physics. So my solution was something that said “if I move here don’t go through this wall and slide along it”. This gives me control of gravity, velocity, etc. I also never had any luck with Bullet. The CharacterControl and BetterCharacterControl always had problems such as vibrating, climbing walls, steps not working, falling through the floor, etc. I also had no need for full on physics. I think this is a good thing for people wanting to make simple games that don’t have AAA physics.
Edit: Just to add I tried to use Bullet’s built in swept sphere, but had no luck. Mostly due to sinking through the floor.
Also for multiplayer I don’t think Bullet is deterministic. So that was a no go.
Not necessarily, I think Riccardo said it’s possible to just grab the new build separately and replace jbullet in 3.0. Not that I have much of an idea how to do that mind you.
And so isn’t any other physics engine that uses floats or doubles in any way for that matter. Even if you’d somehow use integers there’s still a possibility of fps loss that would make everything go out of sync.
If you’re doing physics and multiplayer then you need to have the server do the heavy lifting and add client side predictions.
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.
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.
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.
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).
