What you describe there is not actually a limitation of the system. I’m fully aware that it must be possible that some particles are only influenced by certain force fields after an event. Basically, this is a missing feature, but not something that is impossible to add.
3 Likes
I actually considered using frames for that already. It can work (and does work in other software). I only see an issue when a node influences two different particle types. Visualizing this can be a bit tricky when only frames are used.
1 Like
It is true that especially in the second proposal the Particle Type node would not actually be needed anymore. A list in some panel (similar to how multiple particle types are organized in the old particle system) works as well. I did consider that already. The benefit of having Particle Type nodes is that it can make visualizing relationships a bit easier. Also, when we need per-particle-type settings, it might be nice to put them into the node. This way, the user can see the settings of multiple types more easily.
These examples look very nice. I wonder if you can come up with a nice visualization for my second proposal.
3 Likes
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.