[ODE] Terrain<->Box collision without tri-collider

[gl]

Stephan, Fabian,

(I'm sending this to the list in case anybody else wants to join in)

Sounds great.  Like Stephan I'm tied up this week, but should be free after
that.  I also haven't done any collision yet.

I think for a heightfield contribution to be useful, it should be able to
cope with any sized grid input.

The next question is what format we should pass in.  I can see two
scenarios - either sharing height-only data, and computing triangles and
normals from that on-the-fly.  This might be less than optimal?

The 2nd I guess would be using heights (float?) and pre-computed normals.  I
think we need both averaged vertex normals and face normals?

Anybody else interested in this, please chime in with your requirements.  We
may aswell make this as general (and yet optimal) as possible, if we're
going to contribute it back to ODE...

Stephan, I don't think we can use code from SlickWorm unmodified, as that's
released under the more restrictive GNU license, whilst ODE is also covered
by the far more open BSD style license (something I personally rely on).  Of
course if you're rewritten it a fair bit, it's probably not a problem...

Fabian, sounds great - love to look at the code (but I won't be able to
spend time on it until next week).
--
gl


yes, we are talking about a regular gridded heightfield. If it's of any
use for others, sure, why not contribute it. I found some
terrain<->sphere code (for ODE)
in SlickWorm (slickworm.sf.net -> terrain_collider.cpp). I am using
Demeter as my terrain engine, but it's ok to specify and
TerrainDataExchange interface (for elevation, normal ...) so it's
possible to plug it on all other engines as well.

All i have up to now is the framework to get a new GeomClass into ODE
(Function selector and collider prototypes) -> not much. I also have to
admit that i haven't done collision detection before, just as an excuse :).

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/openmountains/prototype/src/C
ollision.cpp
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/openmountains/prototype/src/C
ollision.h

Let me know if you want to collaborate. I have my last 3 exams this week
(for this term) so i have lots of time after friday.

bye,
Stephan

----- Original Message -----
From: "Fabian Herb" <commander@herb-clan.de>
To: "gl" <gl@ntlworld.com>
Sent: Sunday, January 26, 2003 11:03 AM
Subject: Re: [ODE] Terrain<->Box collision without tri-collider


> Hi,
>
> I've already implemented a simple heightfield collider that collides
> quite well with spheres, and also does with boxes, but that is not
> finished yet (I'm kind of stuck there).
> It uses very simple math (which can be a speed gain), but it is
> currently limited to use heightfield data from my own terrain
> objects, which all have 8x8 quads.
> If you think it would be useful, I can send it to you. The comments
> are currently in German, but I could change that.
>
> Regards
> Fabian Herb
>
> >Hi Stephan,
> >
> >are we talking about a regularly spaced heightfield?  I need this myself
> >fairly soon, and was expecting to have to write it.  I'm currently tied
up
> >with something else, but maybe we could collaborate on it soon.  Are you
> >planning to contribute it back to ODE?
> >--
> >gl
> >
> >----- Original Message -----
> >From: "Stephan Heigl" <steve@eisscholle.de>
> >To: <ode@q12.org>
> >Sent: Saturday, January 25, 2003 7:53 PM
> >Subject: [ODE] Terrain<->Box collision without tri-collider
> >
> >
> >>  Hi,
> >>
> >>  due to data duplication i'd like to do the collision tests against the
> >terrain
> >>  without the tricollider and OPCODE. So i created a custom
dTerrainGeom. I
> >>  found some info on how to do terrain<->sphere intersection but nothing
on
> >box
> >>  intersection.
> >>  Any idea how to handle that?
> >>
> >>  Thank you very much in advance.
> >>
> >  > - Stephan
> >
> >_______________________________________________
> >ODE mailing list
> >ODE@q12.org
> >http://q12.org/mailman/listinfo/ode
>
>
>