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.
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 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).
@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
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.
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)
Cheers!
so it would benefit the quality to add an expert in OpenCL at some point right?
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.
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:
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:
-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.
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.
I actually thought about the same thing already. I’m generally not against it, but I have some more thoughts on the topic.
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.
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.
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:
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.
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
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.
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.
what do you think to add some kind of points light suggested in RCS for better visibility?