+- Forums (https://www.vdrift.net/Forum)
+-- Forum: Community (https://www.vdrift.net/Forum/forumdisplay.php?fid=3)
+--- Forum: Cars & Tracks (https://www.vdrift.net/Forum/forumdisplay.php?fid=11)
+--- Thread: Track collision geometry woes (/showthread.php?tid=1870)
Track collision geometry woes - NaN - 01-18-2015
I've spent some time investigating sudden car vs track collisions.
A part of them can be attributed to how bullet handles triangle mesh collisions. It allows to collide against triangle eges. Which is bad news for our tracks, can be fixed with edge filtering though.
There is a minor issue with edge filtering for 2d collision objects like tree billboards as you can imagine. Just get the approach angle right and you might pass through one or be pushed to the side. But then trees, masts, poles should use capsule shapes maybe.
The other source of unwanted collisions is geometry that looks like this (dirt-3 track):
![[Image: XQVvirw.jpg]](http://i.imgur.com/XQVvirw.jpg)
Here we have road guard rails with caps. Even if there is no gap to the next wall. Bullet will hit this cap faces really hard, while you might be just sliding along the rails. This is something that can not be fixed, as the simulation is running at discrete timesteps.
For dirt-3 the rail geometry is already pre-split. The cap belongs to a separate object, so this object just needs to have collisions disabled.
I am not sure how it looks for other tracks. Sounds like a lot of work...
Anyway, I'll test the edge filtering a bit more and push it to master, as it helps already.
RE: Track collision geometry woes - NaN - 01-26-2015
I've spent some time testing different tracks. Trees are not a problem being cross billboards (2 planes).
Open fence or guardrail endings is what would have to be fixed, by adding crash cushions or tire barriers maybe.
RE: Track collision geometry woes - slickx - 02-18-2015
the problem in that picture is that one of the surfaces has the normal inverted that causes the problem.
RE: Track collision geometry woes - NaN - 02-19-2015
(02-18-2015, 05:52 AM)slickx Wrote: the problem in that picture is that one of the surfaces has the normal inverted that causes the problem.
Bullet collision detection doesn't use normals, is two-sided. One could implement a special variant that takes normals into account, but it is not trivial.
RE: Track collision geometry woes - NaN - 03-06-2015
The article here describes a possible solution to the edges issue:
http://www.codercorner.com/blog/?p=1156