Hello dear devvvvs,
cvtester2019 here from the riot.
I was trying to do something like that: I have some particles and I want to animate them by using a Filter. But the Filter can be provided by a user. So I have an Animator which accepts different filters, each of them is implementing IAnimation interface. There are several Animation nodes which implement this interface, like DamperAnimation, FooAnimation…
As far as I understood, inside the Animator I have to instantiate as many Animation nodes as there are particles in my spread. And my question is if I’m doing this right.
I know, theoretically I can make a spread of damper nodes beforehand, but imagine that I don’t know beforehand if every particle is Animatable or not (suppose, that only some of them are). So the Animator node is asking every particle if it is Animatable or not and then creates a filter for it. (this is not implemented in the document for the sake of simplicity)
Is the animation behavior of the particle something that you would consider a property of the particle?
Would it make sense for you to have more than one animator acting on one particle? It doesn’t look like this. The way it is modeled Animators would overwrite what other Animators did to the particles.
So maybe make the animation part of the update behavior of a particle? And add some instance operations to the particle to switch to other behaviors. In these instance operations, you then could just call the constructors of the particular implementations. The way you instantiated those different animation strategies via VLfactory looks rather suspicious.
I also think that the animation should be part of the particle, otherwise you lose the association between the animation state and the particle state and you run into vvvv beta problems when the spread changes.
i think it fits well with the composition pattern, where you just replace Duck with Particle:
@gregsn, @tonfilm:
Thanks a lot for your answers. Yes, I have a feeling that my approach is not the right one, that’s why I was posting it here in the search of the “Right” or better one.
I was very aware of the Strategy Pattern and it’s very cool to have this “Commonity Coding: Design Patterns” initiative!
The thing with the Strategy Pattern is that you have to define the behavior of the particles beforehand, right? At the moment of creation. At least this is how it is done in the VL example. I would like to switch the behaviours (animations) much later at any point in time (ok, let’s say particles are stand still, at this moment I switch their animation behaviour).
I also would like to just use the filter process nodes which are alredy there and working very good like Damper and Filter (with all it’s tweening modes).
From what @gregsn is saying I read that:
I will create a process node with all the filters I want to have. This process node will be the part of every particle (say I have many different particles, not only their shapes but what they are and what properties they have). And somehow down the patch I define which “part” of this processnode will drive the particle? If I want to add a new filter, I’ll just add it to this processnode and so every particle will get this new filter for its movement?
Here is the new version of the Document with the Animator processnode living inside the Particle. The Particle is now a class. At the moment the “Filter Time” and “Animator” (string) are separate input pins, but of course these (and even more parameters) can be combined into separate Datatype.
