Hi,

I wonder, what would be the best way to timewarp a FLIP fluid simulation? I'm talking about going from realtime (24fps) to say slowmotion (1000fps) and back.

In real life they shoot at 1000fps and do a post timewarp. In simulation land this is quite painful because it takes an awful long time and you throw away a lot.

Ideally I would like to be able to animate something like the timescale attribute on the DOP network. This way you only simulate what you eventually need. How ever this parameter is not ‘animatable’.
You might argue that this is more difficult to tweak because one needs to resim and wish one could do a post timewarp, but I think in the end its the fasted/most detailed method.

With less extreme examples you might be able to do some trickery in SOP's, but this will always be a linear interpolation and you lose the non-diversion property during the in-between frames.

What about .sim files, is there anything we can do with that?

Would it be an option to build a FLIP retime solver which uses an existing FLIP sim (at real time) written out as a .sim seq?

I'm not sure what you would accomplish with a .sim file, aside from sop-dop pipe speed, as opposed to fields in .bgeo form.

It might be worth investigating the attract fluid otls since you essentially want to enforce a “goal” surface field and velocity field given a specific timescale and frange between each frame.

The accuracy of these would be questionable though since those fields are so heavily modified by the particle body, you're really only indirectly controlling the particles in this manner.

houdinick
With less extreme examples you might be able to do some trickery in SOP's, but this will always be a linear interpolation and you lose the non-diversion property during the in-between frames.

Not claiming it has any sense in your case, but this doesn't have to be linear. You could interpolate cubic splines along 3 or 5 consequent frames using particles' id. It takes some hassle to deal with just-seed or about-to-die points but might work.

That is what I have been thinking of since I created this topic. Though I haven't tested if CHOPS can create curves based on ID's instead of point numbers. Let alone how CHOPS behaves when it has to deal with 5 million curves.

I sense it starts with writing out a .clip file and not opening a motion view or curve editor ;-).

Has any one any experience with large number of curves and particle ID's in CHOPS?

I can confirm that retiming particles with CHOPs and using the id attribute works. We only need to figure out something smart to solve the problem of the birth and death of particles. The channel SOP seems to like static geometry that it can ‘deform’ based on a CHOP curve.

From the top of my head, maybe analyze the particles with a Solver SOP, and recreate new points when its corresponding particle is born with corresponding ID's and position frozen in space and remove them when the original point died keeping for the birth and dead the timewarp in mind.

Sounds like a python SOP, Solver SOP and some additional CHOP channels?

It would be so cool if you could sim FLIP particles at 24FPS and timewarp them to 1000FPS, with a speed ramp and all :-D

Call me crazy, but I once did that by using a foreach SOP… I had a lot less particles (few hundreds) and it worked. Really not sure what will happen with 5 million particles though…

Cheers

houdinick
Has any one any experience with large number of curves and particle ID's in CHOPS?

I'm not sure if Chops are the way to go in its current shape (poor shape). Flip tents to operate on millions on points - that might be harmful.

AFAIK you can do the same with pure sops and vex workflow* with a couple of File nodes, and vops.

Point SOP is a handy tool for querying P based on id without any setup. Policy to handle missing points might be to delete now if dies in next frame (PointSOP will set P to (0,0,0,) on missing id), set future position with P+v, previous P-v etc etc. I'm attaching video, don't have the hip though, but it was pure sops and practically free in terms of memory/cpu.

skk.

* - I was doing it once albeit I was mostly interested in interpolating particles at render time, I made the same thing in sops - and finally with vex extension, but this was only an optimization.

I assume you used linear interpolation right? Did you ever noticed the angular steps when a particle passes a ‘key’ frame and suddenly moves in a different direction?

houdinick
I assume you used linear interpolation right? Did you ever noticed the angular steps when a particle passes a ‘key’ frame and suddenly moves in a different direction?

Well, my main motivation was to avoid linear motion blur, that's why I was using up to 5 frames (2xpre, current, 2xafter), and some sort of interpolations (the best I've found was baricentric rational).

Hi SYmek, I just had a look at the ‘barycentric rational’ paper I found on Google. Are you implying you understand this!? Any chance you could explain it in Human? ;-)

http://www.google.nl/url?sa=t&rct=j&q=&esrc=s&source=web&cd=4&cad=rja&ved=0CEwQFjAD&url=http%3A%2F%2Fcg.in.tu-clausthal.de%2Fpapers%2Fhormann%2FDarmstadt.2006.pdf&ei=P1y2UKX3B4HM0AXcq4HgAw&usg=AFQjCNG6bskgV7ITvjcIAcIbEt0Lf-iIkw [google.nl]

houdinick
Hi SYmek, I just had a look at the ‘barycentric rational’ paper I found on Google. Are you implying you understand this!?

O no, I don't have to. I have Numerical Recipes on my shelf . This is really a minor issue here. Cubic splines might work as well as them (or better*). I've chosen bri, because they were easy to implement and their second derivatives are constants, what brings the least possible addition to a hypothetical ballistics.

skk.

* - splines (and other intepolants) are so esoteric subject that I really can't claim anything about it without risking serious misunderstanding.