I’ve done it like this: upon generation of particles, 1 out of x becomes a master – the others become slaves not behind the computer, but I used the modulo of the particle ID by x, which gives the remainder upon division by x. if it’s 0 you make it a master, if not a slave. Add a boolean attribute, for example ‘slave’, so all of this is done on ‘execute on emission’
later on, you can use this ‘slave’ attribute as a condition to do all kinds of things differently for masters and slaves in the same cloud. for instance, ‘add forces’ for the masters only. (slave attribute driving an ‘if’ port ) in my case the slaves had to stay with their ‘birth’ master – so upon generation, besides the slave attribute, I saved a second attribute which was the ID of the master (the particle ID minus the remainder from the modulo I think) there’s many ways you can drive the slaves. in my case I needed an elastic link, where they would also orbit around the master as well as collide with obstacles, and look kind of natural, so they were still simulated - (and there was also an overall ‘character’ to keep in mind) at the basis, using the id of the master I got it’s position, and used that as a target. point position minus the master’s point position used as a vector force will give a force pulling towards (or away from) the master. this was modulated by a change range based on the length of that vector – so if the distance got bigger the force was stronger and vice versa. this gave it the elastic effect, leaving the slaves a bit more loose when near the master but pulling them more rigidly when going too far away. the spinning/orbiting was done with a dot product (I think), and again modulated based on distance from the master, so the closer they were, the faster they spinned around the master. I also added a bit of the direction of the master to it’s position to use as target, rather than just it’s actual position – this is much more precise at high speeds: the master’s point position is where the master is at the beginning of the current simulation step – so using that as the target, the slaves are trailing too much behind the master and have difficulty keeping up when the master makes complex movements. so all of this is using forces on the slaves, so they still behave in a ‘natural’, simulated fashion. you can of course approach it differently, by driving the position itself (set position on the slaves) for a more ‘geometric’ result. you could save the offset between the slave and the master at emission as an attribute, and use this to set position, as master position + ( offset, rotated with master’s orientation) same for rotation and scale, save them at birth and then modulate with the one from the master (add,multiply,.. depends a bit on what you’re after) all of this is assuming you’re ok with assigning the master to the slave at birth. assigning a new master can be as simple as saving a new value for the masterID upon a trigger or a condition – but using a closest point each frame on the cloud itself to dynamically find a master all the time is going to slow things down a lot. I’m not sure if you can find a closest point out of a subset of particles (the masters only) which is a bit like what goes on with slipstream’s vorticles I think. You could do this with two clouds though – one cloud with the masters and a second with the slaves – but that’s going to make other things more convoluted. I hope this gives some ideas? From: Olivier Jeannel Sent: Monday, October 05, 2015 10:08 PM To: softimage@listproc.autodesk.com Subject: Cluster of points driving another cluster of points I don't know how to do that : Let's say I have a grid of 10 particles moving in a simultion (Master). Let's say I create another grid of 100 particles (slaves). I want those 100 particles to follow in position, rotation and scale the 10 master particles. I don't want the slaves to get the position of the master, I want the master to behave like the center of the slaves chunk/cluster. Not sure I'm clear.
