Unsteady simulation problem

[JoeJ]

Awesome! This will also fix the contact force issue i talked about and may help at the other problem i have

[Julio Jerez]

yes that will be the first I do, and the I will see if I can export a character with some basics posses as FBX files. The I can use for the prototype.
The more I think about this the more is make sense, I am sure it will be a few bumps here and there, but it all seem to come into place.

[Julio Jerez]

Oh it turns out the engine do have a function to make spring damper joint
void NewtonUserJointSetRowSpringDamperAcceleration (const NewtonJoint* const joint, dFloat springK, dFloat springD);

I just need to redefine that function so that is it using the proper constraint row instead of applyng the acceleration naivelly to the right side of the equation like is does now. This should be quick very to get joint.
After I made the change I will set the joint with a target position when all joint angle are the identity rotation so the skeleton shown be on the base pose. the by adjusting the gains of the joint we can see how the engine respond.

[Julio Jerez]

this paper is old but is interesting because it gives some tips of what should be the goal and objective of a controller.
http://www.cc.gatech.edu/graphics/proje ... _tog09.pdf
in particular they explain how to design a balance controller, that is a very good starting point for me. there is also a you tube video

My goal is to have something along the line of that paper and video.

[Julio Jerez]

when I read that paper I see that they actaully do exactly what I was thinking about

Motion Synthesizer. The motion synthesizer forms the core of
the framework. Given the current dynamic state of the character,
the motion synthesizer formulates an optimization that
solves for the joint configuration of the next time step. To ensure
physical realism in the synthesized motion, we enforce
Lagrange’s equations of motion and Coulomb’s friction model
as constraints and minimize the change of muscle force usage
as the objective in the optimization.

basically the abandoned the DP momboumbo way of addressing the problem idea and the write a lagragian formulation for calculation joint toeques. I imagine the problem they have is that they have to solve the system using standard matrix techniques like Lemker of Dansig base solvers, My guess that is why that paper can only have academic value and never cached up as real time solution. I believe we do not have the problem.

The motion for all the examples discussed in this section is simulated
at 2 to 10 frames/s on a single core of 2.93 GHz Intel Core
2 Duo processor. The variance in simulation time is primarily due
to the complexity of the controllers. ...
We used SNOPT [Gill et al. 1996] to solve the optimization
problem at each time step. The time step used for simulation
is 0.01s. Our framework does not require any motion capture
sequences.

I suspect that this is what euphoria actually uses with the difference that they just have many more controllers that use biomechanics rules to make their animations look nicer.
for example one such rule would be, say you are making a falling controller, biomechanics says that instinctively a person will move the arms in the direction of the fall to protect the head.
however the fact that euphoria is so unpredictable an very few projects use as the core animation engine, in some game is delegated to better than ragdoll reactions. They do not really promote it, instead they promote an animation system similar to havoc which is not much different that a node blender of key keyframe interpolation.

The more I research the more I am excited I get about this idea and the more clear the implementation seems to become, know there are many, many unknown challenges that I am not even aware of but I believe I have enough to start.

[JoeJ]

Lucky you... understanding papers like that, hehe

I like the fact they create basic behaviours without animation data.
It looks like they use some external forces to cheat a little.
Doing this is the last thing i want, i think it causes uncanny valley effect.

[Julio Jerez]

I would assume that the videos will have some hackberry or tweaks they omit in the paper indeed, but I say that is normal. if you read the paper by the end they do mention that some constraint they do not enforced. Basically that's language for saying solver noise due to solver poor convergence.
My guess at some point I will have to so similar things, but the theory in paper is quite sound and make a vey good sense.

On the point of not using animations. they is nothing that prevent that method form using int.
my pal is to using target poses or a serious as the driver of some kinematic controllers.
once you have a robust physically base Skelton solver the animation is reduced to a sequence of Key frames target pose.
The problem is to have the solve be responsive enough to keep up with the animation highest frequency. not a small one indeed.
once you get a physics right, they ever thing can be integrated, IK, motion capture, environment constraint and so on.