2020-07-28 - Particle Nodes Status

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”.

1 Like

Yep, I know you were. I was just adding some sentences to clarify :slight_smile: I don’t disagree at all.

2 Likes

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

5 Likes

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

16 Likes

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.

2 Likes

In my opinion a diomond shape doesnt really visually stand out nor does it convey that there can be multiple inputs.

What about something like this? (mock-up just to show difference between single and multiple input points)
multipleinput

19 Likes

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 ?

2 Likes

You should embed the gif right into the post, rather than just a link, so it attracts more eyes to your great proposal :wink: I will do it for you just in case, because this is a great idea so it should get the attention in deserves :slight_smile:

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…

6 Likes

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.

1 Like

@JuanGea Something like this?
Captura de pantalla_2020-08-14_21-04-56

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

etc…

1 Like

Mmmm not exactly, since in that situation the input is predefined (a Vector3) and what we talk about is about an arbitrary amount of inputs.

But the [+] [-] idea could work, something similar, not that exactly :slight_smile:

for expand and collapse [►] and [+] for add inputs?..

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.

1 Like

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.

2 Likes

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.

4 Likes

how about something like this?

9 Likes

Generally, you don’t want something as simple as plugging and unplugging node pins to have more than one step :slight_smile:

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.

3 Likes

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?

5 Likes

Just have all the connections come along when dragging to another input socket, I guess.

Why not using the same concept as “add node”? Even though It’s kind of a trade off between consistency and ease of use, to visibility.