Skeleton crash only in release mode

[JoeJ]

My guess is that, you have a misunderstanding of the shared pointer, and somehow the code is not working the way you think is should.

Yes, today i found out it's not enough to remove a model from the world to also delete it's bodies automatically. The bodies remain in the scene if i do so.
That means at least that i do not know how to delete stuff. Will refine my question in the other thread...

I'm not too optimistic that's the reason for the crashes, but ideally it is.

[JoeJ]

Fixing shared pointers had no effect on the Clang crashes. Still the same, will keep an eye on it.

But there is another strange issue, not related to Clang.
I was swapping my scalar math lib with the SIMD lib to see if it's faster for what i do.
But there were problems.
First i noticed was some sqrt implementation using Newton Raphson method.
It raised div by 0 exception, but result was correct and worked. So i did not look closer and disabled your exception setup again.

But then i found a function to generate a rotation matrix gave wrong results.
After some digging, i found the function only fails if called from the ndModel::Update().
If i test my IK solver without Newton, the function works correctly.

That's really strange. But maybe some settings beside exceptions or denormal numbers handling could affect this? Let me know if you have an idea. Posting code of the function.
I've reverted back to scalar math lib, so it's no big problem for now.

Code: Select all

__forceinline const Matrix3 Matrix3::rotationY( const floatInVec &radians )
{
    __m128 s, c, res0, res2;
    __m128 zero;
   __declspec(align(16)) unsigned int select_x[4] = {0xffffffff, 0, 0, 0};
   __declspec(align(16)) unsigned int select_z[4] = {0, 0, 0xffffffff, 0};
    zero = _mm_setzero_ps();
    sincosf4( radians.get128(), &s, &c );
    res0 = vec_sel( zero, c, select_x );
    res0 = vec_sel( res0, negatef4(s), select_z );
    res2 = vec_sel( zero, s, select_x );
    res2 = vec_sel( res2, c, select_z );
    return Matrix3(
        Vector3( res0 ),
        Vector3::yAxis( ),
        Vector3( res2 )
   );
}


The given angle was Pi/2, and i saw both s and c were equal and close to zero, which makes no sense.

[Dave Gravel]

Regarding this crash

And now i get a crash in ndSkeletonContainer::SolveForward() with a similar message as before:
access violation, accel was 0x1110111011101110

Last night, I encountered a similar error. It happened because I accidentally added an ndIkSwivelPositionEffector in the world with AddJoint().

[JoeJ]

Just did a update, and could test the sandbox project with clang.
No crashes, everything worked.
So it looks like my issues are coupled to my project. One day i'll figure out...

[Julio Jerez]

Joe how do you use the library?
do you link to it or do you copy the files and make your own project?

Nothing wrong with doing the second, some time I do it myself. for example, the android studio project can no use the liberates of dll, at least no in an easy way, so I just have cmake copying the file to an android studio empty project, that I use as template.

but when using the library, you have fewer risk of missing some setting.

you can always set the cmake options to generate static libraries alone with a destination folder
in variable CMAKE_INSTALL_PREFIX

then I will copy all the header and the libs, to that folder.

[JoeJ]

do you link to it or do you copy the files and make your own project?

Copy and compile with my project.

Actually i assume i may have some memory corruption in application framework or Vulkan setup.
So i might try to disable all rendering to see if that helps, but currently i'm happy with using MSVC.

But i have spent much more time on physics than i wanted. I could not stop until i got this ragdoll working. Now finally it does, so i have to go back to main work.

Btw, today i have replaced box feet with compounds of spheres.
I expected this to give more robust contacts, but the win on accuracy is much bigger than thought.
The box feet tilt slightly as the ragdoll swings forth and back. The support polygon made from contacts constantly shrinks towards the center of pressure.
Nothing wrong with that, but using the spheres the contacts can't move around and there is no tilting.
Helps a lot, really. I was working on error compensation recently, but results were not great. With the spheres it seems no more error feedback is needed. \:D/

Really recommended.
My foot currently has two bodies - heel and toes.
The heel body has 3 spheres. One at the heel, and two at the left and right side of the foot.
Those two are on the hinge axis of the hinge connecting the bodies.
For the toe i have only one sphere at the tip of the toes.
This forms two triangles sharing the edge made from the two side spheres.

However, i'm sure this also helps as long as you're using just a single body to model the foot.

I have not done much yet, but it seems two body feet just work.
Actually my skeleton came from a female model on high heels. So smaller feet and higher ankle. Worst case, but your simulation works as good as the real thing. Really impressive!

[Julio Jerez]

Btw, today i have replaced box feet with compounds of spheres.
I expected this to give more robust contacts, but the win on accuracy is much bigger than thought

that's quite correct. Using three spheres makes so that the contacts are consistent.

I am however still going to use a box, for simplicity. My new objective is not to use the contacts as support point, but instead use the heel ankle point.
That is why I made the swivel/position effector joint.

I now finished the file format phase, and I am ready to resume the work on self-balancing.
As I stated before, I will start far more humbled with unit cycle.

unitcycles has been around for centuries, here is a better picture than the funny one I posted before.

Untitled1.png (97.7 KiB) Viewed 14491 times

basically, is a heavy body balanced on a rolling wheel.

I set up the environment already when running, it passes the first two test.

1- Conservation of momentum. this is if you put the model on the free space, no gravity.
if the model move any limb, the resulting motion should not add any global rotation or translation to the body. when I run the test, I was expectation that over time the error will crip in and the model will gain some rotation, but to my surprised it run stable for a very long time.
I was very pleased with the first result.

2-secund est, when the h model is resting in equilibrium on the ground, the next force and Torque should be zero.
The engine IK solver actually failed the test.
It took me some time to figure out why.
what I got was a net force of about two newton down, so the model should sinc into the floor,
but it did not, so, it look like there was some bug on the iksolver.

then after some debugging I realized that the IK solver set the contact the same way it's set for the general solver, but the general solver works in contact penetration, that is compensated penetration error with a penalty proportional to the penetration. so essentially the contacts act as a very strong spring.

the IK solver cannot work that way, because if it uses that force which is not part of equilibrium state, I will try to make false corrections on the model actuators.

after making the fix, now everything works as I expect so far.

in the next day or two, I will work on making that model to keep its balance under some small perturbation.

I have seeing many videos where people from Deep Mind use these Reinforcement learning AI algorithm to control humanoid models, and it is quite appalling how these people take their target audience for fools.
here is one
https://www.youtube.com/watch?v=SsJ_Aus ... tg&index=2

you can see how the physics is just terrible, I have a trained Eye to see that those models are not conserving momentum, in fact there shouldn't even be standing up for a frame or two. it is obvious there are God forces that keeps the body up. Yet they say that it is the same as this.
https://www.youtube.com/watch?v=RbyQcCT6890

n the secund model, you can see that the robot has very big feet, therefore the model already has a large defined support polygon, and the model moves already statically stable. Where the simulation only moves the actuators keeping the com inside the polygon defined by the large foot plan.

The AI maybe be good, but the physics is quite terrible.

That's is also my goal, but I do not plan on cheating,

[JoeJ]

Code: Select all

this is if you put the model on the free space, not gravity.
if the model move any limb, there resulting motion should not add any global rotation or translation to the body.

I did this test with my previous ragdoll. Iirc, it did not move but there was some spin. Need t repeat this with the new joints...

it is quite appaling how these people take their targe audience for fools.

Yeah, i also spot some cheating all the time.
For example, Natural Motion made a rugby game. Really ambitious, but it was clearly visible they just rotate the characters in cases, and the rotation did not generate any dynamics on the players.

Well, i think cheating won't go away with games in mind. Sometimes we want to do unrealistic things, and this should be still possible when using simulations.

Inspired from my former helper distance joints, i got a new idea for 'legal cheating':
I calculate the point of pressure from the IP controller, which has to stay within the support poly.
If the ragdoll diverges from the prediction of the controller, i could counteract with external force.
To make the cheat legal, i could find the closest point below a foot to the COP. And then apply a virtual spring force on the line from each ragdoll body to the clamped COP, and apply the force to both the ragdoll body and the ground.

This way it's guaranteed that the skeleton could in theory generate the same force, so the cheating is legal. It's also very cheap and no need for adding extra joints. And it would give maximized agility to the ragdoll, while still respecting laws of physics.
Only downside might be artificial weakening of ground friction from assisting the foot contacts, but i guess it would still work very well.

But yeah - let's see first ho far we can get without cheating.

[Julio Jerez]

I did this test with my previous ragdoll. Iirc, it did not move but there was some spin. Need t repeat this with the new joints...

ah but that, I believe is the most fundamental part. and the reason why I put so much emphasis.

I have spent many years, trying to get this, reading the literature.
I have learned techniques like: zero moment point, statically stable, dynamically stable, support polygon criteria. and the most I got is very, very little progress,
and I do not thing brain so that king of complex math, just to keep a balance, there must be a simple method. Even insects who do have many legs, can actually walk in two legs.

The most I have gotten is a humanoid balance keeping the cg inside the support polygon. but even that is a method that is highly unstable, since getting that information is very unreliable, even one flat plane.

From there I try the AI methods, not in depth, but I do not really want to try an AI method, get a result and them not been able to understand why is works.

They say a definition of insanity is repeating the same thing, expecting different result.

there is no reason that trying again a zero-moment point method will work, but even if it did the method is so limited that it will be useless.
I respect the people who came with criteria, I actually learn a lot from reading.
but I believe it is quite limiting.

so from now on I will develop my own, method.
I will start by writing the math, before any test,