Thanks for the annotated screenshot, that is helpful. Nevertheless, I do not fully grasp the way this works. Maybe you can show how “a force only affects particles after they collide with a mesh” would work here?
I’m not sure how to read actions in this screenshot. Are they executed from the left to the right, or the other way around? Furthermore, I think it is important that no action can come after a Kill Particle node by design. Another issue is that actions do not have to be a single chain. When an action has multiple ends, it is unclear how that would be connected to the Particle Type node.
Thanks for this proposal. Unfortunately, it has a similar issue with action chains as the previous one. Imo, actions really have to grow to the right, otherwise they don’t make too much sense. Also this is much more common in all kinds of control flow graphs.
To me it is not clear how this proposal would work with events like “Close to particle of other particle type”. Would you connect the particle type node directly to the event node then?
I thought about a similar thing: instead of having add effectors/events etc., there would just be an Add Behavior node that unifies things a bit more.
Thanks for trying the system and thinking about how nodes could be reorganized. What is the “node” at the very top on the second image?
I still think it would be good to unify emitters/effectors/actions here. Otherwise node groups would need more outputs than absolutely necessary.
I also do not like that you need such long links for fairly small node trees already. We should try to avoid that and make the relations more clear in other ways.
I do like that you roughly discuss the advantages as well as disadvantages of your solution. I do not see that very often…
1 Like
I agree, I don’t really see the point of having an output node. To me, it does not make much sense to have one in this kind of system. In pure data flow graphs (like all the other node systems in Blender and also modifiers in the future), you need an output node for sure. I’m not exactly sure why many see it as such an important thing, maybe I’m missing something.
1 Like
Thanks for all the different proposals, that was quite interesting to read already.
Two notes for people who want to continue creating proposals:
- Remember that an Action should really grow to the right (for readability) and that it might have multiple last nodes.
- Take the issues into account that I presented in the updated proposal. Most solutions just take the current implementation in the functions branch as base (which is understandable). Maybe I should have been more clear in the first post, that this is actually outdated already.
I feel like I should mention a high level design goal that I have in mind. It might be a bit subjective, but I’ll try to explain.
I think the most intuitive way to build a particle system (or any simulation for that matter) is to declare Entities and Behaviors. In the current case an Entity is a Particle Type (not a single particle). Behaviors would be the emitters, forces, events, …
Building a new particle simulation then becomes:
- Declaring the entities (particle types).
- Declaring the behaviors (a behaviors can influence one or multiple entities).
A completely different approach would be to put artists in the position of a programmer. Then there would be an input and an output node. The artists task would then be to build the function that takes the old state and turns it into the new state. This would result in a very flexible system as well. Furthermore, it would probably even be much easier to implement for me. Unfortunately, it is also much less artist friendly.
A declarative system like the one I am proposing has some real benefits:
- It lets artists work at an abstraction level they are more comfortable with: Just add and tweak individual behaviors until it looks right.
- We could even have a “custom behavior” that could wrap the more programmatic approach mentioned above. Doing it the other way around would be much more difficult.
A downside of having this declarative system at the highest level is, that it can be possible to add conflicting behaviors. It is a matter of good error handling to solve that problem.
p.s. You might notice that to achieve this design goal we do not actually need node trees. A simple list of entities + a list of behaviors in a panel can work as well. However, a node system allows us to build more complex behaviors more easily.
6 Likes
Its important to remember that VFX artist are not simplr artist, also a programmer, and need a powerful system, not only friendly
1 Like
That is true. However, I believe that it is easier to add more flexibility/programmability to a declarative system than to add more declarative components to a procedural system.
In my view, the limitation of your second proposal is that it reduce reusability of behaviors. For example when we create an event with some actions, that node tree is only for a specific particle type. So If we need several particle types, with the same behavior to explode when reached an age, we need to copy paste the same node tree several times. The ideal scenario would be to define the behavior with some inputs autonomous from particle, name it and invoke it for the particle type when we need to use it. Unfortunately I can’t visualize it in a good way.
1 Like
I can see three ways in which this can be solved:
- Use node groups as described in the proposal (maybe I should make an example at some point). I think this is basically what you describe as well.
- Allow selecting multiple particle types within a behavior node.
- Don’t specify the particle types in the behavior nodes at all, but reference the behaviors from the particle types.
I will try to makr a better proposal when i go back to spain. Actually i only have an iPad and i can’t test the build
@jacqueslucke i will try to solve the problem with events. But i dont see the problem with left to right solution
In first way we need to have the particle type as input to node group. In second way I cannot see how this would be compatible with the asset manager. The third is more ideal but I am afraid it will confuse beginner users.
Left to right solutions are fine, not sure what you mean.
Just make sure that something like this works as well:
That is correct.
Why?
That is right to left, for me at least because the event connect in the left side
Ah I see. Please ignore the Event socket, that is not actually part of my proposal anymore, I just did not update the code yet. I wanted to wait a bit to see what the outcome of the discussion in this thread is.
To me it is left to right, because I read the chain of actions from left to right.
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