Hi Erwin, Thanks for trying it out.
For the character controller I'm using a rather old-school system. The gameplay is just first person so I can get away with it. It is continuous in that it projects a path to determine if there are any collisions and then adjusts the path (project onto collision plane) as necessary. When you're in "jello world" it's similar except that it uses a smaller sphere sweep test against the polygons in the vicinity. Ideally I would like to have a more unified solution for all things in motion.
My physics code isn't exactly the magic bullet of physics engines
I didn't want to invest too much time recreating something that you (and the other physics engine authors out there) have already perfected. I just created enough to give me the basics and in a way that I could experiment easily.
The rigid bodies (gems and bricks) use discrete distance checks. I used the easy approach of just finding and adding at most 1 body-body contact per timestep. So if things are moving fast enough then the contacts are lost as fast as they are added. The gems use a position constraint type of grab with a maximum force just enough to keep the gem where you are holding it as you turn and move about. The bricks use a spring grab. For ccd I just use a small sphere sweep against the environment after the impulse solver phase. You might have noticed that if you carry a gem and move along a wall, such that the grab point is behind the wall, then the gem wont slip through, but it might jiggle instead of sliding smoothly along.
For calculating the weight on the balance I actually use the value of the impulse on the joint holding up the apparatus. If you directly grab the teeter balance and apply force to it and look at the scale on the wall you can see how it changes the "weight".
For non jointed objects, the physics update conserves angular momentum. Its a no-brainer, but you have to use runge kutta to update the orientation. If you turn of gravity and watch a long rectangular box spinning then you can see the difference compared to constant spin.
For GJK, instead of hillclimbing, I took your advice and just iterate over all vertices to find support points.
In addition to rigid body dynamics there are other systems at play...
The jello thing uses a voxel based approach. The other digging uses a bsp merging approach. When the game starts up it merges all the hallways, rooms, and ramps together. The moving csg still uses bsps but just for quick clipping instead of commiting the result back into the hierarchy. So potentially you could have lots of moving holes in a scene. Any of these systems would be a good candidate for parallel processing.
I'd like to focus more on the fun tech and the specific implementation/optimization details but then there's all that other stuff a project needs such as rendering, windows hassles, sound, recording guitar riffs, art creation, fixing textures, making heightmaps, game design etc..