[ODE] Re: Heightfield / Collision.

[Chris Brodie]

> From: gl [mailto:gl@ntlworld.com]
> Another complication - heightfield triangle layout.   I use

Or something slightly different, as can be seen in this screenshot:

http://fourth.flipcode.com/screenshots/large/15.html

The reason for this is a stripping optimisation. Each tile is a single strip that is generated by reversing the strip direction at the end of each row by flipping the orientation a few times.

I'm not above using a different index buffer for rendering \ collision though. I'd say this is the way to go, there is no point creating a dependency here. Index buffers are 6 bytes per tri.

To jump in on the debate however, I can't understand why you would even want a full set of triangles for CD. Since you will only even need a few at a time to do CD wouldn't it be better to leave the memory reads of a buffer out of it and just form the triangles from the vertex sample poinjts as other have suggested. I like the idea of just forming a small 9*9 patch and colliding against that. 

The problems I see that we are facing are:

-Speed. we need to understand the platform we're working on. Memory reads of large datasets are slow, we probably want to restrict that as much as possible.

-Memory consumption. a 4096sq heightmap is big enough already without a CD triangle list and a rendering triangle list(the only. A solution that doesn't require a full triangle list would be better simulating larger area's. I use strips that that would just suck for CD, you'd have to search the strip for the tri you wanted. I support the idea of a single triangle without enough knowledge to know better. A patch would be messy if it spanned two tiles in a heightfield.

-Tiny triangle case. Is the triangle within the BV being tested against.
-Large triangle case. You can't test against the verts.
-Edge collision case. This sort of (in my mind) becomes a line vs BV test. A line has infinaite points. Maybe that can be exploited.
-By now you realise my complete lack of experience in this field...

My engine is primed to attack this problems now, I've held off using the TriList for heighfields as my engine will do heightmap vs BV tests so often that a naieve dTrilist implementation would kill performance, imagine an explosion causing stones to roll down a hill, wheels of a vehicle are always in contact with the ground. This problem needs the same finesse that was used to solve the Boxstacking problem as well. Objects need to be brought to rest on a terrain or you'll en up with a few thousand objects jiggling away on the landscape that will make it look like there is a permanant earthquake(+kill performance)


cb



NOTICE
This e-mail and any attachments are confidential and may contain copyright material of Macquarie Bank or third parties. If you are not the intended recipient of this email you should not read, print, re-transmit, store or act in reliance on this e-mail or any attachments, and should destroy all copies of them. Macquarie Bank does not guarantee the integrity of any emails or any attached files. The views or opinions expressed are the author's own and may not reflect the views or opinions of Macquarie Bank.