9 hours ago, JoeJ said:

To me it is not, it is an open research topic.

However, if you, somebody who is more involved in physics than myself i guess, says it is simple,

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. This calculation involves again Newtons laws that is simple,  and compuing of contact points and normals that can be very very complexive. But collision detection and prediction is a analitic geometry, not a phisics. And it really can be very complexive. For example convex aproximation of bodies is simple, but have a quaric computation complexity and gives inaccurate normals. Curved approximation is more complexive to understand, but in most cases have a linear complexity and normals is allways accurate. But with extending complexity of bodies, growth complexity of math involved to collisions detection .  Some time it bring problems that very hard to solve, becouse tools of solutions is not works. For example the separation axis theorem will not work for curved torus, becouse it can not be cuted to convex bodies.

Just looks like you studing to become a Software Engeneer, and all your dreams about making next-gen gaming engines. Feel the difference with just a gamer that call something a phisics. To make engines you  have to know how exactly it works inside and have skills to research something that nobody implemented yet. But to do it, at least required to know what same branch of phisics and mathematics involved, just to know what same to research and what same books can help with it.

Just for example tehcnique with aprroximation of bodies by grids of paricles comes from CADs, where it used at least for 15 years for advanced soft bodies simulations (really nothing is ridgid in real word). Only problem that this technique have - is huge memory requirments to model a complexe world. So to be used for games it require just to find a fast algo to convert curved bodies to grid approximation when it waked up or have other moving objects that anble to affect it. In case guys that made this demo has find this algo, thay really genious.

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.

10 minutes ago, NoAbsoloops said:

I wonder if neural networks can take a cluster of particles and roughly predict the next state they will be in.

Clusters of  particles is not a neural networks at all. It is tool that allow to mix efficiency of Euler grids approach with flexibility of Lagrange volumes approach for integration of finite difference schemes. Also it makes collision detections friendly to GPU by replacing complex curved  surfaces, wich collision detections about imposible to vectorize, by sets of multiple spheres, wich collision detection is perfectly vectorizable on GPU cores.   

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.

25 minutes ago, JoeJ said:

This dates 20 years back. I always thought this is a very naive approach and there should be something better.

Really this approach has been made by sir Iasaak Newton and it can not be other approaches. Any issues depens  from how preciously Newton's approah calculated. Also, impact forces can nod be calculated at all, so usualy dynamics simulation works with impulses instead of forces.

49 minutes ago, JoeJ said:

it did not converge and bodies did not get to rest or there was jitter.

Any issuses wih resting contact comes from simulating it by mechanical dynamics rules, while it it works by mechanical statics rules.

53 minutes ago, JoeJ said:

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.

Did you mean a Inverse Kynematics solver?

1 hour ago, JoeJ said:

Larger bodies need to check MUCH more nodes/cells for collision detection.

I guess thay has marked border particles and test collisions for its subsets only. Also as shown on 2:48 thay use some kind of collision prediction. It very robust approach, something like sending  moving body's distantion mesuarment subsystem , that replaces collision detection, to rest until it get closer to other body. As result it detects impacts with high accuracy, instead of detecting interpenetrations.  This technique has been described by Brian Mirtich into his PhD dissertation at middle of 90-x, but i never seen it implementation into gaming engines before. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.108.783&rep=rep1&type=pdf

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.

3 hours ago, JoeJ said:

An IK solver would be of use only to control the target position/vel/accel of the joints.

It just requite to understand on visual level how IK solver works. Each step it calculates a consequtive positions that moves actuator from start position to target position. So for each position we can propagate back gravity toque and inertion momentum respectively to joint axis of each actuator part, and recalculate each motor torque from it  and required joint's angular acceleration. By other word, in static last joint motor's holding torque have to be eual to  gravity torque that is production of last part mg vector to leg betwin joint and last part centre of mass.  Pre-last joints motor holding torque have to be equal to   gravity torque of both last and prelast legs, so we need to recalculate mass center of both last and prelast parts and then find a torque. And so on until stand's motor.

 In dynamic motor torques have exids holding torques by value required to accelerate joints. to calculate this extra values from acceleration we need just a inertion torques of parts attached to joint respectively to joint axe, that we can recalculate for each joint similary to recalculation of mass centres.

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

3 hours ago, JoeJ said:

f 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).

Chache contacts and threat it like kind of joinnts, with chached contact normals and static friction forces. So on collision with other object collided object first have to  decide is joint has been broken and respond like a dynamic object or respond like whole joined system. after respond, island have to propagate received energy thru the chached joints and wake up bodies that received enought energy to break joints. 

I guess something like this shown on video at 2:40. In case thay has chached nothing, thay have to make exactly two  iterations thru the island - first iteration to find masses attached to the joints, constant friction forces, centre of mass and moment of inertion of whole island, and second iteration to propogate energy. 

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.