Re: Physics, world representation

--===============0202793378==
Content-Type: multipart/alternative; boundary=f46d0447f19a4b6de104c251a198

--f46d0447f19a4b6de104c251a198
Content-Type: text/plain; charset=UTF-8

>
> *My mail is all about what you refer to "coplanar or close to it"
> geometry.*
>

In systems that generate contact joints (step-based systems,) you can do
post-processing on all the contacts you detect, and merge coincident or
near contacts to try to patch over the problem. In CCD systems, I don't
know exactly what to do. Perhaps there's some location within the
detection/reaction loop which lets you do the same.


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


I'm assuming you mean that objects come from outside and collide with both
the objects at x=1.
What you're describing must be a behavior specific to Bullet. In the
systems I have used, the out-facing faces would actually be deemed the
deepest penetrations, and would generate contacts that push the object out.
In general, coincident faces are mostly a problem where they both face the
actual dynamic geometry, in a situation similar to how rendering would
generate Z fighting surfaces.



> No, I don't think I will ever go back to dynamic bodies for modelling
> player or logic controlled entities.
>
>
Use what works for you in your game! I'm just reporting what works for me.
(And if you go down that route, you end up with something like Endorphin,
which IMO is super cool ;-)



> 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.
>


In general, any system will require that some amount of contact
merging/filtering/conditioning is done. For example, you can prefer contact
normals that point towards the center of the collider over contacts that
point away; you can prefer contacts that are deeper to contacts that are
shallower; you can prefer contacts that point opposite to the object
velocity to contacts that point perpendicular or in the same direction as
movement. Some systems have a level of contact filtering built in; others
leave it entirely to the user.



> 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?
>
>

That has to be specific to Bullet, and I have no experience to help out
there.


Sincerely,

jw

--f46d0447f19a4b6de104c251a198
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><b>My mail i=
s all about what you refer to &quot;coplanar or close to it&quot; geometry.=
</b></div>

<div></div></blockquote><div><br></div><div>In systems that generate contac=
t joints (step-based systems,) you can do post-processing on all the contac=
ts you detect, and merge coincident or near contacts to try to patch over t=
he problem. In CCD systems, I don&#39;t know exactly what to do. Perhaps th=
ere&#39;s some location within the detection/reaction loop which lets you d=
o the same.</div>
<div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>So for ex=
ample, say 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 fac=
e whose &quot;collision vertices&quot; will be at x=3D1 yz plane.</div>

This prevents correct=C2=A0behavior=C2=A0of dynamic objects. At the very be=
st, they will get stuck at the edge. If the forces involved are </blockquot=
e><div><br></div><div>I&#39;m assuming you mean that objects come from outs=
ide and collide with both the objects at x=3D1.</div>
<div>What you&#39;re describing must be a behavior specific to Bullet. In t=
he systems I have used, the out-facing faces would actually be deemed the d=
eepest penetrations, and would generate contacts that push the object out. =
In general, coincident faces are mostly a problem where they both face the =
actual dynamic geometry, in a situation similar to how rendering would gene=
rate Z fighting surfaces.</div>
<div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>No, I d=
on&#39;t think I will ever go back to dynamic bodies for modelling player o=
r logic controlled entities.</div>

<div><br></div></blockquote><div><br></div><div>Use what works for you in y=
our game! I&#39;m just reporting what works for me. (And if you go down tha=
t route, you end up with something like Endorphin, which IMO is super cool =
;-)</div>
<div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div></div><=
div>Problem is, if I don&#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>
</blockquote><div><br></div><div><br></div><div>In general, any system will=
 require that some amount of contact merging/filtering/conditioning is done=
. For example, you can prefer contact normals that point towards the center=
 of the collider over contacts that point away; you can prefer contacts tha=
t are deeper to contacts that are shallower; you can prefer contacts that p=
oint opposite to the object velocity to contacts that point perpendicular o=
r in the same direction as movement. Some systems have a level of contact f=
iltering built in; others leave it entirely to the user.</div>
<div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div></div><=
div>Now, there&#39;s a thing I&#39;m thinking about. Considering the two bo=
xes above, they are not actually (.5, .5, .5) in half length. For some reas=
on I don&#39;t quite understand, they have an <i>external </i>margin (other=
 shapes typically have an <i>internal </i>margin). Including the margin, th=
e 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 confi=
rm that?</div>

<div><br></div></blockquote><div><br></div><div><br></div><div>That has to =
be specific to Bullet, and I have no experience to help out there.</div><di=
v><br></div><div><br></div><div>Sincerely,</div><div><br></div><div>jw</div=
>
<div>=C2=A0</div></div>

--f46d0447f19a4b6de104c251a198--

--===============0202793378==
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

--===============0202793378==--