|On this page|
Normally in geometry networks each frame is self-contained: it works out what the geometry should look like based on the nodes in the geometry network, possibly using variables like
$F (the current frame) to modify their behavior, using the animated position of points at the current frame, and so on.
This node lets you create effects where a surface network modifies the previous frame’s geometry, allowing you to create iterative feedback, automata, and simulation-like effects.
In a normal geometry network, the points will jitter to random locations at each frame, creating a look where each frame seems completely independent, with points “teleporting” between random positions.
If you put the jitter in a Solver node network, the jitter is applied to each point’s position from the previous frame, creating a “random walk”, with points wandering around.
In a geometry network, use the ⇥ Tab menu to create a Solver surface node.
Connect the geometry you want the solver to modify to the first input of the solver node.
Double-click the solver node to dive inside.
The network editor jumps to a geometry network containing several nodes representing the inputs to the solver, and a node labeled
Input_1node in the solver network contains the original geometry you connected to the first input. This is sometimes useful, for example for nodes that take a rest position. The solver’s second, third, and fourth inputs allow you pass extra bits of geometry down to the solver’s SOP network if needed.
Start building surface nodes from the output of the
Prev_Framenode. This network will be cooked every frame, with the output of the
Prev_Framenode containing the geometry from the previous frame. Set the display flag on the node containing the “output” geometry of the
For example, if you connected a Transform node to the output of the
Last_Frameand set the transform node’s Translate parameter to
0, 1, 0, the geometry you connected to the solver’s first input would rise one unit every frame.
To get from the solver’s geometry network back up to the original geometry network, press U or click the original network in the path bar at the top of the network editor.
Click Play in the play bar at the bottom of the main window to see the effects of the solver.
If you press play inside the solver’s network, you will not see the feedback effect. The playback will simply show what the network would look like if it ran on the original input geometry at the current frame.
You may want to create and pin a new network editor tab with the solver’s network so you can refer to it more quickly.
How it works
You can use the Solver node to create iterative feedback effects without reading this section, however for advanced users or if you're having a problem, this section may be useful.
The Solver node contains a simple DOP network with a SOP Solver DOP. When you double-click the Solver surface node, a bit of magic jumps not into the actual contents of the node (the DOP network), but down one more level into the contents of the SOP Solver DOP (the network for specifying the solver step SOPs).
If you want to modify the DOP network for some reason, you can jump to it by clicking it in the path bar at the top of the network editor.
If you play back the animation while viewing the contents of the Solver SOP, you will be saving un-feedback frames to the cache, which will look like they aren’t doing anything when replayed. You can fix this by resetting the simulations.
Resets the simulation.
Normally the first input is the initial state. However, this toggle, lets you explicitly specify another SOP to be the initial state, freeing up that input.
Which frame to start solving on. The geometry is empty prior to this frame.
How many substeps to break each frame into.
Pure SOP simulations do not require a cache, but it is useful for scrubbing.
Allow Caching To Disk
If the maximum size of the cache in memory is reached, the DOP Network can either delete old cache entries to make room for new entries, or old entries can be saved to disk. If this option is turned on, the old cache entries are saved to disk and will be reloaded from disk if needed. This mode will be slower than simply throwing away the old cache entries, but it ensures that the entire simulation history is always available regardless of the in-memory cache size.
Cache Memory (MB)
Specifies how much memory in megabytes can be consumed by the cache for this simulation. Once this limit is exceeded, old cache entries are either deleted or saved to disk to make more room, depending on the state of the Allow Caching To Disk parameter above.
This example demonstrates various ways in which you can use a solver node to transform an object based on ordinary differential equations.
There are 6 different solvers in this example. There is also the exact answer as a point of reference. The solvers are numerical methods that solve the following coupled Ordinary Differential Equations with initial conditions:
x' = y ; x(0) = 1 y' = -x ; y(0) = 0
The numerical methods for Ordinary Differential Equations are: Forward Euler, Runge-Kutta Second Order, Runge-Kutta Third Order, Runge-Kutta Fourth Order, and Parker-Sochacki solved two ways. In one version, Parker-Sochacki is hard coded at order 5. In another version Parker-Sochacki is written in a for loop where the order can be adjusted by the user.
This is an example of simple footsteps using sdfs on a grid.
This is an example of a simple cloth using verlet integration and simple explicit springs.