Damper issues when spread count changes

Hi everyone
I am using a damper to “ease” the movement of a spread of quads whose positions are random, but what happens when the spread count changes is that some of the quads swap their positions and they move from their “correct coordinates” even if the ending x,y are correct…

its much easier if i explain to you with a sample patch that i have attached.
try to hit the toggle and slice nr 2 will be removed, the quads with and without damper are the same in the end of the animation but damper moves the quads anyway… do have any solution on how to avoid that kind of behaviour?

the attached patch is just a nonsense usage of the damper node but if i can fix that i can use it in more complicated setups (for example moving some quads with the contour filtered by a damper, virtually same setup as the sample patch but x and y are changing) …

hope you can help me,
thanks!

damper variable spread size.v4p (13.9 kB)

hi crash,

this is a known problem for all nodes that have a state (something like a history).

you can identify such nodes by checking if output values are only dependent on inputs. if NOT then they have a state (typically per slice) and resorting of input slices will cause problems, since the internal state is not resorted… filter nodes like damper obviously have a state, since the output can change with constant input…
so when a slice of the input is removed, and the corresponding state is not removed, we run into the problem.

you can’t remove states however.

so you need to ensure that a certain particle’s parameter always stays in the same slice of the spread that goes into the damper (as long as this particle lives). When removing a particle’s parameter outof such a spread you get a new slot for a future particle. until the “animation slot” is used again, it should be ignored and not affect the rest of the particle animation.

but it is quite tricky to get that right. you suddenly are forced to manage a list of slice numbers that identify the animation slots of your individual particles.

an example of how to do that can be found in the “id buffer” folder in that zip:
vvvv-as-a-language

but there might be more performant solutions to the problem from @eno)) or ((user:vux(?)

Just a simple thought, depending on what s your final purpose may work or not.
(maybe too simple?)

damper variable spread size alpha.v4p (13.7 kB)

@io
thanks for the try but…yes i think it’s too simple, in the example you show me the spread count does not change while it has to change in the real situation i am facing…

@gregsn
ok thanks for that, i must give it a deeper look because i can’t understand much of the buffer nodes and how i could use them to achieve what i need…do you have any more examples of it’s usage? (maybe more simple than the one presented on the id buffer folder…)

thanks!!

Hey, I wrote the dictionary Plugin for exactly this purpose, to handle changing spreadcounts precisely - that is to define which slices are taken out and where new ones are sliced in.
If you use another filter node like DeNiro, I think you should be able to sore the state outside the filter in the dictionary, and set it again as initial velocity whenever the spreadcount changes …

thanks eno for pointing out that node…i undestood it’s working but i can’t understand how it could be usefull to my usage…
i had a look at the deNiro node too and had some ideas about it but didn’t really work out, i have posted another example of what i’d like to achieve but cannot due to this damper issue…
in the example patch the damper moves the points in the spherical spread, and when spread count changes the points switch themselves in a similar way as in the previous example.

if you have some time to point me in the right direction or give me some tips on how to smartly use the dictionary node in this example i’d be gratefull…
thanks anyway to all of you!

byebye

damper variable spread size 1.v4p (44.8 kB)

alright sorry for the delay.
this was quite hard in my opinion.

i attached 2 different solutions: one approach that tries to be more explicit, the other one that tries to hide the complex matter.

the one that hides the magic away is in the folder “hidden magic”. note that i am not so confident that hiding the complexity is always possible. and also: even if patches on a higher level might get cleaner and use less nodes, under the hood there are more nodes and calculations needed to hide the complexity. so this approach should also result in a perforamance loss when compared to the more explicit approach…

so i encourage you to have a look at the “explicit static animation slots” folder, where you

  • first put your contour data (like positions) into a spread with static size, that can be thought of a spread with “animation slots”
  • do all state involving operations over there (animation like filtering)
  • and finally get them into original order after you are done and ready to draw

folder “without Reindexing” tries to get rid of some patches (ReIndex and its subpatches) that only is for getting better IDs than the Contour node is offering. it is quite nice and surprising to see how the implicit modulo in vvvv turns out to do the right thing. however since the IDs of the contour not only get bigger and bigger but also don’t stay together (like 180, 181, 183, 184) but drift apart more and more we sadly get errors after a while. so this is no solution…

damper variable spread size.zip (55.1 kB)

Hi vvvvusers,
I’m trying to smooth the XY coordinates from DetectObject (FreeFrame DShow9) and I have the same problem with Damper (Animation) or Oscillator (Animation) nodes.

Patches posted by @gregsn work but is there an easier and cleaner way to solve the issue?