As Brecht pointed out, multiple types of caches exist (https://wiki.blender.org/wiki/Source/Nodes/Caching). What kind of cache would you like to use this format for?
This is great. Thanks for putting effort into the presentation of your ideas. Below is some food for thought on the individual topics.
Exposing the Solver
I actually thought about the same thing already. Iâm generally not against it, but I have some more thoughts on the topic.
- Why have a âDefault Solverâ node in every node tree? I think that simple node trees should be really simple, and a âDefault Solverâ node does not add any value in my opinion. Most users probably do not care about which solver is used if the simulation is doing what it is supposed to do. A great aspect of node systems is that complexity can be added as needed. Keeping simple things simple also makes it easier to teach the system to new people.
- A downside of having the solver on the right side is that it cannot be part of e.g. a node group that contains emitters. This might or might not be a big loss, Iâm not sure yet.
- As long as there is only one solver, I will not make the system more complicated. Iâd have to make too many assumptions about the future that Iâm not willing to make yet. Itâs still very useful to investigate different approaches already.
- Is a solver really fundamentally different to the other kinds of nodes we have on the left side? If yes, why? How would you define what a solver actually is?
Merging Particle Types
It is fairly easy to add this to the current system. However, Iâm not sure if this is really the best way to go. Maybe it is.
- What is the semantic of the âBehaviorsâ socket in the combined node when something is connected to it? Is it the same as if e.g. an Emitter is connected to every individual type?
- How often do you really need to add the exact same behavior to different particle types? Maybe you always need more control over every particle typesâ behavior in the end, so that youâd have to copy the node a couple of times anyway.
- Maybe a better solution is to have a node like âCombine Behaviorsâ that can take multiple behaviors as input and combines them into one output socket. This output is then connected to particle types. We probably need this node anyway. With this, you can have a single node that collects all the global behaviors (if you have those) and is only connected to every particle type once (instead of a link from every behavior to every particle type).
- If we would have the solver on the right, would it be possible to connect the solver to the Combined Particle Type?
Multi Input Sockets
I agree. As you might have noticed, this is already implemented to a certain degree. For a couple of days now, declarative sockets (which happen to take multiple inputs) have a diamond shape. I think this is a good enough solution for now. Maybe we will add something else in the future.
Particle Type Naming
Thanks for telling me what you think of when hearing âParticle Typeâ. Iâm fine with changing the name. You made some good suggestions. Iâll think about it a little bit more and then change it when I found an appropriate name.
One issue is that we might have two kinds of groups, that need different names:
- A group that describes a set of particles with the same set of attributes and behaviors. Every particle is in exactly one of these groups. This is the âParticle Typeâ currently.
- A group that contains a subset of all particles. Every particle can be in an arbitrary number of these groups. This kind of group has not been implemented yet, but might be necessary to e.g. activate some additional behavior on particles after some event.
I need to think a bit more about the nature of these types of groups and about how different they really are. Fortunately, this name is something that can be changed quite easily.
1 Like
The PRT format is very well suited to store large amount of particles in a âsmall as possibleâ file size with the maximum information possible inside.
This helps a lot to render in a renderfarm (local or not) as fast as possible and reducing transfer times and amount of data, also this is useful to manipulate particles outside of Blender in case is needed, or to import particles from other systems into Blender, like for example granular simulations.
An example would be to use Sequoia to deform the particles, or Real Flow for external particle simulations or white water, or Houdini in general for a variety of things, or Storm for granular complex simulations.
Now thinking only about Blender, it would be perfect to store whitewater from Mantaflow and manipulate it over the cache (something I hope it will be possible with the new system 
), other situation would be to simulate some force fields with letâs say 1000 particles on viewport while particles being calculate and saved are 10 million, in the end as smaller is the saved file per frame the faster is the save and the read process
Particle definition
Particle Builder
- Thatâs the first UI proposal (Mortar particle setup):
- Pretty much the same Setup with the new proposal:
- With color
It feels super intuitive, only strange thing, it also feels more spaghetti-like and maybe more unclear at first glance. The first proposal was more clear imo. Especially with the color-coding.
Iâm not sure how this will evolve whit much more complex node trees.
But I also think this could be cleared up with reroutes.
10 Likes
Colored noodles are such a good idea. When thereâs different kind of data being passed around, it makes it really clearer. Applying it to Cycles node wouldnât be a bad thing either imho.
4 Likes
what do you think to add some kind of points light suggested in RCS for better visibility?
While I like the color in the first UI proposal, I think I find it hard to look at in the current proposal (Though that may just be the RGB colors used). I think it highlights the strings more than the nodes, which yes can be nice for seeing connections but itâs maybe a bit much, for me anyways. If it weâre an option though that wouldnât be bad, we can already color nodes after all.
This isnât mine, but I saw a post on RCS about highlighting all the connections when a node is selected. Seeing this GIF says it better than words:
So things before the actively selected node that are connected get highlighted. That might be some food for thought, though I think that should be an option as well.
Here is the RCS post: https://blender.community/c/rightclickselect/NTcbbc/
7 Likes
Exactly! They are already in there?
Sorry, I didnât see it somehow 
2 Likes
@jacqueslucke, Thank you for such a detailed response.
Iâve been thinking about some of the issues youâve posted and Iâve tried to answer some of your questions as best as I can.
This ended up being a bit long winded so Iâve attached another document where I explain my reasoning in more detail: Link to Document
But in summary:
Why have a âDefault Solverâ node in every node tree? I think that simple node trees should be really simple, and a âDefault Solverâ node does not add any value in my opinion.
I agree, and some of the benefits that I point out of exposing the solver could be achieved through other means, so itâs a matter of exploring all possible solutions.
I do feel the consistency we gain by keeping it exposed is valuable, and the benefits of this might outweigh the downsides, I explain my reasoning in the document.
As long as there is only one solver, I will not make the system more complicated. Iâd have to make too many assumptions about the future that Iâm not willing to make yet. Itâs still very useful to investigate different approaches already.
This is entirely reasonable, and I agree that a lot of my suggestions pivot around the existence of other solvers, which is not really the case now.
Iâm not familiar enough with the system yet and some assumptions I might think are pretty safe to make might not actually be so.
Maybe a better solution is to have a node like âCombine Behaviorsâ that can take multiple behaviors as input and combines them into one output socket. This output is then connected to particle types. We probably need this node anyway. With this, you can have a single node that collects all the global behaviors (if you have those) and is only connected to every particle type once (instead of a link from every behavior to every particle type).
This sounds like a great solution, as it would basically solve all the issues Iâve posed, I might actually prefer it to merging particle types because it leaves very little room for confusion on what the node does, while the âMerge Particle Typesâ node could potentially be misleading.
1 Like
@HectorDubon @jacqueslucke
personally I would be in favour of including a âsolverâ node in the graph, for the reasons already mentioned, but also because:
-
The same design could be used more generally for other types of simulations in the future. For example, you would connect particle types to a particle solver, but also you could connect objects and forces to some kind of âphysicsâ solver, or you could connect objects and/or particle systems to a âfluidâ solver, etc. etc.
-
If particle types must be connected to a âsolverâ node in order to be calculated, then the solver node is effectively an âoutputâ node. (This is also a reason to have the solver to the right of the particle type)
1 Like
Thanks for the mockups. Introducing more colors can help but Iâm not sure if this is the right way to go to make the tree more organized. I think Iâd prefer a âCombine Behaviorsâ node, reroutes and groups to deal with complexity.
The question is also what you want to show with the color. In your mockups you color the links based on what particle type they âbelong toâ. As @Hadriscus suggests, a different possibility would be to color them based on the data/socket type.
1 Like
I agree, that does look quite useful. I might come back to that when I work on these kinds of things.
Exposing the Solver
Thanks for the additional arguments. I think this discussion can be postponed a bit. When we have more than one solver, we can still insert a âDefault Solverâ node in existing node trees in versioning code. Until then, I prefer not to add things that are not really necessary.
I would say the solver is indeed different from other nodes.
While this is kind of correct, things can also be interpreted differently. Since the use of a different solver influences how particles behave, the solver itself could be seen as a behavior.
For example, the document states the Particle Type contains an integrator, whose role (calculating the change in positions and velocities) would be something that I would (perhaps naively) initially attribute to the solver.
That is correct. In fact I called this thing solver at first, but it seems like the solver is more the entire thing that also evaluates events etc. The integrators job is just to compute the next particle states if there are no events.
Merging Particle Types and Multi Input Sockets
Good, then we do have the same opinion on that subject.
Particle Type Naming
With âParticle Groupsâ you could for example do this.
An event could add and remove particles from groups and activate/deactivate certain behaviors by that.
5 Likes
Iâm thinking about renaming âParticle Typeâ to âParticle Systemâ. Previously, I did not do that because to me the âParticle Systemâ is the entire thing that contains possibly multiple particle types. This change has the following implications:
- The term âParticle Typeâ will be gone for now. Maybe we need it later again with some other meaning.
- The entire thing cannot be called âParticle Systemâ anymore, otherwise this term would have two different meanings which can be confusing. I suggest we call the entire thing a âParticle Simulationâ or just âSimulationâ. So a Particle Simulation can then have multiple Particle Systems.
- The term âParticle Systemâ has been used with almost the same meaning in Blender before, so there is less confusion because of new terminology.
- There is less confusion when we have âParticle Groupsâ at some point compared to when we would be using âSetâ, âCollectionâ or âBundleâ instead of âParticle Typeâ.
What do you think?
9 Likes
How about this: particle system is an individual branch, and particly/dynamics integrator is the whole thing integrating the systems? I guess calling it a simulation is more obvious to most people though, so eithe works really, IMO.
Hi @jacqueslucke Why not rename âParticle Typeâ to âParticle Treeâ and leave âParticle Systemâ to the whole System, why I have Chosen this name? for this reasons:
- Every âParticle Typeâ with its nodes resembles like a tree.
- Every âParticle Typeâ resides on the root of its network.
- The System can have Multiple âParticle Typeâ like trees.
Cheers 
1 Like
@megalomaniak Yes, calling the entire thing an integrator is probably too complex and might even be wrong, because we might use different smaller integrators within the entire system.
@elbox01 Iâm not too convinced by the name âParticle Treeâ yet, but maybe I have to let the idea sink in a bit more.
2 Likes
i have a question:
what about simple particles set ups ?
scattering grass/forest/fur/hair donât need all this complexity at allâŚ
Will the average person that use the particles system only for creating hair/vegetation be forced to use this complex new system or the old system will still be avaible for them ?
sorry if i miss anything. I just hope that you guys think about eveyone here. only a minority of peopleâs use particles for animation/explosion/motion graphics ect⌠and i donât see a lot of posts for hair/vegetation related scattering.
1 Like