Prototype for tool system for nodes for mushroom scattering #86395

New Issue

Dalai Felinto · 2021-03-08T14:54:47+01:00

Dalai Felinto commented

2021-03-08 14:54:47 +01:00

The goal of this is to have a few (brush related) tools that work for a specific node-tree.

Result, demo by @SimonThommes:

asset_tools_demo-2021-03-17_17.22.42.mp4

Files:
asset_tools_demo.zip

branch: temp-asset-tools-prototype

Original Pitch

More specifically we will have a node-tree that scatters mushrooms and the following tools:

Paint mushrooms (create initial map if needed)
Scale mushrooms (alert if no mushrooms were painted yet)
Falloff - add a circle of mushrooms, with the bigger ones in the center, and decreasing until the end of circle.

{F9881160, size=full}

The goal of this is to have a few (brush related) tools that work for a specific node-tree. --- Result, demo by @SimonThommes: [asset_tools_demo-2021-03-17_17.22.42.mp4](https://archive.blender.org/developer/F9896597/asset_tools_demo-2021-03-17_17.22.42.mp4) Files: [asset_tools_demo.zip](https://archive.blender.org/developer/F9896637/asset_tools_demo.zip) branch: `temp-asset-tools-prototype` --- Original Pitch More specifically we will have a node-tree that scatters mushrooms and the following tools: - [ ] Paint mushrooms (create initial map if needed) - [ ] Scale mushrooms (alert if no mushrooms were painted yet) - [ ] Falloff - add a circle of mushrooms, with the bigger ones in the center, and decreasing until the end of circle. --- {[F9881160](https://archive.blender.org/developer/F9881160/image.png), size=full}

Dalai Felinto commented

2021-03-08 14:54:47 +01:00

Added subscriber: @dfelinto

Dalai Felinto commented

2021-03-09 14:44:48 +01:00

The falloff could be as simple as the UI we get when pressing alt when painting.

Eyad Ahmed commented

2021-03-09 14:47:56 +01:00

Added subscriber: @IyadAhmed

Hans Goudey commented

2021-03-10 05:07:51 +01:00

Added subscriber: @HooglyBoogly

Hans Goudey commented

2021-03-10 05:07:51 +01:00

Since we've been having some disagreement about this task, Dalai asked me to list some of the downsides of this proposal. I'll reiterate that I think the disagreement is mainly about priorities-- the ability to create specific tools like this is obviously nice in some situations, it's just that (in my opinion) this task proposes to solve problems in the wrong order. Here are some of the main reasons. I hope I remembered everything we talked about.

This places too much emphasis on scripting and the python API for usability improvements that should be accessible to users not familiar with python scripting in Blender.
This expects that people will be interested in making custom tools / icons specifically for scattering one asset when we already acknowledge that even the Blender Studio is likely not interested in doing this.
The design seems a lot more like an addon than an addition to a node tree. AFAIK there is no precedence for attaching a python script to a data-block, which comes with many larger design questions:
What about when the Python API changes? Blender data is expected to be versioned so it works in newer versions. When is the script executed? What is the script allowed to do?
More generally, this task and the general approach place the solution before the problem. For example, instead of starting with the question "What are the problems users are encountering when using attributes and what are the first steps to solving them?", this task says "What can we use this tools idea for?"
Further, even simple improvements to the existing UI might provide more useful solutions to these problems, without the extra burden of implementing this. I won't get into other ideas here to focus on this task though.
Finally, implementing this without first addressing limitations of existing attribute painting in Blender would mean that these tools are too limited in the first place.
Using weight paint mode, only float attributes in the 0 to 1 range can be painted, this is limiting for some use cases. Only attributes on the point domain would be accessible, again limiting in some situations.

I tried to keep the focus on this task's design proposal. When I get the chance I'm happy to work on #86398 as an alternative.

Since we've been having some disagreement about this task, Dalai asked me to list some of the downsides of this proposal. I'll reiterate that I think the disagreement is mainly about priorities-- the ability to create specific tools like this is obviously nice in some situations, it's just that (in my opinion) this task proposes to solve problems in the wrong order. Here are some of the main reasons. I hope I remembered everything we talked about. 1. This places too much emphasis on scripting and the python API for usability improvements that should be accessible to users not familiar with python scripting in Blender. 2. This expects that people will be interested in making custom tools / icons specifically for scattering one asset when we already acknowledge that even the Blender Studio is likely not interested in doing this. 3. The design seems a lot more like an addon than an addition to a node tree. AFAIK there is no precedence for attaching a python script to a data-block, which comes with many larger design questions: **What about when the Python API changes? Blender data is expected to be versioned so it works in newer versions.** When is the script executed? What is the script allowed to do? 4. More generally, this task and the general approach place the **solution before the problem**. For example, instead of starting with the question "What are the problems users are encountering when using attributes and what are the first steps to solving them?", this task says "What can we use this tools idea for?" 5. Further, even simple improvements to the existing UI might provide more useful solutions to these problems, without the extra burden of implementing this. I won't get into other ideas here to focus on this task though. 6. Finally, implementing this without first addressing limitations of existing attribute painting in Blender would mean that these tools are too limited in the first place. **Using weight paint mode, only float attributes in the 0 to 1 range can be painted, this is limiting for some use cases.** Only attributes on the point domain would be accessible, again limiting in some situations. I tried to keep the focus on this task's design proposal. When I get the chance I'm happy to work on #86398 as an alternative.

Paul Szajner commented

2021-03-10 08:20:34 +01:00

Added subscriber: @sozap

Paul Szajner commented

2021-03-10 08:20:34 +01:00

Hope you don't mind me giving my two cents here :
I tend to agree with Hans here : this look very promising as a workflow, look like something similar to how scatter objects addon work, and or the hair particles paint mode used for asset scattering.
Probably users at some point will make some addons either for "artistic" scattering (without messing with nodes) or as a part of an asset bundle ( like grass essential shipped with some particles system presets).

Maybe it's better for a starter to look at what is missing from actual paint tools, how people use geo nodes and then maybe think about a higher level interface for all of this latter.
As an user this doesn't seems to me the most needed feature at the moment, this is something I expect to see later once the whole system is more polished. I'm looking forward some more nodes to extend GN functionality and small quality of life improvements along the way.

Maybe this also implies a bigger picture, like importing a parametric asset with the asset browser and running some scripts that presents a custom interface to modify the asset, all these seems to be good to have as a layer upon a very efficient system.

Hope you don't mind me giving my two cents here : I tend to agree with Hans here : this look very promising as a workflow, look like something similar to how scatter objects addon work, and or the hair particles paint mode used for asset scattering. Probably users at some point will make some addons either for "artistic" scattering (without messing with nodes) or as a part of an asset bundle ( like grass essential shipped with some particles system presets). Maybe it's better for a starter to look at what is missing from actual paint tools, how people use geo nodes and then maybe think about a higher level interface for all of this latter. As an user this doesn't seems to me the most needed feature at the moment, this is something I expect to see later once the whole system is more polished. I'm looking forward some more nodes to extend GN functionality and small quality of life improvements along the way. Maybe this also implies a bigger picture, like importing a parametric asset with the asset browser and running some scripts that presents a custom interface to modify the asset, all these seems to be good to have as a layer upon a very efficient system.

Jacques Lucke self-assigned this 2021-03-16 13:33:03 +01:00

Simon Thommes commented

2021-03-17 17:33:04 +01:00

Added subscriber: @SimonThommes

Simon Thommes commented

2021-03-17 17:33:04 +01:00

I made a demo file for this to show some of it's potential with the current status of geometry nodes:
asset_tools_demo-2021-03-17_17.22.42.mp4

Files:
asset_tools_demo.zip

I made a demo file for this to show some of it's potential with the current status of geometry nodes: [asset_tools_demo-2021-03-17_17.22.42.mp4](https://archive.blender.org/developer/F9896597/asset_tools_demo-2021-03-17_17.22.42.mp4) Files: [asset_tools_demo.zip](https://archive.blender.org/developer/F9896637/asset_tools_demo.zip)

Dalai Felinto commented

2021-03-22 14:56:52 +01:00

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

Dalai Felinto closed this issue

2021-03-22 14:56:52 +01:00

Dhruv Sharma commented

2021-04-03 20:32:06 +02:00

Added subscriber: @pjj

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

Prototype for tool system for nodes for mushroom scattering #86395