ICE - Offset node-animation per particle

2012-04-17 Thread Thomas Volkmann
Good morning List,

maybe it's just too early, but I have a scalar-node with animation on it
(that is supposed to drive scaling) and I want it to offset to get some
variation. Is this possible in this easy way, or do I have to give each
point a triggerAtFrame-attribute, compare to current frame and use a new
state (or similar using an if-node).
How do you do this normally? (I do it with if-nodes, current-frame compared
to triggerFrame and rescaling usually, but my mind is so slow this morning
that I am longing for a quick one-node solution)

Thanks,
Thomas

Re: ICE - Offset node-animation per particle

2012-04-17 Thread Alan Fregtman
How about plugging that animated Scalar node's output into a Multiply 
node's first input, then on its second input you plug either a Turbulize 
Around Value or a Randomize Around Value, where either's "base value" is 
set to 1. That should do it.


On 4/17/2012 4:02 AM, Thomas Volkmann wrote:


Good morning List,


maybe it's just too early, but I have a scalar-node with animation on 
it (that is supposed to drive scaling) and I want it to offset to get 
some variation. Is this possible in this easy way, or do I have to 
give each point a triggerAtFrame-attribute, compare to current frame 
and use a new state (or similar using an if-node).


How do you do this normally? (I do it with if-nodes, current-frame 
compared to triggerFrame and rescaling usually, but my mind is so slow 
this morning that I am longing for a quick one-node solution)



Thanks,

Thomas





Re: ICE - Offset node-animation per particle

2012-04-17 Thread Thomas Volkmann
But this only gives a variation of the intensity, not of the timing. I
ended up doing it as I always do it...I really should start setting up
custom compounds for stuff I do again and again.
Thanks!


Alan Fregtman  hat am 17. April 2012 um 15:36
geschrieben:

> Scalar node's output into a Multiply node's first input, then on its second
> input you plug either a Turbulize Around Value or a Randomize Around Value,
> where either's "base value" is set to 1. That should do it.
> 
> On 4/17/2012 4:02 AM, Thomas Volkmann wrote:
> > Good morning List,
> > 
> > maybe it's just too early, but I have a scalar-node with animation on it
> > (that is supposed to drive scaling) and I want it to offset to get some
> > variation. Is this possible in this easy way, or do I have to give each
> > point a triggerAtFrame-attribute, compare to current frame and use a new
> > state (or similar using an if-node).
> > How do you do this normally? (I do it with if-nodes, current-frame compared
> > to triggerFrame and rescaling usually, but my mind is so slow this morning
> > that I am longing for a quick one-node solution)
> > 
> > Thanks,
> > Thomas


Re: ICE - Offset node-animation per particle

2012-04-17 Thread Alan Fregtman
You can't query data at random frames, so unless you made your animated 
data into an array, you can't offset in X (time), only in Y (value). 
(Not with ICE, anyway.)


With 2013's new SDK enhancements you could at least easily write the 
array via scripting... but I think that's overcomplicated for what you seek.



On 4/17/2012 9:49 AM, Thomas Volkmann wrote:


But this only gives a variation of the intensity, not of the timing. I 
ended up doing it as I always do it...I really should start setting up 
custom compounds for stuff I do again and again.


Thanks!


Alan Fregtman  hat am 17. April 2012 um 
15:36 geschrieben:


How about plugging that animated Scalar node's output into a
Multiply node's first input, then on its second input you plug
either a Turbulize Around Value or a Randomize Around Value, where
either's "base value" is set to 1. That should do it.

On 4/17/2012 4:02 AM, Thomas Volkmann wrote:

Good morning List,


maybe it's just too early, but I have a scalar-node with
animation on it (that is supposed to drive scaling) and I want
it to offset to get some variation. Is this possible in this
easy way, or do I have to give each point a
triggerAtFrame-attribute, compare to current frame and use a
new state (or similar using an if-node).

How do you do this normally? (I do it with if-nodes,
current-frame compared to triggerFrame and rescaling usually,
but my mind is so slow this morning that I am longing for a
quick one-node solution)


Thanks,

Thomas






Re: ICE - Offset node-animation per particle

2012-04-17 Thread Alan Fregtman

  
  
It may not be the effect you're after, but here's a crude non-ICE
approach with an _expression_ offsetting the original fcurve in X
using noise:




On 4/17/2012 10:14 AM, Alan Fregtman wrote:

  
  You can't query data at random frames, so unless you made your
  animated data into an array, you can't offset in X (time), only in
  Y (value). (Not with ICE, anyway.)
  
  With 2013's new SDK enhancements you could at least easily write
  the array via scripting... but I think that's overcomplicated for
  what you seek.
  
  
  On 4/17/2012 9:49 AM, Thomas Volkmann wrote:
  

 But this only gives a variation of
the intensity, not of the timing. I ended up doing it as I
always do it...I really should start setting up custom
compounds for stuff I do again and again. 
 Thanks! 
 
  Alan Fregtman 
  hat am 17. April 2012 um 15:36 geschrieben: 
  
  
 How about plugging that
  animated Scalar node's output into a Multiply node's first
  input, then on its second input you plug either a
  Turbulize Around Value or a Randomize Around Value, where
  either's "base value" is set to 1. That should do it. 
  
  On 4/17/2012 4:02 AM, Thomas Volkmann wrote:
  
  Good morning List,
   
   
  
  maybe it's just
  too early, but I have a scalar-node with animation
  on it (that is supposed to drive scaling) and I
  want it to offset to get some variation. Is this
  possible in this easy way, or do I have to give
  each point a triggerAtFrame-attribute, compare to
  current frame and use a new state (or similar
  using an if-node).  
  How do you do this
  normally? (I do it with if-nodes, current-frame
  compared to triggerFrame and rescaling usually,
  but my mind is so slow this morning that I am
  longing for a quick one-node solution) 

   
  
  Thanks, 

  Thomas 

  


  

  
  


  



Re: ICE - Offset node-animation per particle

2012-04-18 Thread Christian Keller
Hey Thomas !

I always put that stuff in arrays. 
There are many ways to achieve that.
And then it's nice to shift and interpolate 

Greetings from HH

Chris

-- 
christian keller
visual effects|direction

m +49 179 69 36 248
f +49 40 386 835 33
chris3...@me.com

gesendet von meinem iDing

Am 17.04.2012 um 16:48 schrieb Alan Fregtman :

> It may not be the effect you're after, but here's a crude non-ICE approach 
> with an expression offsetting the original fcurve in X using noise:
> 
> 
> 
> 
> On 4/17/2012 10:14 AM, Alan Fregtman wrote:
>> 
>> You can't query data at random frames, so unless you made your animated data 
>> into an array, you can't offset in X (time), only in Y (value). (Not with 
>> ICE, anyway.)
>> 
>> With 2013's new SDK enhancements you could at least easily write the array 
>> via scripting... but I think that's overcomplicated for what you seek.
>> 
>> 
>> On 4/17/2012 9:49 AM, Thomas Volkmann wrote:
>>> 
>>> But this only gives a variation of the intensity, not of the timing. I 
>>> ended up doing it as I always do it...I really should start setting up 
>>> custom compounds for stuff I do again and again.
>>> Thanks!
>>> 
>>> Alan Fregtman  hat am 17. April 2012 um 15:36 
>>> geschrieben: 
>>> 
>>> How about plugging that animated Scalar node's output into a Multiply 
>>> node's first input, then on its second input you plug either a Turbulize 
>>> Around Value or a Randomize Around Value, where either's "base value" is 
>>> set to 1. That should do it. 
>>> 
>>> On 4/17/2012 4:02 AM, Thomas Volkmann wrote:
>>> Good morning List,
>>> 
>>> maybe it's just too early, but I have a scalar-node with animation on it 
>>> (that is supposed to drive scaling) and I want it to offset to get some 
>>> variation. Is this possible in this easy way, or do I have to give each 
>>> point a triggerAtFrame-attribute, compare to current frame and use a new 
>>> state (or similar using an if-node).
>>> How do you do this normally? (I do it with if-nodes, current-frame compared 
>>> to triggerFrame and rescaling usually, but my mind is so slow this morning 
>>> that I am longing for a quick one-node solution)
>>> 
>>> Thanks,
>>> Thomas
>>> 
>>>  
>> 
> 


Re: ICE - Offset node-animation per particle

2012-04-18 Thread Thomas Volkmann
Hej Chris,

how is the weather in HH? ( The webcam on
http://hamburger-rathausmarkt.de/   is
down for some weeks now, and I was always enjoying Hamburg's grey sky while
sitting in sunny (believe it or not!) Sweden)
Without having given further thought about it: How would I store an fcurve
into an array? Since Alan was suggesting the same thing I definitely have
to give it a try. It's always nice to see different approaches to the same
thing.

Ha det bra!
Thomas


Christian Keller  hat am 18. April 2012 um 09:26
geschrieben:

> Hey Thomas !
> 
> I always put that stuff in arrays.
> There are many ways to achieve that.
> And then it's nice to shift and interpolate 
> 
> Greetings from HH
> 
> Chris
> 
> --
> christian keller
> visual effects|direction
> 
> m +49 179 69 36 248
> f +49 40 386 835 33
> chris3...@me.com 
> 
> gesendet von meinem iDing
> 
> Am 17.04.2012 um 16:48 schrieb Alan Fregtman < alan.fregt...@modusfx.com
>  >:
> 
> > It may not be the effect you're after, but here's a crude non-ICE approach
> > with an expression offsetting the original fcurve in X using noise:
> > 
> > 
> > 
> > 
> > On 4/17/2012 10:14 AM, Alan Fregtman wrote:
> > > frames, so unless you made your animated data into an array, you can't
> > > offset in X (time), only in Y (value). (Not with ICE, anyway.)
> > > 
> > > With 2013's new SDK enhancements you could at least easily write the array
> > > via scripting... but I think that's overcomplicated for what you seek.
> > > 
> > > 
> > > On 4/17/2012 9:49 AM, Thomas Volkmann wrote:
> > > > But this only gives a variation of the intensity, not of the timing. I
> > > > ended up doing it as I always do it...I really should start setting up
> > > > custom compounds for stuff I do again and again.
> > > > Thanks!
> > > > 
> > > > 
> > > > Alan Fregtman 
> > > >  hat am 17. April 2012 um 15:36
> > > > geschrieben:
> > > > 
> > > > > Scalar node's output into a Multiply node's first input, then on its
> > > > > second
> > > > > input you plug either a Turbulize Around Value or a Randomize Around
> > > > > Value,
> > > > > where either's "base value" is set to 1. That should do it.
> > > > > 
> > > > > On 4/17/2012 4:02 AM, Thomas Volkmann wrote:
> > > > > > Good morning List,
> > > > > > 
> > > > > > maybe it's just too early, but I have a scalar-node with animation
> > > > > > on it
> > > > > > (that is supposed to drive scaling) and I want it to offset to get
> > > > > > some
> > > > > > variation. Is this possible in this easy way, or do I have to give
> > > > > > each
> > > > > > point a triggerAtFrame-attribute, compare to current frame and use a
> > > > > > new
> > > > > > state (or similar using an if-node).
> > > > > > How do you do this normally? (I do it with if-nodes, current-frame
> > > > > > compared
> > > > > > to triggerFrame and rescaling usually, but my mind is so slow this
> > > > > > morning
> > > > > > that I am longing for a quick one-node solution)
> > > > > > 
> > > > > > Thanks,
> > > > > > Thomas
> > > > 
> > > >