Particle Nodes UI

Not sure how the same concept could be applied.

The difference is that the the last option produces particles that lie directly on top of each other. In the other one, there is not necessarily a correlation between the spawned particle positions.

What I mean is when deciding which particle type to spawn, look up the ‘mix particle’ node and if the factor is 0.5 then choose randomly with equal probability between the two (or three, or more, with the multiple-input sockets you made), and if the factor input is connected to something, evaluate that thing just like you do with any other node tree.
Say you want to have alternating particle types along the length of your timeline :slight_smile: begin by normalizing the scene frame range, feed it into a b&w color ramp, and finally into the mix particle node. There you have your alternating particles.

@jacqueslucke

Ah, I understand now.
In my opinion, the last option is the better option. Because the earlier option (where it is handled as though the emitter is copied multiple times) would introduce a random element that could not be controlled by the artist.

@Hadriscus ah, I think I know what you mean. Where would these mix nodes go, how would they look like? I think this does not make a lot of sense in this context. I’d rather find ways to do the same thing differently (e.g. using an action that is executed whenever a new particle is born).

@alisealy I agree.

First of all, my inspirations come from Unreal Engine 4 blueprint system (https://wiki.unrealengine.com/Blueprint_Fundamentals), in my opinion, a very powerful node base system with easy to understand what is going on. Colors I choose in my example are just for better clarification and visualization (developer like you and the whole community should agree about colors for each type of nodes and connectors).

In my opinion, every node tree should be a particle instance for itself that can be build up to get any kind of possibilities.

We should have a system that gives us options to have variables with all kind of possibilities. E.g. variable for integer/float number that enables a user to change this variable in panel/menu. This way when we have a big node tree we can easily change a few variables and get a different result. Variable/array variable for particle/object emitter mesh that enables a user to quickly change mesh in the panel, etc.

With this system, we should parametrize variables. In other words, use the same node setup with different variable settings (E.g. We could have one node tree for the explosion – Main node tree. Make an instance of this node tree and call it Explosion_01, change variables for mesh, duration, speed, object emitter, etc. and get different explosion in a few seconds.)

As a new user, I can’t upload multiple images, so I improvised.

1) Dot icon except for single input/output, while square icon except for multiple lists of inputs (array variables). Right-click on one can give setting for changing the type of input/output parameter.
White tick line represents the flow of events, those lines connect nodes that do something, like classes, functions, etc.

2) The starting point of Execution Events (red colors) – Initiator of the whole node tree. On Every Frame activate node tree every frame, there could and should be few other events, e.g. every 10th frames, or every other, on collision, at the end of something previous, driver driven events, in future with interactive mode we can have even key pressed events, etc.

3) Object Emitter, grid emitter, or any kind of emitter, actuator or class (purple) – In this example, we have object emitter with few parameters. Object parameter expects some kind of object/mesh or multiple objects (list/array of objects).

Particle input expects mesh/object or meshes/objects if we talk about the list. Rate, velocity, Size, etc. except the float variable. I’m not sure about SpawnedParticle, but in my opinion, we should get information about particle that is actually spawned, this way we could retain information about age, size, speed, etc. and use later for anything else. This type of node could have seed, for RNG, or something like that.

4) Data variable (dark blue) - that we use to create something unique, particularly if we parametrize it. In this case, we see 2 types of data variable- single and list of data/objects. That could be any type of data - object, mesh, material, texture, etc.

5) Number variable (e.g. green for integer, purple for float) – integer, float, also could be parametrized and use in node tree instance outside of node tree.

6) Rand function for float, integer, even list of variables (probably should be light blue like Explode particle (function type node) or dark green (math node) ) – self explainable function node. With 2 inputs for float variable number.

7) Flow nodes like sequencer, branch, delay (white) – in this case,

I don’t use a sequencer and just bypass it (there is for show purpose – should be used for organization, when sequence 1 (or any other custom name) finish, start sequence 2, then sequence 3, etc.)

The branch is actually IF statement with a condition (red color = bool variable).

Delay could have few more options, like time delay, frame delay, etc. (should have a dot for input variable Amount, like any other input value)

8) Mathematical nodes (dark green) – in this example we have compared node, could be a few different nodes like greater, less, or equal. Compare input with some number (should have a dot for input variable like any other input value).

This category includes min, max, multiply, divide, add, subtract, etc.

9) Function nodes (light blue) – In this example, we have Explode Particle, “LifeSpan” (Particle info), and Kill Particle.

Explode Particle have input Particle (in this case array data, could be single data if we choose), and except what particle should explode.
Particle info node should give us properties/parameters of particles like Age, size, speed, orientation, etc.

Kill Particle just destroy particle and except for us to give what exact particle. (In this example we have exploded particle, we could have something else, fracture mesh, destroy an object – for this we could ask something like this: If particle XXX collide with object xxx then destroy it).

I hope this gives you a little bit sense of what is going on in my mockup.no

2 Likes

It’s a totally different approach of a node system, but I just want to leave this here.

I’m not sure if this concept has any downsides if complexity is wanted.
It looks like there are nodes inside nodes, but it’s pretty easy to read I think.
On the other hand, a lot of parameters are inside the nodes.

Maybe for the future, a new type of node group could be added,
which shows it’s content in a list, so similar readability could be achieved if wanted.

@jacqueslucke another question, are there plans to use OpenCL in particle solvers, and would it bring any downsides?

Thanks for the link, checking…

We definitely want to give more functionality to groups at some point. How they will change exactly is still being worked out. I think my current proposal could work great with lists in groups, because particle types just have a list of behaviors.

I currently do not plan to use OpenCL in the near future because (1) I don’t know it well enough to build a system around it, (2) it would probably take quite a bit longer to implement things on the gpu (also for the first reason) and (3) some things might just not be possible on a GPU due to the model of computation. I try not to create major roadblocks that would make it hard to move stuff to the gpu later on.

4 Likes

Hey @jacqueslucke I just want to remind the importance of millions of part… hahaha just joking. :rofl:

I wanted to ask if you saw the PRT link I gave you and what is your opinion about this file format for particle caches (if you had the opportunity to check it) :smile:

Cheers!

so it would benefit the quality to add an expert in OpenCL at some point right?

1 Like

Last commit was 4 year’s ago, is there a maintainer?

@JuanGea I checked it a little bit. It does not seem to be a big thing, maybe I’m missing something. We had a couple of discussions about caching here as well, but did not come up with a perfect solution yet.

@Pipeliner Sure. Personally, I do not think that this is very important right now, because we are still working out more basic things. Nevertheless, we have people here that know OpenCL very well, so that is not an issue.

3 Likes

AFAIK the owner and maintainer is ThinkBox, the actual company behind Krakatoa.

But I think it has no changes because it is what it is, a super rock solid particle cache format that converted in a industry standard due to it’s high quality, speed and low size, it’s supported by all the major VFX plugins and softwares out there, and it basically support you to write whatever you want to it.

IMHO it’s hard to find any particle cache format that is better than this one, ask any VFX particle related artist and he will know this format for sure, ideal to store and render several millions of particles.

@jacqueslucke maybe, and it’s just a cold idea, there is no perfect solution, I mean, having two or three formats with different strengths and different cons could be better than having to try to manage it all with one only format.

There could be a performance blender format, and a “standard” format that could ease interoperability, not just for exporting particles from blender to other packages but rather the other way around, to import them, like what Tangent did with OpenVDB to be able to import Houdini smoke sims.

The only thing I know right now is that my experience working with Alembic and particles hasn’t been good.

It was not because of the importer (that it has been a partially a headache, but I know particle support is limited right now) but because of the format itself, storing several million particles took up to 1Gb per frame, while in PRT it tool less than 250Mb (always aprox. numbers), that made a huge difference to work with those particles.

With that said, I’m curious to know what options do you have in mind for caching, when you are ready to show us some of that I’ll be all ears… or eyes… :slight_smile:

1 Like

First of all, Massive props to @jacqueslucke for all the work on the new particle system, in such a short span of time it’s taken shape and evolved into a very promising system.

This latest proposal seems like a big improvement, and definitely solves many of the previous issues, particularly having free floating particle types disconnected from the rest of the network.

I have a few additions that I think could be useful. I give more details for my reasoning in the attached document: Link to Document

but it boils down to these 3 things:

  1. Exposing the Solver:
    This makes the graph clearer, makes it explicit which Particle Types get solved together or separately, and also gives a spot to configure any parameters of the solver. It also makes the solver the end of the chain, which seems more natural, since the solver is the last step in the sequence of operations that takes place.

  1. Merging Particle Types:
    In reality, some of the benefits of exposing the solver are also solved by having the ability to Merge Particle Types (possibly thorough a dedicated merge node), so it’s definitely not a hard requirement to set the solver as the end of the chain if there’s good arguments against it.
    (although I still having the solver exposed is an overall benefit)

Being able to merge Particle Types not only makes it easier to have several particle types use the same solver, but also to add global forces, like gravity, to multiple Particle Types at once:

  1. UI distinction between single-input and multi-input sockets:

-having a slightly different graphic for input sockets on nodes that take multiple inputs vs ones that only take a single input, can go along way in preventing user confusion. Houdini has what I think is a subtle yet effective implementation of this. Single input sockets use a dot as usual, but multi input sockets have a little bar.

9

** In the document, I also explain why I think the name Particle Type could be a bit misleading, but this is mostly semantics and not really much of a priority.

7 Likes

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 :wink: ), 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
:grin:

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?

connection%20point