3 ms·

I was writing my own 3D engine for some time also. I decided at some point I would not venture into physics, that is where I would draw the line. Then I unders

I was writing my own 3D engine for some time also. I decided at some point I would not venture into physics, that is where I would draw the line. Then I understood that even doing proper collision detection would mean having to implement some kind of physics in order to do proper frame independent linear interpolation of objects moving in 3D space, in order for the objects not to go through each other if the movement step is too big and also to do proper moving of objects anyway in 3D space, as you can't just expect to linearly transform an object from one place to another, as framerates might wildly differ and the object might go through another if the frametime would be too big for this particular frame we are rendering. That is where I just stopped, and decided that it was too much work to do anything proper by myself, and gave up on writing my own 3D engine. I see many people are going through this process, writing their own engines and libraries. Somebody told me when I started I should use an existing engine, but I didn't listen. And that is a good thing, and at the same time, wasting time to do something that could be done using existing libraries or engines. This is what I feel anytime I see somebody write about them re-inventing the wheels, but I guess it's a process that many choose to go through for learning and fun purposes.

flohofwoe 6y ago
Quite a few physics engines don't help much with this particular problem though. If you step the physics world in too large or variable intervals (e.g. once per frame), then small and fast objects can still tunnel through thin objects without registering a collision, you need to tweak the step size for your specific scenario (smallest and fastest objects), call the step function in fixed intervals several times each frame, and carry the last remaining 'time slice' over to the next frame. And since the obvious next question is: Why don't all physics engines implement a "proper" continuous collision system? I guess because checking collision in discrete steps is a lot cheaper, so that it may be an acceptable tradeoff if one knows the tunneling problem exists and how to work around it.
l33tman 6y ago
I also designed my own 3D engine but after attacking the physics engine, I quickly (and, never regrettably!) switched to the open source Bullet engine instead after going through its code. I would never have the stamina to write that, and all that code and bunch of algos are really necessary for doing physics in "free world" games like mine. Btw Bullet has continuous collision detection. It's not fundamentally magical - you extrude a hull of the shapes to do CCD on along their velocity tangents and collide the hulls instead of the shapes. This effectively solves the problem of bullets or other fast moving objects going through walls etc. (this is why the engine is called Bullet btw) Actually the most difficult problem I had with the physics was the player physics, as its usually not handled by letting the player be a normal physics body (for gameplay reasons). The player shape can easily get caught up on infinitesimal seams between polygons and edges in the world around you. :)
TeMPOraL 6y ago
> proper frame independent linear interpolation of objects moving in 3D space Reminds me of another thing - back when I was trying to write my own 3D engine, I've never heard of the concept that you interpolate physics state between rendering frames. Something that's considered table stakes today. When and how did that arise?
- andrewflnr 6y ago
  I've never heard of that either. I thought you were just supposed to fix your physics timestep and sort the graphics out later.
  - TeMPOraL 6y ago
    From what I vaguely understand, the goal here is to reduce jerkiness if you render faster than you tick your physics. But then I always thought that beyond stability, the other main reason to make your physics time step independent from rendering is so that you can tick physics more often than you draw. (Thinking about it now, I suppose this trick lets you update physics less frequently than drawing while faking fluid movement, and free up CPU time for other tasks.)

flohofwoe 6y ago

Quite a few physics engines don't help much with this particular problem though. If you step the physics world in too large or variable intervals (e.g. once per frame), then small and fast objects can still tunnel through thin objects without registering a collision, you need to tweak the step size for your specific scenario (smallest and fastest objects), call the step function in fixed intervals several times each frame, and carry the last remaining 'time slice' over to the next frame. And since the obvious next question is: Why don't all physics engines implement a "proper" continuous collision system? I guess because checking collision in discrete steps is a lot cheaper, so that it may be an acceptable tradeoff if one knows the tunneling problem exists and how to work around it.

l33tman 6y ago

I also designed my own 3D engine but after attacking the physics engine, I quickly (and, never regrettably!) switched to the open source Bullet engine instead after going through its code. I would never have the stamina to write that, and all that code and bunch of algos are really necessary for doing physics in "free world" games like mine. Btw Bullet has continuous collision detection. It's not fundamentally magical - you extrude a hull of the shapes to do CCD on along their velocity tangents and collide the hulls instead of the shapes. This effectively solves the problem of bullets or other fast moving objects going through walls etc. (this is why the engine is called Bullet btw) Actually the most difficult problem I had with the physics was the player physics, as its usually not handled by letting the player be a normal physics body (for gameplay reasons). The player shape can easily get caught up on infinitesimal seams between polygons and edges in the world around you. :)

TeMPOraL 6y ago

> proper frame independent linear interpolation of objects moving in 3D space Reminds me of another thing - back when I was trying to write my own 3D engine, I've never heard of the concept that you interpolate physics state between rendering frames. Something that's considered table stakes today. When and how did that arise?

andrewflnr 6y ago
I've never heard of that either. I thought you were just supposed to fix your physics timestep and sort the graphics out later.
- TeMPOraL 6y ago
  From what I vaguely understand, the goal here is to reduce jerkiness if you render faster than you tick your physics. But then I always thought that beyond stability, the other main reason to make your physics time step independent from rendering is so that you can tick physics more often than you draw. (Thinking about it now, I suppose this trick lets you update physics less frequently than drawing while faking fluid movement, and free up CPU time for other tasks.)