01 Overview
This project is a procedural camera transition built in Houdini. A large number of objects, simulated as soft bodies, interact with each other and with a surface: they are launched along ballistic trajectories, collide with an imaginary screen, stick to it until the visible area is fully covered, and then detach over time.
Implementation context: Houdini, Vellum soft-body simulation, and a custom DOP network. The result is cached, and can be rendered in Houdini or Solaris or exported to a game engine with VAT.
Core idea — controlled chaos. Motion is driven by physical simulation, while variation is introduced intentionally and selectively.
The sections below follow the system in the order it runs: what the setup has to guarantee, how the camera defines the layout, how trajectories become a velocity field, how the simulation and its state logic work, and how objects stick to the screen and release.
02 Design goals
The transition needs motion that is physical but an outcome that is predictable. That set the requirements for the setup:
- a fixed object count;
- stable screen coverage;
- predictable composition;
- deterministic target positions, even though motion comes from a simulation;
- variation that is never global and never breaks the underlying structure.
The next sections show how each requirement is met: the camera fixes the layout, the trajectories fix the targets, and randomness is applied only to selected properties.
03 Camera-driven layout
The entire setup is camera-driven. The camera frustum is used as a spatial template to define the final object positions, which is what ensures a fixed object count, stable screen coverage, and predictable composition.
04 Trajectories and the velocity field
Initial and final positions are defined per object and connected into procedural trajectories. These trajectories define flight direction and curvature.
Objects are not moved directly along splines. Instead, the spline tangents are converted into a velocity field, and that field drives the simulation. This allows acceleration, deceleration, rotation, and noise to be applied while the target positions stay deterministic.
Controlled variation
Variation is introduced through controlled offsets in timing, orientation, and velocity strength. Randomness is never global and never breaks the underlying structure: the trajectories still end where the layout says they should.
05 Soft-body simulation and state logic
Physical interaction is handled with Vellum soft-body simulation. Objects deform on impact and interact with each other during collisions.
Collision volumes are also used to track object states, including screen contact, sticking, and release timing. All state changes are stored as attributes and interpreted inside a custom DOP network.
Launch phases
Velocity is applied only to selected object groups, which allows different launch phases. Key hero objects are activated first, followed by the main group after a controlled delay. This sequencing lets the chaos build up gradually rather than appearing all at once.
| Stage | What drives it |
|---|---|
| Layout | Camera frustum used as a spatial template for final positions |
| Launch | Velocity field from spline tangents, applied to selected groups: hero objects first, then the main group after a delay |
| Flight | Velocity masking: objects are slightly slowed during flight and accelerated before impact |
| Contact | Collision volumes track screen contact; stick constraints are activated |
| Release | Per-object timing from randomized thresholds |
06 Stick and release
When objects reach the screen surface, stick constraints are activated. Release is not triggered simultaneously.
Each object has its own release timing based on randomized thresholds, so objects detach one by one instead of collapsing as a single layer.
Additional velocity masking is applied to slightly slow objects during flight and accelerate them before impact, which reinforces the perception of weight and contact.
07 Pipeline usage
The simulation runs on low-poly proxy geometry. Motion is transferred to the final meshes using Point Deformer and then cached.
The cached result can be rendered directly in Houdini or Solaris, or exported to a game engine using VAT.
08 Result and scope
The outcome is a transition whose motion comes from simulation, while its layout, targets, and timing stay under control. The same approach can be adapted to game cinematics, real-time effects, and stylized transitions.
Scope. The example focuses on system design and problem-solving rather than on a specific engine integration.
Like this post? ( ´◔ ω◔`) ノシ
Support: Buy Me a Coffee | Patreon | GitHub | Gumroad | YouTube
