[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, 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