To the original question, you should be able to do it quite simply by
seeding vortices particles (just flag them as vortices on emit), then
computing the curl of the field. Finally you can use that as a force on
each particle.
To satisfy vortex equation [image: \vec \omega = \nabla \times \vec
\mathit{u}.] each vortex particle (a random probability of being a vortex
particle for simplicity), should give a spin axis (random) and a radius
(might be random, but physically it shouldn't without more sophisticated
volume conservation techniques).
You then need to search for the closest vortex particles - using a large
radius (normally the radius of the biggest vortex). Then compute the sum of
all velocity perpendicular to the spin axis of the closest vortices.
using lagoa you could probably set that as a force on each particle, and
then let the integrator do the rest.
Thiago
On 4 June 2012 14:22, Byron Nash <[email protected]> wrote:
> Thanks for the tips and example Andy (& everyone). I'll work on
> implementing this into my approach.
>
>
> On Mon, Jun 4, 2012 at 1:32 PM, Jonathan Laborde
> <[email protected]>wrote:
>
>> I made 2 compounds that I use regularly to calculate velocity properly.
>> You basically store the current point position and orientation at the
>> beginning of every frame (first port in the stack). Even if you are say on
>> frame 10, since it's the first thing being calculated in the stack the
>> point position is still from frame 9. Then in post-simulation you do the
>> actual calculation and store it in pointvelocity and angularvelocity, that
>> way it won't affect the following frames.
>> It works well, unless you are moving the points in post-simulation as
>> they won't be calculated at the beginning of the next frame.
>> Enjoy!
>> --*
>> **JONATHAN LABORDE*
>> FX Artist
>>
>> www.rodeofx.com
>>
>>
>> On Mon, Jun 4, 2012 at 12:25 PM, Grahame Fuller <
>> [email protected]> wrote:
>>
>>> Verlet integration might be useful in these cases. With Verlet
>>> integration, you store the previous positions and back-calculate the
>>> velocity from that, instead of calculating the forward velocity as in
>>> standard Euler integration.
>>>
>>> gray
>>>
>>> From: [email protected] [mailto:
>>> [email protected]] On Behalf Of Andy Moorer
>>> Sent: Sunday, June 03, 2012 02:18 PM
>>> To: [email protected]
>>> Cc: [email protected]
>>> Subject: Re: ICE: Vortex and Lagoa
>>>
>>> Yeah I should have pointed that out... There's always a sacrifice
>>> between the simplicity and emergent behavior of simulations and the control
>>> you can get by being more direct and specifying explicit positions per
>>> frame.
>>>
>>> The more "custom" you get, the more you have to chase down and account
>>> for this kind of thing. The motionblur problem with nonsimulated ICE
>>> animations is the biggie - enough so that it might be advisable for the
>>> softimage devs to implement some in-box solutions, like perhaps an option
>>> for computing a per point velocity during caching, or writing special
>>> "absolute" point position and velocity variables after the post-process
>>> step...
>>>
>>>
>>> On Jun 3, 2012, at 1:36 PM, Jonathan Laborde <[email protected]
>>> <mailto:[email protected]>> wrote:
>>> Great answer Andy. But be careful with such a technique (blend between
>>> simulation and manual positioning) as the point position will be as you
>>> expect but point velocity will not be calculated properly. Your motion blur
>>> will be wrong in that case, and you will have tu manually set it in post
>>> process.
>>> Rock n' roll
>>> --
>>> JONATHAN LABORDE
>>> FX Artist
>>>
>>> www.rodeofx.com<http://www.rodeofx.com/>
>>>
>>> On Sun, Jun 3, 2012 at 11:33 AM, Andy Moorer <[email protected]
>>> <mailto:[email protected]>> wrote:
>>> Byron hi there. Can't answer your questions about differences between
>>> lagoa and "normal" reaction to forces, but the results you are seeing with
>>> a combination of forces (one to move particles along a curve, the other to
>>> draw particles towards a curve) is one I'm familiar with. It's easy to fall
>>> into the "simulation trap," where you drive yourself crazy trying to find a
>>> perfect balance of forces to get the results you want.
>>>
>>> There are a couple of suggestions I can give you... The first is to
>>> clamp the maximum speed at which a particle is allowed to move: get
>>> particle velocity, get "length" or magnitude of the vector (this is
>>> "speed.") If the speed > a max value you set, new speed=max value.
>>> Normalize your original velocity vector and multiply it by new-speed.
>>>
>>> The result, particles obey the forces you set, but never travel so fast
>>> that they get flung away, and never develop enough momentum to get out of
>>> control. A drag force coupled with velocity can produce similar results .
>>>
>>> Another option is to replace or blend your "suction" and "along curve"
>>> forces with a setup which places each particle at a specific position in
>>> relation to the curve, animated of course. I haven't tried this kind of
>>> approach in this particular context, but in general the result is a hybrid
>>> of a simulated look and an "absolute" look... particles are simulated to a
>>> certain extent, blending to an absolute predetermined position. I've
>>> attached a simple example of this kind of thing, a simple post-sim blend
>>> between a simulation and goal positions on geometry.
>>>
>>> Cheers
>>> Andy
>>>
>>> On Fri, Jun 1, 2012 at 9:32 AM, Byron Nash <[email protected]<mailto:
>>> [email protected]>> wrote:
>>> I'm trying to make something along the lines of this video from Firebird
>>> https://vimeo.com/29367269. It uses Lagoa and some of the vortex
>>> techniques Brad showed in one of his videos. I can get it to move somewhat
>>> but can't keep the points on the curve. They tend to fling off despite
>>> increasing the "suction" controls. How does Lagoa respond differently to
>>> forces than normal ICE particles?
>>>
>>>
>>>
>>
>
