Specify per-object distribution ratio for moss use case #84608

New Issue

Dalai Felinto · 2021-01-11T17:20:28+01:00

Dalai Felinto commented

2021-01-11 17:20:28 +01:00

When instancing from a collection it is important to be able to specify at which ratio each object is instanced.

Existing workaround is to separate the points beforehand.

Prototype: P1906

{F9592504 size=full}

{F9603726 size=full}

When switching "Use Count" it would be nice to sync the collection from the socket default value and vice-versa.
Note that the socket is only available when Use Count is false.

When instancing from a collection it is important to be able to specify at which ratio each object is instanced. Existing workaround is to separate the points beforehand. --- Prototype: [P1906](https://archive.blender.org/developer/P1906.txt) {[F9592504](https://archive.blender.org/developer/F9592504/image.png) size=full} {[F9603726](https://archive.blender.org/developer/F9603726/image.png) size=full} * When switching "Use Count" it would be nice to sync the collection from the socket default value and vice-versa. * Note that the socket is only available when Use Count is false.

Dalai Felinto commented

2021-01-11 17:20:28 +01:00

Added subscriber: @dfelinto

Jacques Lucke commented

2021-01-18 12:21:43 +01:00

Added subscriber: @JacquesLucke

Jacques Lucke commented

2021-01-18 12:21:43 +01:00

Below are some notes on different possible solutions.

1. List all objects in the selected collection with their corresponding ratio in the node.

Very easy to use for common use cases.
Most similar to the existing approach for particle systems.
Implementation is tricky, because the collection is an input socket.
- The node does not know statically (without being executed) which collection is instanced.
- The collection might be passed in from the modifier or some higher level node group. In fact, different collections might be passed to the same Instance node in different contexts.
- When adding an object to a collection, we would somehow have to find all nodes where the collection might be used and add a new weight for the object.
- When we have a switch node, a different collection might be passed to the Instance node depending on the current frame. Do we display weights for all objects for all collections?
Offers very little flexibility. Other nodes cannot control which objects are instanced on what points.
Storing the weight per object in a node seems brittle. Do we reference all object ID data blocks so that references aren't lost? Do we reference by name?

2. Use an integer attribute on points to determine which object are instanced on them.

Requires the use of a separate node to specify weights. This makes it harder to use in the common case.
Indices of objects in a collection are not stable. So adding a new object to a collection, might make the previously prepared weights useless.
Very high flexibility.

3. Have multiple inputs and store a weight per input.

Just had this idea while writing this commeng. I like it currently, but didn't think about it for too long yet.
The idea is to store the weight not per object, but per input socket. Say the user has a set of objects that should be used for 30% of the points, and another set of objects that should be used for the other 70% of points. The user would then have to create two collections, one for each set of objects. The node offers the option to create more inputs. In this case the user has to create two collection input sockets. Then he can specify a weight for every collection input.
Similarly simple to use to compared to the first option, because it does not require a separate node.
Does not have any of the disadvantages of the first option.
An additional "Instance Group Attribute" option can be used to provide more flexibility similar to the second solution, but without its disadvantages.
- When the option is enabled, an attribute on the incoming geometry is used to determine which input is instanced on each point.
- The selection of an object from within a collection is still random and based on a seed.
The "Object/Collection" and "Whole Collection" options could be per input socket.
The implementation is not entirely trivial (because the node is dynamic), but I think there aren't any fundamental problems. If nothing else works, we just hardcode e.g. 10 input sockets that the user can use, until we have better support for dynamic nodes.
Below are some quick mockups for this solution.

Below are some notes on different possible solutions. **1. List all objects in the selected collection with their corresponding ratio in the node.** - Very easy to use for common use cases. - Most similar to the existing approach for particle systems. - Implementation is tricky, because the collection is an input socket. - The node does not know statically (without being executed) which collection is instanced. - The collection might be passed in from the modifier or some higher level node group. In fact, different collections might be passed to the same Instance node in different contexts. - When adding an object to a collection, we would somehow have to find all nodes where the collection might be used and add a new weight for the object. - When we have a switch node, a different collection might be passed to the Instance node depending on the current frame. Do we display weights for all objects for all collections? - Offers very little flexibility. Other nodes cannot control which objects are instanced on what points. - Storing the weight per object in a node seems brittle. Do we reference all object ID data blocks so that references aren't lost? Do we reference by name? **2. Use an integer attribute on points to determine which object are instanced on them.** - Requires the use of a separate node to specify weights. This makes it harder to use in the common case. - Indices of objects in a collection are not stable. So adding a new object to a collection, might make the previously prepared weights useless. - Very high flexibility. **3. Have multiple inputs and store a weight per input.** - Just had this idea while writing this commeng. I like it currently, but didn't think about it for too long yet. - The idea is to store the weight not per object, but per input socket. Say the user has a set of objects that should be used for 30% of the points, and another set of objects that should be used for the other 70% of points. The user would then have to create two collections, one for each set of objects. The node offers the option to create more inputs. In this case the user has to create two collection input sockets. Then he can specify a weight for every collection input. - Similarly simple to use to compared to the first option, because it does not require a separate node. - Does not have any of the disadvantages of the first option. - An additional "Instance Group Attribute" option can be used to provide more flexibility similar to the second solution, but without its disadvantages. - When the option is enabled, an attribute on the incoming geometry is used to determine which input is instanced on each point. - The selection of an object from within a collection is still random and based on a seed. - The "Object/Collection" and "Whole Collection" options could be per input socket. - The implementation is not entirely trivial (because the node is dynamic), but I think there aren't any fundamental problems. If nothing else works, we just hardcode e.g. 10 input sockets that the user can use, until we have better support for dynamic nodes. - Below are some quick mockups for this solution. ![image.png](https://archive.blender.org/developer/F9585176/image.png)

Dalai Felinto commented

2021-01-20 10:43:55 +01:00

@JaquesLucke the 2nd and 3rd ideas are no different than using Point Separate with a couple of Point Instance node, correct?

They would just be a convenient way for users to do that in a single node

@JaquesLucke the 2nd and 3rd ideas are no different than using Point Separate with a couple of Point Instance node, correct? They would just be a convenient way for users to do that in a single node

Jacques Lucke commented

2021-01-20 10:57:53 +01:00

Well, that is kind of true for all three options. Convience and flexibility is what we are trying to achieve, right?

Dalai Felinto commented

2021-01-20 18:47:50 +01:00

I think we should not mix external data (when the collection come from sockets) and local data (per-object count).

When not using "Use Count" it can work as it is now. With the collection that can come via a socket. However when users want to hand pick the use count within the node the collection socket disappears and the collection has to be set inside the node. This should cover the "common every-day use" use case.

I think we should not mix external data (when the collection come from sockets) and local data (per-object count). When not using "Use Count" it can work as it is now. With the collection that can come via a socket. However when users want to hand pick the use count within the node the collection socket disappears and the collection has to be set inside the node. This should cover the "common every-day use" use case.

Jacques Lucke commented

2021-01-20 19:14:15 +01:00

Yes, I'm fine with that. It obviously has significantly less flexibility, but should be good enough for now. Also, if we ever decide to change that, writing versioning code to convert that to a more flexible approach should be possible (not so much the other way arount).

Dalai Felinto commented

2021-01-22 15:59:03 +01:00

An early prototype just to prove the point: P1906

I will move this to a TODO task later, but have it filed for testing now (aka whether the design of the socket/socketless is clear).

{F9592504 size=full}

{F9592507 size=full}

When switching "Use Count" it would be nice to sync the collection from the socket default value and vice-versa

An early prototype just to prove the point: [P1906](https://archive.blender.org/developer/P1906.txt) I will move this to a TODO task later, but have it filed for testing now (aka whether the design of the socket/socketless is clear). {[F9592504](https://archive.blender.org/developer/F9592504/image.png) size=full} {[F9592507](https://archive.blender.org/developer/F9592507/image.png) size=full} When switching "Use Count" it would be nice to sync the collection from the socket default value and vice-versa

ronan ducluzeau commented

2021-01-26 12:17:14 +01:00

Added subscriber: @zeauro

ronan ducluzeau commented

2021-01-26 12:17:14 +01:00

I like the third option of a weight and type per input.
That is more powerful and more intuitive.

No more global switch forcing to use 1 object or 1 collection.
We could mix simple objects outside or inside collection with a whole collection.
That is more powerful than what we have with less buttons.

Unfortunately, the mock-ups are not great.
We could have something really simple.

Per input settings like type or Whole Collection option could be set in Input panel of sidebar.
In sidebar, there could be a button to convert a collection input into corresponding objects inputs.
And instead of settings a count equal to zero for some objects of collection, user could simply delete inputs.

Edit : Oops. I just realized that I forgot weights.
There could be slider under each input.
Order of inputs could influence reccurence of objects.

I like the third option of a weight and type per input. That is more powerful and more intuitive. No more global switch forcing to use 1 object or 1 collection. We could mix simple objects outside or inside collection with a whole collection. That is more powerful than what we have with less buttons. Unfortunately, the mock-ups are not great. We could have something really simple. ![Point_Instance_Mockup.jpg](https://archive.blender.org/developer/F9598528/Point_Instance_Mockup.jpg) Per input settings like type or Whole Collection option could be set in Input panel of sidebar. In sidebar, there could be a button to convert a collection input into corresponding objects inputs. And instead of settings a count equal to zero for some objects of collection, user could simply delete inputs. Edit : Oops. I just realized that I forgot weights. There could be slider under each input. Order of inputs could influence reccurence of objects.

Dalai Felinto commented

2021-01-29 11:18:27 +01:00

I updated the mockup to be a bit more complete.

Jacques Lucke commented

2021-02-01 12:47:00 +01:00

The proposed design can work and does solve the problem it set out to solve. Therefore I'm moving this task to done.

Dalai Felinto commented

2021-02-01 14:11:55 +01:00

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

Dalai Felinto closed this issue

2021-02-01 14:11:55 +01:00

Dalai Felinto self-assigned this 2021-02-01 14:11:55 +01:00

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

Specify per-object distribution ratio for moss use case #84608