52 minutes ago, Oberon_Command said:

Yes, it's bad if your ragdolls vibrate when they're at rest, but nothing needs to be exactly accurate.

It's me who brought this up. I was not clear enough.

The problem is not that they jitter when they are dead, the jitter is only an indication of limitations that prevent living ragdolls.

I've tired the engines you have mentioned. None of those could keep a motorized ragdoll upright, or balanced or even walking. If you want to do this, you have to extend them with your own torque solver, or you use a physics engine with better accuracy.

I did the latter and it was possible to make the ragdoll walk. I don't have the time to continue on this, but i saw it would be possible to have simulated characters in games instead just animation. Yes, people don't care because they've never seen this yet, only in research videos which run at thousands of simulation steps per second. I did it at 120 Hz and the cost is not much more than for a regular dead ragdoll.

I can not prove to you this tech is ready for games, but i'm personally sure it's just lacking software. Hardware is ready since a decade. This means much more agile characters in games because they do not rely on static animation data for every movement they might need to do, and you know how the cost is to generate that data.

So if i'm right, we will see better games with lower costs, and then people WILL see the difference between this and the previous state of the art. And they will care and buy awesome next gen stuff as usual.

AI driven character animation has the same goals. Likely you are more open to this because it comes from more sources than just a single unknown guy like me, but it will happen and both approaches can be combined.

Do you agree this would be nice to have? Or do i run against a wall because you are more happy with state of the art as is and you doubt further progress is necessary? (In the latter case i promise i give up  )

In the former case there are many other limitations with physics that prevent us from doing stuff that would be fun (in a serious way, not just like the goats.) All this comes from lacking accuracy and robustness, shared by all major physics engines you have mentioned, leading to most game devs simply unaware of the limits.

10 minutes ago, JoeJ said:

I've tired the engines you have mentioned. None of those could keep a motorized ragdoll upright, or balanced or even walking. If you want to do this, you have to extend them with your own torque solver, or you use a physics engine with better accuracy.

In my experience, animators usually want a lot of control over the animations of living bodies and are not typically happy about yielding control to the physics engine. When they use mo-cap, they want the animations to look like the mo-cap. 

You can extend this somewhat to rendering, too. If the engine produces results that are physically accurate in terms of lighting, but not what the art director wants, then it's the engine that's going to change. Artist/designer/animator vision takes priority. "But this is what it really looks like" is not an argument that usually holds a lot of water.

10 minutes ago, JoeJ said:

This means much more agile characters in games because they do not rely on static animation data for every movement they might need to do, and you know how the cost is to generate that data.

Sounds great for indie devs without the budget for motion capture or lots of animators. Reminds me of this talk:

23 minutes ago, JoeJ said:

In the former case there are many other limitations with physics that prevent us from doing stuff that would be fun (in a serious way, not just like the goats.) All this comes from lacking accuracy and robustness, shared by all major physics engines you have mentioned, leading to most game devs simply unaware of the limits.

Well, in those cases, if the tech is known and the game needs it, then presumably that game will implement it. But heavily physics-based games are uncommon for a variety of reasons that don't involve the tech side. Game engines need to provide a common set of tools that all their users want; they try to serve the common case, not the exceptional case.

And yes, for many users of the major engines, the status quo is "good enough." Apart from the AAA space, most games don't push the limitations of their engine in any particular way. And when they do, the pushing is in the form of "how many things can I have on screen at once" and "how much art content can I stuff into this game."

16 minutes ago, Oberon_Command said:

In my experience, animators usually want a lot of control over the animations of living bodies and are not typically happy about yielding control to the physics engine. When they use mo-cap, they want the animations to look like the mo-cap.

Absolutely no problem when physics driven! I can playback mo-cap with full accuracy, as long as it conforms laws of physics (which can be bended at will, e.g. by huge max muscle powers). If you have the money for mo-cap, you can still do it. But you can also handle situations when no mo-cap is present.

16 minutes ago, Oberon_Command said:

You can extend this somewhat to rendering, too. If the engine produces results that are physically accurate in terms of lighting, but not what the art director wants, then it's the engine that's going to change. Artist/designer/animator vision takes priority. "But this is what it really looks like" is not an argument that usually holds a lot of water.

Same here. As Realtime GI is what i really work on: You still have full artistic control, but unlike before, you can make it look real. (at least much more real.)

16 minutes ago, Oberon_Command said:

ounds great for indie devs without the budget for motion capture or lots of animators. Reminds me of this talk:

Haha, you've uncovered my true motivation  ... may i once work an a game again, after all that tech... 

Overgrowth is great. It is one of those rare games that give me this 'plausible world' feeling. I really want this in games.

4 minutes ago, Oberon_Command said:

Well, in those cases, if the tech is known and the game needs it, then presumably that game will implement it. But heavily physics-based games are uncommon for a variety of reasons that don't involve the tech side. Game engines need to provide a common set of tools that all their users want; they try to serve the common case, not the exceptional case.

Yeah... i see this similar than the above too: It's easier to build a game upon working lows of nature and bend them at will than to start from smoke and mirrors. But that's not generally applicable to any game of course and much more subjective. So i would not argue here.