… well, it’s available if you agree to some terms and whatnot.
https://developer.nvidia.com/physx-source-github. But hey, it’s a start.
On twitter?
It’s gonna be hard to put the whole code in series of 140 characters tweets 
1 Like
You dont want physx anyway 
Bullet has way more stable behaviour:)
Kinda tempted to test the 3.00 prefeatures in the unstable
Is it sarcastic or not? I’m a n00b in physics, but I think PhysX has more features. Am I mistaken? 
But it misses basic sanity checks,
like if two objects collide that the total energy in the system must stay roughly the same.
Ever saw physx vehicles in action? No thanks.
Any idea why they do that?
Well the same reason as always, performance.
“Hey we know its wrong, but its super fast wrong”
I would say there are reasons you rarely if at all see phys outside of games, while bullet is often used in simulation context for robots and similar.
I’m 1000% speculating, but having written my own physics engine from scratch, I can guess a few things.
There is a form of physics engine (this is what mine uses) where you let objects interpenetrate just slightly and then use collision resolution to ‘fix’ it. So your objects are kind of constantly falling just slightly into what they are sitting on and then getting corrected. When they are stable, the motions are really small and the objects go to sleep anyway. (I also use annealing in my engine to improve accuracy of individual collisions as ‘temperature’ goes down… ie: the less they move the more accurate they move… but I digress.)
The main benefit of an approach like this is that it’s stupid-simple to run objects in parallel. Everyone moves, everyone collides, everyone repulses a bit… and each stage can be multi-core parallelized. The GPU based physics approaches I’ve seen operate pretty much this way also. Throw the acceleration, velocity, and position updates at all the cores. Then throw collision detection at all the cores… then throw restitution at all the cores. Any errors get sorted out the next frame, or the next.
The downside is that you have no real control over the “total energy”… because you have no idea what the total energy is. (The object physics is done one object at a time.) And even if you did know, tiny impulse errors would ruin you.
(…this is why stacking objects in my physics engine sometimes explodes and said objects end up all over the place.)
I can only guess that PhysX might be doing something similar though honestly I haven’t looked even slightly.
I’ll tell you what, though… every time I see this type of instability in “professional” physics engines, it gives me a unique sense of glee. When I walk into a room in Fallout 3 and some object is clanking around trying to settle… I give a silent cheer. 
Wait. Are you trying to tell me that all that “PHYSICS ACCURATE NVIDIA PHYSX ULTRA REALISITC GEFORCE POWERED” is a lie?
My gaming life is ruined! :chimpanzee_cry:
Well, there is no way to do accurate physics on a computer in real time with more than two bodies… something’s gotta give.
bullet does work the same way btw. So that can’t be it alone, maybee bullet has a verify phase after the overlap calulation? I dont know.
Btw apparently it does even on gpu not have problems with stuff stacking several boxes high.
I understood that bullet used a jacobian to solve multiple constraints at the same time… but admittedly I don’t understand how a jacobian really works so I could be wrong.
Also, sweep tests implies that it wants to stop objects before they penetrate… which is another type of physics engine resolver.
With the type of physics engine I’m talking about, it’s easy to see why things get unstable even with just two or three boxes stacked. Stacked boxes slide down a little in a frame. The bottom one interpenetrates the ground slightly and so is pushed up. The second box is now penetrating the first by double the amount and must be pushed up twice as much… and so on up to the next box. Eventually someone wants to blow up. It’s especially nasty if you can’t accurately determine the flatness of the different layers, ie: the restitution forces are slightly non-vertical… things vibrate and slide apart.
A different type of resolver doesn’t operate this way. It detects that the objects will penetrate but stops them short of doing so… thus you don’t have to overcorrect everyone in the stack since none of them actually moved at all. It’s just more complicated… or at least I could never wrap my head around it in 3D.
It could be that my engine’s problem is something else… but while I could stack one crate on another if I was very careful and centered it carefully, I could rarely stack a chair on a table and never stack a table on a table (mesh accurate collisions in both cases). (Note: I have an approach for fixing this in my case… but it’s beyond the scope of this post. :))
Did you notice the margin bullet uses? It is basically exactly usefull for stabilizing this kind of problems.
As mentioned earlier, I know next to nothing about bullet. I think the proper spelling is “bullet”… and that it’s a physics engine.
That is the sum total of my knowledge about bullet other than reading articles on Jacobian matrixes and how they are supposedly used in physics engines like bullet. But perhaps those are totally wrong.