Particle Nodes UI

An exmaple limitation I stumbled upon testing the function nodes branch right away, in the case I present in the picture I want a force to affect particles only after they collide with the plan, but there is no way to make this since the forces are just present in the particle type node, I think having the “effectors” present just in the particle type node is not a good design, a particle type is a thing, and what and when do we want something to affect particles is a different thing.

Like for example in the future having an SPH solver that we can change to a granular solver, or having a FLIP solver to affect a granular solver that drives a cloth for example, there may be A LOT of situations that having things that way is a big limitation.

4 Likes

Regarding the flow order, it could be optional, I mean, not always the user needs to specify the order, it’s just that there should be a way to do so :slight_smile:

1 Like

Is there someone who knows how these things are handled in other software?
Like in every new project if you want to get the big idea right, I think the best way is gathering as many references as you can.

2 Likes

I am of the opinion that first of all it should maintain the same level of consistency of ease of use and understanding of shader and compositing nodes …
(as much as possible of course)

1 Like

If it is indeed the case that these particle node-trees are a different kind of node-tree than the data-flow node-trees of the shaders and the compositor, then IMO there needs to be a clear visual distinction. I.E. these nodes should actually have a different appearance from the nodes in other types of node trees.

Because as it currently is, the fact that the nodes and node-trees are visually the same as in the other node editors, suggests that these node-trees will behave in the same way (ie behave like data-flow node-trees). Which then can cause confusion about how the various nodes are intended to be used.

6 Likes

I find this really important. Makes consistent with all noding workflow inside of Blender.

2 Likes

I tend to agree with this. I know nobody wants to copy other software outright, but if you’re going to design and implement a system that’s well established in other software like Houdini, you might as well take a look at how Houdini does it. Otherwise there’s a risk that Blender does things so differently that nobody will ever adopt Blender for its node tools.

Blender is gaining some serious industry traction and its new UI is designed at least in part to encourage existing 3D users of other apps to use Blender. The UI design of the Everything Nodes project should reflect that ambition, I think.

7 Likes

I also think that houdini should be a role model in this case and it’s worth taking a look at it, especially because the free version has almost all features. Taking a look at each unique node system, which sometimes goes sideways and sometimes down and especially why, is a pretty good idea I think.

I used Houdini quit a bit and wrapped my head around it. It is capable of almost everything… and of course… everything in Houdini is Nodes. Even nodes are out of nodes in some cases. (Simulation engines for example) That’s amazing.

Yet I think Jacques made the best layout/principle about how everything nodes and everything around it should work and integrate in blender, so it will on one side be as flexible as possible but on the other side also very intuitive and easy for beginners.
https://wiki.blender.org/wiki/Source/Nodes/EverythingNodes

The principle of functions is just awesome and makes it really easy to be able to implement custom modifiers, brushes, procedural effects, shaders and maybe custom simulation systems and use them in other places in blender.

Houdini does almost everything with nodes/code and so is it pretty important to understand a lot in advance to be able to just start modeling… or build a small particle setup from scratch. Jeah there are presets but it took me some month’s and a lot of try’s to get used to houdini. Also you need to have a basic understanding of vex code or python, otherwise you will hit your limit pretty fast.

But building a small mortar with three different particle types in bparticles took me only about 15 minutes after reading the instructions :star_struck:

I think everyone want’s “Blendini” and as much features from houdini as possible. (me included) But to stay intuitive and “easy” should be on high priority, even then when some things won’t be possible.

I think it’s not a matter of doing the things in the same way as Houdini or not, because there are a ton of node systems out there for particles, you have Particle Flow from 3dsmax, TyFlow from Tyson Ibele (one man band), Thinking Particles from CEBAS, Houdini, C4D, and now the new Bifrost 2.0, you may like or dislike those systems, I won’t judge them here, but I agree that looking at them is not to copy anything, all have good and bad things, but it’s good to learn from the mistakes of others.

So I think having input from some experts in the field could be very welcome, it’s not about speaking about how houdini does it, but how can we do it better or in a better way than what is already out there, this is a golden opportunity of designing a brand new system, it’s a very big opportunity, doing it right is important :slight_smile:

I invited at least one friend from the VFX industry, he has a lot of experience with VFX and Particles (you may know a tv series called “Game Of Thrones” and all it’s particles vfx work… hahaha), he handles Thinking Particles, some Houdini and other independentes softwares like Storm, so he has a great mindset to know what could be great on a node based particle workflow, of course it would be his opinion, but I think and experienced opinion could be very welcome, unfortunately inside the Blender community there is not too much people with a lot of particles experience (due to the old nature of blender particles), so this type of input could be awesome IMHO. (He also likes Blender a lot BTW… it’s not just a foreign hahaha)

6 Likes

Personally while a particles update is long over do, in order not to make it daunting to new users to learn, nodes shouldn’t be used, as if it were materials that’d be different, as with materials, node based workflows are better with the possibilities of what you can do with nodes for the material. Particles on the other hand would be better suited as a modifier like they are now, expect the new particle modifier would have other modifiers built into the particle modifier that allows the user to manipulate the particle system on a very high level while making it quick and easy. Ill make a proposal for this idea soon to share for a concept.

Not at all!

Particles can be represented as a modifier, even each tree can be it’s own modifier, right now it’s that way, but all the particles effects should heppen inside the node tree to maintain them as procedural as possible.

Nowadays particles are basic for many many reason, it’s a way of handling tons of data, like destruction position, a way of having fast physics by using standarized models, they have to mix all physics inside, the can even drive actual high resolution cloth.

For a new user, if we want to keep particles easy we have to think in a multilevel node tree, even that multilevel being just a visual thing, not like actual node groups that happens inside their own domain, but just like compressing everything inside a node, but without the problems of node groups or “programs” like in AN.

Particles are complex, we should not aim to do them “easy”, that does not mean that there shouldn’t be a way for new users to “use” particles, and that can be achieved by providing some high level node groups, or presets that can be easily manipulable, something like what we do in AN, I prepare a complex program for vegetation distribution, but my artists only see the actual distribution node with it’s settings, that allows them to actually use AN, but they don’t know AN, it’s just a high level node.

But please, don’t try to simplify something like particles, working with particles looking for a fully procedural, complex and high quality result is not an easy thing, that’s why Houdini is not “easy”, the “easy” part should be something present, but not at the particles core, more on a surface level IMHO

2 Likes

You have a point, perhaps for this new system a mix of the two, both modifier and node, to make it right, but I see your point of how it shouldn’t be “easy” as particles truly are never easy. I just think of something like X-Particles 4 when it comes to particle systems, not Houdini while it is one, just didn’t pop into my mind.

Is not that I think particles should be hard to work with, but in this case as it becomes easier it also becomes simpler and with less options.

I think everything done in the modifier front should be just a “front-end” for the real work, something that would be just a cosmetic thing to make it easier for new users, but under the hood it should be everything done inside the node tree.

What I said, some “pre-made” node groups for some specific common tasks (and the option for users to create more) could be a good solution for new users while maintaining the node environment advanced and powerful.

2 Likes

@jacqueslucke why dont you use the frame to link with a particletype? so you can group all nodes inside the frame an all are affected by that particle. The group is clear and use is similar to the new proposal that you have in your wiki, with less buttons, less prone to error, easy to read for users, better for newbies,…

something like this

sorry for the mockup, i dont have the pc now and i’m using the ipad with my hands. youcan imagine with a little changes to make more beauty or move the box for the particle id, with the frame transparent,…

but the idea could be similar, all particles could be created inside frames, and all nodes inside a frame are linked directly to that partcle system. So it is really easy for users to identificate the particle systems and understand the system

4 Likes

Sorry, maybe I’m just being stupid here, but after reading the two proposals, and playing around with the bparticles in the functions branch, and thinking about it for a day, I’m still not sure that I actually understand: what is the purpose of the “Particle Type” node?

Why is it necessary to have a specific node? In every situation I can think of where someone would want to distinguish between different particle types, it is because they want the particles to behave differently (or appear differently) which is surely something that would be described by a tree of nodes anyway.

I guess my suggestion is to remove the “Particle Type” node entirely, and instead just let the node-tree itself be the particle type. Which IMO seems like a logical extension to the 2nd UI proposal

It’s a way to define a specific particle system, then you can make it behave in many different ways, standard driven particles, after that fluid ones and after that granular ones, if you need to renference those particles from another system you use that type as reference, at least is what I have understood

but since the particle systems are created/represented by groups of nodes, essentially you are referencing a group of nodes. So why does there need to be a specific node inside this group of nodes, if all it does is define a name?

I think being forced to put nodes in groups feel quite strange. One could also just put the particle types and their connected nodes into frames or groups if wanted to achieve this kind of overview. Going into groups is even pretty easy with the tab shortcut.

I would rather try to use colors. When the different types of nodes would also be color-coded, it would increase the readability of the nodetree drastically I believe.

An option for showing the dependencies if wanted could help in some cases.

13 Likes

I’m still not sure about the groups thing because without testing and wrapping my head around I cannot think about it very well, also the effector thing is something that bothers me a lot XD I’m not sure on how to affect particles behaviour if effectors can only be applied on particle type node.

I find it a bit weird also, but I need to test it.

If we want to make our own proposal for a particle system, do we just need to make a google doc and link or it does it have to be done in a certain way, dumb question but just asking as I have an idea and want to format my proposal right for everyone to read.