Particles¶

Particle Data and State¶

Particles are discrete points in space with a number of associated attributes (data layers). A few attributes are found in all particle systems, like:

• Position
• Index (a uniquely identifying number for each particle)

Other attributes may or may not exist for a given particle set, depending on its uses and requirements, such as:

• Orientation and Scale, e.g. for instancing
• Velocity and Angular Velocity for physical particle simulation
• Object Reference: an identifier for instancing or rigid body shapes (actual pointers are stored separately in a lookup table)
• Color can be ascribed to each particle for the rendering purposes (Cosmos Laundromat tornado uses colored particles)
• Other physical properties may be used by specialized simulations: Size, Heat, Charge, ...

Most particle attributes can change over time. Any concrete set of particles can therefore only be a snapshot for a particular frame. This is called a particle “state”.

The scene in Blender stores a “current state” of particles, which relates to the “current frame” of that scene in the viewport. But other states may be stored or used temporarily:

• Renderers can request a scene state for any arbitrary frame. For motion blur this also includes subframes.
• Simulating over a frame range generates a sequence of states. In current Blender sims the scene frame is actively changed with each iteration, but particles could be calculated on their own with a local state without touching the scene state.

Caches are commonly used to store each frame’s state during simulation. The scene can then use the cache to look up the “current” state efficiently.

Extra Topology Elements¶

Data Context and Node Levels¶

The node workflows in this chapter will be dealing with a single particle component only. The output node’s meaning is umambiguous then, because the particle component forms the context for all data access.

The workflow on the object level must somehow be separated from the particle level, lest it becomes too complicated to assign data flow to a specific component. This could be achieved by treating particle operations in a sub-tree of the nodes, like a node group.

Object level nodes assign components to node slots.

Internal node networks work with defined components.

Generate Plain Particles¶

1. Create Particle component.

2. In particle nodes, the output node defines the particle state after an update. If nothing is plugged into the output, the particle state remains unchanged.

3. “Create Particles” node by default creates a number of particles over a frame range.

4. A variable frame rate can be used to further control emission. Note that the total number of particles created is still the same and the actual rate is normalized (integration of the fcurve).

5. Emission rate can also be used directly as particles-per-frame, if the total amount is left unspecified. Note that controlling the total amount of particles is more difficult this way.

Initializing new particles¶

1. Emitter node output contains default particles: all positions are (0, 0, 0).

2. Assign a random position on the unit sphere to each new particle, using the particle index as a seed value.

3. Other particle attributes may be initialized in a similar manner, using the “Set Attribute” node.

Combining and Splitting Particle Sets¶

1. Output of basic emitter nodes contains only particles created in that particular frame

2. Existing particles can be modified by using a “Particles” input node. Note that modifying these particles only has an effect if the result is actually plugged into the output node!

3. Joining old particles with the emitter node output yields the complete set of existing particles, which can then be modified further.

4. Particle sets can also be split into separate sets. Each particle is placed in an output set based on a condition.

Distributing particles on a mesh surface¶

1. Random samples on a mesh surface can be created with a “Sample Mesh Surface” node. Again, the particle index serves as a seed value to create a unique value for each particle.

2 Vertex weights can be stored as a particle attribute.

3. This way particles can “track” a deforming mesh surface. The particle positions can be continually updated by re-evaluating the stored mesh surface samples. Other useful techniques could be texture or normals interpolation.

Distributing particles in a volume¶

1. Similar to mesh surfaces, a volume (like a smoke density grid) can be sampled as well.

Billboards¶

Billboards consist of a simple quad faces generated for each particle. They typically are facing the camera, which provides a cheap way to render uniform “blobs” of matter. The most efficient implementation of billboards is probably through mesh faces.

“Billboards” node takes a particle system and generates a mesh.

Instancing Objects¶

“Make Duplis” node takes a particle system and generates a list of object instances (aka. “Dupli List”).

Fluid Surface Generation¶

A more sophisticated method of creating a mesh out of particle data, especially for simulating liquids. Each particle is surrounded by falloff function, the sum of all particle functions defines an implicit surface. Level Set methods can be used to discretize this surface. Thin sheets of fluid can be handled with methods such as [MUS14].

1. “Particle Surface” takes a particle input and outputs a mesh.

Point Density¶

1. “Point Density” node outputs a special volumetric component, which is renderable.
2. Different point density features such as color and falloff may be defined through inputs.

Deep Compositing¶

Point Masses¶

Simulating particles as point masses is a comparatively cheap way of producing physical motion. Collision with other objects is limited to the particle center, and self-collision is not possible efficiently. This limits the usefulness of point mass simulation, but it can still serve a purpose in motion graphics, and is included here for its very simplicity.

1. “Simulate Points” node changes only the particle position (no rotational dynamics).
2. Collision in this case is one-way only: Particles can collide with meshes in the scene, but will not have any effect in turn on other objects. For two-way interaction between objects a fully fledged rigid body simulation must be used.

Rigid Bodies¶

1. “Define Rigid Body” registers a rigid body object with the Bullet physics engine. After the physics step the rigid body’s location and rotation are then copied back to the particle.
2. The collision shape for rigid bodies can be either a mesh or an implicit primitive shape. Primitive shapes are useful for massive simulations with thousands of colliding objects where full mesh collision would be too costly. Here we use an external object reference to define the shape.
3. For rendering an instancing node is very suitable in this case. It can use the same object as the collision shape (or a more detailed version) to make physics and visuals match.

Fracturing¶

This workflow is defined in more detail in Fracture Simulation Workflow with Nodes.

Fluid Simulation with Particles¶

Modern fluid VFX in movie productions and the like is almost exclusively of a “lagrangian” type, meaning that the rendering is based on particle/mesh data rather than directly using density grids. Particles are used as “markers” which are carried along (advected) with the fluid and thus “track” the fluid surface. This approach has the advantage of being very efficient, as well as allowing much more visual detail than would be possible with grids alone. Grids are still an indispensable part of the simulation, but they are used in conjunction with particles to utilize the best of both worlds.

Limiting Particle Lifetime¶

Deleting Particles on Collision¶