Skeleton crash only in release mode

Report any bugs here and we'll post fixes

Moderators: Sascha Willems, Thomas

Re: Skeleton crash only in release mode

Postby JoeJ » Sun Apr 02, 2023 1:01 pm

Julio Jerez wrote:look at the part where they talk of principal axis.
"Inertia matrix in different reference frames"
basically, the moment of inertia of a matrix can be decompose int a rotation matrix and a scale vector.


I'm stopping right here, because (i think) the math you quote is built on the assumption/restriction that any rigid body has the inertial shape of an ellipsoid. It's an approximation. And it can represent the Rattle Back things you did, but only so because this object has an ellipsoid alike shape, so the approximation becomes very (or precisely) accurate.

You are the expert, and we talked about that before. But i think the acceptance on the approximation is so deeply founded in the physics community, that almost nobody remembers it's an approximation. And that it would be eventually worth to research improvements if needed.

I'll try to proof my claim by showing you the code i use to generate this lobe shape, which can't be well approximated with the established methods.

The math should be the same as if you calculate inertia for a set of point masses, or spherical bodies to be precise. (I can do this because i give each ragdoll body a uniform inertia, so the inertia sphere has the same volume as the textbook ellipsoid we use for capsules or boxes.)

Code: Select all
      float CalcInertia (const Vec3 axis, const float *weights) const // current pose
      {
         float inertia = 0;
      
         for (int i=0; i<NUM_BONES; i++)
         {
            float w = (weights ? weights[i] : 1.f);
            if (w == 0.f) continue;
            auto &pose = bodyPose[i];
            auto &info = bodyInfos[i];

            // pose.com is the com of the unique body
            // com is the precalculated com of all bodies
            Vec3 d = pose.com - com;   
            inertia += w * info.mass * Vec3(axis * axis.Dot(d) - d).SqL(); // SqL gives squared length
            inertia += w * info.uniformInertia;
         }
         return inertia;
      }


I have just copied this from the old project and did not verify again. But initially i got the math from Wikipedia or some other source.

The code to visualize is this:
Code: Select all
         for (int i=0; i<360; i++)
         {
            float angle = float(i) / 180.f * float(PI);
            Vec3 axis (sin(angle), cos(angle), 0);
            float inertia = m_controller->CalcInertia(axis, 0);
            RenderVector (m_controller->com, axis * inertia * 0.00001f, 0,1,0);
         }


Her is another function i have used to get Inertia for given direction, but using the standard approximation:

Code: Select all
inline float GetInertia (const sVec3 &localaxis, const float Ixx, const float Iyy, const float Izz)
{
   sVec3 axis = localaxis;
   axis[0] /= Ixx;
   axis[1] /= Iyy;
   axis[2] /= Izz;
   return 1.0f / axis.Length();
}


Not sure that's right, but it seemed to be.
I hope you can verify those things just from reading the code. I can't express myself with math notation ;)

Now here comes my claim based on that code:

If i would make a compound from my ragdoll, your engine would calculate the 3 inertia values Ixx,Iyy,Izz.
And i could visualize them using the third code snippet.

But then i would see an ellipsoid shape, which tries to approximate the lobes i get from looping over all bodies and accumulating precisely.

So if all i said is right, it proofs the traditional method is just an approximation.

Now we have 3 options:
1. Talk bullshit, and i came up with that because my code is wrong.
2. Some of my code is wrong, but my claim is right regardless.
3. I'm totally wrong, and a rotation matrix and a scale vector is indeed enough to represent MOI for any rigid body, whatever it's shape and mass distribution is.

So what do you think?
If you insist on 3 my code must be buggy, and i shall fix it to turn lobes into an ellipsoid.
And i could also represent my ragdoll with the standard inertia representation, getting rid of the cost to iterate over all the bodies each time i need it. But i have tried this first, and it did not work. The ragdoll fell on its node.
User avatar
JoeJ
 
Posts: 1453
Joined: Tue Dec 21, 2010 6:18 pm

Re: Skeleton crash only in release mode

Postby Julio Jerez » Sun Apr 02, 2023 3:58 pm

no Joe, that not an approximation.
That's a correct calculation from Math. It is always a big mistake to disagree with stablished physics and math basics principles.

There is not shape assumption of anything, like that.
Give a shape, the Inertia represents the resistance of that shapes to rotation, the same way mass is the distance to translate. I am not even entertaining discussing that, that was settled several hundred years ago.

you are correct when you said this
The math should be the same as if you calculate inertia for a set of point masses, or spherical bodies to be precise. (I can do this because i give each ragdoll body a uniform inertia, so the inertia sphere has the same volume as the textbook ellipsoid we use for capsules or boxes.)

but that will be an approximation, in general does works quite well. but that's not the problem.
The problem is how to calculate the inertia in any rotational space from some parametric values.
Running that loop will work, and it is in fact how particles and elastic body simulators work.
But this is a small rigid body simulation.
Another approximation is assuming an object is rigid. but that also work for small to media size bodies.
that assumption breaks down really bad for large bodies for the reason that bodies are elastic and that caused forces to take time to propagate.
That's why most physics engine do not simulate large bodies well, they always look funning.

anyway.
I just has some bug when I try to put the code into the base kinematic body.
I now have all merged and committed.
It is set to the default method where bodies are assumed to have symmetry.

later I will enable and see where I made the mistake. but for now, is all works as expected.
the rattle will not work, until that functionality is enabled.

in the Practical sense, Having the ability to simulate skew inertia is just a pendate bragging right.
you do now want to simulate anything with a skew inertia.
Things tend to break apart when the spin fast and they are unbalanced. example will be the tires of a far, just a very small unbalanced make the vibrate really bad.

notice that the emphasis of having a robust inertia is conservation for momentum during integration.
that is:

L = I * w

where:
L is angular momentum
I is inertia
W = angular velocity

when a body rotate, both I and W change with time,

I(t0) * W(t0) == I(t1) * W(t1) == .... == I(tn) * W(tn)

and it is quite difficult to archived.
The reason many of the engines use capsule and sphere to simulate bone and this does not explode really bad is that those shapes had full symmetry, making the about expression to be satisfied simply because I does not changes as the body spins.

I(t0) == I(t1)

but when both I and W are changing with time, that's another ball game.

in the you tube video, they is a simulation of a phitop, that an object that is spinning and loosing speed as is rotate, but is order to conserved momentum, the center of mass rises, which will seem counter intuitive.

Having the behavior, for me, gives me the peace of mind that if I am simulationg something, and I do not get the expected results, my confidence is higher that it is me doing something wrong not the physics simulator. I can't have that confidence with any other engine out there.

anyway, I am now ready to try the CLangCL build mode that you said was cause a crash.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Skeleton crash only in release mode

Postby JoeJ » Sun Apr 02, 2023 6:09 pm

It is always a big mistake to disagree with stablished physics and math basics principles.

That's not what i try to say.
I assume the topic is discussed in literature, i just never came across it.
And i don't say the established method is wrong.
It isn't. If i'm right, the method results in correct simulation, just the simulated object is no exact representation of the real world object (ignoring things like elasticity).

We have similar cases in graphics. We may make a perfectly accurate physically based renderer.
For the material, we use a BRDF from established PBS research to represent a paper wall of a Cornell Box scene. Then we present the resulting image as ground truth.
If then somebody comes by and says 'It's nice, but real world paper looks slightly different, so your BRDF isn't perfectly accurate.', he does no criticize the established research. He only points out ther are approximations used, e.g. all than Schlick, GGX, Fresnel functions which are tuned to match measured results, but or not founded on physical math like E = mc^2 is.
And even the guy is right, that does not mean our renderer is wrong. It only means we have simulated materials which are different from the real world reference.

And that's what i think happens in physics too. I claim the MOI of a uniform density box does not form an ellipsoid. But the established formulas given do produce such ellipsoid.
So if we use this established formula, we actually simulate a different box where density is not uniform but varied in a way so we coincidentally get an ellipsoid. The simulation is still correct in simulating this object, which is slightly different.

So, working just on games, we do not need to care.
But just for the sake of discussion, i would like to achieve agreement.
Which would help me against my constant uncertainty about physics.
And due to that, i'm ofc. NOT sure to be right.
But you have not yet convinced me to be wrong either.

So i worked on new evidence to illustrate my point.
I have visualized MOI of a simple symmetrical box, meant to have unifrom density.
And i too math from this reference: https://www.geeksforgeeks.org/moment-of-inertia/

Here is the result: (ignore small red box and white dots / lines)
box inertia.JPG
box inertia.JPG (48.69 KiB) Viewed 7703 times

The red ellipsoid is the result using the established formula.
The green lobes are calculated by a uniform sampling approach, treating each sample as a point mass.

You can see both methods match at the symmetry axis, so all the code and math is likely correct.
But they disagree anywhere else.
So my conclusion is: The established formula is an approximation, only correct at principal axis, but interpolating elsewhere.

As a result, all our rigid bodies in our simulations behave like ellipsoid, which is the only shape where the interpolation is correct too.

That's what i mean. So please look and think at it again. :mrgreen:
If you disagree on that, how can i fix the GetInertia() function to produce the same correct lobes as the sampling approach?

Code: Select all
            float edgeLengthX = 2.f;
            float edgeLengthY = 5.f;
            float edgeLengthZ = 3.f;
            float mass = 15.f;

            float Ixx = mass / 12.f * (edgeLengthY*edgeLengthY + edgeLengthZ*edgeLengthZ);
            float Iyy = mass / 12.f * (edgeLengthZ*edgeLengthZ + edgeLengthX*edgeLengthX);
            float Izz = mass / 12.f * (edgeLengthX*edgeLengthX + edgeLengthY*edgeLengthY);

            auto GetInertia = [&](const Vec3 &localaxis)
            {
               Vec3 axis = localaxis;
               axis[0] /= Ixx;
               axis[1] /= Iyy;
               axis[2] /= Izz;
               return 1.0f / axis.Length();
            };

            auto SampleInertia = [&](const Vec3 &localaxis)
            {
               float step = 0.1f;
               int resX = (int)round(edgeLengthX / step);
               int resY = (int)round(edgeLengthY / step);
               int resZ = (int)round(edgeLengthZ / step);
               float pointMass = mass / float(resX*resY*resZ);
               Vec3 offset (edgeLengthX*-.5f, edgeLengthY*-.5f, edgeLengthZ*-.5f);

               float I = 0.f;
               for (int x=0; x<resX; x++)
               for (int y=0; y<resY; y++)
               for (int z=0; z<resZ; z++)
               {
                  Vec3 sample = offset + Vec3(
                     (float(x)+.5f) * step,
                     (float(y)+.5f) * step,
                     (float(z)+.5f) * step );
                  //RenderPoint (sample, 0,0,0); // verified the point distribution is right

                  Vec3 diffToAxis = sample - localaxis * localaxis.Dot(sample);
                  float distSquared = diffToAxis.Dot(diffToAxis);
                  I += distSquared * pointMass;
               }
               return I;
            };

            for (int i=0; i<360; i++)
            {
               float angle = float(i) / 180.f * float(PI);
               Vec3 axis (sin(angle), cos(angle), 0);
               float inertiaA = GetInertia(axis);
               RenderPoint (axis * inertiaA * .1f, 1,0,0);
               float inertiaB = SampleInertia(axis);
               RenderPoint (axis * inertiaB * .1f, 0,1,0);
            }

            RenderAABBox (Vec3(edgeLengthX, edgeLengthY, edgeLengthZ) * -.5f, Vec3(edgeLengthX, edgeLengthY, edgeLengthZ) * .5f, 1,1,0);

User avatar
JoeJ
 
Posts: 1453
Joined: Tue Dec 21, 2010 6:18 pm

Re: Skeleton crash only in release mode

Postby Julio Jerez » Mon Apr 03, 2023 10:53 am

Las post on this.

Joe, you are wrong.
No one say the inertial emulate an elipsoid.

The point is that the equation for calculation inertia, are one and only way to simulate angular motion that comport with reality. It is the one an only way to move a solid body and preserve angular momentum.

Is possible to move object in that obey different principles, like preserve angular velocity. But since non of those are in accordant with reality, they fall on the non simulation criteria. That's where most popular physics and game engine fall today.

They is a heavy price to pay in simulation to support that, you need better matrix solvers, better integration scheme, and you simulation will run slower. So maybe there is a good case to make for not supporting skew inertia.

Anyway, this is not really an issue, since supporting it, make possible to nullified it.

I committed the last merge since I did it, and it is disable.

You can now check if is still malfunction when building using ClanCL.
I did a quick compiled last night, but I have not tested yet.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Skeleton crash only in release mode

Postby JoeJ » Mon Apr 03, 2023 12:03 pm

You can now check if is still malfunction when building using ClanCL.

Still the same kind of crash.
I'll now try to see what happens if i use Clang for the Sandbox...

Cmake, Configure: I could specify compilers here, but do not know what to enter. So i leave this at defaults.
Cmake then plots soem errors. Happened last time too and still worked regardless.
But here is what it says:
Code: Select all
building unit tests
-- Selecting Windows SDK version 10.0.22000.0 to target Windows 10.0.19041.
CMake Error at C:/Program Files/CMake/share/cmake-3.26/Modules/ExternalProject.cmake:2806 (message):
  error: could not find git for clone of googletest-populate
Call Stack (most recent call first):
  C:/Program Files/CMake/share/cmake-3.26/Modules/ExternalProject.cmake:4208 (_ep_add_download_command)
  CMakeLists.txt:23 (ExternalProject_Add)


-- Configuring incomplete, errors occurred!

CMake Error at C:/Program Files/CMake/share/cmake-3.26/Modules/FetchContent.cmake:1610 (message):
  CMake step for googletest failed: 1
Call Stack (most recent call first):
  C:/Program Files/CMake/share/cmake-3.26/Modules/FetchContent.cmake:1762:EVAL:2 (__FetchContent_directPopulate)
  C:/Program Files/CMake/share/cmake-3.26/Modules/FetchContent.cmake:1762 (cmake_language)
  C:/Program Files/CMake/share/cmake-3.26/Modules/FetchContent.cmake:1976 (FetchContent_Populate)
  tests/CMakeLists.txt:36 (FetchContent_MakeAvailable)


Configuring incomplete, errors occurred!

I'm using VS 2022. Maybe it's a problem that's too new.

Then i click Generate, again some errors related to 'googletest':
Code: Select all
CMake Error at C:/Program Files/CMake/share/cmake-3.26/Modules/ExternalProject.cmake:2806 (message):
  error: could not find git for clone of googletest-populate
Call Stack (most recent call first):
  C:/Program Files/CMake/share/cmake-3.26/Modules/ExternalProject.cmake:4208 (_ep_add_download_command)
  CMakeLists.txt:23 (ExternalProject_Add)


-- Configuring incomplete, errors occurred!

CMake Error at C:/Program Files/CMake/share/cmake-3.26/Modules/FetchContent.cmake:1610 (message):
  CMake step for googletest failed: 1

No project files were generated. Happened last time too. I close CMake and try again.
But it again does not work. So get no projects and i'm stuck.

I had those problems too last time, but after the second try i got project files even there were errors.
User avatar
JoeJ
 
Posts: 1453
Joined: Tue Dec 21, 2010 6:18 pm

Re: Skeleton crash only in release mode

Postby Julio Jerez » Mon Apr 03, 2023 1:24 pm

if you build the download,
Visual studio already have CMake support, that the CMake gui can find provided you installed ClangCL for visual studio for the MS installer.
you just click delete cache and select the CLangCL option.
like in the image bellow
Untitled.png
Untitled.png (33.03 KiB) Viewed 7686 times


edit:
I am curious to see what you get, sionce I am not getting those crashes,
that test will determine of the crash ins because some misused of shared pointer.

I actually made a post on the shared pointe question, but somehow when posting the same thing happen again, the forum asked me to log in, even when I was logged, and after logging, the post vanish, and I did not feel like doing it again.

I will try again later. but let use see if the sand Box crashes or not in your side.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Skeleton crash only in release mode

Postby JoeJ » Mon Apr 03, 2023 1:27 pm

Unfortunately there is now a new problem after the update:
(Damn - screenshot just 1 kB too large to upload. 256kB is really a tight limit. Need to compress it somehow... made a zip)
newBug.zip
(218.69 KiB) Downloaded 307 times


I get this assert for models with two bodies and one joint. Of which i have two different ones i have tried.
For the ragdoll i do not get the assert, which has way more bodies and joints.

Since all models use the same joint, i speculate there is a bug with low counts.
I have tried to increase the row count for my joint from the correct 6 to 9, but made no difference.

Reverting to the previous version the assert goes away, so i'll keep using that for now.
User avatar
JoeJ
 
Posts: 1453
Joined: Tue Dec 21, 2010 6:18 pm

Re: Skeleton crash only in release mode

Postby JoeJ » Mon Apr 03, 2023 1:40 pm

if you build the download,
Visual studio already have CMake support, that the CMake gui can find provided you installed ClangCL for visual studio for the MS installer.
you just click delete cache and select the CLangCL option.
like in the image bellow

Ok, idk how to use cmake from VS, but tried again with a freshly unpacked zip, and entering 'ClangCL'.
It would work. Log shows it find the compiler.
But the errors regarding google seemingly break it soon after that.
Actually it has created some project files this time, e.g. sandbox for 3.14, but unfortunately no 4.0 project.
User avatar
JoeJ
 
Posts: 1453
Joined: Tue Dec 21, 2010 6:18 pm

Re: Skeleton crash only in release mode

Postby Julio Jerez » Mon Apr 03, 2023 1:44 pm

ah cool I am getting too. it is an optimization I made,

Let me check that out and we try again.

let us fix these errors first. them we go over the Google unit test thing.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Skeleton crash only in release mode

Postby Julio Jerez » Mon Apr 03, 2023 1:53 pm

oh this is very scary. you are right It crashes with clang but not with visual studio.

That's a huge problem.

ok I found the bug, it is a huge oversight, I am fixing it now.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Skeleton crash only in release mode

Postby Julio Jerez » Mon Apr 03, 2023 2:35 pm

yes, I might have to temporarily revert to the previous skeleton, tonight until I fix this.
The good part is that it is a simple bug,
I need to add a body local enumeration. because the global one will not map to a temp array.
easy to fix but takes some careful work.

we continue tonight after I added the fix.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Skeleton crash only in release mode

Postby Julio Jerez » Tue Apr 04, 2023 10:34 am

Ok, I think I have it fix now.

Did a small test, before commiting.

I will do more clang test later, but you can try again.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Skeleton crash only in release mode

Postby Julio Jerez » Tue Apr 04, 2023 2:17 pm

ok I now did a debug/Release test using Clang and seem to work fine.

you can sync and try again, when you have time.

when you do, please try the sand box first them is this check passes, then try your test, and we know if something is incorrect wit the shared pointer usage and we address that.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Skeleton crash only in release mode

Postby JoeJ » Tue Apr 04, 2023 4:36 pm

Now MSVC works also with the small models. Both in release and debug. No more bugs.

Clang still crashes, but this time on my code. So maybe something is wrong with my project.
It's again access violations on bogus addresses but i can see all related variables and they have proper values. Perhaps i should try to reduce compiler optimizations.
Can't check Sandbox because of the cmake google issue.

Trying again disabling float exceptions, because i still get some of these on my code...
No, still the same crash.
Trying to run the release exe without debugging crashes too.
Debug mode with Clang gives the same crash as well. So reducing with optimization options won't help.

Too bad, but i guess those Clang crashes will remain a mystery for some time.
If i would be registered, this is the point where i would try ChatGPT. :D

Edit:
The crash happens in code from my small model, so i have remove it to see if it works then.
And now i get a crash in ndSkeletonContainer::SolveForward() with a similar message as before:
access violation, accel was 0x1110111011101110
But i can see accel has a regular address, and i can see its first entry which look fine.

So again what the debugger shows does not help. Maybe MSVC debugger does not always work with Clang after a crash.
User avatar
JoeJ
 
Posts: 1453
Joined: Tue Dec 21, 2010 6:18 pm

Re: Skeleton crash only in release mode

Postby Julio Jerez » Tue Apr 04, 2023 6:02 pm

JoeJ wrote:Trying again disabling float exceptions, because i still get some of these on my code...
No, still the same crash.
Trying to run the release exe without debugging crashes too.
Debug mode with Clang gives the same crash as well. So reducing with optimization options won't help.


the fact that crash in release and debug is a good step, because the bug is predictable.

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.

so now is a good time to move top the other question you ask about shared points.
I have a very strong supposition that that where the problem is.

do not worry few people has had similar issues.

anyway, I will make a series of post explain why using share pointer and how to use the properly.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

PreviousNext

Return to Bugs and Fixes

Who is online

Users browsing this forum: No registered users and 22 guests