I was actually in approval of your previous post -not sure if “acute” actually means what I thought it meant… totally agree that scattering is basically particle emission without the temporal factor, I mean you said it well already.
I also understand that instancing is no longer possible with a simulation on top, but that doesn’t mean we shouldn’t be able to do it.
Anyway I was trying to express that generally, there should be interoperability between whatever “data contexts” we end up having. So, particle simulations should be send-able to a “geometry context” where the user can spawn edges or polygons between particles, etc. OR just let this happen within the already existing simulation node tree, and make it a general purpose “geometry context”.
Another question came to mind recently : is there a way to spawn particles onto objects that are themselves instanced on particles ?
Imagine one particle system as a bunch of cacti in a desert (this example with cacti, you surely reckon, is close to my heart), and you want to procedurally distribute buds (or flowers) on these cacti -let’s say on any surface point of them. Furthermore, let’s say these cacti are procedurally generated so that every instance is unique -or let’s say we have five variations of them, five different cacti that are generated through a nice and tidy “geometry node tree”. And let’s say this node tree defines (through geometry attributes) a few hotspots where buds or flowers are more likely to appear… can we go and create a particle system that scatters these procedural cacti, then scatters buds and flowers on top of them, using that geometry attribute we created earlier (and that’s part of the original cacti procedural model) ?
That’s the kind of workflow I would like to see explained. Have these questions been explored ? @jacqueslucke
I know this is in fairly early development, but thought I would give my 2 cents on the multiple inputs part. It would make sense from an user experience standpoint to show that it accepts multiple, for everywhere else in Blender there is only one input. Here is a quick mockup: https://i.imgur.com/cYrGrKW.gif
Isn’t this what the “diamond” socket shape is supposed to convey ? The argument from Jacques, if I remember correctly, was that forces are unordered, all acting on particles at once, which is why he chose to use a single socket to bind them all (in darkness) instead of a list of sockets.
That being said, I like your mockup. Dynamic inputs like this have been missing from Blender.
Looks nice to me, this is more or less how Houdini has been communicating it for a couple versions (not posting a screenshot!). However the socket shape is just a symbol, something to learn only once, so I’m not super worried about it being this or that shape. In fact rather confident users will discover it, or learn about it in the fantastic manual that will undoubtedly have a chapter about it.
Now that I think about it, wasn’t there a sort of dynamic input list for events in early builds ? Or am I dreaming this ?
You should embed the gif right into the post, rather than just a link, so it attracts more eyes to your great proposal I will do it for you just in case, because this is a great idea so it should get the attention in deserves
The only issue I see here is that currently, Blender allows you to reconnect multiple wires going into the same pin at once, so for example if you have 5 wires going from UV Coords node to 5 different textures, and want to reconnect all 5 of them to another UV node, you can just grab that pin at the old UV node and drag all of them at once to the new one. Your proposal would make that more difficult.
The one by @ManuelGrad , while not looking as pretty, would maintain that ability. So if you wanted to reconnect multiple emitters into different simulation node, you could do that easily. At the same time, not sure how often would that kind of scenario happen…
Why not to give the node a collapsed / not collapsed state to the sockets, so you may see one socket per connection, or one socket with multiple connections, leaving it to the user choice, some times many sockets it’s easier to understand the tree, some times one socket alone makes it easier to modify the tree.
I think it might be a good idea, for example if you want to modify the 3 values at the same time, or just one of them.
For example, the first input “Translate” could receive something like
Translate = [1, 2, 3]
and if it is expanded you can modify only one of the 3 values without modifying the others or 2 or all.
would be equivalent to
Translate.x = 1
or
Translate.y = 2
Nope, the input addition could behave in the same way it works in node groups, just link a new node to the first one and a new socket will be added, the arrow [►] pointing left or down could be a better solution, maybe @jacqueslucke has something already planned for this.
I personally don’t see a problem with sockets expecting multiple inputs. It’s just something to get used to. We don’t question that a socket can have multiple outgoing connections either.
Some sockets only allow for one input wheres others allow for multiple inputs. There needs to be a distinction imo. Trail and error method to find out wich ones support multiple inputs is not a nice UX and quite annoying.
Generally, you don’t want something as simple as plugging and unplugging node pins to have more than one step
Multiple connections per output pin are already a thing in Blender, just multiple connections per input are. What’s being talked about here is just the visual indication, to make people aware one pin can handle multiple inputs. But there’s no need to introduce additional complication by changing how the inputs actually work.
In fact, even if there’s no visual indication, it will still be relatively fine, since there is no visual indication for multi-output pins, yet most people got used to that.
Currently, having one input per input pin allows the user to drag the connection out (with the mouse) and place it into another pin.
If you have a dozen connections going into one pin, and you want to place one of them into another pin, how would you do it without nuking the connection and figuring out which output to drag from?