[ODE] Methods of handling terrain

[Paul Vint]

----- Original Message ----- 
From: "Matthias Grumet" <matthias at grumet.at>
>
> a few days ago, i started working on the very same thing! :-)
> i still have a few problems with the terrain though.
>
> i have my heightfield data in a 2-dimensional array and fill the
> Vertices/Indices the following:
>
>        for (int i=0;i<size;i++) {
>                for (int j=0;j<size;j++) {
> .... <edited for length>
>               Indices[k++]=i+1+size;
>        }
>
> i am not sure if this is correct, so if anyone else has a better
> solution, please let me know!

I did try something similar - it doesn't suit my needs though, as I really 
want the size of the triangles to vary based on the terrain. When I was 
doing it this way I ran into a limitation in that depending on the scaling 
(ie: the size of each triangle) I either ended up with WAY too many 
triangles, or with problems where right angles (ie: a wall on the ground) 
showed up as angular slopes.

>> 2. Must be able to convert a *modelled* terrain to ode (I want
>> the ability to make caverns/caves, so I believe that the terrainZ
>> functions won't fit my needs). (I have already written the code to
>> import my models, and have some code for converting to trimesh)
>
> what are you using to model the terrain?
> i am painting a greyscaled image in Photoshop and load it as a TGA in
> my program to get the 2d-array.

I did some experimenting with heightmaps as well, but I really want a 
modelled environment. I do my modelling in Blender and then export the file 
to a text file (Milkshape3d format) using an export script I wrote. (If 
anyone is interested, the script  can be found at 
http://www.scorched3d.co.uk/phpBB2/viewtopic.php?t=1089)


>
>> I'm quite certain I'll be using a trimesh, and that it'll have to
>> be "segmented" into x*y chunks to speed up the collision detection
>> process. I had previously tried to implement the terrain model using
>> a trimesh, but had trouble with objects falling through it, but I
>> have never really looked into it again (I dropped that at the time
>> and instead spent my time getting networking, sound, etc working
>> while I put more thought into how to handle terrain.)
>
> i too have problems with my car just sinking through the trimesh,
> though it should be a solid object.
>
>
Megan said:
>As for things falling through... check the usual suspects - Did you
>verify the winding order/normals were correct?  Were you generating at
>least 24 contacts per point?  What step-size were you using?  You
>weren't depending on trimesh-trimesh collisions, right?  Etc.

I haven't really looked into it - I will though, and then let you know. :)

Megan also said:
> As you say, a trimesh would fit the needs of your specifications.
> However, you might want to think about NOT breaking the trimesh into
> multiple smaller/separate geoms - OPCODE already has an AABB tree
> built into it, and it may end up being more efficient if you hand it
> all the triangle data in one lump and let it do what it needs to do
> with the data.

Interesting, thanks! I think you just saved me a whole lot of time! I'll 
still need to break it up for rendering, but it's good to know that ODE will 
handle large trimesh well. :)

Cheers!
Paul