Re: Physics, world representation
Jon Watte <[email protected]> Mon, 11 Jun 2012 11:12:48 -0700
| Newsgroups | gmane.games.devel.sweng |
|---|---|
| Message-ID | <CAJgyHGPQZd2jzU8JXpPKxHXKNa_P_70R==M-=sYQtKXqU6xTAg@mail.gmail.com> |
--===============1414161083== Content-Type: multipart/alternative; boundary=e89a8ff1c32624994704c2364c27 --e89a8ff1c32624994704c2364c27 Content-Type: text/plain; charset=UTF-8 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): 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. > 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 > 2. DYNamic > 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.com > > --e89a8ff1c32624994704c2364c27 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I've been wanting to learn Bullet, but time is scarce... My physics exp= erience 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 variat= ions in naming and API):<div> <br></div><div>First, collision detection, done between shapes/hulls/boxes,= is separate from physical movement/rotation, done by bodies. You can have = one without the other.</div><div><br></div><div>In general, the "world= " built from "static" geometries is fixed. It won't move= , take damage, or do anything other than provide impenetrable barriers. Imp= ortant to note is that the collision shapes in this world have no rigid bod= ies 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 dynam= ic body. Another use for no-rigid-body colliders is volumes used for trigge= rs/detectors -- in that case, the "static" geometries don't e= ven provide any collision response forces.</div> <div>Because static geometry doesn't move, static geometry won't ty= pically 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.</div> <div><br></div><div>"Dynamic" is used for anything that moves. &q= uot;Dynamic" means that you can receive forces, as well as apply them = to others. "Dynamic" also means that the solver will resolve geom= etry intersections by pushing both objects in inverse proportion to their m= ass. (CCD such as used in Bullet may "resolve" by simply moving t= he object a shorter amount of time through the time step -- that's one = of the things I've been wanting to learn about Bullet)</div> <div><br></div><div>"Kinematic" is somewhat of a mix between the = two. It's a body that can be moved, but the body doesn't participat= e in incoming force resolution, only in outgoing force generation. There is= some variability here -- some kinematic bodies tied to collision geometrie= s will "stop" when running into static geometries. Thus, a dynami= c body that hits a kinematic body will be resolved entirely by moving the d= ynamic body, not affecting the kinematic body.<br> <br>"Static" geometry, which really means geometry without a dyna= mic rigid body, can generally be whatever you want -- trimeshes, convex hul= ls, half-open planes, boxes, cylinders, spheres, ... Whatever fits your &qu= ot;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 i= s a fine way to go about things. Regarding your understanding of BSP geomet= ry:</div> <div>- BSP can describe convex geometry, because each plane only splits the= current half-space sub-cell, not the entire world.</div><div>- Worlds don&= #39;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 "stati= c bodies," but these don't partake in the linear constraint solver= used for force/body/collision interaction.</div> <div><br></div><div>"Dynamic" geometry, which really means geomet= ry with a dynamic rigid body, generally has some constraints, especially wi= th respect to concave bits. Typically, it's very hard to generate a san= e representation of how you're supposed to "resolve" contact,= or penetration, between two concave geometries. Thus, trimeshes used for d= ynamic movement are often not as robust or well-performing as convex geomet= ries 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 likel= y 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 s= tation.</div> <div><br></div><div>Finally, I've found that, for me, it works better t= o avoid kinematic bodies, and simply drive user agents (avatars, cars, tank= s, 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 curren= t velocity and spin is; I can apply appropriate forces/torques (controlled = by a PID controller) to "trend towards" that goal. This ends up h= aving pretty good interaction with various obstacles, piles of rigid body d= ebris, stacks of crates, etc. For higher-fidelity simulations, you can do t= he same thing for an animated avatar; play back the animation as a force ge= nerator (based on a PID controller per joint, with the animation as target.= )</div> <div><br></div><div><br></div><div>Sincerely,<br><br>Jon Watte<br><br><br>-= -<br>"I pledge allegiance to the flag of the United States of America,= and to the republic for which it stands, one nation indivisible, with libe= rty and justice for all."<br> ~ Adopted by U.S. Congress, June 22, 1942<br><br> <br><br><div class=3D"gmail_quote">On Mon, Jun 11, 2012 at 12:54 AM, Massim= o Del Zotto <span dir=3D"ltr"><<a href=3D"mailto:[email protected]" t= arget=3D"_blank">[email protected]</a>></span> wrote:<br><blockquote = class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid= ;padding-left:1ex"> Hello to all contributors.<div>I need some help in understanding how physic= s 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 lic= ensing.</div> <div>So far I have been experimenting with physics for a few months with mi= xed results at best. As I write this, I have just resolved an issue with pl= ayer-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.</div> <div><br></div><div>Now, in Bullet there are three kinds of objects:</div><= div><ol><li>STAtic</li><li>DYNamic</li><li>KINematic</li></ol></div><div>I = think I have finally got a kinematic behaviour that works right for my game= .</div> <div>The point of this email is the interaction of dynamic objects and a wo= rld built from static objects.</div><div>I started modelling my world by pr= ocedurally generating a set of hulls, in most cases, those were boxes. I do= n'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.</div> <div>The <b>main problem</b> I've observed is that <b>DYN objects won&#= 39;t interact properly with static collision geometry at bounduaries</b>. I= am not well aware if this happens as I allow the static geometry to overla= p or not. That is, I don't know if adjusting the collision geometry by = a margin would fix that.</div> <div><br></div><div>The current line of thinking in Bullet forums appears t= o be using generic trimeshes and GIMPACT collision. Trimeshes allow to mark= internal edges and thus provide proper information to dynamic bodies to in= teract properly.</div> <div><br></div><div>Now, let's leave out the fact that Bullet's dem= o about internal edges 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 filter to brute-force internal edge detection.</div> <div>Let's start by considering that in general, I don't really fee= l ok with feeding collision systems with graphics-oriented meshes. It <b>mi= ght</b>=C2=A0work for now, but I'm afraid someone should be producing a= reduced polycount mesh.</div> <div><br></div><div>But my main problem is that I feel like I'm serious= ly missing something.=C2=A0For example, Bullet has a BSP demo from which th= ey 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 mu= ltiple rigid bodies rather than a single big trimesh. BSP demo <b>appears <= /b>to work ok with dynamic rigid bodies to me.</div> <div><br></div><div>So in short, <b>I am asking for a direction is choosing= a world representation for my collisions</b>. <b>Maybe collision shapes ar= e only meant to be used for dynamics, with trimeshes being the only way to = represent a world?</b></div> <div><br></div><div>I cannot quite see a big picture with those things, so = I start thinking perhaps I've misunderstood everything since day 0.</di= v><div><br></div><div>Elaborations are welcome.</div><span class=3D"HOEnZb"= ><font color=3D"#888888"><div> <br></div><div> Massimo</div> </font></span><br>_______________________________________________<br> Sweng-Gamedev mailing list<br> <a href=3D"mailto:[email protected]">Sweng-Gamedev@list= s.midnightryder.com</a><br> <a href=3D"http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnig= htryder.com" target=3D"_blank">http://lists.midnightryder.com/listinfo.cgi/= sweng-gamedev-midnightryder.com</a><br> <br></blockquote></div><br></div> --e89a8ff1c32624994704c2364c27-- --===============1414161083== 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 --===============1414161083==--