Particle Nodes UI

[So3Datel]

My expectations for Particle Nodes and Everything nodes it is that they will be understandable to me as an artist, and only as an artist, because I am not a mathematician or a programmer.
For example, now in the node editor you can make a procedural shader for snake skins, jeans or LCD display. Can I make the same procedural shaders? No, because those shaders are pure math, and I just don’t understand how this is done.

ps. For people who need a special explanation. I’m talking about something like “usability” and “user friendly”.

[Alberto]

The system of nodes only gives the user the ability to use more functions and tools, and for that one must know how to use them, any other expectation is false.

If someone wants a custom shader that does exactly what he wants he can’t expect the blender foundation to give him a node that does it all alone. He should do it himself, ask a friend, get it online or pay for someone else to do it for him.

Just like people who want to model 3D would like not to know what a vertex is, but if you want to use blender must use them.

[nokipaike]

He should do it himself, ask a friend, get it online or pay for someone else to do it for him.

or maybe create custom basic presets that can be mixed together … this would be something in between that made everyone’s life.

[So3Datel]

The system of nodes only gives the user the ability to use more functions and tools, and for that one must know how to use them, any other expectation is false.

Yes, that’s why Blender is so popular all over the world for creating procedural textures, shaders and geometry … in the whole industry, in the whole universe …
I came here to make my user feedback, not argue.

[Alberto]

A preset for jeans? a preset for LCD? a preset for CRT? a preset for every thing in the world?

It won’t happen.

[Alberto]

Yes, that’s why Blender is so popular all over the world for creating procedural textures, shaders and geometry … in the whole industry, in the whole universe …
I came here to make my user feedback, not argue.

The most popular software to create procedurals materials in the world is substance designer.

They don’t give a shit with the program, only a few examples to learn how to do the things. If you want to use it you need to learn, obtain the materials from community or pay for it to somebody.

[nokipaike]

@Alberto

A preset for jeans? a preset for LCD? a preset for CRT? a preset for every thing in the world?

It won’t happen.

don’t be so extreme.
offer the possibility to create presets add the asset manager that will come …
and the world will bury you of presets.

[Alberto]

That’s exactly what I’m saying about “get it online”

You can create presets right now, you have material libraries addons in cycles and we’re not buried in community presets.

And substance designer has exactly that, a preset system, official, in the cloud, maintained by the creators of the program… and they’re not buried in presets either. And that they have a lot, but in the end you never find what you are looking for and you must create it yourself. You can use an example, but not much more.

But we return to the essentials of the question. No program gives all the presets of the world, neither blender nor the most used in the world. Let’s stop using cheap fallacies. If somebody want to use nodes will need to learn to use nodes or obtain nodes from other people, paying or not.

[nokipaike]

In any case, a preset of basic examples is still useful and necessary, more than anything I was referring to this …
in the same way as the scripts templates

[Pipeliner]

I agree, templates and examples help a lot to learn how something works. But I think this will becreated by the community.

[Ansraer]

Blender could come with a default particle node group that allows selecting an emmiter, particle shape, lifetime, gravity. That shouldn’t be too hard to setup and/or maintain and would allow users to do simple stuff like creating rain or snow without having to really get into how the entire system works.

Overall I think the second proposal (Source/Nodes/UpdatedParticleNodesUI2 - Blender Developer Wiki) is definitely a step in the right direction. However, I really dislike how the Event and Execute stuff works. imo the logic should flow from left to right and not from the right to the left.

Additionally, I would also like to see an output on the Particle Type/Output node. Or to have a node that allows me to “import” an entire particle system based on its name with a dropdown menu.
This would allow me to simply plug an entire particle system into another system if I want them to interact with each other.

And thank you for mentioning Houdini Bobo_The_Imp, that’s definitely one of the best node based systems out there right now. Would love it if Blender’s workflow was a bit more like it. Your slimey green sphere with pimples was an excellent example of why it’s so powerful.

[HectorDubon]

@jacqueslucke , I’ve been testing some of the newest additions, they are proving really useful, awesome work!

In particular, I’m very pleased with the Combine Influences node, it really helps maintain the graph clean as setups start getting more complex.

I do, however, have a bit of a concern with respect to the user friendliness of this node, since there’s ways of using it that might seem very intuitive to new users, but are not quite correct, and can lead to a very different behavior in the simulation from what the user is expecting.

For example, in the image below, a user could have a set of global forces they want to apply to all particles, In this case a set of nodes that try to emulate collision behavior (just an example, I would assume collision response would be probably handled by the solver), but could want to apply an additional force to only one of their emitters:

They could intuitively try to use the combine influences node like in the image above, since it visually creates a separation between the different node chains in the graph.

However, as the new force that was supposed to be independent is still wired to the same particle system as all the others, all the other emitters also receive that force.
The correct way to do this would be to split the emitter that is going to receive the separate force into its own particle system:

This makes sense in hindsight, and its probably something that users can pick up on quickly, but it does feel like a potential point of confusion for new users, since there’s nothing on screen that hints that it’s set up incorrectly.

Its not a solution that I actually like, since it seems less clean, but one of the only things that comes to my mind to solve this could be splitting the emitters from the behaviors, like one of the earlier UI proposals:

This makes it pretty clear that you cannot “apply” a Force to an emitter, just to a Particle System, which is not quite so evident in the current state of affairs.
I’d be happy to hear what other solutions anyone else has for this, or if you even think that this is a problem that needs to be addressed.

[jacqueslucke]

However, I really dislike how the Event and Execute stuff works. imo the logic should flow from left to right and not from the right to the left.

I think that doing this logic left to right is more intuitive as well (I even mentioned that before in this thread). However, there were some issues with this approach. It took me a while to change my mind to use the current approach, but now I think it works quite well. It’s actually the same solution that is used in Softimage ICE.

Additionally, I would also like to see an output on the Particle Type/Output node. Or to have a node that allows me to “import” an entire particle system based on its name with a dropdown menu.
This would allow me to simply plug an entire particle system into another system if I want them to interact with each other.

You really have to give me some more details on what you actually want to do/how it should look like in your opinion. I don’t fully understand what you mean based on this description.

I would assume collision response would be probably handled by the solver

That is correct.

They could intuitively try to use the combine influences node like in the image above, since it visually creates a separation between the different node chains in the graph.

However, as the new force that was supposed to be independent is still wired to the same particle system as all the others, all the other emitters also receive that force.

I understand what you mean. I’m not a big fan of your first proposed solution either, because it might conflict with other use cases. The same is true for your second proposed solution. Otherwise it might get confusing what an emitter actually is. E.g. are the Trail and Explode nodes considered emitters? They are multiple things at the same time.

I want to address this use case separately. Actually, I implemented a solution for this on Sunday and Monday: Particle Groups. The nice thing about this solution is that it is more generic and therefore more flexible.

This does not solve the issue that new users could have a wrong understanding of how the Combine Influences node works, but I guess this is something that just has to be learned… Maybe a different name or layout could help as well.

In this screenshot you can also see that I removed the Falloff inputs again, as mentioned some days ago. This makes it easier to give the user more control while not introducing a new concept (falloffs), that has to be learned. They will be replaced by more “particle function inputs”, like the Particle Info or Is In Group node.

[DanielPaul]

So I tried to use the new “Combine Influences” node to rebuild the mortar particle tree.

It’s much more clear now, if frames and the combine nodes are used.
When these single frames could be grouped one day, and the parameters could be promoted, it would clear it up even more. This could also be packed in one single group with the mesh for the emitter, Turbulent force and rate promoted. Would be super intuitive to use for beginners.

I think it would be a really neat feature to give the frames a random color, but that’s off-topic.

Well done! @jacqueslucke

[Hadriscus]

I’m not sure I understand the need for a ‘combine influences’ node when the ‘particle system’ nodes can be connected to several influences already ?

[DanielPaul]

I’m not sure I understand the need for a ‘combine influences’ node when the ‘particle system’ nodes can be connected to several influences already ?

Only reason I see for it is clarity… but that is pretty important.
Without them the tree above would look like this.

[omgold]

I’m not sure whether I’m sidetracking here, but what I am thinking about in relation to this topic is hair particles. In particular how hair children are handled. The fact that people often create several particle systems to get nice hair indicates that it would make sense to also be handled by nodes.

Is this a separate topic, or this it also belong here?

[Hadriscus]

Ah yes, fair enough !

Thinking of it some more, I can see why it can be so much clearer to visually group influences before piping them into particle systems.

@jacqueslucke totally unrelated question, are you planning on keeping the existing force objects, or is it just going to be nodes ? Some forces (turbulences, wind…) have a placement in space that matters (unlike gravity which acts globally) so if it’s just nodes there probably should be a straightforward, visual way of placing their origin and zone of influence… or simply be able to connect any force to an arbitrary object transform ?

[jacqueslucke]

In particular how hair children are handled.

We want to separate the hair and particle system. Therefore, the topic of hair children should not be discussed here.

are you planning on keeping the existing force objects

I definitely want to have gizmos in the viewport for various forces. Whether we will use the old force fields or do it differently still has to be determined. A simple solution would be to have a node that lets you select a force field object (or a collection of force field objects) and it outputs the influence of it. I don’t know exactly how the force fields are implemented in Blender right now, but that should be relatively easy to do.

What I do not want is that all the force field objects affect all simulations by default. I think it is good when the user has to be a little more specific about which force fields affect which simulations. That helps with keeping the scene organized and is probably faster as well.

[Hadriscus]

Great ! Current particle system can be restricted to a subset (collection) of force fields already. I agree that inclusion of force fields should be ‘opt-in’ (ie none unless specified).