Enabling Bodies

A place to discuss everything related to Newton Dynamics.

Moderators: Sascha Willems, walaber

Re: Enabling Bodies

Postby JoeJ » Sat Nov 12, 2011 2:27 pm

Thanks, i'll try out as soon as possible and let you know.

I'm currently using 4 iterations but 1 iteration seems to work as good as 4 or more, after doing a quick test still on 2.29.
In situations where something went wrong i tried the exact solver sometimes, but that never was an advantage for me.
My work does not need so much accurary, but it's surely a very hard test case for stability issues.
User avatar
JoeJ
 
Posts: 1489
Joined: Tue Dec 21, 2010 6:18 pm

Re: Enabling Bodies

Postby Julio Jerez » Sat Nov 12, 2011 3:59 pm

If you want a powred ragdoll, the exact solve is what you want. the iterative solver does not have the converge rate to produce a hard reponce in one frame.

The future that can select solver based of the contacts is on core 300, you sync to svn and just swap library is should juts works.
then you get the best thet the engine can offer, more resposive rag doll, bu also fast scene.

The one thing I mention to you is that what you wnat to do is not matamatcailly possible. you cna no make a joint the can rotae independllly aorudn three angles.
the is what the Euler and Shoemake theorem demostrate, three euler rotation are equivalent to a single rotation around the shorter spherical arch.

so there are not three degree of fredomn ther is just one.

There one thing that you can do is to use an approximation that states "for small angles the the product of rotation matrices commute"
that is: say you have a matrix, you can decompose ther matrix into tree angles, pitch, Yaw, Roll, the you you get the

matrix = picthMatrix * Yawmatrix * RollMatrix;

however teh solev will not take lareg angular stepe, it will talke smale steps like this.

1) Matrix = matrix1 * mnatrix2 + ... != (picthMatrix0 * Yawmatrix0 * RollMatrix0) * (picthMatrix1 * Yawmatrix1 * RollMatrix1) * ....

and that so the problem, the path is just incorrect sinc the corrent identity is

2) Matrix = matrix1 * matrix2 + ... == (picthMatrix0 * picthMatrix1 * ...) * (Yawmatrix0 * Yawmatrix1 * ...) * (RollMatrix0 * RollMatrix1 * ....)


this is what you can do, ther is a Leman teh say that the product fo tow euler is comutative is the angle are small.

so if you dicide you angle into a series of small sube angles.

then you cna say that

Matrix = matrix1 * mnatrix2 + ... == (picthMatrix0 * picthMatrix1 * ...) * (Yawmatrix0 * Yawmatrix1 * ...) * (RollMatrix0 * RollMatrix1 * ....) == (picthMatrix0 * Yawmatrix0 * RollMatrix0) * (picthMatrix1 * Yawmatrix1 * RollMatrix1) * ....

only when:

if picthMatrix0 = picthMatrix1 = .. = picthMatrix / N == a small angle
if Yawmatrix0 = Yawmatrix1 = .. = Yawmatrix / N == a small angle
...

in fact that is the procip[la assumetion that it is use to demostrate teh Euler Shwemeke threrem.

so basically what you do is to make a joint that solves for the tree angles but intead of usin the full angle you use a fraction of the angle, and you run the solve N times.
That will Guareantee a amost 100% accurate Euler rotation Joints whe the three angles are independet.

even the iteratove solve can deal with with that,
I hope that is clear. :idea:


for Newton Core300 I was planning to make an anymation systm with a pweful IK system which at teh core will have that Joint,
bu I iwll ahev to make a minisolve that will take care of th sube steps in insulation.

That joint can make if possible to have Perfect Arm Socket and Femul socke joints for alticulate bodies that can be controll at will.
Julio Jerez
Moderator
Moderator
 
Posts: 12426
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Enabling Bodies

Postby JoeJ » Sun Nov 13, 2011 12:56 pm

Maybe my idea to handle that problem is useful for you, i sent you a PM.
User avatar
JoeJ
 
Posts: 1489
Joined: Tue Dec 21, 2010 6:18 pm

Re: Enabling Bodies

Postby Julio Jerez » Sun Nov 13, 2011 1:34 pm

I read the PM, I think my English got in the way of clarity.
running at 120 or any other fps will not do the trick. the joint need to do the calculation all in teh same step independen of the step.
It shoudl handle small angle as well as large angles.
basically the idea is to use three hinges joints. to achieve an generic power joint.
this will be correct because the product of two rulers angle commute if the angles are small.
so say you want a power joint that want to rotate by pitch = 30, Yaw = 20, and Roll = 60 for the current relative orientation.

since the angles are big you will find that there are 6 different way to combine the Euler matrices,
therefore any implementation of a joint will be subject to the convection that was use to produce the matrix. Ideally want we want is the joint follows the quaternion path.
you can run this test to see what I mean, divide the angles into a fix number of steps, say 10,
now you get 10 rotations each of pitch = 3, Yaw = 2, and Roll = 6
you can run this test verify that

m1 = Pichmatrix (3) * Yawmatrix (2) * Roll (6);
m2 = Yawmatrix (2) * Roll (6) * Pichmatrix (3);
m3 = Roll (6) * Pichmatrix (3) * Yawmatrix (2);
...

you will see that m1 ~= m2 ~= m3 ...

if this is true, then implementation of the joint can be done as three impendent Hinge joints, each rotating around a fixed axis system
(you can select the one of the parent, or even the global axis system) that perform 10 updates.
But it all has to be done in the same step. This is a feature that have to build into the solver.
I do not think it can be done with the current existing functionality.
and eh reason for that is that running at smal fps will update teh positions of the two joint after each step, therefore wou will lose the Fix Frame of reference

It will make the joint evaluation more expensive but only in the places that count.
Also by adding that as a solver feature the steps can be adaptives, so small steps will do variable number of steps with having keep changinf the overall FPS.
It could be a very powerful feature.
Julio Jerez
Moderator
Moderator
 
Posts: 12426
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Enabling Bodies

Postby JoeJ » Sun Nov 13, 2011 4:36 pm

The problem of euler angles ordering is clear to me. I was surprised to face it again in physics.
The source of the problem from my pov was:
I want to do a single relative rotation between the 2 bodies, so i try a single angular constraint.
That works, but if the joint is nearly satisfied (angle nearly zero), the axis of that rotation jumps around wildely, so it gets instable - damn, damn and once again: Damn!
To fix that, i distribute the rotation on three fixed axis, in a way that at least guaranties that the extraction of the angles is order indipendent.
Now everything is stable, but less exact, so less responsive.

The method i use tries to get the best from the two worlds and works well in practice.
Both important cases (rotate large angle / keep at rest) are well defined and everything is done using the same, slightly over time changing input for the solver.
The control system does not require any exact output from physics. It tries to advance from current state, and that's the point where i need 120 Hz.
The gravity looks natural, for that "slow motion" look alike physics seen in actual games 60 Hz would probably be enough.

But i agree that there is surely a better way to do it.
I know a combination of 3 hinges can do a generic rotation joint, but didn't want to try that because the loss of stiffness and performance.
If you can combine that to a single thing, great! I'll use it :) I just thaught that my "choose basis" trick helps for that too, and could make it more effective.
You say that the user will be able to select any axis system. Is the result of the simulation indipendent from its orientation? If not, maybe using a trick like mine could help to improve the result.

----

I really don't know how any or your solver works (weak algebra background), does it solve the constraints in some order?
Example: Three stacked objects on the ground, each one intersecting with top / bottom object:
The solver i did 10 years ago would do that: For each contact calc seperation forces for both bodies, accumulate forces for each object. At the end apply the accumulated forces and repeat this 10000000 times to get a good result :)
Is your solver smart enough to sepearate the bottom most object from ground first, then the object above it (knowing that object below can't go down, so above object can go only upwards) and so on...?
And if so, what happens if the order changes? How to avoid explosions or terrible jittering in that case?
... Just in case you have time to answer such questions :)
User avatar
JoeJ
 
Posts: 1489
Joined: Tue Dec 21, 2010 6:18 pm

Re: Enabling Bodies

Postby Julio Jerez » Sun Nov 13, 2011 4:44 pm

I am curios to know what are you doing.
can you say anything?
Julio Jerez
Moderator
Moderator
 
Posts: 12426
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Enabling Bodies

Postby JoeJ » Sun Nov 13, 2011 5:04 pm

I'm not in game industry.
I work as a graphics artist, mostly CD-covers, some 3D Animation.
Game dev is hobby since childhood, but didn't earned some money from that until now.
I was close to get in contract with a big mobile content company, but failed to deliver enough mobile games for them as a single person.
Currently i'm porting 2 of those Java games to iPhone, cause selling Audio-CDs isn't the best business nowadays :|
User avatar
JoeJ
 
Posts: 1489
Joined: Tue Dec 21, 2010 6:18 pm

Re: Enabling Bodies

Postby JoeJ » Tue Nov 22, 2011 6:03 pm

...tried the update to 3.0, but now i get linker errors like

1>Physics.obj : error LNK2019: unresolved external symbol __imp__NewtonBodySetTorque referenced in function "void __cdecl ForceAndTorqueCallback(struct NewtonBody const *,float,int)" (?ForceAndTorqueCallback@@YAXPBUNewtonBody@@MH@Z)
1>Physics.obj : error LNK2019: unresolved external symbol __imp__NewtonBodyGetMatrix referenced in function "void __cdecl ForceAndTorqueCallback(struct NewtonBody const *,float,int)" (?ForceAndTorqueCallback@@YAXPBUNewtonBody@@MH@Z)
1>Ragdoll.obj : error LNK2001: unresolved external symbol __imp__NewtonBodyGetMatrix
...

I used project in: coreLibrary_300\projets\windows\project_vs2008 which generated newton_d.lib, i link to this in my project.
Also i include newton.h from: newton-dynamics-read-only\packages

So what i've missed... any ideas?
User avatar
JoeJ
 
Posts: 1489
Joined: Tue Dec 21, 2010 6:18 pm

Re: Enabling Bodies

Postby Julio Jerez » Wed Nov 23, 2011 9:15 am

Oh sorry I check in the project file with a diffrent file name, you wher probably usin an old dll.
sync again and it it should be fine.
Julio Jerez
Moderator
Moderator
 
Posts: 12426
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Previous

Return to General Discussion

Who is online

Users browsing this forum: No registered users and 1 guest

cron