I feel bad about being negative here, but I prefer the lower level node approach that Jacques described, with a built-in node group to handle this use-case.
We've already slightly violated that approach with the operation option, but that required using a temporary attribute, so there were performance considerations in addition to the need to type in the temporary attribute name twice. Those don't really apply here.

But I see this as the perfect use case for the built-in node group idea that has been discussed before, where it would appear in the add node list. IMO that idea should be explored more before we add options to nodes like this.

@Jacques Lucke (JacquesLucke) @Hans Goudey (HooglyBoogly) @Simon Thommes (simonthommes)

I understand the reluctance of adding options for the sake of it, but I can't bring myself to agree with the viewpoint of using Node Groups, they are just not fit for purpose for adding this type of option.

Below is a node group to create the Midpoint-Variance option.

This is just for vector attribute data type and Node Groups would need to be created for all data types.

In addition, it is not even possible to use anything but sockets in the Node Group. So there is no way to expose the Operation and Data Type enums.

Example of Node Group for Vector data type:

Example of real world nodes that would benefit from having this option (copied from Twitter feed by @Erindale (Erindale)):

+1 for more probability distributions! I've been thinking for a while now that adding more ways to sample random values would be very useful :)

I wouldn't use the names Min - Max and Midpoint Variance though, but the standard names of the probability distributions with their most common parametrizations, e.g:

• Uniform (parameters: min and max)
• Normal or Gaussian (parameters: mean and standard deviation)

Other distributions e.g. Exponential, Poisson, Gamma, Log-Normal, Weibull, Binomial, etc would definitely be useful too in the future! Just as an example to show how you could arrive at these distributions, here's a flow chart I found that helps you choose one:

In D10459#273483, @Charlie Jolly (charlie) wrote:

Add Triangular distribution

Left to right:
Uniform, Midpoint, Gaussian, Triangular

That gaussian distribution looks quite suspicious to me...
I haven't looked at the code but I looked at the patch and recreated a random 3D distribution and it looks to me like there is either some bias in the distribution itself or correlation between the components.
Judging from the fact that creating the vector from multiple different seeds gives the same result, I'd guess that there is something fishy with the values themselves.

In D10459#273867, @Simon Thommes (simonthommes) wrote:

In D10459#273483, @Charlie Jolly (charlie) wrote:

Add Triangular distribution

Left to right:
Uniform, Midpoint, Gaussian, Triangular

That gaussian distribution looks quite suspicious to me...
I haven't looked at the code but I looked at the patch and recreated a random 3D distribution and it looks to me like there is either some bias in the distribution itself or correlation between the components.
Judging from the fact that creating the vector from multiple different seeds gives the same result, I'd guess that there is something fishy with the values themselves.

Sounds like a bug. I'll check through it again. Did you happen to have the test file to hand?

@Charlie Jolly (charlie) thanks for looking into it that looks good now! I didn't really have an example file, sorry. Just seemed wrong to me when looking at it.

@Charlie Jolly (charlie) Is this patch ready to test? If so could you merge it with current master? It didn't build for me when I tried it just now.

@Simon Thommes (simonthommes) this is really good feedback. I agree with pretty much everything you've said.

The spherical distribution certainly needs more work to make it spatially uniform.

The use case for the spherical distribution is to provide a way to randomize a vector by angle/direction and length. This can be used to distribute points radially. spherically in angular space.

In this example, spherical distribution is used to randomly point the cones in a 40 degree arc. This is much easier to control and natural than using euler rotations. I see this in a comparable way to the Axis Angle vs Euler rotation methods in the vector rotate node.

In D10459#276380, @Charlie Jolly (charlie) wrote:

@Simon Thommes (simonthommes) this is really good feedback. I agree with pretty much everything you've said.

Great, I'm glad!

The spherical distribution certainly needs more work to make it spatially uniform.

The use case for the spherical distribution is to provide a way to randomize a vector by angle/direction and length. This can be used to distribute points radially. spherically in angular space.

In this example, spherical distribution is used to randomly point the cones in a 40 degree arc. This is much easier to control and natural than using euler rotations. I see this in a comparable way to the Axis Angle vs Euler rotation methods in the vector rotate node.

Okay, so it is what I was thinking then. Hm, I'm not sure this should be in this node then, to be honest. To me this is a special case, just as well as randomization of colors. It goes beyond just simply randomizing an attribute's components according to a distribution and correlates the components.

My proposal would be to remove this distribution from the node and create a new task for this case (we might actually still have one for randomizing rotations uniformly). It would probably be a new node, but the design would still need to be figured out.

And yeah, it should be spatially uniform for this, so it would need more work anyways. My initial idea would just be to re-roll random values uniformly if they are not meeting the angle and radius constraints, but there is probably a more elegant solution.

Thanks for addressing my feedback!
I'm pretty happy with what we have with this node now!

There are two minor things that I am wondering about:

• Min/Max inputs are shared by the Uniform and Triangular distribution type, which makes sense. I feel like the same way it would be nice to have shared inputs for Gaussian and Midpoint Variance. That way the distribution method can easily be changed while keeping the wire connections/set values intact. Actually, after reviewing the behaviour again I see that the inputs are shared between all methods except Gaussian even though the labels change for Midpoint Variance. I think, either should the Gaussian method share the inputs as well, or, if possible, the pairs of Uniform/Triangular and Gaussian/Midpoint Variance should have shared inputs, as they are conceptually similar. (I'd personally go for the latter) The labeling should stay the same though.
• I am wondering if the Triangular method would benefit from the Mode input being relative to Min and Max. I can see both option being useful depending on the case and I'm not sure. I do feel like the relative method would be more intuitive to use, as usually I would use this method to bias a distribution towards either side, rather than place the area of maximum likelihood around a point. So I'd propose to do it relative as in:

Mode(0,0,0)=Min
Mode(0.5,0.5,0.5)=(Min+Max)/2
Mode(1,1,1)=Max

@Simon Thommes (simonthommes) I think it makes sense to share the inputs in this way. The idea about the mode as a factor is also good. I'll make these changes and update the patch.

I've also uploaded a WIP patch for the spherical distribution here: D10883: Geometry Nodes: Attribute Randomize Spherical Node

I think we should put this patch on hold until we have the details of the new attribute workflow settled, which will hopefully be soon.
The implementation would probably be quite simpler in that case, which is very nice.

I still think the functionality in this patch is important though.

EDIT: To clarify, I think this node could be "preemptively" implemented as a function node so that it was ready when function nodes can be used for attributes.

Waiting on design task T91373: Random Number node.