[ODE] better way to handle terrain

[Tri Sulistiono]

believe it or not, my past experience with ODE collision library proves that
a single merged tri-mesh collision geom is faster than 'chunked'
tri-meshes... and yes, the 'chunked' way was my first trial coz it
should --in theory-- be faster, but after some testing and coding iteration
to enhance our fps stats, it shown that merging all tri-mesh geoms result in
fastest 'updates' in our implementation case... but again, as the ODE doc
says, your mileage may vary :).
I think it depends on how you define 'huge' is...

Tri S.

----- Original Message -----
From: "cesar pachon" <cesarpachon at yahoo.es>
To: <ode at q12.org>
Sent: Wednesday, January 05, 2005 8:27 PM
Subject: [ODE] better way to handle terrain


> Hello! first, thanks to the people who wrote me giving
> some clues about the trimesh problem I posted (trimesh
> crash problem). It was a setup problem and it is
> already fixed. Thanks!
> Now, I am doing a small car racing demo, and I wonder
> what would be the better way to setup and handle the
> terrain geom. a first aproach would be a huge mesh,
> but I think it is not a good idea. maybe splitting the
> mesh into squared tiles, and adding them to a Quadtree
> or  a Hash space??
>
>
>
> ______________________________________________
> Renovamos el Correo Yahoo!: ¡250 MB GRATIS!
> Nuevos servicios, más seguridad
> http://correo.yahoo.es
> _______________________________________________
> ODE mailing list
> ODE at q12.org
> http://q12.org/mailman/listinfo/ode
>