[ODE] ODE 0.6 and Terrain

[Megan Fox]

I did what you mentioned, and converted my heightmap data to triangle
data on the fly.  As you say, this is SLOW.  My solution was going to
be to modify ODE with a function to let me persist out that pre-baked
data, to avoid that (very slow) step on future loads.

There is, however, a perfectly good heightmap collider you could use
too.  I never tried it (I needed holes in my terrain and didn't want
to modify the heightmap collider to support that), but it has the
significant advantage that a heightmap can be assumed to be infinitely
thick underneat - vs the trimesh "paper thin triangle" thing that
causes so many warping issues.

On 7/26/06, Mark Fournier <mfournier at artech.ca> wrote:
> I notice that a lot of posters on the mailing list seem to have worked
> terrain or heightmaps into collision detection, and I'm wondering how they
> did it. I'm hoping that, in some cases at least, it wasn't simply the raw
> conversion of the terrain mesh or heightmap into a trimesh.
>
> I had my own system with 0.5 which consisted of converting a heightmap into
> a trimesh, but this relied on hybrid trees and a method for saving and
> restoring a preprocessed mesh (building the trimesh could take up to 10
> seconds for a 512 x 512 tile heightmap with up to 64 polys per tile, and
> using other tree types could take up to 20 megs while the hybrid tree did it
> in 2 megs or less.) I would like to modify the ODE code so that I can just
> submit a heightmap to ODE and have it calculate the polys as needed--this
> would allow us to have a dynamically changing heightmap.
>
> So, if you didn't use pregenerated trimeshes, how did you do it?
>
> _______________________________________________
> ODE mailing list
> ODE at q12.org
> http://q12.org/mailman/listinfo/ode
>


-- 
-Megan Fox
Idyllon, LLC
http://shalinor.circustent.us/megan/resume/