Re: Cluster of points driving another cluster of points

[Morten Bartholdy]

Really nice stuff Christian! :)

Morten


Den 10. oktober 2015 kl. 00:05 skrev Christian Keller <chris3...@me.com>:

> Good you managed a way to do it.
> We used a similar approach for example on that one:
> 
> https://vimeo.com/channels/96149/118590224
> <https://vimeo.com/channels/96149/118590224>
> 
> Not feasible for everything, but much nicer and more predictable than to
> use bullet in SI.
> 
> --
> Christian Keller
> Visual effects|direction
> m  +49 179 69 36 248
> 
> chris3...@me.com <mailto:chris3...@me.com>
> Vimeo.com/channels/96149 <http://vimeo.com/channels/96149>
> 
> Am 08.10.2015 um 19:15 schrieb Olivier Jeannel < facialdel...@gmail.com
> <mailto:facialdel...@gmail.com> >:
> > Thank you !
> > it's based on 2 pointclouds PC Masters and PC Slaves.
> > PC Slaves picks up one Master based on closest position.
> > The proud part is that it works with any rotations, masters and slaves
> > don't have to match.
> > 
> > I wanted to use it in a momentum simulation to enhance the look, but
> > finally it didn't look that good. Oh well
> > 
> > On Thu, Oct 8, 2015 at 6:17 PM, pedro santos < probi...@gmail.com
> > <mailto:probi...@gmail.com> > wrote:
> > > Looks nice :)
> > > 
> > > On Thu, Oct 8, 2015 at 2:00 PM, Olivier Jeannel < facialdel...@gmail.com
> > > <mailto:facialdel...@gmail.com> > wrote:
> > > > With some help from PeterB, here's what I had in mind.
> > > > https://drive.google.com/open?id=0B1QqhXD7Y15qR3BOZGtZRXcxSDg
> > > > <https://drive.google.com/open?id=0B1QqhXD7Y15qR3BOZGtZRXcxSDg>
> > > > Pedro, my apologies, I was dragged away and didn't take time to answer.
> > > > Thank's for sharing the compound :)
> > > > 
> > > > On Thu, Oct 8, 2015 at 2:54 PM, Olivier Jeannel < facialdel...@gmail.com
> > > > <mailto:facialdel...@gmail.com> > wrote:
> > > > > It works !
> > > > > W !
> > > > > I only have 2015, do you want the scene anyway ? Maybe just the
> > > > > compounds
> > > > > could export and work in 2012?
> > > > > https://drive.google.com/open?id=0B1QqhXD7Y15qR3BOZGtZRXcxSDg
> > > > > <https://drive.google.com/open?id=0B1QqhXD7Y15qR3BOZGtZRXcxSDg>
> > > > > 
> > > > > On Wed, Oct 7, 2015 at 8:48 PM, < pete...@skynet.be
> > > > > <mailto:pete...@skynet.be> > wrote:
> > > > > > yes the third example was toto3.scn – gotta love my naming
> > > > > > convention.
> > > > > > 
> > > > > > I gave slaves and masters an initial random orientation to make sure
> > > > > > it was
> > > > > > respected – so having a cylindrical basis *should* work.
> > > > > > of course, as always, the abstract test is nice, and then you try to
> > > > > > do
> > > > > > something more specific, and all hell breaks loose.
> > > > > > 
> > > > > > if at some point you want to / can send a scene where you would like
> > > > > > to
> > > > > > solve the issue, I can have a look
> > > > > > (no promises – and I’m on 2012 here – perhaps 2013 somewhere – and
> > > > > > depending on available time of course..)
> > > > > > 
> > > > > > regards, Peter
> > > > > > 
> > > > > > 
> > > > > > From: Olivier Jeannel <mailto:facialdel...@gmail.com>
> > > > > > Sent: Wednesday, October 07, 2015 6:57 PM
> > > > > > To: pete...@skynet.be <mailto:pete...@skynet.be>
> > > > > > Subject: Re: Cluster of points driving another cluster of points
> > > > > > 
> > > > > > Nope, was on my scene, I tried to build the brick wall. It's a
> > > > > > cylindrical,
> > > > > > like a tower, brick wall.
> > > > > > But having both Master rotations and Slave rotations with different
> > > > > > values
> > > > > > (not beeing zero) gives some troubles.
> > > > > > No time to investigate today, a bit overwhelmed by other stuff :/
> > > > > > The second test is Toto3.scn ?
> > > > > > 
> > > > > > 
> > > > > > On Wed, Oct 7, 2015 at 6:11 PM, < pete...@skynet.be
> > > > > > <

Re: Cluster of points driving another cluster of points

[Jason S]

   make sure it was
respected – so
having a
cylindrical
basis *should*
work.
  of course, as
always, the
abstract test is
nice, and then
you try to do
something more
specific, and
all hell breaks
loose.
   
  if at some
point you want
to / can send a
scene where you
would like to
solve the issue,
I can have a
look
  (no promises
– and I’m on
2012 here –
perhaps 2013
somewhere – and
depending on
available time
of course..)
   
  regards,
Peter
   
  

   
  
   From:
  Olivier Jeannel
  
   Sent:
  Wednesday,
  October 07,
  2015 6:57 PM 
   To:
  pete...@skynet.be 
  
  
   Subject:
      Re: Cluster of
          points driving
      another
      cluster of
      points 
  
  
  

 
  
  

  
  
  Nope, was on
  my scene, I
  tried to build
  the brick
  wall. It's a
  cylindrical,
  like a tower,

Re: Cluster of points driving another cluster of points

[Olivier Jeannel]

Damn that's an impressive one. I thought it was some Houdini snow stuff !

Btw, I experienced some nice Mom setup, really not as bad as I was told,
with some cool clustering effects (real Mom clusters).

On Sat, Oct 10, 2015 at 12:05 AM, Christian Keller <chris3...@me.com> wrote:

> Good you managed a way to do it.
> We used a similar approach for example on that one:
>
> https://vimeo.com/channels/96149/118590224
>
> Not feasible for everything, but much nicer and more predictable than to
> use bullet in SI.
>
> --
> Christian Keller
> Visual effects|direction
> m  +49 179 69 36 248
>
> chris3...@me.com
> Vimeo.com/channels/96149 <http://vimeo.com/channels/96149>
>
> Am 08.10.2015 um 19:15 schrieb Olivier Jeannel <facialdel...@gmail.com>:
>
> Thank you !
> it's based on 2 pointclouds PC Masters and PC Slaves.
> PC Slaves picks up one Master based on closest position.
> The proud part is that it works with any rotations, masters and slaves
> don't have to match.
>
> I wanted to use it in a momentum simulation to enhance the look, but
> finally it didn't look that good. Oh well
>
> On Thu, Oct 8, 2015 at 6:17 PM, pedro santos <probi...@gmail.com> wrote:
>
>> Looks nice :)
>>
>> On Thu, Oct 8, 2015 at 2:00 PM, Olivier Jeannel <facialdel...@gmail.com>
>> wrote:
>>
>>> With some help from PeterB, here's what I had in mind.
>>> https://drive.google.com/open?id=0B1QqhXD7Y15qR3BOZGtZRXcxSDg
>>> Pedro, my apologies, I was dragged away and didn't take time to answer.
>>> Thank's for sharing the compound :)
>>>
>>> On Thu, Oct 8, 2015 at 2:54 PM, Olivier Jeannel <facialdel...@gmail.com>
>>> wrote:
>>>
>>>> It works !
>>>> W !
>>>> I only have 2015, do you want the scene anyway ? Maybe just the
>>>> compounds could export and work in 2012?
>>>> https://drive.google.com/open?id=0B1QqhXD7Y15qR3BOZGtZRXcxSDg
>>>>
>>>> On Wed, Oct 7, 2015 at 8:48 PM, <pete...@skynet.be> wrote:
>>>>
>>>>> yes the third example was toto3.scn – gotta love my naming convention.
>>>>>
>>>>> I gave slaves and masters an initial random orientation to make sure
>>>>> it was respected – so having a cylindrical basis *should* work.
>>>>> of course, as always, the abstract test is nice, and then you try to
>>>>> do something more specific, and all hell breaks loose.
>>>>>
>>>>> if at some point you want to / can send a scene where you would like
>>>>> to solve the issue, I can have a look
>>>>> (no promises – and I’m on 2012 here – perhaps 2013 somewhere – and
>>>>> depending on available time of course..)
>>>>>
>>>>> regards, Peter
>>>>>
>>>>>
>>>>> *From:* Olivier Jeannel <facialdel...@gmail.com>
>>>>> *Sent:* Wednesday, October 07, 2015 6:57 PM
>>>>> *To:* pete...@skynet.be
>>>>> *Subject:* Re: Cluster of points driving another cluster of points
>>>>>
>>>>> Nope, was on my scene, I tried to build the brick wall. It's a
>>>>> cylindrical, like a tower, brick wall.
>>>>> But having both Master rotations and Slave rotations with different
>>>>> values (not beeing zero) gives some troubles.
>>>>> No time to investigate today, a bit overwhelmed by other stuff :/
>>>>> The second test is Toto3.scn ?
>>>>>
>>>>>
>>>>> On Wed, Oct 7, 2015 at 6:11 PM, <pete...@skynet.be> wrote:
>>>>>
>>>>>> woops – not much time behind the computer today -
>>>>>>
>>>>>> > Still some rotation problem I might ask you ;)
>>>>>>
>>>>>> you mean in the test scene I sent you?
>>>>>> at first sight the rotations looked correct but I’m not sure
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From:* Olivier Jeannel <facialdel...@gmail.com>
>>>>>> *Sent:* Tuesday, October 06, 2015 9:34 PM
>>>>>> *To:* mailto:softimage@listproc.autodesk.com
>>>>>> <softimage@listproc.autodesk.com>
>>>>>> *Subject:* Re: Cluster of points driving another cluster of points
>>>>>>
>>>>>>
>>>>>> Ok I'll check that tomorrow ;)
>>>>>> Well, the ribbon plan is ended, i defenetly prefer 

Re: Cluster of points driving another cluster of points

[Christian Keller]

Good you managed a way to do it. 
We used a similar approach for example on that one:

https://vimeo.com/channels/96149/118590224

Not feasible for everything, but much nicer and more predictable than to use 
bullet in SI.

--
Christian Keller 
Visual effects|direction
m  +49 179 69 36 248

chris3...@me.com
Vimeo.com/channels/96149

> Am 08.10.2015 um 19:15 schrieb Olivier Jeannel <facialdel...@gmail.com>:
> 
> Thank you !
> it's based on 2 pointclouds PC Masters and PC Slaves. 
> PC Slaves picks up one Master based on closest position.
> The proud part is that it works with any rotations, masters and slaves don't 
> have to match.
> 
> I wanted to use it in a momentum simulation to enhance the look, but finally 
> it didn't look that good. Oh well
> 
>> On Thu, Oct 8, 2015 at 6:17 PM, pedro santos <probi...@gmail.com> wrote:
>> Looks nice :)
>> 
>>> On Thu, Oct 8, 2015 at 2:00 PM, Olivier Jeannel <facialdel...@gmail.com> 
>>> wrote:
>>> With some help from PeterB, here's what I had in mind.
>>> https://drive.google.com/open?id=0B1QqhXD7Y15qR3BOZGtZRXcxSDg
>>> Pedro, my apologies, I was dragged away and didn't take time to answer. 
>>> Thank's for sharing the compound :) 
>>> 
>>>> On Thu, Oct 8, 2015 at 2:54 PM, Olivier Jeannel <facialdel...@gmail.com> 
>>>> wrote:
>>>> It works !
>>>> W !
>>>> I only have 2015, do you want the scene anyway ? Maybe just the compounds 
>>>> could export and work in 2012?
>>>> https://drive.google.com/open?id=0B1QqhXD7Y15qR3BOZGtZRXcxSDg
>>>> 
>>>>> On Wed, Oct 7, 2015 at 8:48 PM, <pete...@skynet.be> wrote:
>>>>> yes the third example was toto3.scn – gotta love my naming convention.
>>>>>  
>>>>> I gave slaves and masters an initial random orientation to make sure it 
>>>>> was respected – so having a cylindrical basis *should* work.
>>>>> of course, as always, the abstract test is nice, and then you try to do 
>>>>> something more specific, and all hell breaks loose.
>>>>>  
>>>>> if at some point you want to / can send a scene where you would like to 
>>>>> solve the issue, I can have a look
>>>>> (no promises – and I’m on 2012 here – perhaps 2013 somewhere – and 
>>>>> depending on available time of course..)
>>>>>  
>>>>> regards, Peter
>>>>>  
>>>>>  
>>>>> From: Olivier Jeannel
>>>>> Sent: Wednesday, October 07, 2015 6:57 PM
>>>>> To: pete...@skynet.be
>>>>> Subject: Re: Cluster of points driving another cluster of points
>>>>>  
>>>>> Nope, was on my scene, I tried to build the brick wall. It's a 
>>>>> cylindrical, like a tower, brick wall.
>>>>> But having both Master rotations and Slave rotations with different 
>>>>> values (not beeing zero) gives some troubles.
>>>>> No time to investigate today, a bit overwhelmed by other stuff :/
>>>>> The second test is Toto3.scn ?
>>>>>  
>>>>>  
>>>>>> On Wed, Oct 7, 2015 at 6:11 PM, <pete...@skynet.be> wrote:
>>>>>> woops – not much time behind the computer today -
>>>>>>  
>>>>>> > Still some rotation problem I might ask you ;)
>>>>>>  
>>>>>> you mean in the test scene I sent you?
>>>>>> at first sight the rotations looked correct but I’m not sure
>>>>>>  
>>>>>>  
>>>>>>  
>>>>>> From: Olivier Jeannel
>>>>>> Sent: Tuesday, October 06, 2015 9:34 PM
>>>>>> To: mailto:softimage@listproc.autodesk.com
>>>>>> Subject: Re: Cluster of points driving another cluster of points
>>>>>>  
>>>>>> Ok I'll check that tomorrow ;)
>>>>>> Well, the ribbon plan is ended, i defenetly prefer the tests I made 
>>>>>> rather than the end result, but at least the director is happy.
>>>>>> Too bad the  strand orientation is such a nightmare, could have be so 
>>>>>> cool with sole little maintenance...
>>>>>> 
>>>>>> The destruction (it's another shot) part is because I decided to run 
>>>>>> some tests on ice. In fact the sequence has been made in c4d and the 
>>>>>> fractures were so bad that I felt the need to

Re: Cluster of points driving another cluster of points

[Olivier Jeannel]

With some help from PeterB, here's what I had in mind.
https://drive.google.com/open?id=0B1QqhXD7Y15qR3BOZGtZRXcxSDg
Pedro, my apologies, I was dragged away and didn't take time to answer.
Thank's for sharing the compound :)

On Thu, Oct 8, 2015 at 2:54 PM, Olivier Jeannel <facialdel...@gmail.com>
wrote:

> It works !
> W !
> I only have 2015, do you want the scene anyway ? Maybe just the compounds
> could export and work in 2012?
> https://drive.google.com/open?id=0B1QqhXD7Y15qR3BOZGtZRXcxSDg
>
> On Wed, Oct 7, 2015 at 8:48 PM, <pete...@skynet.be> wrote:
>
>> yes the third example was toto3.scn – gotta love my naming convention.
>>
>> I gave slaves and masters an initial random orientation to make sure it
>> was respected – so having a cylindrical basis *should* work.
>> of course, as always, the abstract test is nice, and then you try to do
>> something more specific, and all hell breaks loose.
>>
>> if at some point you want to / can send a scene where you would like to
>> solve the issue, I can have a look
>> (no promises – and I’m on 2012 here – perhaps 2013 somewhere – and
>> depending on available time of course..)
>>
>> regards, Peter
>>
>>
>> *From:* Olivier Jeannel <facialdel...@gmail.com>
>> *Sent:* Wednesday, October 07, 2015 6:57 PM
>> *To:* pete...@skynet.be
>> *Subject:* Re: Cluster of points driving another cluster of points
>>
>> Nope, was on my scene, I tried to build the brick wall. It's a
>> cylindrical, like a tower, brick wall.
>> But having both Master rotations and Slave rotations with different
>> values (not beeing zero) gives some troubles.
>> No time to investigate today, a bit overwhelmed by other stuff :/
>> The second test is Toto3.scn ?
>>
>>
>> On Wed, Oct 7, 2015 at 6:11 PM, <pete...@skynet.be> wrote:
>>
>>> woops – not much time behind the computer today -
>>>
>>> > Still some rotation problem I might ask you ;)
>>>
>>> you mean in the test scene I sent you?
>>> at first sight the rotations looked correct but I’m not sure
>>>
>>>
>>>
>>> *From:* Olivier Jeannel <facialdel...@gmail.com>
>>> *Sent:* Tuesday, October 06, 2015 9:34 PM
>>> *To:* mailto:softimage@listproc.autodesk.com
>>> <softimage@listproc.autodesk.com>
>>> *Subject:* Re: Cluster of points driving another cluster of points
>>>
>>>
>>> Ok I'll check that tomorrow ;)
>>> Well, the ribbon plan is ended, i defenetly prefer the tests I made
>>> rather than the end result, but at least the director is happy.
>>> Too bad the  strand orientation is such a nightmare, could have be so
>>> cool with sole little maintenance...
>>>
>>> The destruction (it's another shot) part is because I decided to run
>>> some tests on ice. In fact the sequence has been made in c4d and the
>>> fractures were so bad that I felt the need to prepare a backup solution
>>> just in case. Finally the shot was validated as is. Nice rdb in c4d, with
>>> easy control, but the fracture tool is just a bad joke.
>>> I'm half happy with momentum, some nice ice control, but feels maybe
>>> unfinished. Or maybe not enough docs.
>>> So well, the  ice destruction is a side project. I'm very happy with
>>> that cluster solved problem :)
>>> Still some rotation problem I might ask you ;)
>>>
>>> And the whole project is a documentary about le Louvre, how it was built
>>> along history.
>>> Le 6 oct. 2015 20:25, <pete...@skynet.be> a écrit :
>>>
>>>> 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 <facialdel...@gmail.com>
>>>> *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

Re: Cluster of points driving another cluster of points

[pedro santos]

Looks nice :)

On Thu, Oct 8, 2015 at 2:00 PM, Olivier Jeannel <facialdel...@gmail.com>
wrote:

> With some help from PeterB, here's what I had in mind.
> https://drive.google.com/open?id=0B1QqhXD7Y15qR3BOZGtZRXcxSDg
> Pedro, my apologies, I was dragged away and didn't take time to answer.
> Thank's for sharing the compound :)
>
> On Thu, Oct 8, 2015 at 2:54 PM, Olivier Jeannel <facialdel...@gmail.com>
> wrote:
>
>> It works !
>> W !
>> I only have 2015, do you want the scene anyway ? Maybe just the compounds
>> could export and work in 2012?
>> https://drive.google.com/open?id=0B1QqhXD7Y15qR3BOZGtZRXcxSDg
>>
>> On Wed, Oct 7, 2015 at 8:48 PM, <pete...@skynet.be> wrote:
>>
>>> yes the third example was toto3.scn – gotta love my naming convention.
>>>
>>> I gave slaves and masters an initial random orientation to make sure it
>>> was respected – so having a cylindrical basis *should* work.
>>> of course, as always, the abstract test is nice, and then you try to do
>>> something more specific, and all hell breaks loose.
>>>
>>> if at some point you want to / can send a scene where you would like to
>>> solve the issue, I can have a look
>>> (no promises – and I’m on 2012 here – perhaps 2013 somewhere – and
>>> depending on available time of course..)
>>>
>>> regards, Peter
>>>
>>>
>>> *From:* Olivier Jeannel <facialdel...@gmail.com>
>>> *Sent:* Wednesday, October 07, 2015 6:57 PM
>>> *To:* pete...@skynet.be
>>> *Subject:* Re: Cluster of points driving another cluster of points
>>>
>>> Nope, was on my scene, I tried to build the brick wall. It's a
>>> cylindrical, like a tower, brick wall.
>>> But having both Master rotations and Slave rotations with different
>>> values (not beeing zero) gives some troubles.
>>> No time to investigate today, a bit overwhelmed by other stuff :/
>>> The second test is Toto3.scn ?
>>>
>>>
>>> On Wed, Oct 7, 2015 at 6:11 PM, <pete...@skynet.be> wrote:
>>>
>>>> woops – not much time behind the computer today -
>>>>
>>>> > Still some rotation problem I might ask you ;)
>>>>
>>>> you mean in the test scene I sent you?
>>>> at first sight the rotations looked correct but I’m not sure
>>>>
>>>>
>>>>
>>>> *From:* Olivier Jeannel <facialdel...@gmail.com>
>>>> *Sent:* Tuesday, October 06, 2015 9:34 PM
>>>> *To:* mailto:softimage@listproc.autodesk.com
>>>> <softimage@listproc.autodesk.com>
>>>> *Subject:* Re: Cluster of points driving another cluster of points
>>>>
>>>>
>>>> Ok I'll check that tomorrow ;)
>>>> Well, the ribbon plan is ended, i defenetly prefer the tests I made
>>>> rather than the end result, but at least the director is happy.
>>>> Too bad the  strand orientation is such a nightmare, could have be so
>>>> cool with sole little maintenance...
>>>>
>>>> The destruction (it's another shot) part is because I decided to run
>>>> some tests on ice. In fact the sequence has been made in c4d and the
>>>> fractures were so bad that I felt the need to prepare a backup solution
>>>> just in case. Finally the shot was validated as is. Nice rdb in c4d, with
>>>> easy control, but the fracture tool is just a bad joke.
>>>> I'm half happy with momentum, some nice ice control, but feels maybe
>>>> unfinished. Or maybe not enough docs.
>>>> So well, the  ice destruction is a side project. I'm very happy with
>>>> that cluster solved problem :)
>>>> Still some rotation problem I might ask you ;)
>>>>
>>>> And the whole project is a documentary about le Louvre, how it was
>>>> built along history.
>>>> Le 6 oct. 2015 20:25, <pete...@skynet.be> a écrit :
>>>>
>>>>> 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 <facialdel...@gmail.com>
>>>>> *Sent:* Tuesday, October 06, 2015 6:59 PM
>>>>> *To:* softimage@listproc.autodesk.com
>>>>&

Re: Cluster of points driving another cluster of points

[Olivier Jeannel]

Thank you !
it's based on 2 pointclouds PC Masters and PC Slaves.
PC Slaves picks up one Master based on closest position.
The proud part is that it works with any rotations, masters and slaves
don't have to match.

I wanted to use it in a momentum simulation to enhance the look, but
finally it didn't look that good. Oh well

On Thu, Oct 8, 2015 at 6:17 PM, pedro santos <probi...@gmail.com> wrote:

> Looks nice :)
>
> On Thu, Oct 8, 2015 at 2:00 PM, Olivier Jeannel <facialdel...@gmail.com>
> wrote:
>
>> With some help from PeterB, here's what I had in mind.
>> https://drive.google.com/open?id=0B1QqhXD7Y15qR3BOZGtZRXcxSDg
>> Pedro, my apologies, I was dragged away and didn't take time to answer.
>> Thank's for sharing the compound :)
>>
>> On Thu, Oct 8, 2015 at 2:54 PM, Olivier Jeannel <facialdel...@gmail.com>
>> wrote:
>>
>>> It works !
>>> W !
>>> I only have 2015, do you want the scene anyway ? Maybe just the
>>> compounds could export and work in 2012?
>>> https://drive.google.com/open?id=0B1QqhXD7Y15qR3BOZGtZRXcxSDg
>>>
>>> On Wed, Oct 7, 2015 at 8:48 PM, <pete...@skynet.be> wrote:
>>>
>>>> yes the third example was toto3.scn – gotta love my naming convention.
>>>>
>>>> I gave slaves and masters an initial random orientation to make sure it
>>>> was respected – so having a cylindrical basis *should* work.
>>>> of course, as always, the abstract test is nice, and then you try to do
>>>> something more specific, and all hell breaks loose.
>>>>
>>>> if at some point you want to / can send a scene where you would like to
>>>> solve the issue, I can have a look
>>>> (no promises – and I’m on 2012 here – perhaps 2013 somewhere – and
>>>> depending on available time of course..)
>>>>
>>>> regards, Peter
>>>>
>>>>
>>>> *From:* Olivier Jeannel <facialdel...@gmail.com>
>>>> *Sent:* Wednesday, October 07, 2015 6:57 PM
>>>> *To:* pete...@skynet.be
>>>> *Subject:* Re: Cluster of points driving another cluster of points
>>>>
>>>> Nope, was on my scene, I tried to build the brick wall. It's a
>>>> cylindrical, like a tower, brick wall.
>>>> But having both Master rotations and Slave rotations with different
>>>> values (not beeing zero) gives some troubles.
>>>> No time to investigate today, a bit overwhelmed by other stuff :/
>>>> The second test is Toto3.scn ?
>>>>
>>>>
>>>> On Wed, Oct 7, 2015 at 6:11 PM, <pete...@skynet.be> wrote:
>>>>
>>>>> woops – not much time behind the computer today -
>>>>>
>>>>> > Still some rotation problem I might ask you ;)
>>>>>
>>>>> you mean in the test scene I sent you?
>>>>> at first sight the rotations looked correct but I’m not sure
>>>>>
>>>>>
>>>>>
>>>>> *From:* Olivier Jeannel <facialdel...@gmail.com>
>>>>> *Sent:* Tuesday, October 06, 2015 9:34 PM
>>>>> *To:* mailto:softimage@listproc.autodesk.com
>>>>> <softimage@listproc.autodesk.com>
>>>>> *Subject:* Re: Cluster of points driving another cluster of points
>>>>>
>>>>>
>>>>> Ok I'll check that tomorrow ;)
>>>>> Well, the ribbon plan is ended, i defenetly prefer the tests I made
>>>>> rather than the end result, but at least the director is happy.
>>>>> Too bad the  strand orientation is such a nightmare, could have be so
>>>>> cool with sole little maintenance...
>>>>>
>>>>> The destruction (it's another shot) part is because I decided to run
>>>>> some tests on ice. In fact the sequence has been made in c4d and the
>>>>> fractures were so bad that I felt the need to prepare a backup solution
>>>>> just in case. Finally the shot was validated as is. Nice rdb in c4d, with
>>>>> easy control, but the fracture tool is just a bad joke.
>>>>> I'm half happy with momentum, some nice ice control, but feels maybe
>>>>> unfinished. Or maybe not enough docs.
>>>>> So well, the  ice destruction is a side project. I'm very happy with
>>>>> that cluster solved problem :)
>>>>> Still some rotation problem I might ask you ;)
>>>>>
>>>>> And the whole project is a 

Re: Cluster of points driving another cluster of points

[peter_b]

woops – not much time behind the computer today - 

> Still some rotation problem I might ask you ;)

you mean in the test scene I sent you?
at first sight the rotations looked correct but I’m not sure



From: Olivier Jeannel 
Sent: Tuesday, October 06, 2015 9:34 PM
To: mailto:softimage@listproc.autodesk.com 
Subject: Re: Cluster of points driving another cluster of points

Ok I'll check that tomorrow ;)
Well, the ribbon plan is ended, i defenetly prefer the tests I made rather than 
the end result, but at least the director is happy.
Too bad the  strand orientation is such a nightmare, could have be so cool with 
sole little maintenance...

The destruction (it's another shot) part is because I decided to run some tests 
on ice. In fact the sequence has been made in c4d and the fractures were so bad 
that I felt the need to prepare a backup solution just in case. Finally the 
shot was validated as is. Nice rdb in c4d, with easy control, but the fracture 
tool is just a bad joke.
I'm half happy with momentum, some nice ice control, but feels maybe 
unfinished. Or maybe not enough docs.
So well, the  ice destruction is a side project. I'm very happy with that 
cluster solved problem :)
Still some rotation problem I might ask you ;)

And the whole project is a documentary about le Louvre, how it was built along 
history. 

Le 6 oct. 2015 20:25, <pete...@skynet.be> a écrit :

  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 

Re: Cluster of points driving another cluster of points

[peter_b]

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.

Re: Cluster of points driving another cluster of points

[peter_b]

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 up

Re: Cluster of points driving another cluster of points

[Olivier Jeannel]

Ok I'll check that tomorrow ;)
Well, the ribbon plan is ended, i defenetly prefer the tests I made rather
than the end result, but at least the director is happy.
Too bad the  strand orientation is such a nightmare, could have be so cool
with sole little maintenance...

The destruction (it's another shot) part is because I decided to run some
tests on ice. In fact the sequence has been made in c4d and the fractures
were so bad that I felt the need to prepare a backup solution just in case.
Finally the shot was validated as is. Nice rdb in c4d, with easy control,
but the fracture tool is just a bad joke.
I'm half happy with momentum, some nice ice control, but feels maybe
unfinished. Or maybe not enough docs.
So well, the  ice destruction is a side project. I'm very happy with that
cluster solved problem :)
Still some rotation problem I might ask you ;)

And the whole project is a documentary about le Louvre, how it was built
along history.
Le 6 oct. 2015 20:25, <pete...@skynet.be> a écrit :

> 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 <facialdel...@gmail.com>
> *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 <facialdel...@gmail.com>
>> *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 

Re: Cluster of points driving another cluster of points

[pedro santos]

Hi Olivier

the static value is static kine state, I'm almost saying you could just use
the envelope ICE solver since this what you're doing mapping influence that
after will be translated into tranformations. But since I don't know if the
compound is easy to adapt to your case here's a small payload:
https://app.box.com/s/gb34e136cpusg78kc95nhm7yk1ch2ydv
I fleshed out some compound like I had done in LightWave, to basically
transform 3Dvector, 2D and scalar. Here you just want the 3D Transform. The
only new addition to a simply multiply by matrix is the Center.

I assume that there is a position where the master point does no
transformation on the cluster. That's the position you want to store. Just
Set it per point in a Tree lower in the stack, set the pb_HoldParameter
compound in a Tree above and then freeze the Tree below. The compound will
keep the values live, so you can calculate the master ID and the Center
position, and access it as a static parameter, will not update again when
the master points move because is not being calculated, but looked up on
the HoldParameter compound. Like I said this is a way I've found to have
static parameters that do not update (you don't want the master points
position update to change which points are being transformed by them I
think) or when the calculations are heavy, and you just want to keep the
result and not cleaned up by ICE garbage collection.

Image: http://prntscr.com/8okmqe  Set the pb_HoldParameter in the Top Tree
for master point rest position an for the ID of the master point for each
point in the grid point cloud. Then Freeze the bottom Tree.

Cheers

On Tue, Oct 6, 2015 at 11:58 AM, Olivier Jeannel 
wrote:

> Thank you Pedro !
> The Master particles center are moving, and the slaves are supposed to
> move (SRT) driven by the master their belong to.
> Where I'm lost is : how do I create a static value / rest Position ?
> You freeze the Master, but then how do I animate it ? am I supposed to
> clone it ?
>
>
> I get the concept I think, but I'm a bit lost.
>
>
>
> On Tue, Oct 6, 2015 at 12:29 PM, pedro santos  wrote:
>
>> So assuming the point could items are not animated and you want a static
>> area of influence, kine.global = kine.local.
>>
>> You can store for each point in the grid the id of the master point. So
>> you don't have this calculation live, but set in one ICE Tree and Tree
>> above. So when you freeze the calculation one the other keeps the stored
>> value live, without the calculation ( like I go through here:
>> vimeo.com/138074155#t=16m10s ) This can be useful when the calculation
>> that generates the value is heavy or the the data is changing state and you
>> want a static reference (in this case, which master point are the small
>> points following).
>>
>> Other than that is like I told, this is like a "cluster with center". I
>> don't know if this is simulated or not, so I could be failing to see some
>> extra details, but:
>> Store not just the ID of the master point for each point, but also where
>> it is his "rest position", like a static value.
>> For each point you'll subtract the "rest position" of the corresponding
>> ID master point. You'll apply it's corresponding Scale and Rotation and
>> then put it back by adding the "rest position". Afterwards you add to them
>> the corresponding master point current position (which will probably be
>> different by now than the "rest position" used as pivot)
>>
>> image: http://prntscr.com/8ob1lv
>>
>>
>> Cheers
>>
>>
>> On Tue, Oct 6, 2015 at 10:57 AM, Olivier Jeannel 
>> wrote:
>>
>>> Here's a pic, what do you think ?
>>> [image: Inline image 1]
>>>
>>> On Tue, Oct 6, 2015 at 6:20 AM, pedro santos  wrote:
>>>
 So for each point in cloud A you want the same corresponding(i) in
 cloud B to be the scaling and rotation pivot? Do you additionally want it
 to be position driver?

 I don't know how you're applying the transformations, but basically
 just center A ones on B ones: cloudA[i].position *-* cloudB[i].position
 ||| then apply Scale and Rotation to cloudA[i ||| then cloudA[i].position
 *+* cloudB[i].position if it's just for scaling and rotation.

 Images, images save lives :D


 cheers

 On Mon, Oct 5, 2015 at 10:44 PM, Olivier Jeannel <
 facialdel...@gmail.com> wrote:

> @ eric : Slaves are taking the closest master.
> @ Simon no, one cluster of slaves is like "parented" to one master.
> A sort of multiply by  matrix
> The closest slaves particles get their SRT multiplied by the matrix of
> their respective slave.
>
>
>
>
>
> On Mon, Oct 5, 2015 at 11:15 PM, Simon Reeves 
> wrote:
>
>> Or do you want all of the slaves to using the average position of all
>> the masters?
>>
>> On Mon, 5 Oct 2015 at 21:20, Eric Thivierge 

Re: Cluster of points driving another cluster of points

[Olivier Jeannel]

Here's a pic, what do you think ?
[image: Inline image 1]

On Tue, Oct 6, 2015 at 6:20 AM, pedro santos  wrote:

> So for each point in cloud A you want the same corresponding(i) in cloud B
> to be the scaling and rotation pivot? Do you additionally want it to be
> position driver?
>
> I don't know how you're applying the transformations, but basically just
> center A ones on B ones: cloudA[i].position *-* cloudB[i].position |||
> then apply Scale and Rotation to cloudA[i ||| then cloudA[i].position *+* 
> cloudB[i].position
> if it's just for scaling and rotation.
>
> Images, images save lives :D
>
>
> cheers
>
> On Mon, Oct 5, 2015 at 10:44 PM, Olivier Jeannel 
> wrote:
>
>> @ eric : Slaves are taking the closest master.
>> @ Simon no, one cluster of slaves is like "parented" to one master.
>> A sort of multiply by  matrix
>> The closest slaves particles get their SRT multiplied by the matrix of
>> their respective slave.
>>
>>
>>
>>
>>
>> On Mon, Oct 5, 2015 at 11:15 PM, Simon Reeves 
>> wrote:
>>
>>> Or do you want all of the slaves to using the average position of all
>>> the masters?
>>>
>>> On Mon, 5 Oct 2015 at 21:20, Eric Thivierge 
>>> wrote:
>>>
 How are you going to tell which slave to follow which master?

 
 Eric Thivierge
 http://www.ethivierge.com

 On Mon, Oct 5, 2015 at 4:08 PM, Olivier Jeannel  wrote:

> 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.
>

 --
>>> Simon Reeves
>>> London, UK
>>> *si...@simonreeves.com *
>>> *www.simonreeves.com *
>>> *www.analogstudio.co.uk *
>>>
>>
>>
>
>
> --
>
>
>
> *--[image:
> http://i153.photobucket.com/albums/s202/animatics/probiner-sig.gif]Pedro
> Alpiarça dos Santos >>  http://probiner.xyz/ 
> *
>

Re: Cluster of points driving another cluster of points

[pedro santos]

So assuming the point could items are not animated and you want a static
area of influence, kine.global = kine.local.

You can store for each point in the grid the id of the master point. So you
don't have this calculation live, but set in one ICE Tree and Tree above.
So when you freeze the calculation one the other keeps the stored value
live, without the calculation ( like I go through here:
vimeo.com/138074155#t=16m10s ) This can be useful when the calculation that
generates the value is heavy or the the data is changing state and you want
a static reference (in this case, which master point are the small points
following).

Other than that is like I told, this is like a "cluster with center". I
don't know if this is simulated or not, so I could be failing to see some
extra details, but:
Store not just the ID of the master point for each point, but also where it
is his "rest position", like a static value.
For each point you'll subtract the "rest position" of the corresponding ID
master point. You'll apply it's corresponding Scale and Rotation and then
put it back by adding the "rest position". Afterwards you add to them the
corresponding master point current position (which will probably be
different by now than the "rest position" used as pivot)

image: http://prntscr.com/8ob1lv


Cheers


On Tue, Oct 6, 2015 at 10:57 AM, Olivier Jeannel 
wrote:

> Here's a pic, what do you think ?
> [image: Inline image 1]
>
> On Tue, Oct 6, 2015 at 6:20 AM, pedro santos  wrote:
>
>> So for each point in cloud A you want the same corresponding(i) in cloud
>> B to be the scaling and rotation pivot? Do you additionally want it to be
>> position driver?
>>
>> I don't know how you're applying the transformations, but basically just
>> center A ones on B ones: cloudA[i].position *-* cloudB[i].position |||
>> then apply Scale and Rotation to cloudA[i ||| then cloudA[i].position *+* 
>> cloudB[i].position
>> if it's just for scaling and rotation.
>>
>> Images, images save lives :D
>>
>>
>> cheers
>>
>> On Mon, Oct 5, 2015 at 10:44 PM, Olivier Jeannel 
>> wrote:
>>
>>> @ eric : Slaves are taking the closest master.
>>> @ Simon no, one cluster of slaves is like "parented" to one master.
>>> A sort of multiply by  matrix
>>> The closest slaves particles get their SRT multiplied by the matrix of
>>> their respective slave.
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Oct 5, 2015 at 11:15 PM, Simon Reeves 
>>> wrote:
>>>
 Or do you want all of the slaves to using the average position of all
 the masters?

 On Mon, 5 Oct 2015 at 21:20, Eric Thivierge 
 wrote:

> How are you going to tell which slave to follow which master?
>
> 
> Eric Thivierge
> http://www.ethivierge.com
>
> On Mon, Oct 5, 2015 at 4:08 PM, Olivier Jeannel <
> facialdel...@gmail.com> wrote:
>
>> 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.
>>
>
> --
 Simon Reeves
 London, UK
 *si...@simonreeves.com *
 *www.simonreeves.com *
 *www.analogstudio.co.uk *

>>>
>>>
>>
>>
>> --
>>
>>
>>
>> *--[image:
>> http://i153.photobucket.com/albums/s202/animatics/probiner-sig.gif]Pedro
>> Alpiarça dos Santos >>  http://probiner.xyz/ 
>> *
>>
>
>


-- 



*--[image:
http://i153.photobucket.com/albums/s202/animatics/probiner-sig.gif]Pedro
Alpiarça dos Santos >>  http://probiner.xyz/ 
*

Re: Cluster of points driving another cluster of points

[Olivier Jeannel]

Thank you Pedro !
The Master particles center are moving, and the slaves are supposed to move
(SRT) driven by the master their belong to.
Where I'm lost is : how do I create a static value / rest Position ?
You freeze the Master, but then how do I animate it ? am I supposed to
clone it ?


I get the concept I think, but I'm a bit lost.



On Tue, Oct 6, 2015 at 12:29 PM, pedro santos  wrote:

> So assuming the point could items are not animated and you want a static
> area of influence, kine.global = kine.local.
>
> You can store for each point in the grid the id of the master point. So
> you don't have this calculation live, but set in one ICE Tree and Tree
> above. So when you freeze the calculation one the other keeps the stored
> value live, without the calculation ( like I go through here:
> vimeo.com/138074155#t=16m10s ) This can be useful when the calculation
> that generates the value is heavy or the the data is changing state and you
> want a static reference (in this case, which master point are the small
> points following).
>
> Other than that is like I told, this is like a "cluster with center". I
> don't know if this is simulated or not, so I could be failing to see some
> extra details, but:
> Store not just the ID of the master point for each point, but also where
> it is his "rest position", like a static value.
> For each point you'll subtract the "rest position" of the corresponding ID
> master point. You'll apply it's corresponding Scale and Rotation and then
> put it back by adding the "rest position". Afterwards you add to them the
> corresponding master point current position (which will probably be
> different by now than the "rest position" used as pivot)
>
> image: http://prntscr.com/8ob1lv
>
>
> Cheers
>
>
> On Tue, Oct 6, 2015 at 10:57 AM, Olivier Jeannel 
> wrote:
>
>> Here's a pic, what do you think ?
>> [image: Inline image 1]
>>
>> On Tue, Oct 6, 2015 at 6:20 AM, pedro santos  wrote:
>>
>>> So for each point in cloud A you want the same corresponding(i) in cloud
>>> B to be the scaling and rotation pivot? Do you additionally want it to be
>>> position driver?
>>>
>>> I don't know how you're applying the transformations, but basically just
>>> center A ones on B ones: cloudA[i].position *-* cloudB[i].position |||
>>> then apply Scale and Rotation to cloudA[i ||| then cloudA[i].position
>>> *+* cloudB[i].position if it's just for scaling and rotation.
>>>
>>> Images, images save lives :D
>>>
>>>
>>> cheers
>>>
>>> On Mon, Oct 5, 2015 at 10:44 PM, Olivier Jeannel >> > wrote:
>>>
 @ eric : Slaves are taking the closest master.
 @ Simon no, one cluster of slaves is like "parented" to one master.
 A sort of multiply by  matrix
 The closest slaves particles get their SRT multiplied by the matrix of
 their respective slave.





 On Mon, Oct 5, 2015 at 11:15 PM, Simon Reeves 
 wrote:

> Or do you want all of the slaves to using the average position of all
> the masters?
>
> On Mon, 5 Oct 2015 at 21:20, Eric Thivierge 
> wrote:
>
>> How are you going to tell which slave to follow which master?
>>
>> 
>> Eric Thivierge
>> http://www.ethivierge.com
>>
>> On Mon, Oct 5, 2015 at 4:08 PM, Olivier Jeannel <
>> facialdel...@gmail.com> wrote:
>>
>>> 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.
>>>
>>
>> --
> Simon Reeves
> London, UK
> *si...@simonreeves.com *
> *www.simonreeves.com *
> *www.analogstudio.co.uk *
>


>>>
>>>
>>> --
>>>
>>>
>>>
>>> *--[image:
>>> http://i153.photobucket.com/albums/s202/animatics/probiner-sig.gif]Pedro
>>> Alpiarça dos Santos >>  http://probiner.xyz/ 
>>> *
>>>
>>
>>
>
>
> --
>
>
>
> *--[image:
> http://i153.photobucket.com/albums/s202/animatics/probiner-sig.gif]Pedro
> Alpiarça dos Santos >>  http://probiner.xyz/ 
> *
>

Re: Cluster of points driving another cluster of points

[Olivier Jeannel]

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 <facialdel...@gmail.com>
> *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.
>

Re: Cluster of points driving another cluster of points

[peter_b]

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.

Re: Cluster of points driving another cluster of points

[Olivier Jeannel]

Pfoo the Closest point and the Find in Array (boolean), I would never
have guessed ^^

On Tue, Oct 6, 2015 at 7:39 PM, Olivier Jeannel <facialdel...@gmail.com>
wrote:

> Done something, thanks to you peter :)
>
> Simulated, sadly but that's something at least to me :)
>
> On Tue, Oct 6, 2015 at 6:59 PM, Olivier Jeannel <facialdel...@gmail.com>
> wrote:
>
>> 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 <facialdel...@gmail.com>
>>> *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

Re: Cluster of points driving another cluster of points

[Olivier Jeannel]

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 <facialdel...@gmail.com>
> *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

Re: Cluster of points driving another cluster of points

[Eric Thivierge]

How are you going to tell which slave to follow which master?


Eric Thivierge
http://www.ethivierge.com

On Mon, Oct 5, 2015 at 4:08 PM, Olivier Jeannel 
wrote:

> 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.
>

Cluster of points driving another cluster of points

[Olivier Jeannel]

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.

Re: Cluster of points driving another cluster of points

[Olivier Jeannel]

@ eric : Slaves are taking the closest master.
@ Simon no, one cluster of slaves is like "parented" to one master.
A sort of multiply by  matrix
The closest slaves particles get their SRT multiplied by the matrix of
their respective slave.





On Mon, Oct 5, 2015 at 11:15 PM, Simon Reeves  wrote:

> Or do you want all of the slaves to using the average position of all the
> masters?
>
> On Mon, 5 Oct 2015 at 21:20, Eric Thivierge  wrote:
>
>> How are you going to tell which slave to follow which master?
>>
>> 
>> Eric Thivierge
>> http://www.ethivierge.com
>>
>> On Mon, Oct 5, 2015 at 4:08 PM, Olivier Jeannel 
>> wrote:
>>
>>> 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.
>>>
>>
>> --
> Simon Reeves
> London, UK
> *si...@simonreeves.com *
> *www.simonreeves.com *
> *www.analogstudio.co.uk *
>

Re: Cluster of points driving another cluster of points

[Simon Reeves]

Or do you want all of the slaves to using the average position of all the
masters?
On Mon, 5 Oct 2015 at 21:20, Eric Thivierge  wrote:

> How are you going to tell which slave to follow which master?
>
> 
> Eric Thivierge
> http://www.ethivierge.com
>
> On Mon, Oct 5, 2015 at 4:08 PM, Olivier Jeannel 
> wrote:
>
>> 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.
>>
>
> --
Simon Reeves
London, UK
*si...@simonreeves.com *
*www.simonreeves.com *
*www.analogstudio.co.uk *

Re: Cluster of points driving another cluster of points

[pedro santos]

So for each point in cloud A you want the same corresponding(i) in cloud B
to be the scaling and rotation pivot? Do you additionally want it to be
position driver?

I don't know how you're applying the transformations, but basically just
center A ones on B ones: cloudA[i].position *-* cloudB[i].position ||| then
apply Scale and Rotation to cloudA[i ||| then cloudA[i].position *+*
cloudB[i].position
if it's just for scaling and rotation.

Images, images save lives :D


cheers

On Mon, Oct 5, 2015 at 10:44 PM, Olivier Jeannel 
wrote:

> @ eric : Slaves are taking the closest master.
> @ Simon no, one cluster of slaves is like "parented" to one master.
> A sort of multiply by  matrix
> The closest slaves particles get their SRT multiplied by the matrix of
> their respective slave.
>
>
>
>
>
> On Mon, Oct 5, 2015 at 11:15 PM, Simon Reeves 
> wrote:
>
>> Or do you want all of the slaves to using the average position of all the
>> masters?
>>
>> On Mon, 5 Oct 2015 at 21:20, Eric Thivierge  wrote:
>>
>>> How are you going to tell which slave to follow which master?
>>>
>>> 
>>> Eric Thivierge
>>> http://www.ethivierge.com
>>>
>>> On Mon, Oct 5, 2015 at 4:08 PM, Olivier Jeannel 
>>> wrote:
>>>
 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.

>>>
>>> --
>> Simon Reeves
>> London, UK
>> *si...@simonreeves.com *
>> *www.simonreeves.com *
>> *www.analogstudio.co.uk *
>>
>
>


-- 



*--[image:
http://i153.photobucket.com/albums/s202/animatics/probiner-sig.gif]Pedro
Alpiarça dos Santos >>  http://probiner.xyz/ 
*