Re: Physics, world representation
pontus birgersson <[email protected]> Mon, 11 Jun 2012 22:01:17 +0200
| Newsgroups | gmane.games.devel.sweng |
|---|---|
| Message-ID | <[email protected]> |
--===============2102372742== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0027_01CD481D.B9C7E870" ------=_NextPart_000_0027_01CD481D.B9C7E870 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Finally, I've found that, for me, it works better to avoid kinematic = bodies, and simply drive user agents (avatars, cars, tanks, whatever) = using somewhat large forces and a PID controller. I know where I want = the avatar to be next frame; I know where it is and what its current = velocity and spin is; I can apply appropriate forces/torques (controlled = by a PID controller) to "trend towards" that goal. This ends up having = pretty good interaction with various obstacles, piles of rigid body = debris, stacks of crates, etc. For higher-fidelity simulations, you can = do the same thing for an animated avatar; play back the animation as a = force generator (based on a PID controller per joint, with the animation = as target.) I tried something like this for animation once and I found it to be very = prone to oscillations due to forces compensating one another between = frames. Did you do something special in order to cope with this? BTW = what is a PID controller? Regards Pontus From: Jon Watte=20 Sent: Monday, June 11, 2012 8:12 PM To: [email protected]=20 Subject: Re: [Sweng-Gamedev] Physics, world representation I've been wanting to learn Bullet, but time is scarce... My physics = experience comes from a few other libraries, both Open Source and = commercial. The main ones are ODE, JigLib, PhysX, and some home-grown = systems. Here's my generalization of how they all work, more or less = (with slight variations in naming and API):=20 First, collision detection, done between shapes/hulls/boxes, is separate = from physical movement/rotation, done by bodies. You can have one = without the other. In general, the "world" built from "static" geometries is fixed. It = won't move, take damage, or do anything other than provide impenetrable = barriers. Important to note is that the collision shapes in this world = have no rigid bodies at all in the simulation/solver. Resolving a = collision between a static geometry and a geometry tied to a dynamic = body means moving only the dynamic body. Another use for no-rigid-body = colliders is volumes used for triggers/detectors -- in that case, the = "static" geometries don't even provide any collision response forces. 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. "Dynamic" is used for anything that moves. "Dynamic" means that you can = receive forces, as well as apply them to others. "Dynamic" also means = that the solver will resolve geometry intersections by pushing both = objects in inverse proportion to their mass. (CCD such as used in Bullet = may "resolve" by simply moving the object a shorter amount of time = through the time step -- that's one of the things I've been wanting to = learn about Bullet) "Kinematic" is somewhat of a mix between the two. It's a body that can = be moved, but the body doesn't participate in incoming force resolution, = only in outgoing force generation. There is some variability here -- = some kinematic bodies tied to collision geometries will "stop" when = running into static geometries. Thus, a dynamic body that hits a = kinematic body will be resolved entirely by moving the dynamic body, not = affecting the kinematic body. "Static" geometry, which really means geometry without a dynamic rigid = body, can generally be whatever you want -- trimeshes, convex hulls, = half-open planes, boxes, cylinders, spheres, ... Whatever fits your = "game level" and won't move around in the game design. Building a = trimesh out of a BSP tree and using that as static geometry for a level = is a fine way to go about things. Regarding your understanding of BSP = geometry: - BSP can describe convex geometry, because each plane only splits the = current half-space sub-cell, not the entire world. - Worlds don't typically use bodies at all, especially in BSP based = games like Quake or whatnot. Some physics APIs may still want you to = talk about "static bodies," but these don't partake in the linear = constraint solver used for force/body/collision interaction. "Dynamic" geometry, which really means geometry with a dynamic rigid = body, generally has some constraints, especially with respect to concave = bits. Typically, it's very hard to generate a sane representation of how = you're supposed to "resolve" contact, or penetration, between two = concave geometries. Thus, trimeshes used for dynamic movement are often = not as robust or well-performing as convex geometries of various sorts. = For a CCD system, you may be able to calculate time-of-first-contact = between two moving convex geometries, but that's likely to use a lot of = CPU. Might still be worth it for cases where there's really only a few = things moving -- like a space ship docking with a space station. Finally, I've found that, for me, it works better to avoid kinematic = bodies, and simply drive user agents (avatars, cars, tanks, whatever) = using somewhat large forces and a PID controller. I know where I want = the avatar to be next frame; I know where it is and what its current = velocity and spin is; I can apply appropriate forces/torques (controlled = by a PID controller) to "trend towards" that goal. This ends up having = pretty good interaction with various obstacles, piles of rigid body = debris, stacks of crates, etc. For higher-fidelity simulations, you can = do the same thing for an animated avatar; play back the animation as a = force generator (based on a PID controller per joint, with the animation = as target.) Sincerely, Jon Watte -- "I pledge allegiance to the flag of the United States of America, and to = the republic for which it stands, one nation indivisible, with liberty = and justice for all." ~ Adopted by U.S. Congress, June 22, 1942 On Mon, Jun 11, 2012 at 12:54 AM, Massimo Del Zotto = <[email protected]> wrote: Hello to all contributors.=20 I need some help in understanding how physics libraries are supposed = to be used. I am referring to Bullet in particular as it appears to have = everything I need with a liberal, cross-platform licensing. So far I have been experimenting with physics for a few months with = mixed results at best. As I write this, I have just resolved an issue = with player-controlled objects which has been keeping me awake at night = for quite a while so I'm thinking at the next problem I see on the = horizon. Now, in Bullet there are three kinds of objects: 1.. STAtic=20 2.. DYNamic=20 3.. KINematic I think I have finally got a kinematic behaviour that works right for = my game. The point of this email is the interaction of dynamic objects and a = world built from static objects. I started modelling my world by procedurally generating a set of = hulls, in most cases, those were boxes. I don't remember the exact = numbers but I'd say my current data set for the world is about 96% boxes = (mostly axis-aligned) and 4% hulls. The main problem I've observed is that DYN objects won't interact = properly with static collision geometry at bounduaries. I am not well = aware if this happens as I allow the static geometry to overlap or not. = That is, I don't know if adjusting the collision geometry by a margin = would fix that. The current line of thinking in Bullet forums appears to be using = generic trimeshes and GIMPACT collision. Trimeshes allow to mark = internal edges and thus provide proper information to dynamic bodies to = interact properly. Now, let's leave out the fact that Bullet's demo about internal edges = does not seem to work as intended on my system. Let's leave out the problem that I would need to write some code in = the filter to brute-force internal edge detection. Let's start by considering that in general, I don't really feel ok = with feeding collision systems with graphics-oriented meshes. It might = work for now, but I'm afraid someone should be producing a reduced = polycount mesh. But my main problem is that I feel like I'm seriously missing = something. For example, Bullet has a BSP demo from which they build = collision geometry. Now, BSPs are strictly related to convex hulls so it = appears to me that worlds are meant to be built as an assembly of = multiple rigid bodies rather than a single big trimesh. BSP demo appears = to work ok with dynamic rigid bodies to me. So in short, I am asking for a direction is choosing a world = representation for my collisions. Maybe collision shapes are only meant = to be used for dynamics, with trimeshes being the only way to represent = a world? I cannot quite see a big picture with those things, so I start = thinking perhaps I've misunderstood everything since day 0. Elaborations are welcome. Massimo _______________________________________________ Sweng-Gamedev mailing list [email protected] = http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.c= om -------------------------------------------------------------------------= ------- _______________________________________________ Sweng-Gamedev mailing list [email protected] http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.c= om ------=_NextPart_000_0027_01CD481D.B9C7E870 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable <HTML><HEAD></HEAD> <BODY dir=3Dltr> <DIV dir=3Dltr> <DIV style=3D"FONT-FAMILY: 'Calibri'; COLOR: #000000; FONT-SIZE: 12pt"> <BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px" dir=3Dltr> <DIV>Finally, I've found that, for me, it works better to avoid = kinematic=20 bodies, and simply drive user agents (avatars, cars, tanks, whatever) = using=20 somewhat large forces and a PID controller. I know where I want the = avatar to=20 be next frame; I know where it is and what its current velocity and = spin is; I=20 can apply appropriate forces/torques (controlled by a PID controller) = to=20 "trend towards" that goal. This ends up having pretty good interaction = with=20 various obstacles, piles of rigid body debris, stacks of crates, etc. = For=20 higher-fidelity simulations, you can do the same thing for an animated = avatar;=20 play back the animation as a force generator (based on a PID = controller per=20 joint, with the animation as target.)</DIV></BLOCKQUOTE> <DIV dir=3Dltr>I tried something like this for animation once and I = found it to be=20 very prone to oscillations due to forces compensating one another = between=20 frames. Did you do something special in order to cope with this? BTW = what is a=20 PID controller?</DIV> <DIV dir=3Dltr> </DIV> <DIV dir=3Dltr>Regards</DIV> <DIV dir=3Dltr>Pontus</DIV> <DIV=20 style=3D"FONT-STYLE: normal; DISPLAY: inline; FONT-FAMILY: 'Calibri'; = COLOR: #000000; FONT-SIZE: small; FONT-WEIGHT: normal; TEXT-DECORATION: = none"> <DIV style=3D"FONT: 10pt tahoma"> </DIV> <DIV style=3D"FONT: 10pt tahoma; BACKGROUND: #f5f5f5"> <DIV style=3D"font-color: black"><B>From:</B> <A = [email protected]=20 href=3D"mailto:[email protected]">Jon Watte</A> </DIV> <DIV><B>Sent:</B> Monday, June 11, 2012 8:12 PM</DIV> <DIV><B>To:</B> <A [email protected]=20 href=3D"mailto:[email protected]">sweng-gamedev@midnightryd= er.com</A>=20 </DIV> <DIV><B>Subject:</B> Re: [Sweng-Gamedev] Physics, world=20 representation</DIV></DIV> <DIV> </DIV></DIV> <DIV=20 style=3D"FONT-STYLE: normal; DISPLAY: inline; FONT-FAMILY: 'Calibri'; = COLOR: #000000; FONT-SIZE: small; FONT-WEIGHT: normal; TEXT-DECORATION: = none">I've=20 been wanting to learn Bullet, but time is scarce... My physics = experience comes=20 from a few other libraries, both Open Source and commercial. The main = ones are=20 ODE, JigLib, PhysX, and some home-grown systems. Here's my = generalization of how=20 they all work, more or less (with slight variations in naming and API):=20 <DIV> </DIV> <DIV>First, collision detection, done between shapes/hulls/boxes, is = separate=20 from physical movement/rotation, done by bodies. You can have one = without the=20 other.</DIV> <DIV> </DIV> <DIV>In general, the "world" built from "static" geometries is fixed. It = won't=20 move, take damage, or do anything other than provide impenetrable = barriers.=20 Important to note is that the collision shapes in this world have no = rigid=20 bodies at all in the simulation/solver. Resolving a collision between a = static=20 geometry and a geometry tied to a dynamic body means moving only the = dynamic=20 body. Another use for no-rigid-body colliders is volumes used for=20 triggers/detectors -- in that case, the "static" geometries don't even = provide=20 any collision response forces.</DIV> <DIV>Because static geometry doesn't move, static geometry won't = typically be=20 tested against other static geometry, so most libraries actually work = just fine=20 with intersecting static geometry. However, static geometry which has = surfaces=20 that alias (coplanar, or close to it,) may generate bad contact = information for=20 dynamic objects that contact.</DIV> <DIV> </DIV> <DIV>"Dynamic" is used for anything that moves. "Dynamic" means that you = can=20 receive forces, as well as apply them to others. "Dynamic" also means = that the=20 solver will resolve geometry intersections by pushing both objects in = inverse=20 proportion to their mass. (CCD such as used in Bullet may "resolve" by = simply=20 moving the object a shorter amount of time through the time step -- = that's one=20 of the things I've been wanting to learn about Bullet)</DIV> <DIV> </DIV> <DIV>"Kinematic" is somewhat of a mix between the two. It's a body that = can be=20 moved, but the body doesn't participate in incoming force resolution, = only in=20 outgoing force generation. There is some variability here -- some = kinematic=20 bodies tied to collision geometries will "stop" when running into static = geometries. Thus, a dynamic body that hits a kinematic body will be = resolved=20 entirely by moving the dynamic body, not affecting the kinematic=20 body.<BR><BR>"Static" geometry, which really means geometry without a = dynamic=20 rigid body, can generally be whatever you want -- trimeshes, convex = hulls,=20 half-open planes, boxes, cylinders, spheres, ... Whatever fits your = "game level"=20 and won't move around in the game design. Building a trimesh out of a = BSP tree=20 and using that as static geometry for a level is a fine way to go about = things.=20 Regarding your understanding of BSP geometry:</DIV> <DIV>- BSP can describe convex geometry, because each plane only splits = the=20 current half-space sub-cell, not the entire world.</DIV> <DIV>- Worlds don't typically use bodies at all, especially in BSP based = games=20 like Quake or whatnot. Some physics APIs may still want you to talk = about=20 "static bodies," but these don't partake in the linear constraint solver = used=20 for force/body/collision interaction.</DIV> <DIV> </DIV> <DIV>"Dynamic" geometry, which really means geometry with a dynamic = rigid body,=20 generally has some constraints, especially with respect to concave bits. = Typically, it's very hard to generate a sane representation of how = you're=20 supposed to "resolve" contact, or penetration, between two concave = geometries.=20 Thus, trimeshes used for dynamic movement are often not as robust or=20 well-performing as convex geometries of various sorts. For a CCD system, = you may=20 be able to calculate time-of-first-contact between two moving convex = geometries,=20 but that's likely to use a lot of CPU. Might still be worth it for cases = where=20 there's really only a few things moving -- like a space ship docking = with a=20 space station.</DIV> <DIV> </DIV> <DIV>Finally, I've found that, for me, it works better to avoid = kinematic=20 bodies, and simply drive user agents (avatars, cars, tanks, whatever) = using=20 somewhat large forces and a PID controller. I know where I want the = avatar to be=20 next frame; I know where it is and what its current velocity and spin = is; I can=20 apply appropriate forces/torques (controlled by a PID controller) to = "trend=20 towards" that goal. This ends up having pretty good interaction with = various=20 obstacles, piles of rigid body debris, stacks of crates, etc. For=20 higher-fidelity simulations, you can do the same thing for an animated = avatar;=20 play back the animation as a force generator (based on a PID controller = per=20 joint, with the animation as target.)</DIV> <DIV> </DIV> <DIV> </DIV> <DIV>Sincerely,<BR><BR>Jon Watte<BR><BR><BR>--<BR>"I pledge allegiance = to the=20 flag of the United States of America, and to the republic for which it = stands,=20 one nation indivisible, with liberty and justice for all."<BR>~ Adopted = by U.S.=20 Congress, June 22, 1942<BR><BR><BR><BR> <DIV class=3Dgmail_quote>On Mon, Jun 11, 2012 at 12:54 AM, Massimo Del = Zotto <SPAN=20 dir=3Dltr><<A href=3D"mailto:[email protected]"=20 target=3D_blank>[email protected]</A>></SPAN> wrote:<BR> <BLOCKQUOTE=20 style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; = PADDING-LEFT: 1ex"=20 class=3Dgmail_quote>Hello to all contributors.=20 <DIV>I need some help in understanding how physics libraries are = supposed to=20 be used. I am referring to Bullet in particular as it appears to have=20 everything I need with a liberal, cross-platform licensing.</DIV> <DIV>So far I have been experimenting with physics for a few months = with mixed=20 results at best. As I write this, I have just resolved an issue with=20 player-controlled objects which has been keeping me awake at night for = quite a=20 while so I'm thinking at the next problem I see on the horizon.</DIV> <DIV> </DIV> <DIV>Now, in Bullet there are three kinds of objects:</DIV> <DIV> <OL> <LI>STAtic=20 <LI>DYNamic=20 <LI>KINematic</LI></OL></DIV> <DIV>I think I have finally got a kinematic behaviour that works right = for my=20 game.</DIV> <DIV>The point of this email is the interaction of dynamic objects and = a world=20 built from static objects.</DIV> <DIV>I started modelling my world by procedurally generating a set of = hulls,=20 in most cases, those were boxes. I don't remember the exact numbers = but I'd=20 say my current data set for the world is about 96% boxes (mostly = axis-aligned)=20 and 4% hulls.</DIV> <DIV>The <B>main problem</B> I've observed is that <B>DYN objects = won't=20 interact properly with static collision geometry at bounduaries</B>. I = am not=20 well aware if this happens as I allow the static geometry to overlap = or not.=20 That is, I don't know if adjusting the collision geometry by a margin = would=20 fix that.</DIV> <DIV> </DIV> <DIV>The current line of thinking in Bullet forums appears to be using = generic=20 trimeshes and GIMPACT collision. Trimeshes allow to mark internal = edges and=20 thus provide proper information to dynamic bodies to interact = properly.</DIV> <DIV> </DIV> <DIV>Now, let's leave out the fact that Bullet's demo about internal = edges=20 does not seem to work as intended on my system.</DIV> <DIV>Let's leave out the problem that I would need to write some code = in the=20 filter to brute-force internal edge detection.</DIV> <DIV>Let's start by considering that in general, I don't really feel = ok with=20 feeding collision systems with graphics-oriented meshes. It = <B>might</B> work=20 for now, but I'm afraid someone should be producing a reduced = polycount=20 mesh.</DIV> <DIV> </DIV> <DIV>But my main problem is that I feel like I'm seriously missing = something.=20 For example, Bullet has a BSP demo from which they build collision = geometry.=20 Now, BSPs are strictly related to convex hulls so it appears to me = that worlds=20 are meant to be built as an assembly of multiple rigid bodies rather = than a=20 single big trimesh. BSP demo <B>appears </B>to work ok with dynamic = rigid=20 bodies to me.</DIV> <DIV> </DIV> <DIV>So in short, <B>I am asking for a direction is choosing a world=20 representation for my collisions</B>. <B>Maybe collision shapes are = only meant=20 to be used for dynamics, with trimeshes being the only way to = represent a=20 world?</B></DIV> <DIV> </DIV> <DIV>I cannot quite see a big picture with those things, so I start = thinking=20 perhaps I've misunderstood everything since day 0.</DIV> <DIV> </DIV> <DIV>Elaborations are welcome.</DIV><SPAN class=3DHOEnZb><FONT = color=3D#888888> <DIV> </DIV> = <DIV>Massimo</DIV></FONT></SPAN><BR>_____________________________________= __________<BR>Sweng-Gamedev=20 mailing list<BR><A=20 = href=3D"mailto:[email protected]">Sweng-Gamedev@lists= .midnightryder.com</A><BR><A=20 = href=3D"http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnigh= tryder.com"=20 = target=3D_blank>http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev= -midnightryder.com</A><BR><BR></BLOCKQUOTE></DIV> <DIV> </DIV></DIV> <P> <HR> _______________________________________________<BR>Sweng-Gamedev mailing = list<BR>[email protected]<BR>http://lists.midnightryd= er.com/listinfo.cgi/sweng-gamedev-midnightryder.com<BR></DIV></DIV></DIV>= </BODY></HTML> ------=_NextPart_000_0027_01CD481D.B9C7E870-- --===============2102372742== 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 --===============2102372742==--