Thanks guys. This all really helped.
I will have a large body ratio problem. I wonder what the limits to that look like.

I wonder if neural networks can take a cluster of particles and roughly predict the next state they will be in. I think that may help with certain chunks in the simulation.

I don't think my size ratios need to be extreme, but I think 1 to 100 is a good limit.

I posted this, then forgot about it. I wish i had alerts set up better. I will read the rest and get back to this.

2 hours ago, Fulcrum.013 said:

Really single body dynamic involving a Newton laws and law of summing forces and torques. So its is simple  for understand and implement. To extend it to multibody dynamics is require to compute response impulses of contacts only.

What i did to solve for forces is this: Calculate forces between pairs of bodies in contact, sum them up for each body, and repeat this process iterative. 

This dates 20 years back. I always thought this is a very naive approach and there should be something better. I've got stable stacks from it, but it was not good enough for large mass ratios. I tried to cache contacts and reuse forces for the next update, but this alone did not worked well. IIRC, it did not converge and bodies did not get to rest or there was jitter.

Are there better methods?

The other issue i've had was motorized joints for robotics, for similar reasons. Joints have been too soft, and increasing iteration count decreased performance quickly but improved results slowly.

So i gave up and used physics engines instead. I noticed they have the same problems, but they had more features. Finally i found Newton engine, which managed to solve those problems, recently using a graph based solver similar to Featherstone, but force based - as far as i know.

So i will not work on those things again, but if you'd describe the usual way to solve those constraints, i'd be very interested. Having bad education about math, i always need to reinvent wheels and i'm never sure how others do it, because i do not understand their language. I wonder why you say it is simple, so maybe you have simple description for dummies...

(Collision detection / contact generation is, although complicated, much easier to learn for a person like me. I've had no problems there.)

38 minutes ago, NoAbsoloops said:

I don't think my size ratios need to be extreme, but I think 1 to 100 is a good limit.

Sounds like a big problem. 1:100 is huge.

This means potential high divergence on GPU: Larger bodies need to check MUCH more nodes/cells for collision detection. Same for calculating response with many tiny bodies. But this can be likely solved by binning bodies by size, and running one compute shader dispatch per bin. This way divergence can be reduced a lot, and async compute can run all dispatches in parallel. Sounds good but in practice it may be still an issue i guess.

The larger problem is probably robust simulation. Large size ratios means large mass ratios too. Or can you use similar mass for small and big bodies? (I asked for how to handle large mass ratios myself just before in my previous post...) Also, large bodies having many contacts with tiny bodies will likely cause heavy jitter. You'll have to cheat: Use large sleep thresholds, things like shock propagation, etc. This solves some problems but also introduces new problems.

Another option would be to store and simulate physical properties in the grid cells instead of individual bodies. E.g. average velocity / density per cell, similar to how grid based fluid simulation works. Then you drive the bodies by the resulting grid velocity vector field. I don't know if PhysX particles already do this, but if you can afford some inaccuracy, this might be the way to go. (And why don't you use PhysX? It's NV exclusive, but you could check out what's possible there.)

Can't comment on Neural Networks, but here's some research i've found: https://homes.cs.washington.edu/~barun/files/icra17_se3nets.pdf

If you can, you should tell us more. What kinds of geometry do you want to simulate? Breaking buildings the player can interact with? Or just some debris flying around after explosions, but not affecting anything?... makes a big difference.

50 minutes ago, Fulcrum.013 said:

while it it works by mechanical statics rules.

How do you do this? Does that mean you build a large system of equations, e.g. all bodies that form an island, and solve for the exact solution?

If so, is this utilized for games, or is it common to solve contacts unrelated of each other simply by accumulation and iteration (the 'naive' approach, which worked well enough for me and did not cause jitter, but was not perfectly stiff of course).

1 hour ago, Fulcrum.013 said:

Did you mean a Inverse Kynematics solver?

You mean Inverse Dynamics? An IK solver would be of use only to control the target position/vel/accel of the joints. My question is how to calculate the necessary joint torques / forces to get there, e.g. for a robot consisting of many bodies? The problem is pretty similar to the calculation of resting contact forces, but contacts act only in one direction, so i assume both require / allow different approaches to solve them. I would be happy to understand just one.

16 hours ago, Fulcrum.013 said:

this task comes from hoisting-and-transporting machinery so have solved on ancient ages.

Ok, but the algorithm you describe assumes a static base, which makes it easy. But what if it is a walking robot standing with two feet on the ground (or worse: standing on stacks of dynamic boxes) - in that case feet contacts form a cycle and calculating a solution becomes hard, probably leading to using the algorithm within iterations in hope to converge towards an acceptable solution.

If i would try to apply your algorithm to the resting contact problem of a pyramid stack (so each body has two bodies below it), i could do so by forming something like a spanning tree and traverse it from bottom upwards to get quick and pretty exact contact forces. But in the next frame the tree may look slightly different, choosing different paths. Result, in comparison to the naive approach, would be increased stiffness, but unacceptable jitter. (I remember i've tried lots of things like this.)

So i still do not see a 'simple' way to do rigid body simulation. At least not if we desire more complex simulations than some boring boxes standing around and doing nothing and some dead ragdolls.

16 hours ago, Fulcrum.013 said:

I guess something like this shown on video at 2:40.

I remember i've experimented with shock propagation es well, and it had some bad side effects for me so i dropped the idea. It's one of those many failures that led me to the conlusion: Either you do it right, or it does not work. You can fake graphics, but not physics.

But this really depends on your goals of course - they want' massive stuff, not accuracy.