This seems useless. "Depth" is obtained from GetContactData's "Dist",
computed with this code:
Dist = dSqrt(dFabs(DistSq));
if (Dist <= Radius){
Dist = Radius - Dist;
return true;
}
else return false;
Radius is positive, Dist is non-negative. If Dist <= Radius, the
subtraction can never be negative. So the test "if (Depth < 0)" will
never be triggered. I believe GetContactData should return false when
the depth is zero too.
Could you try changing the above "<=" test to "<", and see if it solves
your problem? Or even better, if you have a test case we can try out.
--
Daniel K. O.
"The only way to succeed is to build success yourself"
Oleh Derevenko
-- ICQ: 36361783
----- Original Message -----
From: "Entropy" <tom.gau...@gmail.com>
To: "ode-users" <ode-...@googlegroups.com>
Sent: 29 жовтня 2008 р. 11:42
Subject: [ode-users] ODE Internal Error 1: Assertion "bNormalizationResult"
funk
>
> Greetings. I am getting:
>
> ODE INTERNAL ERROR 1: assertion "bNormalizationResult" failed in
> _dNormalize3() [../../include/ode/odemath.h]
>
> when using ODE and colliding a trimesh. Below is a stack trace:
>
> #0 0xb71b0c87 in raise () from /lib/libc.so.6
> #1 0xb71b24f8 in abort () from /lib/libc.so.6
> #2 0xb651986b in dDebug (num=1,
> msg=0xb661a7dc "assertion \"bNormalizationResult\" failed in %s()
> [%s]")
> at error.cpp:103
> #3 0xb6547e12 in _dNormalize3 (a=0x931e590) at ../../include/ode/
> odemath.h:314
> #4 0xb654912f in dCollideSTL (g1=0x931d1f8, SphereGeom=0x931d508,
> Flags=32,
> Contacts=0x931e580, Stride=116) at collision_trimesh_sphere.cpp:
> 436
...
But thinking more carefully, why should zero-depth contact points be
illegal?
The error seems to lie in the "ifdef MERGECONTACTS" block; don't use
normals from zero-depth contacts in the merging step (because their
weight is proportional to their depth).
Not if I place the sphere there, to be in contact with the triangle.
Other than maybe "it's too much work", I don't why we shouldn't handle
this case. I'll try to come up with the proper fix later.
More precision is never a bad thing.
> If objects will
> continue motion towards the penetration, there will be a normal positive
> depth contact on next world step.
Yes, but I'm talking about the collision detection part.
> The nature of floating point computations does not allow you to just "place
> the sphere there, to be in contact with the triangle".
Yes, I can. And I wrote a test case for it. As long as I have a sqrt()
implementation that gives exact answers for powers-of-two.
> Also, if MERGECONTACTS is defined, that dummy contact will affect
> Contact->pos merging but will not affect Contact->normal, which looks like
> an inconsistency to me.
Not any more inconsistent than the original code; near-zero depth also
means it will contribute little to the averaged normal, but will
contribute as much as any other point over the position. Maybe that part
too should use the depths as weights?
But anyway, I just avoided computing the new normal over the original;
if the accumulated normal is <= dEpsilon, the first contact normal is used.
>> Could you explain, what is the use of zero-depth contact?
> More precision is never a bad thing.
In my opinion, it is not more precision, just more uncertainty.
>> If objects will
>> continue motion towards the penetration, there will be a normal positive
>> depth contact on next world step.
>
> Yes, but I'm talking about the collision detection part.
You can consider that there was a computational error and your zero-depth
collision has not been detected. And indeed, it will not be detected from
time to time.
N.B.: I've removed normalization for normal in case the merged depth is less
than dEpsilon and normal is not assigned. Original normals of individual
contacts should be already normalized.
I've just noticed that apparently this isn't a collision detection
issue anymore, since it's failing on the world step method, apparently
when normalizing the body quaternion.
Any idea how can this happen? Singularities?
I'll check tag version 0.10.1 since there I was pretty sure it was a
collision detection error.
Anyway, here is the stacktrace in WinDbg format.
ChildEBP RetAddr Args to Child
0338d0c0 7e419418 7e42dba8 00000000 00000000 ntdll!KiFastSystemCallRet
WARNING: Stack unwind information not available. Following frames may be wrong.
0338d0f8 7e42593f 0019186a 00000000 00000001 USER32!WaitMessage+0xc
0338d120 7e43a91e 7e410000 00218cd0 00000000 USER32!DrawStateW+0x1f2
0338d3e0 7e43a284 0338d53c 00000000 ffffffff USER32!SoftModalMessageBox+0x677
0338d530 7e4661d3 0338d53c 00000028 00000000 USER32!MessageBoxIndirectA+0x23a
0338d588 7e466278 00000000 0550c4f8 04123e10 USER32!MessageBoxTimeoutW+0x7a
0338d5bc 7e450617 00000000 0338d74c 0338d6e0 USER32!MessageBoxTimeoutA+0x9c
0338d5dc 7e4505cf 00000000 0338d74c 0338d6e0 USER32!MessageBoxExA+0x1b
*** WARNING: Unable to verify checksum for
D:\Projects\YDreams\YLabs\InteractiveSurfaces\Trunk\Source\YDreams.InteractiveSurfaces.Standalone\bin\Release\ode_singled.dll
0338d5f8 092e24df 00000000 0338d74c 0338d6e0 USER32!MessageBoxA+0x45
0338db48 0931775d 00000001 09334764 093347a0 ode_singled!dDebug+0xbf
[d:\projects\ydreams\ylabs\odenet\trunk\source\externals\ode\ode\src\error.cpp
@ 158]
0338dc38 093172fc 08e65a04 0338ede0 0338e060
ode_singled!_dNormalize4+0x4d
[d:\projects\ydreams\ylabs\odenet\trunk\source\externals\ode\include\ode\odemath.h
@ 321]
0338de70 093043e2 08e65928 3dcccccd cccccccc
ode_singled!dxStepBody+0x40c
[d:\projects\ydreams\ylabs\odenet\trunk\source\externals\ode\ode\src\util.cpp
@ 267]
0338ede0 09317bdb 08e646d8 0338eee0 00000001
ode_singled!dxQuickStepper+0x14b2
[d:\projects\ydreams\ylabs\odenet\trunk\source\externals\ode\ode\src\quickstep.cpp
@ 842]
0338f078 092ff103 08e646d8 3dcccccd 0929082a
ode_singled!dxProcessIslands+0x39b
[d:\projects\ydreams\ylabs\odenet\trunk\source\externals\ode\ode\src\util.cpp
@ 375]
0338f158 05a6617d 08e646d8 3dcccccd e44091b8
ode_singled!dWorldQuickStep+0x83
[d:\projects\ydreams\ylabs\odenet\trunk\source\externals\ode\ode\src\ode.cpp
@ 1645]
0338f1dc 79e71b4c 01355648 00000000 0338f284 0x5a6617d
0338f1f0 79e821b1 0338f2c4 00000001 0338f290 mscorwks+0x1b4c
0338f270 79e96501 0338f2c4 00000001 0338f290
mscorwks!DllUnregisterServerInternal+0x6195
0338f3b8 79e96534 792546dc 0338f514 0338f410 mscorwks!CoUninitializeEE+0x2e95
0338f3d4 79e96552 792546dc 0338f514 0338f410 mscorwks!CoUninitializeEE+0x2ec8
Best regards,
Gonçalo
2008/11/22 Oleh Derevenko <od...@eleks.lviv.ua>:
I admit that this may introduce odd singularities with the collision
detection + contact joint system. I got it to a point where mostly it
seems pretty stable and smooth, collision-wise, but suddenly,
out-of-the-blue, a bNormalizationResult appears on dWorldQuickStep().
Anyone knows what are the usual symptoms for this error and the
possible workarounds?
I've increased both contact and global CFM values so far and tried
approaching masses and lengths to unity.
I understand the difficulties with controlling physics integrators,
but it's frustrating to have a perfectly good-looking simulation
suddenly crashing out of nowhere. It's not even a case of growing
instability. Everything looks perfectly stable and smooth until
eventually, it just crashes.
Best regards and thanks in advance for all your help,
I guess it was just a matter of "taming the beast".
Thanks for everything,
Gonçalo
2008/11/23 Gonçalo Lopes <goncal...@gmail.com>: