The Boundless Flow

Let's say you're sold on the reasons to use Standalone because of all the majestic benefits covered in "The Assembly Philosophy".

And you've done the work discussed in "The Reusable Arsenal".

You've built your asset libraries - trees, rocks, foliage, debris, whatever your world demands. Each collection sitting in its own clean OCS or ORBX file, waiting. Now you need to place them. Hundreds of thousands of rocks along a riverbed. Trees across an entire hillside. Shrubs, roots, and ground cover filling every gap. And not just placed, but varied in rotation, scale, density, color.

The real question isn’t “how.” It’s why isn’t this the default way of building everything?

‍Because you haven’t been doing it inside an assembly environment.

In a DCC you already use this idea constantly, just in a simplified, convenient wrapper. In Cinema 4D it’s Cloner. In Octane plugins it’s a Scatter tool. In Blender it’s Distribute Points. In Houdini it’s Copy to Points. Same concept, different UI.

Here’s the core: any object in 3D can be described by a tiny set of coordinates: TX/TY/TZ, RX/RY/RZ, SX/SY/SZ. Translation, rotation, scale. That transform is effectively “bound” to a single point in space.

You can deform the mesh, add details, subdivide it, but its transform anchor (the thing you actually place in the world) is still just that. A point + a transform.

And that’s why most people don’t think about it this way: we’re trained to treat geometry as a self-sustained unit that exists in 3D space. But you’re familiar with the pain: you animate a spaceship and then the director asks, “Can we swap it for a pink wooden elephant?”
‍
Suddenly your animation is untransferrable from the object.

That’s why experienced animators put geometry under a null or any other parent object, and animate it instead.

You’re not animating the spaceship, you’re animating a controller that happens to carry a spaceship today… and can carry a pink wooden elephant tomorrow.

A pointcloud driven scene is exactly that “experienced trick” scaled up from one null to millions of controllable nulls, each with its own transform, variation, etc. That’s when points stop being “scatter” and start being a scene descriptor.

Set-dressing scatters are the most conventional use cases for points. Convenient and powerful. But that's absolutely not the end of the use cases for points. What else can we drive with this?

Layouts

Might seem minor, but when working on a massive landscape, you may want to opt for this method, to cut processing costs. Same principle, we save our Megascans as library (Singulars or Collection). After layout work is done, we export it as points. Connect in Standalone, and perfectly optimised clone of your layout is rendering on GPU for a fraction of resource-cost.

Simulations

Simulations that require set of instances (pebbles, rocks for example). "The Rings of Power" Titles sequence! Any mograph type of simulation, RBD, that kind of stuff.

Lights

We often animate secondary lights with scatter approach: light beams, projectors, accents, organic lights lurking in the shadows.

Even hero animations

Rigid-body elements, spaceships, robots, rigged arms and structures, cars - all of this can be driven by points like in the example above. In practice it means your modeling department can supply animation team with a proxy geometry; car body and wheels, for example. Animation department can carry out their work while model is being finished. Once model is done, just swap the geometry - animation is already there.And remember, your team can do all these different production disciplines in the software of their choice. Because of this, your team is software-agnostic. Let them shine where they're most comfortable! Work anywhere, assemble in one place.

For years, almost nobody treated Octane like a scene-building environment, it was seen as a place you render from, or check a scene before Render Network, not a place you assemble & lookdev in.

So when people did try, they typically went for the most obvious route: export the entire scene as an ORBX - everything, all at once. Whole scenes, fully packed, in one go. That’s when things started to fall apart: scatters would get messy, with duplicated geo, file sizes would balloon, and so on. If they would export at all in the first place. Not because Octane “can’t do complexity” - but because it was being pushed through the wrong workflow. More on this here.

And that’s exactly why we built tools like LMI Pointbaker: to make Standalone assembly actually practical, controllable, and scalable, not a brute-force blind export. Now that this pipeline is finally getting traction (slowly, but it is), OTOY are pushing in the same direction too - including upcoming support for binary containers (USD) as scatterers, which makes this method even more powerful.

That old reputation that “Octane can’t handle complex productions” wasn’t based on Octane’s limits, it was based on how it was being used. Now it can be used correctly. Try it.

There's something that happens when you start building this way that's hard to explain until you experience it.

The first project feels like investment. You're building libraries, learning the baking workflow, reorganising how you think about scenes. There's a setup cost, and it's real.

The second project is faster. You have libraries already. Your scatter workflow is familiar. The baking is reflex now.By the fifth project, you're assembling scenes that would have been impossible before, not because you've gained new capabilities, but because each project left something behind. A tree library. A rock collection. A light rig. A scatter setup you can repurpose. The pipeline compounds.And crucially, the scenes themselves stay fast. You can add complexity that would have buckled a DCC-integrated workflow, millions of instances, animated elements - and Standalone handles it, because it's working with point data and pre-built assets, not trying to resolve and convert everything simultaneously.

This is what we mean by "boundless." Not that there are no limits, but that the limits stop arriving when you'd expect them to.

Andrey Lebrov

Head of CG & VFX