Have you ever wrapped up a complex fluid or particle simulation only to realize the timing feels off? You know that sinking feeling when your shot needs to slow down for dramatic effect or speed up to match your edit.
Re-running your entire sim for a simple timing tweak can eat up hours of render time and blow past your deadline. You’re left juggling cache files and keyframes, hoping for a quick fix that doesn’t exist.
That’s where Houdini Retime SOP comes in. This powerful node lets you perform retiming simulations in post, giving you precise control over speed without restarting your sim.
In this guide, you’ll learn step-by-step how to slow down and speed up your sims using the Retime SOP, adjust curves, manage caches, and integrate these tweaks into your pipeline for efficient, deadline-friendly workflows.
What is the Retime SOP in Houdini and when should you retime simulations in post?
The Retime SOP in Houdini is a procedural tool designed to remap frame timings on geometry or particle streams after a simulation has been cached. Unlike resimulating with new time scales, the Retime SOP shifts and stretches existing frame data, interpolating point attributes, normals, and velocity fields to create smooth speed ramps without rerunning heavy sims.
In production, retiming becomes essential when you need to:
- Adjust the dramatic impact of a fluid splash or smoke reveal by slowing down or speeding up motion.
- Match action timing to editorial cuts or music beats without returning to the simulation stage.
- Optimize render budgets by compressing long simulations into a tighter frame range.
Consider the Retime SOP as a time-warp layer: it accepts frame numbers on its input, applies a user-defined remapping curve, and outputs corresponding frames. Internally, Houdini performs linear or higher-order interpolation on all per-point data, preserving mesh connectivity and velocity continuity for motion blur.
You should favor retiming in post when your base simulation is physically accurate but the scene’s pacing demands refinement. For instance, a pyro run might simulate correctly at 24 fps, but an emotional slow-motion shot at 48 fps requires smooth subframe interpolation. Retiming avoids re-simulating with increased substeps and costly solver iterations.
Be mindful that extreme speed ramps can introduce stretching artifacts if the source cache lacks sufficient temporal resolution. In those cases, combining the Retime SOP with a TimeBlend SOP or re-simulating only specific segments may yield higher fidelity results.
How does the Retime SOP affect simulation data — positions, velocities, attributes, and topology?
The Retime SOP works by remapping frame samples in a geometry sequence, then interpolating between those samples. For point-based simulations—particles, FLIP fluids, grains—it reads two bracketing frames and computes a weighted blend of positions. This creates smooth slow-mo or speed-up effects without re-simulating. Internally it uses linear interpolation for vector attributes, so each point’s new position is a lerp of its placement in the original frames.
For velocities, the Retime SOP offers two methods: you can either scale the existing v attribute by the time stretch factor, or ask the SOP to recompute velocity from the interpolated positions (difference over time). Scaling preserves the original simulation’s momentum curves but can look off if you combine retime with forces. Recomputed velocities ensure physical consistency in post-retimed flips or grains, since they match the actual movement between retimed frames.
Other point or primitive attributes follow a similar interpolation scheme:
- Vector/float attributes (Cd, pscale, density): linearly interpolated per component
- Integer or string attributes (id, material): held constant from the nearest original frame
- Volume grids or VDBs: each voxel is blended, which can introduce diffusion in temperature or density grids
Topology itself remains unchanged: the Retime SOP does not add, remove, or weld points/primitives. However, if your simulation generates a varying point count (for instance, emission bursts in POPs), missing or newly introduced points simply appear or vanish based on the sampled frames. In such cases, maintain consistent point IDs upstream or use a Time Blend SOP before retiming to preserve continuity in attributes and avoid “ghost” particles when ramping speed.
How do you set up a safe retime workflow for DOP simulations using the Retime SOP?
Essential preparatory steps: caching, exporting velocity/forces, and timecode preservation
Before applying the Retime SOP to DOP simulations, it’s critical to bake out your sim to disk. Use a File Cache node or an ROP File Output in a Solaris LOP chain to export geometry, velocity, and force fields. This avoids re-simulating when tweaking timing.
- Cache per-frame VDBs or packed geometry with velocity attributes (v).
- Export forces or custom fields as separate bgeo files for post-adjustment.
- Store original timecode under a custom attribute (e.g. “orig_time”) to trace back if curves shift.
Preserving the simulation’s timecode lets you compare pre- and post-retime versions in compositing or shading networks. It also helps drive procedural offsets if you layer simulations in SOPs.
Applying Retime SOP: modes, velocity recompute vs. blend, and frame mapping best practices
Drop in a Retime SOP after your File Cache. Choose between Velocity Recompute and Velocity Blend under the “Method” parameter. Recompute generates clean per-frame v by finite differences—ideal for large slow-motion stretches. Blend interpolates between stored velocities—faster but may introduce drift.
- For subtle speedups (up to 2x), use Velocity Blend to retain existing force curves.
- For dramatic slowdowns (over 3x), select Velocity Recompute to avoid linear streaking.
- Use the “Time Warp” mode with a custom ramp to non-uniformly vary speed.
Frame mapping controls how input frames map to output. A linear scale of 0.5 will double playback length; use a curve to ease-in or ease-out sim speed. Always preview in the viewport with velocity display turned on—misaligned v fields are your first sign of potential popping or jitter.
How can you preserve physical realism when slowing down or speeding up (recomputing velocities, substepping, and constraints)?
When you retime a simulation in Houdini with the Retime SOP, you change the frame rate without running the solver at its original pace. That distorts particle and rigid body velocities, causing unnatural motion or jitter. To maintain physical realism, you must recompute velocities based on the new time step, adjust solver substeps, and re-evaluate constraint timings so collisions, Vellum stitches, or RBD glue bonds respond correctly.
First, enable “Compute Velocity” inside the Retime SOP. This calculates velocity as (P_next – P_prev)/(2×dt_new), where dt_new is the stretched or compressed time step. For finer control, you can use a Point Wrangle after the Retime SOP:
- v = (P@ptnum_next – P@ptnum_prev) / (2 * @TimeInc);
- store it in @v to override distorted motion.
Next, adjust DOP substepping. When slowing down by 50%, time steps double; you should double your substeps to preserve solver stability. In your DOP network, under the Solver node, set Substeps to ceil(OriginalSubsteps / TimeScale). This keeps collision detection sharp and avoids tunneling.
- TimeScale = chf(“time_scale”)
- Substeps = ceil(chf(“base_substeps”) / TimeScale)
Finally, constraints like glue or bend springs rely on activation and break thresholds tied to frame count. Wrap a SOP Solver inside your DOP network to remap constraint attributes each frame. Multiply activation times and lifespans by TimeScale so bonds break or restitch at the intended moments. This ensures your slowed or sped-up sim honors the same procedural timing you authored.
What common artifacts occur after retiming and how do you diagnose and fix them (popping, particle drift, collisions)?
Retiming a simulation fundamentally alters how frames are sampled and interpolated. When you speed up or slow down playback via a Retime SOP or TimeBlend, per-frame velocity, collision, and attribute data can become misaligned. Identifying the root cause often means inspecting velocity fields, subframe interpolation, and solver substeps inside your DOP Network.
Popping manifests as sudden jumps in geometry or flip particles when time samples don’t match. It’s usually caused by missing velocity or attribute reconstruction between frames, so your mesh or particle system skips too far.
- Diagnose: Enable “Compute Velocity” in TimeBlend or check Trail SOP velocity vectors. Look for zero or inverted vectors between frames.
- Fix: Use TimeBlend SOP with velocity enabled, or insert a Trail SOP on the source to regenerate smooth per-point v and N attributes. Increase solver substeps in DOPs for finer sampling.
- Optional: Apply a tiny attribute blur (Attribute Blur SOP) on P and v to soften harsh transitions.
Particle Drift shows as particles lagging or detaching from expected surfaces. After retime, original velocity fields may be too coarse, so particles follow outdated flow data.
- Diagnose: Visualize point v in Geometry Spreadsheet across retimed frames. Look for large deltas or zero velocities.
- Fix: Re-project velocity fields at each new time sample via a Volume Sample or Volume Trail before popping into POP Solver. Alternatively, pump particle positions through a POP Wrangle that lerps between old and new v attributes.
- Best Practice: Cache a high-resolution velocity VDB and retime that volume, ensuring consistent driving forces.
Collision Artifacts appear as ghosting, penetrations, or floating geometry when collisions aren’t re-evaluated at the right times. Retiming can desynchronize collision proxies from the solver’s substep schedule.
- Diagnose: In the DOP Network, visualize collision geometry at each substep. If proxies skip, you’ll see geometry intersect or hover.
- Fix: Increase the subframe collision iterations in RBD Solver or Pyro Solver. Use “Enable High Quality Collision” and refine the collision margin.
- Advanced: Bake collision geometry to packed primitives and retime the packed sequence before importing into DOPs to preserve consistent collision timing.