just sent you a second test which might work better for you – see your inbox.
first you’re building a castle with unfolding ribbons and then you are
collapsing it?
sounds like a cool job you’re on!
From: Olivier Jeannel
Sent: Tuesday, October 06, 2015 6:59 PM
To: softimage@listproc.autodesk.com
Subject: Re: Cluster of points driving another cluster of points
Hey Peter !
You just created this ? It's very impressive !
I'm looking at it atm, very interesting.
For what I wanted to use, it doesn't work (yet).
Here's the exact scenario
I've made a Mom Simulation of a tower colapsing down. I've used the
Mom_Create_Cluster By Cloud tool so that I have big chunks made of smaller
chunks that collapse again themselves later.
This is done in ice so each chunk has a particle center.
Then I wanted to add some inside bricks to give details : Imagine bricks
stucked into chunks of mortar.
When the chunk falls, it brings with him the cluster of bricks attached to him
(the closest bricks) (no RBD).
So I thought I could generate a brick wall, and use the center of each chunk
to drive the SRT of the clustered bricks.
But for this, I'll need 2 pointclouds.
One PC is the RBD chunks (master/driver)
The other PC is the bricks (Slaves)
Not sure if I'm clear
But your example is superb, and very inspirative. Thank's a lot for taking the
time to put this together !
Olivier
On Tue, Oct 6, 2015 at 5:10 PM, <pete...@skynet.be> wrote:
sent a quick test scene offline –
unfortunately I don’t have the ones I’ve done in the past, which tackled a
few interesting issues (at least for me)
From: Olivier Jeannel
Sent: Tuesday, October 06, 2015 2:33 PM
To: softimage@listproc.autodesk.com
Subject: Re: Cluster of points driving another cluster of points
Hi Peter,
Do you have a scene that I could dissect ?
On Tue, Oct 6, 2015 at 1:28 PM, <pete...@skynet.be> wrote:
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.
