Справка Houdini на русском Nodes Dynamics nodes

Smoke Solver 2.0 dynamics node

Sets and configures a Smoke solver. This is a slightly lower-level solver that is the basis for the Pyro solver.

On this page

See Pyro look development for information on using the parameters to achieve different flame and smoke looks.

The smoke solver provides the basics of smoke simulation, whereas the Pyro Solver adds flame simulation and extra shaping controls. If you just want to generate smoke, the smoke solver is useful since it is simpler and expert users can build their own extensions on it. However, the Pyro Solver is more flexible.

See how to use the Pyro tools for information on creating simulations using the shelf tools.

Setting up

If you use the shelf tools to create Pyro effects, they will set up the sourcing, solver, and output object for you automatically.

If you are setting up a pyro network from scratch, you can use the Smoke Object node to create a DOP object with the data required by the Pyro solver already attached. If you already have a DOP object, you can use the the Smoke Configure Object node to add the necessary data to it.

This solver makes use of various field subdata on the object.

  • The object should have a scalar field density for the density of the smoke.

  • The object should have a vector field vel for the velocity at each voxel.

  • Optionally, the object can have a scalar field temperature for internal buoyancy calculations.

Inputs

Object

A Smoke object to work on. Note that a smoke object can contain multiple containers.

Pre-solve

Run the network branch attached to this input before each solving step. In the standard pyro setup, the attached node (Gas Resize Fluid Dynamic) automatically resizes the fluid containers at each step.

Velocity update

Nodes attached to this input can edit the simulation network’s velocity fields, for example to apply custom forces, before the "project gas non-divergent" step (see also the "Sourcing (post-solve)" input below).

Advection

Connect a Gas Advect node to this input to allow the it to advect the points of geometry data attached to the container based on the fields in this solver.

Sourcing (post-solve)

The main use for this input is to add volumes attached to this input as fuel sources, density sources, sinks, collision fields, pumps, etc. These volumes will usually be created by a Source Volume node that imports volumes from a geometry network. See pyro sourcing for more information.

Nodes attached to this input can also edit the simulation network’s velocity fields, for example to apply custom forces, after the "project gas non-divergent" step.

Parameters

Simulation

These parameters control how the simulation develops over time. See how pyro simulations work for information on how the temperature and velocity fields drive the simulation to a great extent.

Timescale

A scaling factor for time inside this solver. 1 is normal speed, greater than 1 makes the pyro sim appear speeded up, less than 1 makes the pyro sim appear to be in slow motion.

You can use expression functions such as doptime, dopframe,dopsttot, and dopttost to convert between global times and simulation times.

Note

Changing the Timescale only affects the timestep of the simulation. If adding velocities calculated in SOPs to the simulation for collisions or pumps with the Source Volume DOP, scale the incoming velocities by 1 / Timescale to match the timestep of the simulation.

Temperature Diffusion

A Gaussian blur factor on the temperature field. Higher values spread the temperature out more and create a less sharply defined effect and more cooling. For example, a value of 2 will blur the temperature field by a radius of 2 every second.

(The real-world motivation for this parameter is to simulate turbulence at a finer scale than the sim’s resolution, which spreads the field out.)

Cooling Rate

How fast the temperature field cools to zero. A value of 0.9 will decrease the temperature of hot gas by 90% (to 10% of its original value) every second.

Warning

This is the inverse of the Cooling Rate parameter in Houdini 11 and lower versions.

Viscosity

The "fluid-ness" of the velocity field. Higher values make neighboring voxels have the same velocity, creating a more flowing look. A value of 0 allows adjacent voxels to move any direction without resistance, creating a more chaotic, turbulent look.

(Inside the solver, higher viscosity values introduce a penalty when a voxel’s velocity varies from that of its neighbors. This is currently implemented by applying a diffusive term to the velocity field.)

Buoyancy Lift

An upward force at each voxel scaled by the difference between the ambient temperature and voxel’s temperature, so hotter areas will get more lift and cooler areas will sink. Increasing this makes the effect rise faster and go higher.

Buoyancy Dir

The direction in which buoyancy is applied. This is usually the Up direction of your simulation, but often can be altered to quickly tweak the look of a sim.

Relationships

Prior to Houdini 12, the Pyro solver used DOP relationships to associate sources, pumps, sinks, and collision geometry with a fluid container, using the Merge DOP and/or Apply relationship DOP to create the relationship. The preferred method in Houdini 12 and later is to use SOP networks to create sources, pumps, sinks, and collision geometry and import them using the Source volume DOP.

If you want to use the old relationship method to set up sources, sinks, etc., you can enable relationships using the parameters on this tab. By default, relationships are turned off, and the solver ignores relationship data.

You can use both methods (import SOP geometry and attach it to the solver’s "sourcing" input, as well as set up DOP object relationships). When relationships are enabled, the solver will combine the sources, sinks, etc. from both methods.

Enable Relationships

Use object relationship data to add sources, pumps, sinks, and collision geometry to the simulation (in addition to imported data connected to the sourcing input, if any).

Sources

Tip

When using a source relationship, make sure the source object is emitting temperature. You can set this up on the object’s physical properties tab.

Enable Source Relationship

Use DOP objects with a "source" relationship to the solver.

Add Source To

The field to add the source to. The default is density, which will create smoke. To create flame, you could change this to fuel and set the temperature physical property of the source object.

Source Merge

How the source object’s volume will be added to the simulation. Scale controls the addition amount.

Velocity Merge

How the source object’s velocity will affect the container’s velocity field. Scale controls the amount to add.

Temperature Merge

How the source object’s temperature physical parameter will affect the container’s temperature field. Scale controls the amount of temperature to add.

Velocity Type

How to measure velocity on the source object. If the source geometry does not deform (change shape) over time, use "Rigid velocity". If the source deforms but does not change topology over time, use "Point velocity".

Rigid Velocity

Treat the source object as non-deforming.

Point Velocity

Use point history to allow deforming geometry. This only works if the topology of the source geometry doesn’t change.

Volume Velocity

Use the SDF representation of the object. Allows deforming geometry and does not require a fixed topology over time, but cannot detect tangential velocities.

Pumps

Enable Pump Relationship

Use DOP objects with a "pump" relationship to the solver.

Velocity Merge

How the source object’s velocity will affect the container’s velocity field. Scale controls the amount of velocity to add.

Velocity Type

Temperature Merge

Whether the object’s temperature property affects the temperature field of the container. If you choose "Set interior", the part of the temperature field corresponding to the inside the object will be set to the object’s temperature.

Collisions

Enable Collide Relationship

Use DOP objects with a "collision" relationship to the solver.

Temperature Merge

Whether the object’s temperature property affects the temperature field of the container. If you choose "Collision interior", the part of the temperature field corresponding to the inside the object will be set to the object’s temperature.

Restrict Mask to Bandwidth

Normally the collision mask SDF is only calculated up to a certain distance from the original collision geometry. Turn this off to compute the full range of the mask if you need it for some special effect, such as having things react before they reach the object.

Use Point Velocity for Collisions

Turn this on if the collision geometry is deforming (changing shape) over time, but has consistent topology (e.g. number of points). If the topology changes over time, turn on Use volume velocity for collisions.

Use Volume Velocity for Collisions

Turn this on if the collision geometry is deforming (changing shape) and topology (e.g. number of points) over time.

Collide with Non-SDF

Allows the fluid to collide with objects that don’t have Geometry/SDF, such as other fluids.

Extrapolate into Collisions

Copies the density and fuel fields into the collision field. This causes the smoke to become "sticky" to avoid an air gap between the smoke and the collision field. This also prevents smoke from passing through moving collision fields.

Sink

Enable Sink Relationship

Use DOP objects with a "sink" relationship to the solver.

Advanced

You should generally not need to change these parameters.

Use OpenCL

  • Caching is enabled by default in DOPs.

  • Resizing is enabled by default. Resizing has to go through the CPU to manage the field changes. It can also fragment the GPU memory resulting in out-of-memory errors.

Min Substeps

Forces the solver to run a minimum number of substeps. Normally the pyro solver works best with no substeps. If you have smoke and unusual forces you may want to increase this parameter for better stability. Increasing this will usually make the simulation much slower.

Max Substeps

Forces the solver to not run more substeps than this maximum. Normally the pyro solver works best with no substeps. If you have smoke and unusual forces you may want to increase this parameter for better stability. Increasing this will usually make the simulation much slower.

CFL Condition

When Max Substeps is greater than 1, the solver uses this parameter to decide the number of substeps. The "condition" is that no substep can allow objects to interpenetrate by more than this many voxels. Higher values allow a substep to move smoke by more voxels, possibly letting it pass through collision objects.

Quantize to Max Substeps

Alway use substeps that divide up the frame by Max Substeps. For example, if Max Substeps is set to 4, but the CFL Condition only requires 3 substeps, the solver will take frame steps of 0.25, 0.5, and 0.25. This option can be useful for re-using input geometry that has been cached to file at increments of 1/Max Substeps.

Frames Before Solve

Delays the actual simulation this many frames after the object creation. Sourcing will still occur in these frames. This may be needed if some solve nodes can’t be processed before certain initial conditions have been met.

External Forces

Scaled Forces

A list of forces to scale by the value of the forcescale field at each voxel. The default is all forces except gravity.

Absolute Forces

A list of forces to apply uniformly to all voxels, ignoring the forcescale field.

Rest Field

Enable Rest

Creates rest fields, which can be used to track the position of the fluid over time. Turn this on to correctly map noise or textures in the volume shader.

Dual Rest Fields

Creates a rest2 field that is one back from the the main rest field, allowing you to run long simulations without popping.

Frames Between Solve

Number of frames before resetting the rest field.

Frame Offset

Which frame the rest field will be reset on. If you are prerolling the simulation, delaying the rest field initialization until after the preroll will usually give a better result.

Time Scale

How fast the rest field moves in response to the velocity field. A value of 1 would make the rest field match the fluid exactly, however that would quickly smear the rest field out in streaks. Values lower than 1 move the rest field slower than the actual fluid, decreasing streaking.

Projection

The "project non-divergent" step of the simulation removes the divergence components in the velocity field.

Projection Method

The project non-divergence algorithm. "PCG" has more accurate boundary conditions and avoids computation inside collision objects. Multigrid is significantly faster, especially on large or high resolution containers.

Multigrid Iterations

The multigrid project non-divergence method has inaccurate boundary enforcement. You can increase this number to run the enforcement/projection multiple times, making it more accurate. You should not have to set this higher than 5.

Advection

Advection Type

The algorithm to use for advecting the fields.

Single stage

Equivalent to the Gas Advect DOP, where each point is back traced through the velocity field once to find the new voxel value.

BFECC and Modified MacCormack

Run a second basic advection stage, resulting in a sharper fluid that doesn’t disperse as much.

Clamp Values

The error correction of the BFECC and Modified MacCormack advection types can move voxel values outside the container, leading to strange effects such as negative density values. This parameter lets you choose a method to avoid this problem. The default is "Revert".

None

Do not attempt to prevent error correction from moving values outside the container.

Clamp

Restrict each voxel to the range of values possible given its eight original values.

Revert

If the error-corrected voxel is out of range, return it to the single-stage value.

Reverting can avoid checker artifacts where the error correction breaks down.

Blend

Apply a smooth blend between non-clamped and clamped values as the advected field approaches the clamping limit. Particularly with the Revert option, applying a small amount of Blend (e.g. 0.05 - 0.1) can reduce grid artifacts in the advected field at the cost of some additional smoothing of the field.

Vel Advection Type

The algorithm to use for advecting the velocity field. Higher types in the list will reduce the apparent viscosity of the field, but may add energy or cause chatter.

Advection Method

Controls particle tracing.

Single step

Takes the velocity at each voxel and makes a single step in that direction for the time step. This is fastest and is independent of the speed of the velocity field, but will start to break up for large time steps.

Trace

Ensures the backtracking does not move more than a single voxel before its velocity is updated, allowing for larger time steps.

Trace Midpoint

Like Trace but uses second order advection for more accuracy but slower simulation.

HJWENO

A non-lagrangian integrator, this allows for theoretically more accurate advection of divergent fields. Unfortunately, if too large substeps are taken, it will explode.

Upwind

A faster but less accurate non-lagrangian integrator.

Trace RK3

Like Trace but uses third order advection for more accuracy but slower simulation.

Trace RK4

Like Trace but uses fourth order advection for more accuracy but slower simulation.

Advection CFL

When tracing the particles, this controls how many voxels the particles can move in a single iterations. Higher values give faster tracing and faster advection, but more errors.

Collisions

Correct Collisions

Sets density and fuel fields to 0 inside collision objects. This helps prevent fuel and density from leaking through moving objects.

Feedback Scale

A scale factor for applying feedback forces to other objects. Setting this to 0 will prevent any feedback.

Clear

Fields to Clear

Zeros out the specified types of fields after the solve step. This ensures the .sim files, which store the complete state of the simulation, do not have extra information, reducing their size and saving time.

None

Do not clear fields.

Hidden

Clear fields not needed for the next time step that do not have guide parameters.

Static

Clear fields not needed for next time step. Some of these fields will have guides and the guides will start showing zero values since the underlying field was cleared.

Additional

A space separated list of fields to clear after each solve.

Outputs

First Output

The operation of this output depends on what inputs are connected to this node. If an object stream is input to this node, the output is also an object stream containing the same objects as the input (but with the data from this node attached).

If no object stream is connected to this node, the output is a data output. This data output can be connected to an Apply Data DOP, or connected directly to a data input of another data node, to attach the data from this node to an object or another piece of data.

Locals

channelname

This DOP node defines a local variable for each channel and parameter on the Data Options page, with the same name as the channel. So for example, the node may have channels for Position (positionx, positiony, positionz) and a parameter for an object name (objectname).

Then there will also be local variables with the names positionx, positiony, positionz, and objectname. These variables will evaluate to the previous value for that parameter.

This previous value is always stored as part of the data attached to the object being processed. This is essentially a shortcut for a dopfield expression like:

dopfield($DOPNET, $OBJID, dataName, "Options", 0, channelname)

If the data does not already exist, then a value of zero or an empty string will be returned.

DATACT

This value is the simulation time (see variable ST) at which the current data was created. This value may not be the same as the current simulation time if this node is modifying existing data, rather than creating new data.

DATACF

This value is the simulation frame (see variable SF) at which the current data was created. This value may not be the same as the current simulation frame if this node is modifying existing data, rather than creating new data.

RELNAME

This value will be set only when data is being attached to a relationship (such as when Constraint Anchor DOP is connected to the second, third, of fourth inputs of a Constraint DOP).

In this case, this value is set to the name of the relationship the data to which the data is being attached.

RELOBJIDS

This value will be set only when data is being attached to a relationship (such as when Constraint Anchor DOP is connected to the second, third, of fourth inputs of a Constraint DOP).

In this case, this value is set to a string that is a space separated list of the object identifiers for all the Affected Objects of the relationship to which the data is being attached.

RELOBJNAMES

This value will be set only when data is being attached to a relationship (such as when Constraint Anchor DOP is connected to the second, third, of fourth inputs of a Constraint DOP).

In this case, this value is set to a string that is a space separated list of the names of all the Affected Objects of the relationship to which the data is being attached.

RELAFFOBJIDS

This value will be set only when data is being attached to a relationship (such as when Constraint Anchor DOP is connected to the second, third, of fourth inputs of a Constraint DOP).

In this case, this value is set to a string that is a space separated list of the object identifiers for all the Affector Objects of the relationship to which the data is being attached.

RELAFFOBJNAMES

This value will be set only when data is being attached to a relationship (such as when Constraint Anchor DOP is connected to the second, third, of fourth inputs of a Constraint DOP).

In this case, this value is set to a string that is a space separated list of the names of all the Affector Objects of the relationship to which the data is being attached.

ST

This value is the simulation time for which the node is being evaluated.

This value may not be equal to the current Houdini time represented by the variable T, depending on the settings of the DOP Network Offset Time and Time Scale parameters.

This value is guaranteed to have a value of zero at the start of a simulation, so when testing for the first timestep of a simulation, it is best to use a test like $ST == 0 rather than $T == 0 or $FF == 1.

SF

This value is the simulation frame (or more accurately, the simulation time step number) for which the node is being evaluated.

This value may not be equal to the current Houdini frame number represented by the variable F, depending on the settings of the DOP Network parameters. Instead, this value is equal to the simulation time (ST) divided by the simulation timestep size (TIMESTEP).

TIMESTEP

This value is the size of a simulation timestep. This value is useful to scale values that are expressed in units per second, but are applied on each timestep.

SFPS

This value is the inverse of the TIMESTEP value. It is the number of timesteps per second of simulation time.

SNOBJ

This is the number of objects in the simulation. For nodes that create objects such as the Empty Object node, this value will increase for each object that is evaluated.

A good way to guarantee unique object names is to use an expression like object_$SNOBJ.

NOBJ

This value is the number of objects that will be evaluated by the current node during this timestep. This value will often be different from SNOBJ, as many nodes do not process all the objects in a simulation.

This value may return 0 if the node does not process each object sequentially (such as the Group DOP).

OBJ

This value is the index of the specific object being processed by the node. This value will always run from zero to NOBJ-1 in a given timestep. This value does not identify the current object within the simulation like OBJID or OBJNAME, just the object’s position in the current order of processing.

This value is useful for generating a random number for each object, or simply splitting the objects into two or more groups to be processed in different ways. This value will be -1 if the node does not process objects sequentially (such as the Group DOP).

OBJID

This is the unique object identifier for the object being processed. Every object is assigned an integer value that is unique among all objects in the simulation for all time. Even if an object is deleted, its identifier is never reused.

The object identifier can always be used to uniquely identify a given object. This makes this variable very useful in situations where each object needs to be treated differently. It can be used to produce a unique random number for each object, for example.

This value is also the best way to look up information on an object using the dopfield expression function. This value will be -1 if the node does not process objects sequentially (such as the Group DOP).

ALLOBJIDS

This string contains a space separated list of the unique object identifiers for every object being processed by the current node.

ALLOBJNAMES

This string contains a space separated list of the names of every object being processed by the current node.

OBJCT

This value is the simulation time (see variable ST) at which the current object was created.

Therefore, to check if an object was created on the current timestep, the expression $ST == $OBJCT should always be used. This value will be zero if the node does not process objects sequentially (such as the Group DOP).

OBJCF

This value is the simulation frame (see variable SF) at which the current object was created.

This value is equivalent to using the dopsttoframe expression on the OBJCT variable. This value will be zero if the node does not process objects sequentially (such as the Group DOP).

OBJNAME

This is a string value containing the name of the object being processed.

Object names are not guaranteed to be unique within a simulation. However, if you name your objects carefully so that they are unique, the object name can be a much easier way to identify an object than the unique object identifier, OBJID.

The object name can also be used to treat a number of similar objects (with the same name) as a virtual group. If there are 20 objects named "myobject", specifying strcmp($OBJNAME, "myobject") == 0 in the activation field of a DOP will cause that DOP to operate only on those 20 objects. This value will be the empty string if the node does not process objects sequentially (such as the Group DOP).

DOPNET

This is a string value containing the full path of the current DOP Network. This value is most useful in DOP subnet digital assets where you want to know the path to the DOP Network that contains the node.

Note

Most dynamics nodes have local variables with the same names as the node’s parameters. For example, in a Position node, you could write the expression:

$tx + 0.1

…to make the object move 0.1 units along the X axis at each timestep.

See also

Dynamics nodes