Physics in 3D software

Physics, sometimes "dynamics", is the process by which the computer figures out the movement of objects based on real world properties such as mass and force.

A Rigid body is a mesh which acts as a singular, unchanging, solid body within a physics system.

Physics objects can, for the most part, be divided into two different types. "Rigid" bodies where the sub-objects such as vertices, edges, and polygons won't be take into account individually and "Soft" bodies where they will. When we say taken into account we mean they will move on their own, giving the impression of a non-solid state like cloth or jelly, they are soft.

A Soft body physics object can have its sub-objects (points & polys) changed by the physics solver.

Keep in mind that these types only describe the *object* and not the environment they exist in. Most 3D packages will make use of a "solver" of some kind where the actual calculations are done and also environment forces where you change settings for things like gravity or wind which can affect multiple objects at once.

Collision meshes

A collision mesh is an invisible mesh that is quicker to calculate physics for than the visible mesh.

The general idea will be thus...

  1. Make a model as normal to be the visible model.
  2. Make a your collision mesh based on the final model.
  3. Use either a parent/child relationship or a constraint to ensure the visible model always takes transform and rotational information from collision mesh.

Consider the model shown here.

We want the collision mesh to conform to the lower post so we can't go with the typical "convex" option. But it's a waste to create physics geometry within the inset area so we don't really need the "concave" option.

It may also be a waste to define openings or holes in a model. The coffee cup shown here. If we drop the cup on the floor we expect it to roll until the handle stops it so we need geometry around the handle. But do we need the model the opening on the handle itself? Unless there is something in the scene that might possibly or intentionally go *through* the handle loop, then there's no point in such geometry.

Cloth

Cloth simulation in *any* program will be a somewhat taxing calculation. So be advised before attempting any of the walkthroughs in the program-specific pages that you shouldn't start by trying to make too complex of an object. Make a simple plane of 20x20 segments and drop it onto a primitive to test the process first.

With that said, cloth simulation typically works very similar to rigid and soft body setups in any given program, but will almost always be considered a different type of object. In will not be uncommon for you to have to apply two different types of collider modifiers to a rigid body if it is supposed to reflect both other rigid bodies and cloth bodies as well.

Common guidelines between programs will apply typically when trying to create more complex cloth shapes such as clothing. In any program you'll want to consider how to minimize the complexity of cloth calculations and what a cloth does and does not need to actually interact with.

Collision meshes, again

The phrase "collision mesh" should bring about the same mental images of simplified shapes and cages that it did when applied to rigid and soft body objects. The difference now is that some of those simplified meshes will be beneath the cloth instead of above it.

The goal is the same. Create a surface that minimizes the number of calculations needed for a collision while maintaining an acurate appearance. It's a balancing act that can take some trial and error. Let's look at an example.

There are two images below. Each has the same three spheres in it but the second image has had a cloth object (a simple 40x40 segment plane) draped over two of the spheres.

Try to imagine that the sphere in the center is our visual model and that the two spheres on the sides are our attempts at making a collision mesh.


In this example the sphere on the left has 512 polygons, the middle sphere (meant to be our visible model) has 2048, and the sphere on the right only has 32 polygons.

You should be able to see a correlation in quality between the collision mesh sphere and the appearance of the cloth over that collision mesh. The angles of the low-poly sphere are showing through the draped cloth and doesn't represent what we want to be our visible model very well. At he same time it would be wasteful to use the visible model in the center as our visible model as it has so many polygons.

The first model on the left has the appropriate amount of polygons. It will take fewer calculations than the visible model but represent it more accurately than the low-poly model.

Caching

As with other dynamic systems most cloth solvers will allow you to "cache" the results of a simulation. The idea will always be that you can calculate the results of a simulation once and run it again quicker each concurent time (unless the scene changes). This process is specific to each program and is better detailed within the program specific pages however.

Liquid

TBD Oh this will totally get done, sure.