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.