[ODE] Terrain colliders and/or Trimesh/OPCODE

Sun Feb 8 22:55:33 MST 2004

My 2 cents about terrain collisions.

I'm currently using trimesh for my terrain collisions. It works fine
but has a lot of drawbacks:

- build time (my terrain is 2048x2048), each cell tesselated in 4
triangles. As a result my terrain has a total of 16 millions tris.
Trimesh works, but is slow to build (load times of up to many
minutes).

- non deformable, as you mentionned

- but (and that's my main concern at the moment), memory usage is
skyrocketing. I can render my terrain at up to 200 fps, but collisions
take 550 Mb of ram... hum

For these reasons i think i'm soon going to switch to Benoit's terrain
collider. I also have my Y axis as up, but i guess it shouldn't be too
hard to swap Y and Z in Benoit's code. I will likely only use terrain
vs box collisions.

F. Brebion

-----Original Message-----
From: ode-bounces at q12.org [mailto:ode-bounces at q12.org]On Behalf Of gl
Sent: dimanche 8 février 2004 22:17
To: ode at q12.org
Subject: Re: [ODE] Terrain colliders and/or Trimesh/OPCODE

I started writing one a while back.  It works great for spheres - and
nothing else : ).  I never got around to implemented other primitives, and
to be honest, it's not really my forte.  Benoit Chaperot's sounds good -
I'll have to check that out.

One thing worth pointing out is that Opcode/trimeshes are not suited to
real-time deformation, as a lot of work is done pre-processing the meshes -
for that you really need a heightmap collider.
--
gl

----- Original Message -----
From: "Nate W" <coding at natew.com>
To: <ode at q12.org>
Sent: Sunday, February 08, 2004 7:14 PM
Subject: RE: [ODE] Terrain colliders and/or Trimesh/OPCODE

> On Sun, 8 Feb 2004, John Miles wrote:
>
> > Amund wrote:
> >
> > > Also, there was another terrain collider in here somewhere, right? How
> > > is that one in comparison, and does anyone have a link from where it
> > > could be downloaded?
> >
> > My preliminary tinkering suggests that TriMesh is actually pretty
> > effective at representing height-mapped terrain.
>
> There's a heightmap collider included in the source distribution of a game
> demo called oracer (google for it), and another in a contribution called
> TerrainAndCone, which is in ODE's CVS.  I have done a bit of
> experimentation with both... The former works OK, but the latter (by
> Benoit Chaperot) seems much better.  Benoit's terrain collides with more
> shapes and does more sophisticated collision detection with each terrain
> polygon.
>
> I haven't objectively compared the performance against OPCODE, but I
> suspect that Benoit's approach is slightly (negligibly?) faster.  Of
> course, if you want cavities in your terrain then OPCODE is the only way
> to go.
>
> Also, in order to reduce startup time, I have modified both of the
> heightmap colliders so that they get their vertex information from a
> callback that talks to the terrain engine that's already part of the
> project I'm working on.  This adds some extra cycles per frame for each
> vertex, but there's no startup penalty and no additional storage
> requirement.  It only took a few lines of code - I just pass a function
> pointer in to the terrain constructor, and changed the collider code to
> invoke it rather than retrive vertex data from its own data structures.  I
> have no idea how (or if) this could be done with OPCODE.
>
> Bottom line... I agree with John that OPCODE is effective (I used OPCODE
> for Juice's terrain), but I think that Benoit's code is probably better
> still.  OPCODE has extra storage and startup-time requirements, and (most
> importantly) once something passes through an OPCODE mesh, it stops
> colliding.  A heightmap has a notion of "beneath" that a mesh doesn't
> have, and Benoit has provided us with a nice implementation.  Again,
> unless you need caves, in which case OPCODE is the right tool for the job.
> And OPCODE is useful for stuff that isn't terrain, like bunnies. :-)
>
> I've had OPCODE doing terrain in Juice for about a year, but I've only
> have a few hours experience each with the two heightmap colliders.  So, I
> reserve the right to change my mind about this stuff, but I am pretty
> confident the assessment above.
>
> --
>
> Nate Waddoups
> Redmond WA USA
> http://www.natew.com/
>
>
>
> _______________________________________________
> ODE mailing list
> ODE at q12.org
> http://q12.org/mailman/listinfo/ode
>
>

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.580 / Virus Database: 367 - Release Date: 06/02/2004

_______________________________________________
ODE mailing list
ODE at q12.org
http://q12.org/mailman/listinfo/ode