If a node tree reference multiple particle types it cannot shared to asset manager as a behavior but as whole participle type with specified emitters and forces
Awesome 
I just comment what I tested up to the moment.
Right now I think itâs kind of hard to control the birth and the particles in general, I saw there is an option to create a cutom emmiter with nodes, thatâs cool, will those have the same performance as the pre-built emmiters?
I tried also performance regarding some million particles, right now is way better than the old particles, thatâs cool, please donât forget about particle rendering since itâs a key part of all this.
Iâm doing a shot where I had to simulate sand and right now itâs absolutely impossible to do so in Blender for various reasons:
1.- Apart from molecular (which is a bit slow for this) we donât have any kind of granular solver, so simulation cannot be done in Blender, thatâs part particles, part physics of course, but the fact is that itâs not possible right now.
2.- Handling several million of particles in Blender is completely impossible right now, even with the new system I tried going up to 6 million dummy particles (I mean without any real simulation of course, we donât have any yet) and itâs slow, better than before but slow right now.
3.- For something like a granular simulation like sand or snow we need several millions and when I say several millions I mean 100 million particles for something like actual sand, of course no one handles 100 million particles in viewport, but for doing anything related to VFX like that we need to be able to easily work with this amount of particles, even watching just a percentage.
4.- For the same situation right now itâs impossible to render this kind of particle FX in Blender, even doing the simulation in a third party software with this capabilities (like Storm) and importing those particles to Blender through Alembic, itâs impossible to actually render that, just the particle pre-load times are too high for some million particles, around 25 minutes of preload in an empty scene with just the particles and a light.
Something like Krakatoa is able to handle this amount of particles in seconds, rendering more than 300 million particles in less than 10 to 15 seconds per frame, including pre-load times.
Of course I donât expect Cycles to be able to render particles in such amount of time, I hope we could get some kind of raster layer for particles leveraging Eevee and being correctly mixed with Cycles, or having some kind of cycles implementation, but in any case a solution has to be found for this, proper granular or even general particle FX need large amount of particles to be rendered, specially when render resolution is going up with no stop, for 720p we needed a lot less particles than for 1080p, and much more particles are needed for 4k for example, we need both, a way to manage them and a way to render them, and IMHO I think the moment to tackle this is now that the new system is being designed and a good basis can be created.
Regarding the declarative system, I may be wrong, and I wish Iâm wrong but while I understand the willing of having an artist friendly system, in general particle artists as @Alberto already stated, are not modellers or animators that do the artistic job with a direct manipulation of the âthingâ they are manipulating, particle artists need to work with the abstract, need to procedurally manipulate something with âcodeâ, no matter the kind of code, nodes or written code, but in general with code, if the system to have this code is too simple or too âartisticâ friendly, it could work for simple situations, simple scenes, a few pebbles going doing along a ramp, or a few debris detail, but as you stated a declarative system is not too different from the old Blender particle system, you could add a few modifiers to the old particle system and you have what you described.
Again, I may have missunderstood this, but proper particle systems used in general in any kind of production are not simple ones, they may have a high level with low complexity and presets for new users, with the most common tasks solved, but you can go on the inside and modify those, no matter if you look at Houdini or Thinking Particles, they are the best particle systems out there, both of them have âsimpleâ presets that can be used by any user, but none of them are simplified to those two terms of âdeclare the entityâ + âdeclare the behaviourâ, because what happens when we want to deeply modify the behaviour? are we going to be able to specify complex behaviours? what will happen when we need to work with 7 particle types at the same time?
Again, I donât understand what you tried to explain completely, so I may be totally wrong, but to me it seemed too similar to what we have today, and too simplified to support years of improvements and freedom for the particle artist, when a director wants the particle 345 in an specific location the particle artist needs to be able to achieve that, when a director wants a splash to have a specific shape, the particle artist need to be able to achieve that shape while maintaining the physical simulation, and Iâm afraid with this declarative systems things can be a bit over simplified.
Please, I know I may be wrong, but itâs what I understood from the description, I wish I am totally wrong.
2 Likes
BTW, as a particle cache format I want to propose one format that is widely used in the fx industry and AFAIK itâs open source and licensed under Apache, PRT.
I think there are no binaries in that code and everything is under APACHE license, so it should be compatible with Blender, itâs way more efficient than Alembic for handling particles since it was designed specifically for that, for example 18 million particles in Alembic was around 800Mb per frame, while in PRT it was around 250Mb.
1 Like
Yes. If necessary, they can be fully compiled at runtime.
You told that to me directly three times in different places now, no need to bring the same point over and over again. I want it to be fast as well. Declarative systems can actually be made faster, because the core framework has more freedom to optimize.
I did not forget about it, but I did not think about it too much yet. I make sure that I have all the data in efficient data structures (simple arrays), so that the rendering can be as fast as possible.
Please consider splitting up your paragraphs into multiple sentences, that makes it easier to understand what you are saying.
You seem to forget that I am a technical person as well, and of course I want to build a system that Iâd like to use as well. As mentioned, a key benefit of being declarative at the highest level is, that we actually have more flexibility. Because now it can be beginner friendly as well as powerful for people who can program. The ability to add custom behaviors with individual nodes, node groups and also code gives you a whole lot of power. I did not implement everything yet, obviously.
We can also have a Particle Type that is entirely controlled by a single behavior that has some data flow node tree that controls how the attributes change over time. Or it uses a script that changes attributes.
2 Likes
Oh, nonono, what I said is that I hoped it could be faster, what I said now is that I actually tried it finally and my findings about it, but donât worry, I wonât mention it again
Ok, understood, seems logical, just knowing that you have that in mind is enough.
Not at all, thatâs why I have a lot of confidence that you will achieve an awesome system in the end, and you know that I love AN.
I also think that many situations present in production cannot be imagined without having a wide background in particle and fx productions, and AFAIK (and with all respect, and correct me if Iâm wrong, this may sound a bit hars but i donât want it to be, itâs just that I donât know how to say it more softly) you donât have that background in fx production where a high amount of detail is required.
You are not alone, I include myself in that group up to some point too, while I have exprience I have not done any Game of Thrones shot, in fact, not many Blender users have that kind of experience specially because it was not something that could be done in Blender easily.
I have confidence in that it will be possible in the near future (2.83 maybe? hehe)
Of course I understand not everything is implemented itâs just that I understood a different thing with the declarative way, and even after your explanation Iâm not entirely sure I fully understand the final way of doing complex systems but with this:
I think you solved me biggest fear
The design implementation and execution of Softimageâs ICE Tree system was years ahead of its time, and there are probably several things that could be adapted from that system into the Particle Nodes overhaul. The basis for any successful project like this is good background research, and I think you would be hard pressed to find a more apt example of a good node system, than ICE Trees. I emphasize good, as the ICE Tree system was the killer feature for Softimage, and is what set that software package apart from the rest of the pack 5-10 years ago. At very least, Iâd at least like to see some of the ICE components considered in any future proposals, even if they arenât adopted.
1 Like
I checked a couple of videos about Softimageâs ICE, but my understanding of it is still fairly superficially.
If you know ICE better, please point me at specific concepts that I should consider.
1 Like
off-topic,
I had a stupid idea 
I donât think if it is possible, but it will be nice if there will be a node similar to Particle Condition with Condition(e.x. named split) as float that would split particles into two particle groups. In this example if set to 0.4 it should kill 40% of particles and change the rest to a direction. Maybe it can be done with an action node to move some particles from a particle type to another particle type.
p.s. it can also be done with an influence in Age Reached event.
There is no special node for that right now, but that does work already. You can control the condition per particle.
1 Like
Sure! The Node Tree is almost the same as last time, just with a couple more nodes in the âpreliminary forcesâ section
(TonR: removed image, mot allowed to share screenshots of commercial apps here)
Iâm no houdini genius, but this was a simple way I got this to work. its happens in 3 steps.
- Pop Collision Behavior
- Pop Group
- Pop Force
Pop just stands for âParticle OPerationâ, and doesnât really matter. The explanation goes like this:
- The Collision Behavior node has a set of built in responses, I chose âstopâ, which sets the particles velocity to 0 if it collides with something.
- The PopGroup node groups particles, just like vertex groups. This node usually brings everything above it into a group (even dead particles can be stored), but it also has an area where you can use an expression to group things. Essentially Iâve told it to group every particle with a velocity of 0 into a group which I called â0Velâ.
- Finally, in PopForce, I give it a force of my choice. The trick is this node allows for groups. In other words, I tell it the node to only apply this force on the group â0Velâ.
Done. Now, Iâm not sure if this is the best way in houdini to do this, I feel like maybe using a âswitchâ node could do the same, regardless maybe this could help? This might be overcomplicated for what we would plan in blender, especially with a PopGroup node with an optional expression boxâŚHowever, I feel like this could all be simplified into a general âParticle Eventâ node. These nodes might already be close to achieving this:
I put mesh collision event here, but I would love to see particle self collision as well.
1 Like
Its basically similar to actual design, but you connect each behaviour to the âtreeâ, like a list.
http://softimage.wiki.softimage.com/xsidocs/ICE_particles_OverviewofICEParticles.html
The node at the very top is a particle type name - just a string I guess. What I was trying to get at is that if the âParticle Typeâ node is inside a node group, then you would want to be able to have a way to have its name be an input, so that the node group would be reusable.
I have played around with the functions branch several times and had a query. Was wondering why the main node is called âparticle typeâ and not âparticle groupâ?
Maybe I am missing something, but are these not particle group nodes allowing several emitters to act as a group? Maybe there is a plan to group several of these âtypeâ nodes into groups?
This is more of a feature request, so Iâm not sure I should post it here. It would be great if we could get a âParticle Colorâ node.
Over here all the particles that are created from the mesh emitter are colored blue, and once their age reaches 3, they are colored green and explode. This makes it super easy to see what is happening, debugging etc. It can also be used in the final render for the desired color perhaps.
Maybe we should start a âParticle Node Ideasâ thread for this kind of stuff? What do you think?
I donât know if this already exists, but not just color node also a change material node
In general, I am quite skeptical of the new proposal. It partially defeats the purpose of having node based system at all. There are number of other 3D packages, which have successfully implemented node based particle systems without the node tree growth issues this proposal: https://wiki.blender.org/wiki/Source/Nodes/UpdatedParticleNodesUI is trying to address. Iâd rather refer to how they have done it instead of watering down proper node based workflow with tons of dropdowns and buttons.
Houdini and Blackmagic Fusion both do node based particles really well.
1 Like
Thank you very much, that is good information.
Yes, we could easily have an action that puts particles in a group, and a force only affects particles in a certain group. It might even be more obvious what is happening just by looking at the node tree.
3 Likes
This node does exist already. Itâs the Change Particle Color node (yeah, we need better names^^). To change the color directly after the particle has been emitted, you have to connect it to the âOn Birthâ output in the emitter.
2 Likes
@jacqueslucke Maybe a little bit off topic, but will you build solvers (grain, fluid, cloth etc.) from scratch?
Or does it make sense to use existing ones for inspiration. In Houdini for example, all solvers and how they work, are more or less easy to discover when diving into a popsolver node. Solvers there are build from other nodes and some vex code.
I am glad that you mention being able to create a behaviour with data from the previous timestep : I think thatâs important to have that kind of control.
Right now, is there a way to control assignment of custom attributes to particles (either on event⌠or linearly) ? eg size, color, rotation, etc. the user might want to trigger those things in arbitrary and intricate ways.
Secondly is there a way for the user to make their own events ? Say once a particle reaches a certain position in space, or when they enter a volume, etc. basically put a variable âunder watchâ and flip a switch when it reaches an arbitrary value.