Alternative to scatter device

Development and Feature Requests
#1

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
#3

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
#4

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
#5

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.

4 Likes
#6

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
#7

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

#8

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.