Implement per-object distribution ratio for moss use case #85189

New Issue

Dalai Felinto · 2021-01-29T11:24:02+01:00

Dalai Felinto commented

2021-01-29 11:24:02 +01:00

{F9592504 size=full}

{F9603726 size=full}

Notes:

The socket only exists when "Use Count" is false.
When switching "Use Count" it would be nice to sync the collection from the socket default value and vice-versa
It is fine to find a different name for "Use Count". Just keep in mind that "Use Count" is what the old particle system uses. So for all effects this is the implementation reference.

Initial UI prototype for socketless: P1906

--

Different workarounds:

Separate the points ahead of time and use multiple Point Intance nodes.
Manually create duplis in the collection based on the ratio you want them to be instanced.

--

Original design task: #84608

{[F9592504](https://archive.blender.org/developer/F9592504/image.png) size=full} {[F9603726](https://archive.blender.org/developer/F9603726/image.png) size=full} Notes: * The socket only exists when "Use Count" is false. * When switching "Use Count" it would be nice to sync the collection from the socket default value and vice-versa * It is fine to find a different name for "Use Count". Just keep in mind that "Use Count" is what the old particle system uses. So for all effects this is the implementation reference. Initial UI prototype for socketless: [P1906](https://archive.blender.org/developer/P1906.txt) -- Different workarounds: * Separate the points ahead of time and use multiple `Point Intance` nodes. * Manually create duplis in the collection based on the ratio you want them to be instanced. -- Original design task: #84608

Dalai Felinto commented

2021-01-29 11:24:02 +01:00

Changed status from 'Needs Triage' to: 'Confirmed'

Dalai Felinto commented

2021-01-29 11:24:02 +01:00

Added subscriber: @dfelinto

Hadrien Brissaud commented

2021-01-29 17:32:33 +01:00

Added subscriber: @hadrien

Hadrien Brissaud commented

2021-01-29 17:32:33 +01:00

It may be good to expose individual counts as sockets, so as to drive them from the modifier interface.

Is there a design reason why the collection socket would be hidden ? a technical one ?

It may be good to expose individual counts as sockets, so as to drive them from the modifier interface. Is there a design reason why the collection socket would be hidden ? a technical one ?

Kenzie commented

2021-01-30 09:56:38 +01:00

Added subscriber: @KenzieMac130

Kenzie commented

2021-01-30 09:56:38 +01:00

I feel like instead of carrying the fixed burden of the old particle system. This might be a good use case for some sort of weighted random value selection node that can generate an attribute to be fed into the point instance node as an object index. This could also be controlled by ramps and noise this way.

I would ask around but I think it would be acceptable to users to select the object they want to instanced based on indexing its alphanumerical order (or maybe future string attributes) in the collection if they were given this kind of control.

I feel like instead of carrying the fixed burden of the old particle system. This might be a good use case for some sort of weighted random value selection node that can generate an attribute to be fed into the point instance node as an object index. This could also be controlled by ramps and noise this way. I would ask around but I think it would be acceptable to users to select the object they want to instanced based on indexing its alphanumerical order (or maybe future string attributes) in the collection if they were given this kind of control.

Ludvik Koutny commented

2021-05-19 15:19:38 +02:00

Added subscriber: @Rawalanche

Ludvik Koutny commented

2021-05-19 15:19:38 +02:00

Yes, this seems like quite poor, hard coded design. Why should just the Point Instance node have this special hard coded thing? I mean everywhere around the entire GN systems, it will be desirable to have some per object variance.

Rather than having this kind of hard coded solution, why not establish some more generic system, which would for example utilize Custom Properties every Blender object can have, and then those could be used to drive parameters of various others nodes too.

So for example, I could create "Density" custom property on my object:

And GN could then access this property, and I could use this Density custom property float value as a multiplier of the "Count" value in the Point Instance node. And these custom properties could be used in other nodes too, to control other values.

Current design is so weird. For example what if I move an object out of collection and then back into it? Will the value get lost? Or will the node keep the value? If so, will it accumulating garbage of old values associated to no longer existing objects? Will these values be stored in the node?

Yes, this seems like quite poor, hard coded design. Why should just the Point Instance node have this special hard coded thing? I mean everywhere around the entire GN systems, it will be desirable to have some per object variance. Rather than having this kind of hard coded solution, why not establish some more generic system, which would for example utilize Custom Properties every Blender object can have, and then those could be used to drive parameters of various others nodes too. So for example, I could create "Density" custom property on my object: ![image.png](https://archive.blender.org/developer/F10126600/image.png) And GN could then access this property, and I could use this Density custom property float value as a multiplier of the "Count" value in the Point Instance node. And these custom properties could be used in other nodes too, to control other values. Current design is so weird. For example what if I move an object out of collection and then back into it? Will the value get lost? Or will the node keep the value? If so, will it accumulating garbage of old values associated to no longer existing objects? Will these values be stored in the node?

Dalai Felinto commented

2021-05-19 16:32:45 +02:00

Hi @hadrien:

"Is there a design reason why the collection socket would be hidden ?"

If the collection comes from outside the node (e.g., the socket is connected to the Node Group as an input for the modifier) the node can't (shouldn't anyways) store data related to that.
Imagine a Point Instance node that is inside a NodeGroup that is used with different Collection inputs. Which objects to use for the object count?

For that reason the proposal has a clear separation when users want to specify the object count - thus all data is locally known to the node, so no sockets.

Hi @hadrien: > "Is there a design reason why the collection socket would be hidden ?" If the collection comes from outside the node (e.g., the socket is connected to the Node Group as an input for the modifier) the node can't (shouldn't anyways) store data related to that. Imagine a Point Instance node that is inside a NodeGroup that is used with different Collection inputs. Which objects to use for the object count? For that reason the proposal has a clear separation when users want to specify the object count - thus all data is locally known to the node, so no sockets.

Igino commented

2021-08-15 16:58:57 +02:00

Added subscriber: @igiornotigi

Igino commented

2021-08-15 17:20:36 +02:00

I understand the perplexities in having "hard coded design" and lack of flexibility, but as proposed it would solve situations where otherwise we would need many more nodes and changes in more inputs that disadvantage the visual feedback.
I often find myself having to use the particle system instead of GM because of this lack.
It may be limited, but what it has to do it does well.

I understand the perplexities in having "hard coded design" and lack of flexibility, but as proposed it would solve situations where otherwise we would need many more nodes and changes in more inputs that disadvantage the visual feedback. I often find myself having to use the particle system instead of GM because of this lack. It may be limited, but what it has to do it does well.

Jacques Lucke commented

2021-11-09 18:05:14 +01:00

Added subscriber: @JacquesLucke

Jacques Lucke commented

2021-11-09 18:05:14 +01:00

Changed status from 'Confirmed' to: 'Archived'

Jacques Lucke closed this issue

2021-11-09 18:05:14 +01:00

Jacques Lucke commented

2021-11-09 18:05:14 +01:00

The design of the node has changed completely.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Implement per-object distribution ratio for moss use case #85189