[ODE] csg + collision detection
John D. Gwinner
jgwinner at dazsi.com
Tue Dec 18 12:20:01 2001
This is a multi-part message in MIME format.
------_=_NextPart_001_01C187F8.AF20865C
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Wow, nice - I downloaded the app but haven't run it yet.
=20
I will look at Solid and Swift. First, I need to parse POV-Ray to get a
scene built in memory, and I'll use simple primitives for that.
=20
My other thought, if I can do CSG, would be to just add all of POV-Ray's
primitives, i.e. height fields, torus, etc. to the collision routines.
This might be easier and more accurate than Solid/Swift; however, if
anyone has loaded a mesh object, then I'd need the more general
solution.
=20
What would be really strange would be to allow the CSG to happen IN the
simulation. I'll have to think about that, but it wouldn't be that hard
to construct the code so the CSG decomposition into the polygon soup
occurs 'per frame' vice done at the start of the frame. Bruce Naylor's
algorithms seem fast anyway, I don't think this will be a limiting
factor. The ray tracing is the longest part of the run anyway.
=20
My major concern at this point is that ODE, and Naylor's work, may or
may not be the most accurate way to go - I think this is the right way
but for a ray trace solution, slower but more accurate might be better.
Maybe I should just run the simulation at 2x frame rate or something.
Stability is actually very important as you don't want to start a 10 day
ray trace run and find out on day 7 that there was a stability issue!
=20
=3D=3D John =3D=3D
-----Original Message-----
From: Erwin Coumans [mailto:erwin.coumans@havok.com]=20
Sent: Monday, December 17, 2001 3:53 AM
To: ode@q12.org
Subject: [ODE] csg + collision detection
=09
=09
=09
> John D. Gwinner wrote:
> I'm using this for POV-Ray. The more I've been thinking of
this, it
> won't be easy, as POV-Ray typically uses a lot of CSG. I
would really
> need something to decompose CSG into a polygon soup. =20
=20
regarding the csg tesselation: this is something I've been
working on,
and I do have a nice solution. Other people who had solutions
for this
are Bruce Naylor (using dynamic merging bsp trees) and Chris
Butcher
http://www.finality.net/otago/modeller.php3 .=20
Dynamic csg and Solid collision detection combines fine, so if
you are interested
I can pass you some information.
=20
=09
>I guess I was wondering if there was any
>interest to one particular package or another.=20
=20
please do solid and swift, else I do it :)
=09
Erwin Coumans
=20
------_=_NextPart_001_01C187F8.AF20865C
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2712.300" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><SPAN class=3D084261319-18122001><FONT face=3DArial color=3D#0000ff =
size=3D2>Wow,=20
nice - I downloaded the app but haven't run it yet.</FONT></SPAN></DIV>
<DIV><SPAN class=3D084261319-18122001><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D084261319-18122001><FONT face=3DArial color=3D#0000ff =
size=3D2>I will=20
look at Solid and Swift. First, I need to parse POV-Ray to get a =
scene=20
built in memory, and I'll use simple primitives for =
that.</FONT></SPAN></DIV>
<DIV><SPAN class=3D084261319-18122001><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D084261319-18122001><FONT face=3DArial color=3D#0000ff =
size=3D2>My=20
other thought, if I can do CSG, would be to just add all of POV-Ray's=20
primitives, i.e. height fields, torus, etc. to the collision =
routines. =20
This might be easier and more accurate than Solid/Swift; however, if =
anyone has=20
loaded a mesh object, then I'd need the more general=20
solution.</FONT></SPAN></DIV>
<DIV><SPAN class=3D084261319-18122001><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D084261319-18122001><FONT face=3DArial color=3D#0000ff =
size=3D2>What=20
would be really strange would be to allow the CSG to happen IN the=20
simulation. I'll have to think about that, but it wouldn't be that =
hard to=20
construct the code so the CSG decomposition into the polygon soup occurs =
'per=20
frame' vice done at the start of the frame. Bruce Naylor's =
algorithms seem=20
fast anyway, I don't think this will be a limiting factor. The ray =
tracing=20
is the longest part of the run anyway.</FONT></SPAN></DIV>
<DIV><SPAN class=3D084261319-18122001><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D084261319-18122001><FONT face=3DArial color=3D#0000ff =
size=3D2>My=20
major concern at this point is that ODE, and Naylor's work, may or may =
not be=20
the most accurate way to go - I think this is the right way but for a =
ray trace=20
solution, slower but more accurate might be better. Maybe I should =
just=20
run the simulation at 2x frame rate or something. Stability is =
actually=20
very important as you don't want to start a 10 day ray trace run and =
find out on=20
day 7 that there was a stability issue!</FONT></SPAN></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial=20
size=3D2> &nbs=
p; =20
=3D=3D John =3D=3D</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
<DIV></DIV>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> =
Erwin Coumans=20
[mailto:erwin.coumans@havok.com] <BR><B>Sent:</B> Monday, December 17, =
2001=20
3:53 AM<BR><B>To:</B> ode@q12.org<BR><B>Subject:</B> [ODE] csg + =
collision=20
detection<BR><BR></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>> John D. Gwinner =
wrote:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>> I'm using this for =
POV-Ray. The more=20
I've been thinking of this, it<BR>> won't be easy, as POV-Ray =
typically=20
uses a lot of CSG. I would really<BR>> need something to =
decompose=20
CSG into a polygon soup. </FONT></DIV>
<DIV> </DIV></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>regarding the csg tesselation: this =
is something=20
I've been working on,</FONT><FONT face=3DArial size=3D2></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>and I do have a nice solution. =
Other people=20
who had solutions for this</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>are Bruce Naylor (using dynamic =
merging bsp=20
trees) and Chris Butcher</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><A=20
=
href=3D"http://www.finality.net/otago/modeller.php3">http://www.finality.=
net/otago/modeller.php3</A> .=20
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Dynamic csg and Solid collision =
detection=20
combines fine, so if you are interested</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I can pass you some =
information.</FONT></DIV>
<DIV> </DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>>I guess I was wondering if there =
was=20
any<BR>>interest to one particular package or =
another. </FONT></DIV>
<DIV> </DIV>
<DIV>please do solid and swift, else I do it :)<BR></DIV>
<DIV>Erwin Coumans</DIV>
<DIV> </DIV></BLOCKQUOTE></FONT></BODY></HTML>
=00
------_=_NextPart_001_01C187F8.AF20865C--