Download
1 / 61
610 likes | 748 Views
Automatic Generation of Dynamics Models. John W. Ratcliff Most Worshipful Senior Programmer Simutronics Corporation. Introduction. Work for this presentation was supported by Ageia Technologies.
E N D
Automatic Generation of Dynamics Models John W. Ratcliff Most Worshipful Senior Programmer Simutronics Corporation
Introduction • Work for this presentation was supported by Ageia Technologies. • This is an open source project to facilitate the rapid production of physics content from raw source graphics data • Much assistance provided by Matthias Mueller, Pierre Terdiman, Adam Moravansky, Billy Zelsnack and Dilip Sequeira
The Code Suppositorywww.codesuppository.blogspot.com “A Place Where I Insert My Code into the Anus of the Internet” John W. Ratcliff, Flipcode, January 12, 2000 “Yes, I know what that word means” John W. Ratcliff in response to an email received on January 13, 2000.
The Problem • The rapid acceptance of pervasive physics in games has created new authoring and asset requirements. • There is a general lack of tools to facilitate the rapid creation of dynamics assets. • Many games send their raw graphics assets to the physics engine which is highly inefficient and often causes significant problems.
Where should Physics Content be Authored? • Physics models are usually derived from a final production art asset. • Iteration on physics assets is primarily a ‘design’ problem rather than an art issue. • Ideally editing of dynamics data assets should occur directly in the game engine/editor for rapid iteration cycles to test the behavior and interaction of the models in real-time.
Existing Tools to Author Physics Content • Feeling Software : www.feelingsoftware.com • PhysX Plugin for 3D Studio Max (free open source) • Nima for Maya : (Unsupported version Free) • Lead developer Christian Laforte • Blender 3D : www.blender.org (Free open source) • Lead developer Ton Roosendaal • Bullet Physics Library : www.continuousphysics.com (Free open source) • Developed by Erwin Coumans • CreateDynamics : www.codesuppository.blogspot.com (Free open source) • Developed by John W. Ratcliff • Unreal Editor : www.epicgames.com • Proprietary tools. • Physics authoring happens in the game editor • Uses some of the CreateDynamics toolkit for generating compound objects. • Lead developer on the physics tools James Golding • Scythe Physics Editor : www.physicseditor.com • Supports ODE, Newton, PhysX • Free and Commercial vesions available • Lead developer Chris Hunt
Existing Standardized File Formats for Physics Content • COLLADA 1.4.1 : www.collada.org • Supports basic rigid body physics markup in an XML format. • NxuStream : www.ageia.com • Provided as part of the free PhysX SDK. • Source library. • Exact reflective object model of every component in the SDK, including rigid body, constraints, all shapes, including heightfields, cloth, softbodies, fluids, collision filters, energy fields, and much more. • XML, Binary, and supports COLLADA 1.4.1 physics only specification. • Scythe : www.physicseditor.com
Multiple Collision Models Per Asset • For any given art asset there are usually at least three, if not more, physics representations. • Raycast model: A static triangle mesh that is identical to the original graphics model for precise line of sight evaluation as well as certain graphics support such as decal generation. • Static collision model: An often dramatically simplified version which corresponds to what the player character would collide with (rarely should be the raycast version.) May be a simplified mesh, a convex hull, or a compound shape. • Dynamic collision model(s): One or more versions to be used when the object is dynamic. Should never be a triangle mesh. Typically a single convex hull or compound object.
Components of a Physics Asset • Rigid Body properties • Collision Shapes • Triangle Mesh • Box • Capsule • Convex Hull • Sphere • HeightField • Constraints • Cloth properties and topology • Soft Body properties and topology • Fluid and fluid emitter properties • Energy Fields
Typical Rigid Body Properties • World Transform (global pose) • List of collision shapes • Collision group and/or other flags • Dynamics Properties • Linear Velocity and Angular Velocity • Mass or Density • Mass Local Pose and Mass Space Inertia Tensor • Engine specific components • Solver Iterations • Sleep Threshold • Maximum Angular Velocity • Etc.
Collision Shape Properties • Local Transform (relative to parent rigid body) • Material Index • Collision filtering information • Contact report flags • Shape data: • Box dimensions • Sphere radius • Capsule height and radius • Convex hull faces • Triangle mesh triangles • Heightfield sample data • Plane equation
Programmable ConstraintCustomizable on all 6 degrees of freedom angular and linearPhysX SDK implementation by Matthias Mueller-Fischer • A constraint that can be configured on three angular and three linear degrees of freedom. Each degree of freedom can be fixed, free, or limited and can be configured to support drive, motors, and springs. • Advantages • A single model can be configured to behave in any of the most common custom joint configurations. • Allows for a much simpler and easier to maintain code path. • Provides new types of constraints not typically available with most engines. • Predictable behavior in all configurations. • Orthogonal data definition. • Disadvantages • Initially can be more difficult to configure. This can be improved by providing helper setup routines for common constraint types.
Authoring Collision Shapes • For simple objects, when a single shape is sufficient, collision fitting is not difficult Single Collision Shape with Oriented Bounding Box approximation Single Collision Shape Convex Hull approximation
Compound ShapesApproximate Convex Decomposition • Published work • Approximate Convex Decomposition Texas A&M University Algorithms & Applications Group Jyh-Ming Lien and Nancy M. Amato (parasol.tamu.edu/groups/amatogroup/research/app-cd) • Variational, meaningful shape decomposition University of British Columbia Vladislav Krayevoy and Alla Scheffer (www.cs.ubc.ca/~vlady/Papers/Segmentation.pdf)
Convex DecompositionAlgorithm by John W. Ratcliff • ‘Inspired’ by the work of Jyh-Ming Lien and Nancy M. Amato at Texas A&M. However, this brute force implementation has little in common with their technique. • Accepts open meshes • Not real time • Available as a plug-in or open source library • Simple interface
The Algorithm • A recursive routine is passed, as input, the source triangle mesh • The first step is to compute the ‘volume of concavity’ • Build a convex hull around the mesh. • Project each triangle on the original mesh onto the hull. • Compute the volume of the mesh that results from the projected triangle onto the convex hull skin. • The sum of the volume of all projected triangles to the convex hull surrounding it becomes the ‘volume of concavity’ • Compute the percentage volume of concavity by dividing it by the volume of the hull around the original source mesh. • If the percentage volume of concavity is below a user supplied threshold then accept this mesh as sufficiently convex. • By measuring against the total volume this allows highly concave pieces to be ignored if they are quite small and unimportant relative to the overall size of the object.
The Algorithm cont. • Compute the best fit oriented bounding box • If the mesh is concave then compute the best fit oriented bounding box around the mesh. • Compute a split plane along the long axis of the OBB • Split all of the input triangles against the plane producing two output meshes • Each triangle is tested to see which side of the plane it lies on. • If the triangle straddles the plane it is split and one triangle piece is sent to the ‘top’ mesh and the other sent to the ‘bottom’ mesh. • The ‘edge’ of each split triangle is added to an edge list.
The Algorithm cont. • Using the edges that lie along the split plane compute a delaunay triangulation. • Project the points onto the plane so the operation can be performed in 2d • Must support multiple polygons • Must support ‘holes’ by testing polygons inside other polygons (example splitting a glass in half) • See: “Triangle : A Two-Dimensional Quality Mesh Generator and Delaunay Triangulator “ by Jonathan Richard Shewchukhttp://www.cs.cmu.edu/~quake/triangle.html • Project the polygon points back into 3d and weld them into the mesh producing a whole piece. • Without this operation deep recursion produces hollow objects and does not converge to an optimal solution set.
The Algorithm cont. • Pass the top and bottom split meshes back into the recursive routine. • Wash, rinse, and repeat until there are no concave pieces left or at the maximum recursion depth provided by the user. • This results in an oriented bounding volume tree based on the original source mesh. • The output hulls are over described since an optimal split was not performed. • To correct for this a cleanup phase is run where hulls are merged back together again if they are largely convex afterwards. • In short, what the process has done is created too many hulls but a straightforward cleanup pass can easily stitch them back together again. Simply compute the volume of two hulls separate then compute the volume of the two hulls combined. If the volume is within a percentage threshold provided by the user (called the merge threshold) then these two hulls are combined back into one.
The Algorithm cont. • Attempt to merge hulls by largest volume first. • At each phase of the merge process select the largest hull first and then attempt to merge it in order of the largest volume to the smallest. • The end result is that even though the mesh was chopped up more than was necessary, the post-process cleanup phase ends up producing results as if the most optimal split had been performed in the first place. Behold the power of brute force, sometimes a blunt instrument beats out the most advanced mathematics.
Approximate Convex DecompositionExamples using various fitting rules
VideoA high poly count helix mesh simulated as a rigid body composed of only 15 convex hull shapes
Automatic Rag Doll GenerationDirectly from Skeletal Deformed Mesh • Creating Ragdoll models can be very time consuming. Artists spend a great deal of time rigging up a skeletal system for an art asset to begin with. There should not be a need to spend an equal amount of time producing a physics representation of the same. • Embedded within a standard skeletal deformed mesh is sufficient information to auto-generate a reasonable approximate ragdoll model.
Automatic Rag Doll GenerationStep 1 : Skeleton Pruning • The skeleton used for a ragdoll physics simulation is typically far simpler than what is used for graphics. • The graphics version may include many details such as fingers, toes, facial bones and marker bones for game play elements. None of these bones are desirable in the physics representation • Before attempting to generate constraints for all of the bones in the skeleton the skeleton needs to be pruned and a new skeleton created which is usable for a real-time physics simulation.
Automatic Rag Doll GenerationStep 1 : Skeleton Pruning • Traverse the skeleton and examine the triangles which have significant weightings to each bone. • Bones which are not influenced by any geometry are marked for deletion. • For the rest of the bones compute the volume of the convex hull around the triangles weighted to it. • Compare the volume of the geometry associated with the volume of the whole. If the volume is below a user supplied percentage threshold this bone should be marked for removal. This will leave only bones associated with larger components of the source mesh; in a humanoid character this would correspond to head, arms, legs, and torso, but not eyes, fingers, or toes.
Automatic Rag Doll GenerationStep 1 : Skeleton Pruning • Now a new skeleton must be produced that leaves only the bones which were marked for removal. • Leaf node bones marked for deletion may simply be removed. • Bones marked for removal that are not leaf nodes must have their child/parent relationship patched up so the skeleton will still be intact. The parent should keep track of the now dead child bones it has inherited. • Now that a reduced skeleton has been created the deformed mesh geometry has to be revised so the bone indices point to the correct locations in the new skeleton. • For each bone referenced in the source mesh re-assign it to the corresponding bone in the new skeleton for the output mesh. • If a vertex refers to a bone that has been deleted then attach it to the parent bone that the original bone was collapsed into.
Automatic Rag Doll GenerationStep 2 : Generating Collision Shapes • Walk the reduced skeleton and collect the triangles associated with each bone. • On a per-bone basis run the CreateDynamics shape fitting tool and approximate the shape as a box, sphere, capsule, or convex hull based on user input selection. • Using a rules based system, different shape fitting techniques can be applied to the skeleton using wildcards and inheritance.
Automatic Rag Doll GenerationStep 3 : Generating Constraints • Constraints are created based on the transforms of the reduced skeleton. • Joint types and limits are selected from user input using the same rules system for deciding shape fitting. • Though not currently implemented it would be feasible to infer joint types and limits by interpreting a reference animation. • Joint limits and types are supported by Maya and might be able to be passed as part of the export process.
Automatic Rag Doll GenerationStep 4 : Generating Collision Filters • To prevent the ragdoll model from constantly colliding with itself collision filters are needed to prevent this artifact. • Walk the skeleton and compute the skeletal distance between bones. Bones which are near each other along the skeleton should have collisions disabled between their bodies. • For more accurate collision modeling (such as convex hulls) the filtering need not be too deep. For cruder collision models such as capsules or boxes, filtering to avoid the model colliding with itself will need to be more aggressive. • Though not currently implemented, it might be best to decide where collision filters are needed by detecting contacts while the skeletal model is in its rest pose.
Video : Auto Generated RagDoll Models Simulated with the PhysX SDK
Auto Generated Constraints • The previous example showed how to create a ragdoll from a skeletal deformed mesh rigged up by an artist. • If you don’t have an already rigged up skeletal deformed mesh but still want to get a fast ragdoll or cheap illusion of soft body then a skeletal deformed mesh can be automatically generated.
Auto Generated Constraints • First generate an oriented bounding volume system for the raw source mesh. • This is easy to implement because all we have to do is disable the merge portion of the convex decomposition algorithm. • By removing the merge option the system is much more balanced and will simulate more realistically.
Auto Generated Constraints Auto-Generated Oriented Bounding Volume System using Approximate Convex Decomposition without Merge Original Raw Source Mesh : No Skeleton No Bone Weightings
Auto Generated Constraints • Auto-generating the constraints uses a recursive algorithm that begins with finding the largest volume hull in the decomposed object. The largest hull is used as the root node for the skeleton. • From this hull locate all hulls which ‘touch it’. • Touching is determined by finding two triangles which have roughly the same vector normal pointing in opposite directions. • If the two triangles lie along the same plane, then they are projected into 2d along that plane and a 2d triangle-triangle intersection test is performed. • If these two triangles intersect then they are considered ‘touching’ and are added to an intersection bounding volume. • If the two hulls were found to be touching then the median intersection point of those touching surfaces becomes the anchor point for the constraint. • This same process is repeated for every hull in the object, each time starting with the last hulls that were connected. • In the end each hull will have a single constraint at the location where it touches a neighbor hull.
Auto Generated Skinned Meshes • Once the auto-generated constrained rigid body system has been saved there are now run-time considerations. • A skeletal deformed mesh has to be created from the original raw source mesh. This could be done as a pre-process step but is more powerful to do on the fly at run time. • Converting the raw mesh to a skeletal deformed mesh requires that each vertex be assigned bone indices and bone weightings. • For each vertex in the source mesh, compute the four nearest bones (rigid bodies) and the distance of those bones from the vertex. • Compute the weighting of each bone based on the ratio of the distance of that bone relative to the sum total of the distances of all four. An additional weighting bias can be applied if desired (Example: 4x bone1, 2x bone2, 1x, bone 3 and 4.)
Video : Auto-Generated constrained system mapped to an auto-generated skinned mesh
Auto-Generated Pre-Fractured Objects • The same technique used to produce skeletal meshes from raw mesh data can be applied for pre-fractured objects • Do not disable the merge in this case. • Constraints are generated against fewer shapes at more natural break boundaries. • The constraints are rigged up to be fixed joints with a particular breaking force based on game design. • The difficult part is producing fracture artwork. This is a ‘hard’ problem, but not unsolvable. Currently the CreateDynamics toolkit cannot produce pre-fracture graphics, only pre-fracture physics.
Cloth Authoring • Cloth is simulated based on a source triangle mesh. • Authoring is straightforward as the physics representation is simply the source triangle mesh with duplicate vertex positions removed. • Additional data associated with cloth are numerous physics properties describing how the simulation should behave. • Attachment points must be captured where needed.
Cloth at Run-Time • The graphics representation of the cloth usually does not exactly match up to the physics representation due to material assignments. • A mapping table must exist between the indices in the physics mesh to the indices in the graphics mesh. • Additional challenges arise from dealing with torn cloth which creates new triangle indices, and those indices must be remapped to the graphics representation on the fly. • Double sided cloth can be visualized using a shader that renders the cloth twice; flipping the normals and culling direction on the back side. • Cloth is typically authored in a ‘rest pose’ so a simulation may need to be run a number of frames before rendering it initially to avoid watching the cloth ‘fall into place’.
Authoring Fluids • Fluids are represented as a set of simulation properties and emitters. • 3D fluids have numerous and often complex physical properties that influence the behavior of the simulation. • Emitters can be attached to rigid body actors. • Numerous emitter properties can be edited as well. • A real-time preview tool to rapidly iterate on fluid properties is essential to achieve good results.
Rendering Fluids • The challenges in turning a set of 3d points into a compelling visual illusion of fluid surfaces would take a whole talk by itself. • Think outside the box. Just because you are using a physics simulation called ‘fluids’ doesn’t mean you have to visualize it as a fluid surface. • Smoke • Sparks • Micro-Debris • Fog • Energy fields • And whatever your artists imagination can come up with.
Common Fluid Visualization Methods • Sprites • Each fluid particle is rendered using a camera facing billboard sprite. • Excellent opportunity to use hardware point sprites. • Multi-Pass techniques on each sprite can produce interesting layered effects. • Full Screen multipass effects can produce the illusion of refraction and reflection by rendering sprites as normals which are then Gaussian blurred in an off-screen buffer. • Surface Mesh • Algorithm by Matthias Mueller • Performs mesh operations in 2d and then back-projects the results producing a highly efficient 3d mesh.
