@wevon Thanks for the description. I’m not sure what to say about it exactly yet, sry. Maybe I’ll come back to it when I thought about it a bit more. I’m still thinking about how the data and control flow is working here…
@bagylender Yes, we definitely need a really good search for nodes (and also in general) at some point. Otherwise this is not going to work. Fortunately, there are many good examples to learn from. It should not be very hard to implement it, it’s just a matter of doing it at some point.
Could you also describe what is happening in your mockup, please?
Particle Type seems more like Group or Set.
How would merging or changing particle type work in the latest design?
Will you be able to limit a Particle Type to a maximum amount of particles?
Emitters
If an emitter is linked to more than once Particle Type, will it cycle the types or emit a particle for both types?
Is there anymore thoughts about time handling?
Frames, seconds, subframes etc. Event sequencing.
Instantiation
Is this a property of the Particle Type or will there be additional nodes for this?
What differentiates Particle Types from Groups in my mind is that particles of different types can have different attributes. I think we can have groups within Particle Types.
Not sure what “merging” means in this context exactly. Changing the particle Type is essentially just killing one particle and creating a new one in the same position. There could be a simple node for that.
I don’t see why this should not be possible.
Funny, I thought about this exact problem on my way to work today ^^
I see four main options:
Don’t allow an emitter to be linked to multiple particle types. This would conflict with the general design a bit, and should be avoided if possible.
Handle it as if the emitter node is copied multiple times. So it emits particles of the different types independently.
For every emitted particle, pick one of the connected particles types using some user specified method. Getting the user interface for this right could be a bit tricky. It probably makes more sense to just use two different emitters in this case.
Emit every particle in the different particle types with the same attributes. This seems to be the most interesting option for me currently.
Internally, there are just time-steps the duration of which is measured in seconds. At the user interface level, it probably makes sense to have e.g. emission rates in particles/second.
You need to be more specific with what you mean with “event sequencing”.
Both is still possible (beside other options). I have not decided on that yet.
Event sequencing is just a thought that events could be placed on a timeline of some sorts. This was a bit of a brain dump idea.
I think for emitters connected to more than one particle type, the emitter should just have an option to emit synchronously or asynchronously. The asynchronous mode would have an option to choose particle type randomly or sequentially.
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 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.
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).
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
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?
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.
Hey @jacqueslucke I just want to remind the importance of millions of part… hahaha just joking.
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)
@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.
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…
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:
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.
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:
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.
** 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.
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.
