Note the use of pointers, this forces other systems to take care of the actual storing of objects, leaving the physics engine to worry about physics, not memory allocation.
The wording makes it sound clever, but now we’re just jumping around memory and this system is now 10x slower than it could be :/
Why? They could all be pointers to memory blocks that are close to each other, and the allocator for this type of object could just return from there (eg. arenas). The main issue seems to be that you can’t ever “move” any object now bc. all of the pointers to it would be invalidated. So maybe it’d’ve been better as a ‘sparse map’ (id map to indices into a contiguous array, when you delete you can swap the last element in keeping elements contiguous); but it depends on tradeoff between that map lookup and complete contiguousness.
This material was presented nicely, and gave a good overview of the main phases of a physics system, but didn’t really cover the gnarly bits of physics engine implementation. I’ve gone down the rabbit hole of trying to implement my own physics engine before, and if you want generic convex hull/convex hull collision detection (which most modern games use – not just sphere/sphere detection), the code becomes a whole lot more complicated. The standard algorithm in use is GJK, which has some elegant ideas embedded in it but for a practical 3D use case, is a lot of painful cases to implement. Once you’ve implemented, I’ve heard of serious numerical issues that lead to subtle collision detection bugs that are hard to track down. I wish there were some more robust alternatives that are easier to implement, but I haven’t found anything…
That was enough to scare me away – I’m at the point where I’ll just use an implementation of a physics engine with moderate popularity in the hopes that it’s battle-tested enough to have some confidence in.
GJK and SAT upset me, because looking at the literature everybody’s consensus is “oh this is a solved problem, just go see the talk by person” and then when you actually try to build it it’s just a colossal pain in the ass.
And god forbid you’re trying to do any of this in, say, a functional language with immutable data. That’s just a whole exercise in fun. >_<
Not OP but if you’re doing 3D PhysX is by far the best, because of the docs and PVD.
Bullet is trash, I don’t know if the actual library itself is bad but everything around it is. The only docs you get are a 10 page outdated pdf. If you try to google anything you just get the same unanswered questions on their forums. There’s a bullet3 which seems to be an AMD tech demo to get people to care about OpenCL that ended up being shipped with zero documentation. The debugging stuff is a pain to set up and kills perf.
For 3D physics, there’s always Bullet which is old, but pretty standard. I’m going to give nphysics a shot for a new project of mine. And if you don’t need anything besides box detection, qu3e looks like a nice lightweight alternative.
The wording makes it sound clever, but now we’re just jumping around memory and this system is now 10x slower than it could be :/
Why? They could all be pointers to memory blocks that are close to each other, and the allocator for this type of object could just return from there (eg. arenas). The main issue seems to be that you can’t ever “move” any object now bc. all of the pointers to it would be invalidated. So maybe it’d’ve been better as a ‘sparse map’ (id map to indices into a contiguous array, when you delete you can swap the last element in keeping elements contiguous); but it depends on tradeoff between that map lookup and complete contiguousness.
This material was presented nicely, and gave a good overview of the main phases of a physics system, but didn’t really cover the gnarly bits of physics engine implementation. I’ve gone down the rabbit hole of trying to implement my own physics engine before, and if you want generic convex hull/convex hull collision detection (which most modern games use – not just sphere/sphere detection), the code becomes a whole lot more complicated. The standard algorithm in use is GJK, which has some elegant ideas embedded in it but for a practical 3D use case, is a lot of painful cases to implement. Once you’ve implemented, I’ve heard of serious numerical issues that lead to subtle collision detection bugs that are hard to track down. I wish there were some more robust alternatives that are easier to implement, but I haven’t found anything…
That was enough to scare me away – I’m at the point where I’ll just use an implementation of a physics engine with moderate popularity in the hopes that it’s battle-tested enough to have some confidence in.
GJK and SAT upset me, because looking at the literature everybody’s consensus is “oh this is a solved problem, just go see the talk by
person” and then when you actually try to build it it’s just a colossal pain in the ass.And god forbid you’re trying to do any of this in, say, a functional language with immutable data. That’s just a whole exercise in fun. >_<
If I may ask, what options out there did you consider?
Not OP but if you’re doing 3D PhysX is by far the best, because of the docs and PVD.
Bullet is trash, I don’t know if the actual library itself is bad but everything around it is. The only docs you get are a 10 page outdated pdf. If you try to google anything you just get the same unanswered questions on their forums. There’s a bullet3 which seems to be an AMD tech demo to get people to care about OpenCL that ended up being shipped with zero documentation. The debugging stuff is a pain to set up and kills perf.
Conversely, the PhysX docs are some of the best I’ve ever seen. With a few lines of code you get a standalone, rewindable(!) physics debugger. One of the guys who wrote it has a nice tips series on their blog.
For 3D physics, there’s always Bullet which is old, but pretty standard. I’m going to give nphysics a shot for a new project of mine. And if you don’t need anything besides box detection, qu3e looks like a nice lightweight alternative.