[ODE] Terrain colliders and/or Trimesh/OPCODE

[gl]

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, collision math is 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