Recursive vvvv programming (i think?)

I’m trying to get to grips with the idea of making things in vvvv more generatively, like programming simple behaviors and conditions, inspired in part by dottore’s great write up on particles gpu.

So for example making objects that move in a certain direction until they reach a limit whereby they will change direction etc…

I’m mainly playing with framedelay and addition at the moment but I’m sure there are other foundation techniques people could tell me about. One thing in particular I can’t get my head around is how to make one object (or property of one object as a value in a spread) be influenced by another.

An example of this is something I’m trying to replicate as a lesson. Have a look here - and read the brief description on how each blade of grass is made. How might I make the width, rotation, or whatever of each segment depend on the one before it?

A more complex example would be this kind of thing - How do you make an object have properties that influence, and are influenced by other objects?

I get the impression this kind of thing may be much easier using cs in a plugin, which I would like to try, but I’d also like to know how you approach it in pure vvvv.

Thanks for any suggestions

S (Value) and R (Value) ?

this may or may not help > integral-transform and structuresynth-(spreads)

About particle systems in vvvv:

-your framedelay (animation)and + (value) approach is correct. this part of the patch doesn’t determinate the behaviour, it’s just the structure: the behaviour depends on what you add to the spread.

-if you want that one particle is influenced by another (“target”), you have to retrieve for each slice his “target” and use it to evaluate any behaviour you want (go to, minimum distance,…).In other words you have to build a spread of targets and match it to the particle spread.
The most important thing building particle systems in vvvv (using spreads) is to stay aligned:
slice0 <-> target0
slice1 <-> target1

use GetSlice (Spreads) , Select (Value), … to build your target spread (getslice: for each particle take the index of his target)

-about, as xd_nitro told you, the best way to achieve this behaviour is using contribution/integral-transform.

-more complex particle systems: as you see in Flight404 works, particles must have many informations (mass, damping, born time, type…) to allow advanced behaviours. you have to manage these data in the same spread of the particle system (or in another one, just has to be aligned with the principal). (like i did in the ParticleGPU Guide, in 07 - More sofisticated particle system in CPU (patched) patch: the fourth value of the spread is used to store born time)
have a look at this patch for an example of interaction between particles:

…i should write a new guide for patched particle systems eheheh… less time than explane here :)

Hey Dottore, thanks for that!

The boubles patch looks very useful, and seems to touch on one of my questions -

To enable interaction between objects (or particles) For any attribute, do I need to have a spread containing all the possible combinations of slices, to be able to compare them against one another? It seems like this would be exponentially impractical with any large number of objects.

In boubles (though I haven’t had a proper look) you seem to have a process to restrict the number of slices you want to check, against some predetermined value. Is this generally the way you approach building a spread (or whatever) to compare object attributes?

I’ll take a look at integral transform too as I never properly checked it out, but I’d love to know how to patch (or code) a basic version of that grass problem, where each segment (slice) is a function of the previous segment. Any idea?

And congrats on your continuing role as uber shader master!

if you want each particle to keep a minimum distance from the others, in theory you have to evaluate these steps:
-calculate distance between the particle and all the others
-check if distance < certain value
-evaluate the velocity vector that push away the particle if it’s too close to another.
-sum all the vectors of each particle to obtain the final movement vector you will add in the position cycle.

as you noticed this approach brings exponential ammount of operations:
for 10 particles, considering all the possible couples, you will need 90 distance evaluations (not considering distance with itself).
1000 particles = 999000 distance evaluations.
not possible approach.

in this old boubles patch, there’s a module i did called Proximity. this module (wich would be great to have as a proper plugin, i told many times to vux… :) ) really make the difference in terms of optimization:
-it subdivides the space in a grid, each cell has a index
-check in wich cell each particle stays
-provide to each particle ONLY the indices of those particles who are in the neighbour cells.
in this way the distance check is reduced to those particles who really could be too close.

generally, if you have lot of particles and in your behaviour you need comparison, than is needed a way to optimize it. this is not the only one. it depends on what you need.

about your grass question.
the integral transform is the way. you can even patch it building a transform cascade:
let’s say each grass leave is 10 segments.
you have to connect 10 transfom and spread the input you need (position,angle,scale)
each transform than will receve a spread of 10, but the first slice will be transformed only in the first transform (it’s the first segment of the grass). the second slice will be effected in the first and second transform… and keep going…
very didactic approach. use the plugin in the end :)