raycast issue

A place to discuss everything related to Newton Dynamics.

Moderators: Sascha Willems, walaber

Re: raycast issue

Postby Julio Jerez » Mon Sep 03, 2018 12:48 pm

I do no undertand what I am doing wrong, I copy the CrashTest demo in teh same location than the Demos, in the plug in, and no matter what I do I get these errors.
DllNotFoundException: NewtonWrapper
NewtonWrapperPINVOKE+SWIGExceptionHelper..cctor ()
Rethrow as TypeInitializationException: An exception was thrown by the type initializer for SWIGExceptionHelper
NewtonWrapperPINVOKE..cctor ()
Rethrow as TypeInitializationException: An exception was thrown by the type initializer for NewtonWrapperPINVOKE
dNewtonWorld..ctor ()
NewtonWorld..ctor ()
Julio Jerez
Moderator
Moderator
 
Posts: 11039
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: raycast issue

Postby Julio Jerez » Mon Sep 03, 2018 1:17 pm

well I am very sorry, but I do no undertand Unity, I try to delete the dlls from the editor but some how when I run the demo, it recreate them from some cache or something.
If I try to add the new recompiled dll as new assets, it renames them and still try run the old ones.
Maybe Sweenie can recreate a sample test to recreate the bug, and commite to guthub, otherwise I do no knwo how I can help.
edit: I think I figure out hwo to make use the new dll, but there are still problem running the demos.
Julio Jerez
Moderator
Moderator
 
Posts: 11039
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: raycast issue

Postby Julio Jerez » Mon Sep 03, 2018 1:31 pm

ah I see is getting the from folder PluginBin
if I add the asset from that folder then is run the new compile ones.
I now cna run the test, but I do not see the bux moving, it seems that tracing the same ray from the same location and prioduceing the results in teh image.
Is there anything I need to do top make scan the floor?
Untitled.png
Untitled.png (72.46 KiB) Viewed 1129 times
Julio Jerez
Moderator
Moderator
 
Posts: 11039
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: raycast issue

Postby Julio Jerez » Mon Sep 03, 2018 1:37 pm

ah I see, you move the box by using teh keys left and right.
and I see the difference, yes.
when is changes from one plane to teh next the distance changes, I am debugging it now.
Julio Jerez
Moderator
Moderator
 
Posts: 11039
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: raycast issue

Postby Sweenie » Mon Sep 03, 2018 1:39 pm

I will try do some tests tomorrow :)

[EDIT]
Never mind, just saw you got it going :lol:
Sweenie
 
Posts: 490
Joined: Mon Jan 24, 2005 7:59 am
Location: Sweden

Re: raycast issue

Postby blackbird_dream » Mon Sep 03, 2018 5:58 pm

:)
Sorry I'm late too but finally you managed to make the demo run
User avatar
blackbird_dream
 
Posts: 279
Joined: Wed Jun 07, 2006 3:08 pm
Location: Italy

Re: raycast issue

Postby Julio Jerez » Mon Sep 03, 2018 6:38 pm

Ok I think I fixed now, if you sync the newton SDK and build it, it should be fine now.
This was a legacy bug that goes back to the very early version of the engine.

Basically the collision tree caches the polygons face normal, so when I said the reason for these kind of errors is usually the face normal and that is seem a float32 rounding.
I was correct, but the source of the bug was not the input data, it was a bug In the collision tree builder.

The collision tree caches the face normal because there is a lot of redundancy on face normal and by pre calculating them we can do the intermediate calculation in higher precision and truncate the error to single precision on the result. This trick is use a lot in newton. In fact some calculations are done in up to 256 bit of precision using adaptive arithmetic.

This is done in function void dgPolygonSoupDatabaseBuilder::End(bool optimize)

you can see that the intermediate calculation is done using dgDouble, my mistake was the last function that call to remove the duplicates normal, I was calling.
m_normalCount = dgVertexListToIndexList(&m_normalPoints[0].m_x, sizeof (dgBigVector), 3, m_faceCount, &m_normalIndex[0], dgFloat32 (1.0e-4f));

since these are normalized values we can use a bound tolerance. we need to use a torelace or else some values may come out incorrect because of rounding errors, (is posible that two values yeal the wrong result because of round error and the a conditional pick the wrong branch, producing a bad sorting.
Anyway the value (1.e-4) dated from when this was all done with 32 bit floats which are about 6 digit of dynamic range, after I code to use double, i forgot to change that value to something smaller.
The result was that normal that were close enough where fused and an avagare was used as a representative.

By making the tolerance 100 time smaller the bug does not goes away, but it becomes 100 time smaller. The error can be made even smaller, but just trust me, that will result in some unhealthy calculation when using single precision like you are doing, I am going to ask you to trust me on that, I am not saying it likely, this is many years of numerical analysis, and I can tell you that it is a fool errand to try to do exact arithmetic with floating point precision.

Anyway, if you sync and try again, the error should be within a bound of +-1e-5

Thank for that bug, this was would probably never be fixed without such a precise repro case.
Julio Jerez
Moderator
Moderator
 
Posts: 11039
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: raycast issue

Postby blackbird_dream » Tue Sep 04, 2018 4:33 am

OK Thks a lot for your quick and efficient work.
I've tested it. the distance varies from 1.9879 to 1.9884 which is good.
User avatar
blackbird_dream
 
Posts: 279
Joined: Wed Jun 07, 2006 3:08 pm
Location: Italy

Previous

Return to General Discussion

Who is online

Users browsing this forum: No registered users and 3 guests

cron