Particle Nodes UI

Archive User Feedback
203

@BD3D I believe the intention is to make the hair a separate system.

204

ah nice, where can i read about that ? and why not keeping the old one for the hair then ? (in the meanwhile i suppose ?) if it’s going to be replaced it hope it’s not going to be neglected.

205

We need something as powerful as Bifrost 2.0, Autodesk had ICE and rebuilt Bifrost with it, of course it took them years to do it and now it can be used for more than just Particles,fluids
I haven’t used it yet but have seen crazy stuff from users, maybe when i learn it well i can share some ideas.
My emphasis is the foundation of Everything Nodes should be solid and easily expandable in the future

1 Like
206

Sounds much more logical to me! The “type” naming was always going to be confusing. I guess that the input socket name will also be called “system”? This should be clearer, as you will know that all relevant nodes are feeding into this one system, and that you can have various systems within the one simulation tree.

Will also make it clearer when groups are added, as I had originally mistaken the type node to be the equivalent of a group.

207

Just going to throw some more food for thought from Houdini in here:

Dynamic
Dynamic783×333 18 KB

In Houdini, a particle operator, or “Popnet” is used for when you want to deal with particles, whereas a dynamic operator, or “Dopnet” is used when dealing with simulations like rigid body, softbody etc. This makes it seem like they are distinctly different nodes for different jobs, but they are actually the same exact node. Once inside either of these nodes, they give you access to the same exact tools; the ONLY difference, other than the name, is that if you add a popnet, it automatically adds the basic particle node setup inside of it, whereas if you add a dopnet it is empty, allowing you to make whatever you want. In fact, in the picture, you may have noticed that the popnet has a slightly greyed out “DOP Network” above its name, just to let you know it is in fact the same node.

I’m not sure if this is entirely helpful, but I thought i’d share because I thought it was very interesting that Houdini makes this distinction in naming these two nodes when they are effectively the same node.

As far as my opinion goes, if we are strictly going to keep this as a particle tool,

Seems fine to me. However, in the future if we add more things, like other simulations then

Would work well, or something like it.

It just depends on how things go in the future since it is still unclear where this project will go in the future:

1 Like
208

Thanks for the feedback. If no good reason against the name change comes up until tomorrow, I’ll change it.

@Bobo_The_Imp Thanks for the info.

4 Likes
209

At first glance, “Particle System” did suggest to me something global, that would include many “Particle Types”.
Although I’m not against the change, since it seems to be consistent with how the behavior used to be before (for example, I recall the only way to have particles emit from other particles in the old system was to have several “Particle Systems”,
and have a particle instance modifier so one system could emit from the faces of another)

I think it’s a good compromise since it’ll also make the distinction clear with “Particle Groups” if they get added later, and the idea of having a global “Particle Simulation” with several Systems inside seems pretty logical.

I also like that the name “Particle System” suggests quite a bit about the function of the node, (i.e. you can have several particle systems, and each of these have their own specific physical properties, but the name still suggests to me that different systems can still interact with each other)

I also found the name “Particle Tree” interesting, although, I can’t make up my mind if I like it or not.
On one hand it is very clear in describing how to use the node, it is very easy to understand in the sense that it literally describes what is happening on the node graph. On the other it doesn’t really explain much about the function of the node (i.e. when would a user want to split some behaviors into a different tree).

I think one of the reasons why I found it interesting is that I associated with what Houdini calls “Particle Streams”.

Screenshot%20from%202019-09-11%2010-18-44
Screenshot%20from%202019-09-11%2010-18-441920×1080 425 KB

These might have some additional functionality internally, but for the end user, they are basically just Particle Groups, it’s just that they also they let you visualize the split of particles into different groups by creating a new chain, to
which different forces, etc, can be added, and then the separate chains can be merged back before going into the solver.

From the SideFX docs:

A stream is basically a group that you can split off into a separate chain and then merge back together before the solver, which is useful when trying to determine what is happening in the network. It also prevents you from having to reference the group in each node you want to affect.

https://www.sidefx.com/docs/houdini/dopparticles/streams.html
https://www.sidefx.com/docs/houdini/nodes/dop/popstream.html

This is a bit different from my current understanding of what the Particle Type Node currently does, but it is food for thought.

2 Likes
210

Aren’t you the guy who is developing the “Scatter” plugin? Nice one!

I think the new nodes will make it much easier for beginners to get into the particle stuff. At the moment the particle system is a big pile of parameters and isn’t quite intuitive, at least for me.

With the new node systems it will be more intuitive to do basic stuff and on the other hand, it will be easier to build more complex systems. Biggest advantage is, that people will be able to build complex systems with controllers, without coding. So even beginners can use such systems and only have to tweak some sliders, almost the same like your plugin.

You just load a particle/hair-modifier and you even don’t have to see the nodes that do the magic. Basically you could rebuild your own particle system, with sliders and stuff, if wanted, but much more powerful and faster.

1 Like
211

Aren’t you the guy who is developing the “Scatter” plugin? Nice one!

Yup :slight_smile:

memorizing all the node related to what you need to do isn’t either attractive to the beginner. But i get what you mean. there’s too much parameters for some simple tasks. hoperfully i’ll will be able to build all a “master” particle node by code per particle system with all the necessary parameters related for scattering vegetation and link all the parameters in the n panel like i did here.

Annotation%202019-09-13%20004251
Annotation%202019-09-13%20004251977×233 19.7 KB

okay now that’s clear. can we start another topic dedicated to the dev of this branch ?

212

I hope I’m not too late, but I’ve mentioned this note some time ago in a seperate thread and was invited to repeat it here:

Some tips for the Blender development.

If you are looking for concepts or ideas to solve complex challenges, especially in developing node based solutions for blender, then take a look into the “old” softimage XSI manual.
http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/index.html

There you 'll find solutions for complex node based topics like

I don’t want to bother you here with old stuff, but it’s always good to know what was already possible in the history.

I know there are great modern solutions like houdini, today etc., but XSI offered some solutions that are even not possible today, but very logic and artist friendly. And all this already in the years 2010-2014.

My links directs you to the user guide chapters, where the topics are explained. And I know a lot of this is not easy to port into Blender because of many technical reasons, like the different Renderer etc. But it gives you an idea how to solve or organise upcoming functions for Blender. So why invent something new, if there is already a well thought solution that can be improved maybe?

Best wishes
Chris

9 Likes
213

I don’t know what Devs take on this but to me it seems like you are saying(not just you but others too), hey look how another software did it and copy it’s solutions,this might have legal implications or something, It’s best if you had experience with that software and know it’s system well to suggest what could work well in Blender,small UX maybe justifiable but not a whole system.

2 Likes
214

yeah this is a serious topic. Devs claimed several times not to “hey we want feature x from software y”.

2 Likes
215

I don’t think Christopher is doing that.

Earlier in the thread Jacques asked about ICE and what was it, how was it, he just replied with useful information regarding that IMHO :slight_smile:

3 Likes
216

we’re going off-topic but everyone seems to link Docs of other Softwares without proper explanation & how could that benefit Blender & Jacques also said this.

Please don’t just provide screenshots or video links, but also explain how it works in a concise way,

I am sure he and others have done their own research even before the project got started and now asks for users feedback on high level UI interaction, the Project is already half way, so even Chris is deviating from the main topic which is just Particle Nodes UI and nothing else.

This thread can be used to discuss the high level particle nodes user interface. If possible, discussions about individual features should be kept separate.

217

Thank you for the feedback.

It wasn’t my intention to direct someone to “outdated” 3D software and see what happen then.

I’m creating professional CG since 1991 and support the Blender Development fund. As always, I try to support the development of great software if I can.

I think I’ve understood the advice and will read the whole thread to get up to date, what is going on here. When I see something I can help more in detail, I’ll post proposals.

Regards from germany
Chris

7 Likes
218

Hi @jacqueslucke :slight_smile:

I really like the interface and node flow of blender particle-nodes (BPN). Here is my opinion for particle-nodes (some of the points have already mentioned in the latest proposal and/or in replies but I’m including some of them to complete the picture).

I use AN nodes to illustrate my points and follows from left to right in this image:

Screenshot%20from%202019-09-15%2019-33-28
Screenshot%20from%202019-09-15%2019-33-281015×666 66.6 KB

  • Emitter Node - There five types of emitter node in the current version BPN. I think it would be nice if we have an emitter node for Curve-Object.

  • Force Node - (1) I think each force node should have falloff input along with other inputs (see Force Node in the image) with that we can control the force with any type of falloff. (2) A custom force node would be a nice addition which can allow a user to define any complex force or use other software data (e.g, scientific simulation) to define the nature of the force. (3) A Mix Forces node also required to mix different forces.

  • Falloff Node - There are three falloff nodes and possibly you may add few more in the future. (1) A custom falloff node is necessary with that we can control the falloff with any data e.g., to use particles as an effector (I have demonstrated with AN x.com) or texture/image to define the falloff. (2) An Event Falloff node can allow controlling the forces directly with events.

  • Influence Node - We can change the emission-rate, size, rotation, color, etc. of the particles (at any time or position or with an object or vertex color, etc) if we have different types of influence nodes or influence node with type option (see the Influence Node) to control different properties of the particles.

I can provide more examples (AN) for Mix Forces Node, Falloff based on texture, etc. if you want.

Thank you so much for everything :slight_smile:

4 Likes
219

Thanks for the feedback.

Emitter Nodes
Yes, we will get a curve emitter node. It’s just a matter of time.

Force Nodes
I’m actually considering removing the Falloff concept again and replacing it with something else. Other than that I agree, it should be possible to control every force with it. That’s also just a matter of time.

Falloff Nodes
Nice demo! The updated falloff concept I’m considering will make them a bit more powerful I hope. Still need to think about and test it a little bit more. Just got the idea this morning.
I’m don’t quite understand how an Event Falloff would work, please give a more specific example. Btw, you can easily create node mockups with Python in the functions branch in release/scripts/startup/nodes.

Influence Node
You can kinda do this already, although I still have ideas on how this can be done better. There is a Always Execute node and nodes like Change Size, Change Color, 


8 Likes
220

I agree Particle System will make more sense.
Particle Type makes me think to physics type (keys, newtonian, boids, fluid).

I am not sure about simulation. IMO, that term is associated to baking.
We are talking about cloth, sofbody, rigid bodies simulations.
Maybe in a close future, we will talk about a simulation for baking all those aspects as one.
And I don’t know if we will isolate those different things under different node editors or different views of same node editor or nodegroups of same tree.
I would rather Particle Nodetree instead of simulation.

221

Well, I don’t know about that, to me a sim is a sim, doesn’t matter whether cached or dynamic.

2 Likes
222

Event Falloff Node - If all forces are going to be controlled (only) by falloff then this node is relevant. It works like a constant falloff (0 or 1) because events are basically booleans e.g., suppose when particles hit a surface we want to change the strength/direction of the force or switch the forces with Mix Force Node then we need Event Falloff Node.