Alternative to scatter device

The current implementation of the scatter device is a bit limited in my opinion. It would be more powerful to have a scatter device that lets you hook up a generator (or even better, a group of nodes/macro), and let you change the seed/parameters for each instance you scatter. For example, you create a radial grad with some distortion. Those two nodes are then fed into the scatter device with a certain set of parameters promoted as “scatter-able”, allowing the scatter device to change their value for each created instance. This would result in a terrain of unique radial grad like shapes without the hassle of having to create a unique instance and without duplicates (or well, duplicates would be improbable)!

Another really important feature that is currently missing is the ability to mess with the placement and especially the density of the instancing. Being able to let instances overlap would eliminate the need for multiple octaves as a filler.

1 Like

Agree with this!
At the very least the Scatter device needs a random rotation function, and the ability to explicitly state ‘I want 5 of these scattered entirely within the world extents’.

1 Like

That’s very helpful feedback - originally, the Scatter device was going to have a “distribute N instances” mode, but most of the use cases I was hearing at the time had N very large, in which case the current implementation is much more suitable.

Adding a “scatter N instances randomly” mode would be straightforward to add.

2 Likes

Having a controllable shape input is something interesting indeed - in WM’s flow-forward model, the way this would need to be implemented is as an internal device graph, much like a macro. That way, the scatter device could call into it for each object required.

The scatter device is interesting in that it’s a prime example where almost every parameter could ideally be controlled by an input map. For the next major feature release of WM, some internal refactoring is planned to make this kind of thing much easier. More on that later :slight_smile: but it is an actively planned dev area.

3 Likes

That’s great to hear! I’m really excited to see how this will find its way into WM’s workflow. I was indeed thinking of either having multiple devices, kind of like the River devices, or a macro world like thing. The latter is I think the better implementation, as it will keep the device overview free from clutter.

A thing to consider is the same behaviour we see in macros, where the individual state of each device within the macro world is forgotten upon build. A same strategy should apply to the Scatter device I think, BUT, it would even be better if this behaviour could be toggled (and is ON by default), because it is extremely annoying if you’re making lots of iterations due some small changes and having to re-render every device that’s part of it.

One thing to keep in mind, is that it would be best to render the scatter object at the world’s resolution × the object’s scale, with the object’s scale at 1 being “full” world size and 0.5 being half the world’s size. This will prevent unnecessary high res rendering of scatter objects that end up being small. This would only be applicable for scatter objects that are randomised for each instance.

1 Like

Also is there any reason the Scatter device’s Seed isn’t randomized with the global randomize button?