Solver#
Solver node manages all global simulation parameters, simulation states, and the simulation cache. HiPhyEngine allows multiple solvers in the same scene. Though HiPhyEngine allows full coupling of all different material models, for better performance and iterative workflow, unless coupling interaction is needed, it is still recommended to split out different materials (such as hair, cloth, and soft body of the same character).
Solver Space#
Solver node can be represented by any type of object. In the quick-start example, we used an empty axis object in Blender. Though the solver node is not rendered, the transformation of the solver node is still critical to the simulation. It defines the solver space. The solver space, is the object space of the solver node, it defines the origin, orientation, and scale of the simulation space.
A common use of the solver space is for reducing numerical issues. For instance, if the shot is far from the origin (for instance, 1000s of units off), in such cases, the numerical effectiveness of the simulator will be significantly reduced, if the simulation runs in the world space. However, by moving the solver node to where the shot is, this numerical issue is mitigated.
Another use of the solver space is to reduce motion introduced by animation using animated solver space. For instance, a character running or turning at a fast speed, to reduce or remove the motion introduced by such motion, user can make the solver node follow the animated character, this can remove/reduce the motion's effect on the simulation.
Scaling the solver node
DO NOT introduce scaling on the solver node, especially non-uniform scaling. The simulator will accept it as input, but there is no guarantee all parameters will be scaled accordingly. If you wish to scale the simulation space, for instance, for the purpose of unit conversion, use the solver scale parameter.
You can find an example of multi-solver set up, and moving solver space here. In the example, you can see the moving solver space eliminated the effect of the moving point constraint.
Solver Scale, and Model Unit#
The internal length unit of HiPhyEngine is \(cm\). Instead of requiring users to manually convert all parameters to \(cm\), HiPhyEngine provides a single parameter, solver scale, for unit conversion. For instance, if the scene is in \(inch\), user can set the solver scale to \(2.54\), then HiPhyEngine will internally scale up the scene by \(2.54\), effectively converts the units from \(inch\) to \(cm\).
Some parameters in HiPhyEngine is labeled as model units instead of standard cm. Those parameters will be scaled with solver scale internally. The reason for HiPhyEngine to use model unit instead of cm is to make it easier for user to measure those parameters in the scene. For instance, collision thickness/radius and deformable body grid size are measured in model unit.
Cache Management#
Each solver node owns and manages their own simulation cache files. In Blender, user has to manually save/load the cache file. Simulation cache can be rather big for large scenes. To prevent large load/save time, and to provide more flexibility, we decided to let the user manually manage the cache files. HiPhyEngine cache save/load are registered Blender operators, so user can also write simple scripts to manages the cache IO when there are multiple solver nodes, or even version control system for simulation caches.
Properties#
| Property Name | Description |
|---|---|
| Simulate In Memory | If unchecked, the simulator will offload unused data to disk to minimize memory footprint |
HiPhyEngine have to cache the whole simulation timeline and stores necessary intermediate data for simulation restarts. It can be very memory consuming, especially for volumetric simulations with deformable bodies. Unchecking the simulate in memory will allow the HiPhyEngine to offload unused data in the cache folder, and load them back in when requested. The offloaded simulation cache files will share the same filename as the main cache file, but with the frame number appended to the file extension.
| Property Name | Description | Animatable |
|---|---|---|
| Frame Start | The start frame of the simulation | |
| Frame End | The end frame of the simulation | |
| Checkpoint Frequency | How often is the checkpoint data saved | NO |
| Solver Scale | Scale factor between the scene and the solver space | YES |
| Number of Subframes | Number of substeps inside each frame | YES |
| Frame Rate | Number of frames per second | YES |
| Perform curve curve continuous time collision | If continuous time collision will be performed for elastic rods. see elastic rods for more detail | YES |
| Newton Tolerance | The order of error reduction for the Newton iteration | YES |
| CG Tolerance | The order of error reduction for the linear solve iteration | YES |
| Max Newton Iterations | The maximum number of Newton iterations the solver will perform | YES |
| Max Continuous Time Iterations | The maximum number of continuous collision detection iteration the solver will perform | YES |
Checkpoint Frequency#
Checkpoint data are used to restart simulations. They can be way larger than the position data, expecially for volume simulations such as deformable body and MPM. To reduce the simulation cache size, we allow simulations to checkpoint less frequently. However, it also means the simulation will only be able to restart at the the latest frame with checkpoint data stored. When resuming simulation, HiPhyEngine will find the latest frame with checkpoint data prior to the restart frame, and resume from there.
Number of Subframes#
The default value for the number of subframes is \(10\). It is a very conservative setting that will create stable simulation in most cases. The number of subframes has the most drastic effect on the simulation time, user can choose to reduce the number of subframes to improve the simulation speed.
Subframe Interpolation#
HiPhyEngine exports the simulation data at each frame, and linearly interpolate the subframes inside the simulator. HiPhyEngine currently does not support export subframe data from rig. If the animation input has a large rotation within a frame, HiPhyEngine will not be able to handle it properly, user will need to manually increase the frame rate for the scene, stretch out the frames and pass it into the simulator with corresponding frame rate (don't forget to reduce the number of subframes as well).
Solver Tolerance and Simulation Performance#
Lower the tolerance is, longer the simulation will need to run to achieve that. The default values are set very conservatively. They will make sure the simulation will run through in the vast majority of the cases, however, they are also overly safe for most cases. If the simulation rig is too slow, those are the parameters need to be tuned. Smaller tolerance will run significantly faster, but might introduce jitters and other instabilities. Those tolerance are also animatable, so during shot work, user can selectively reduce the tolerance if they see instability in certain frames.
An example output of the simulation might look like:
Newton iteration 0: 67.2891, step size: 1. CG iteration: 0
Newton iteration 1: 6.89694, step size: 1. CG iteration: 9
Newton iteration 2: 2.23009, step size: 1. CG iteration: 9
Newton iteration 3: 0.273542, step size: 1. CG iteration: 7
Newton iteration 4: 0.00789377, step size: 1. CG iteration: 8
Newton iteration 5: 0.000133047, step size: 1. CG iteration: 9
Newton iteration 6: 6.69312e-06, step size: 1. CG iteration: 9
Newton iteration 7: 1.41424e-07, step size: 1. CG iteration: 10
User should see the Newton iteration goes down steadily. If the Newton iteration does not converge (i.e. reducing), user might need to reduce the CG tolerance.
Elastic Grid Parameters#
Please see deformable body for the grid parameters.
Preloading Parameters#
Please see elastic rod for the preloading.