TreeCollision optimization bug

A place to discuss everything related to Newton Dynamics.

Moderators: Sascha Willems, walaber

Re: TreeCollision optimization bug

Postby Cannos » Fri Dec 22, 2017 2:36 pm

Just wanted to follow up on the last post and see if there's a chance you can look at the bug with the latest data. If not, I'll try to work around it. Thanks!
Cannos
 
Posts: 129
Joined: Thu Mar 04, 2010 5:41 pm

Re: TreeCollision optimization bug

Postby Julio Jerez » Fri Dec 22, 2017 3:11 pm

oh I forget about that, I am debugging now.
tell me something.
is that teh same mesh as before?
when you say a work around, what do you mean?
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: TreeCollision optimization bug

Postby Cannos » Fri Dec 22, 2017 3:20 pm

No, it's a similar mesh, but slightly different. It seems that small changes in the mesh can make holes appear and disappear in different places.

The workaround would be to just keep tweaking it until there are no holes. I don't really know what's causing the holes, so it would be trial and error adjustments. Another alternative is to just not optimize this mesh, but I'd rather not do that. But I can do one of those two workarounds if there's not a good fix.

Thanks, I really appreciate you looking at it!
Cannos
 
Posts: 129
Joined: Thu Mar 04, 2010 5:41 pm

Re: TreeCollision optimization bug

Postby Julio Jerez » Fri Dec 22, 2017 3:46 pm

Cannos wrote: Another alternative is to just not optimize this mesh

no that should not be an option, newton rely on good mesh quality for good quality simulation.
we need to get the optimizer 100% reliable.

The optimizer works by pattern matching in a graph.
these bugs are caused by cases in the mesh that match some of the pattern that can be recognized for optimization. so some extra test has to be added to discriminate bad matches.

I have narrowed to a set fo 136 triangle by bisection, if you sync the demos you will see the sub mesh that cause it.

136 trangle is still to large a set to debug, I seen thet the case happen when one triangle seen to math agoes the is really far away from it vicinity, which indicate that the mesh maniford is incorrect.
is not productin any warning,

anyway I will try to norrowint down more before start debugging it, but it seem the facts are no adjacent so I will need to make an indirect table to remove faces.

In a way these are very good stress test for the optimizer so I appreciated the repros.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: TreeCollision optimization bug

Postby Julio Jerez » Fri Dec 22, 2017 10:25 pm

all right this bug is fixed now. It was another pattern that I did no recognized.
basically is an edge is a candidate to be remove, that edge can change if some adjacent edge was removed, so the need to be test every time.

this fixed it, is hard to anticipate these cased, so if you get another please let me know again, this makes the engine more robust.

you can get dgPolyhea.cpp and .h
thank for the repro.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: TreeCollision optimization bug

Postby Cannos » Sun Dec 24, 2017 2:06 am

Yeah, looks like that fixes it. Thanks!! I'll let you know if I run into any more issues.
Cannos
 
Posts: 129
Joined: Thu Mar 04, 2010 5:41 pm

Previous

Return to General Discussion

Who is online

Users browsing this forum: No registered users and 17 guests

cron