Re: Physics, world representation

--===============1086180321==
Content-Type: multipart/alternative; boundary=e89a8f50390ab79c6204c241c866

--e89a8f50390ab79c6204c241c866
Content-Type: text/plain; charset=ISO-8859-1

Thank you Jon for your elaborated answer.
It appears I have not pointed out my concerns clearly enough.

I also notice I have not made out clear what is the relationship between
the BSP and the physics.
The idea is this: we need to make dynamics collide with the world. So,
BSP-based engines typically pull out hulls from BSPs (because BSPs,
regardless of the geometry, will describe hulls as well). Either the game
provides the physics API with this information or the world will be
non-solid. That's it. For what it counts, my understanding of BSP appears
to agree with yours.
As a final note about that, let me state that clear: *I do not use BSP and
I don't plan to*.
My current system has a fully decoupled representation for physics.

*My mail is all about what you refer to "coplanar or close to it" geometry.*
When two static rigidbodies are placed near each other the contact
information is indeed garbled. And this is the problem because, as you
notice, it gives issues in resolving the dynamics.
So for example, say we have two boxes with half extents being (.5, .5, .5),
centered at O1=(.5, .0, .0) and O2=(1.5, 0, 0). They'll both generate a
face whose "collision vertices" will be at x=1 yz plane.
This prevents correct behavior of dynamic objects. At the very best, they
will get stuck at the edge. If the forces involved are big
in magnitude then they will (very likely) cause the dynamic object to jump
over the shared plane. This approach also appears to interact poorly with
encroaching resolution.
Not to mention it does not support warping natively. And I cannot figure
out how to walk upstairs without causing hiccups. It also has some
nontrivial implication WRT scripting design.
No, I don't think I will ever go back to dynamic bodies for modelling
player or logic controlled entities.

While we're at it, I would be interested in knowing for what kind of
geometry this system actually works, because I see no way for which it
would work for me. In general, it appears to me modelling "self-moving"
entities by dynamic object is a bit of an overcomplication compared to just
move a kinematic body.
But again,* the problem is not player controlled stuff, the problem is
purely dynamic objects.*

Problem is, if I don't solve the multiple contact issue above, then I won't
be able to use *dynamic objects reliably* at all.

Now, there's a thing I'm thinking about. Considering the two boxes above,
they are not actually (.5, .5, .5) in half length. For some reason I don't
quite understand, they have an *external *margin (other shapes typically
have an *internal *margin). Including the margin, the real half-extents
would be (.54, .54, .54). So the boxes actually overlap a bit. Maybe the
problem would go away if I subtract .04. Can anyone confirm that?

To quote the original message:

main problem I've observed is that DYN[amic] objects won't interact
properly with static collision geometry at [shared] bounduaries.


It would also be interesting to know if and how other libraries deal with
this issue (of collision geometry near each other). In general, the
question remains the same: how should I set up my world to allow dynamic
objects to work as intended?

Thank you,
Massimo


2012/6/11 Jon Watte <[email protected]>

> Because static geometry doesn't move, static geometry won't typically be
> tested against other static geometry, so most libraries actually work just
> fine with intersecting static geometry. However, static geometry which has
> surfaces that alias (coplanar, or close to it,) may generate bad contact
> information for dynamic objects that contact.
>

--e89a8f50390ab79c6204c241c866
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Thank you Jon for your elaborated answer.<div>It appears I have not pointed=
 out my concerns clearly enough.</div><div><br></div><div>I also notice I h=
ave not made out clear what is the relationship between the BSP and the phy=
sics.</div>
<div>The idea is this: we need to make dynamics collide with the world. So,=
 BSP-based engines typically pull out hulls from BSPs (because BSPs, regard=
less of the geometry, will describe hulls as well). Either the game provide=
s the physics API with this information or the world will be non-solid. Tha=
t&#39;s it.=A0For what it counts, my understanding of BSP appears to agree =
with yours.</div>
<div>As a final note about that, let me state that clear:=A0<b>I do not use=
 BSP and I don&#39;t plan to</b>.</div><div>My current system has a fully d=
ecoupled representation for physics.</div><div><br></div><div><b>My mail is=
 all about what you refer to &quot;coplanar or close to it&quot; geometry.<=
/b></div>
<div>When two static rigidbodies are placed near each other the contact inf=
ormation is indeed garbled. And this is the problem because, as you notice,=
 it gives issues in resolving the dynamics.=A0</div><div>So for example, sa=
y we have two boxes with half extents being (.5, .5, .5), centered at O1=3D=
(.5, .0, .0) and O2=3D(1.5, 0, 0). They&#39;ll both generate a face whose &=
quot;collision vertices&quot; will be at x=3D1 yz plane.</div>
This prevents correct=A0behavior=A0of dynamic objects. At the very best, th=
ey will get stuck at the edge. If the forces involved are big in=A0magnitud=
e=A0then they will (very likely) cause the dynamic object to jump over the =
shared plane. This approach also appears to interact poorly with encroachin=
g resolution.<div>
Not to mention it does not support warping natively. And I cannot figure ou=
t how to walk upstairs without causing hiccups. It also has some nontrivial=
 implication WRT scripting design.</div><div>No, I don&#39;t think I will e=
ver go back to dynamic bodies for modelling player or logic controlled enti=
ties.</div>
<div><br></div><div>While we&#39;re at it, I would be interested in knowing=
 for what kind of geometry this system actually works, because I see no way=
 for which it would work for me. In general, it appears to me modelling &qu=
ot;self-moving&quot; entities by dynamic object is a bit of an overcomplica=
tion compared to just move a kinematic body.</div>
<div>But again,<b> the problem is not player controlled stuff, the problem =
is purely dynamic objects.</b></div><div><br></div><div>Problem is, if I do=
n&#39;t solve the multiple contact issue above, then I won&#39;t be able to=
 use <b>dynamic objects reliably</b> at all.</div>
<div><br></div><div>Now, there&#39;s a thing I&#39;m thinking about. Consid=
ering the two boxes above, they are not actually (.5, .5, .5) in half lengt=
h. For some reason I don&#39;t quite understand, they have an <i>external <=
/i>margin (other shapes typically have an <i>internal </i>margin). Includin=
g the margin, the real half-extents would be (.54, .54, .54). So the boxes =
actually overlap a bit. Maybe the problem would go away if I subtract .04. =
Can anyone confirm that?</div>
<div><br></div><div>To quote the original message:</div><blockquote style=
=3D"margin:0 0 0 40px;border:none;padding:0px"><div><span style>main proble=
m</span><span style>=A0I&#39;ve observed is that=A0</span><span style>DYN[a=
mic] objects won&#39;t interact properly with static collision geometry at =
[shared] bounduaries</span><span style>.</span></div>
</blockquote><div><br></div><div>It would also be interesting to know if an=
d how other libraries deal with this issue (of collision geometry near each=
 other). In general, the question remains the same: how should I set up my =
world to allow dynamic objects to work as intended?</div>
<div><br></div><div>Thank you,</div><div>Massimo</div><div><br></div><div><=
br></div><div><div class=3D"gmail_quote">2012/6/11 Jon Watte <span dir=3D"l=
tr">&lt;<a href=3D"mailto:[email protected]" target=3D"_blank">jwatte@gmail.=
com</a>&gt;</span><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>Because static geometry doesn&#39;t mov=
e, static geometry won&#39;t typically be tested against other static geome=
try, so most libraries actually work just fine with intersecting static geo=
metry. However, static geometry which has surfaces that alias (coplanar, or=
 close to it,) may generate bad contact information for dynamic objects tha=
t contact.</div>
</blockquote></div></div>

--e89a8f50390ab79c6204c241c866--

--===============1086180321==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Sweng-Gamedev mailing list
[email protected]
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com

--===============1086180321==--