Retiming FumeFX??

[gakkie]

Hello there,
im finding difficulties of making slow-motional explosion FX, using FumeFX. :?
(Reference: http://www.lucidmovement.com/?cat=47)

in normal speed (24fps) it looks fine, but i deeply stuck when it comes to slow-mo like 120fps.....
i've tried tweaking and animating timeScale, VelocityDamping, Turbulences.... i cannot get the result of the one i did in normal speed...orz

has anyone had a good result of making things slow-mo in Fume FX??
any suggestion??

Or....
is there some sort of retiming FumeFX tool (or script) like a MayaMEL script "Maya Fluids Retimer(created by Seth Hall)"???
http://www.highend3d.com/maya/downloads ... -4892.html

i think it will be great if fumeFX has some sort of Retiming tool.... :o :o :o
thanks

gakkie

[Solitude]

Not sure about doing slo-mo, however I too hope for a retiming option in future versions of fume... I suggest that in the cgfluids forum so as far as I know they have it on the wishlish.

[jrand]

Under your Simulations tab.

"Time Scale - Use this to speed up or slow down the passage of time during simulation. If you set it to 0, the simulation comes to a halt; set a higher value to increase speed. If you accelerate time by some significant amount (>1.5x), you will have to increase the simulation steps as well to preserve stability and continuity. Also, note that you can animate this parameter."

This is strickly a guess since I don't not know how the feature was built (ie if its is linear or on an exponential curve) but:
1.0 being "real-time" or 30 FPS so:
.5 would equal to 60 FPS
.25 would be equal to 120 FPS
.125 would be equal to 240 FPS

That is how I understand it anyway, I would be curious to know if that is correct.

-John

[sitnisati]

With values

[Rif]

We are talking about an After Cached Fume Retimer here correct ?
cause i think thats what was wished and i still think it could be really usefull ..

[jrand]

We are talking about an After Cached Fume Retimer here correct ?
cause i think thats what was wished and i still think it could be really usefull ..

Ahh, I see. that could be very handy wouldn't you still have to resim for fill in the extra frames? I mean at least the already sim'd frames would still exist just the frames inbetween need to be interpolated. just stretching the cache, that would look funky wouldn't it?

[sitnisati]

Probably a simple interpolation of two caches for a slow-mo effect wouldn't look good.
Imagine having an animation of a ball flying around and then interpolation of two frames -- you wouldn't get a feeling of motion.

We will look into possible options, but it's not trivial to make it look good.

Kresimir

[jrand]

I guess what I was thinking was something like (realviz retimer)that would look at a voxel in frame A, look at the same voxel in frame B, and sim an intermediate frame with the difference between the two. Personnally, doesn't seem like it would be easy to do and it could seriously break down the longer the duration between frames.

My humble opinion would think it would be easier just to be able to link the time scale of the sim to the frame rate of the animation. So if you adjusted to say 200 frames per second the the simulation would then calculate 200 sim frames per second. Making it easier to sync a slow motion animation too. Is that possible within reason?

[Solitude]

http://www.serrao3d.com/demoreel.html has an example of a fluids retimer... pretty good demo reel to watch anyway =)

[jrand]

Sorry for going a little of topic :|

Hey Ian, thanks, I have seen his reel

I have been bashing away playing with the Time Scale. Tried a script and couldn't get the math right, so trial and error it is.

Really getting some strange results, have to do some tweaking.

I have gotten what seems to be like the right numbers to scale with the framerates (thanks Kresimir), although some strange things occur with the velocities or at least on how they are being interpreted.

30FPS base of 1.0
60FPS = .5
120FPS = .25
240FPS = .125
480FPS = .063
960FPS = .031 (i haven't let this one bake all the way)

I tested with a simple source emitter smoke only with a box passing through to disturb and carry the smoke, I rendered out all the sims (60 frames, 120, frames, 240 frames, ects)
and brought them into fusion and adjusted there speeds so the all equaled one second. All of the emissions matched up but something is
screwball with the velocities. When the box pass through the smoke in the 1sec 30 FPS clip you get real sweet curls and trailing smoke, that diminishes immediately when dropping the Time Scale to .5 for 60 FPS. and act really strange at 480FPS, not sure whats up. Like I mentioned I have to play with some settings to see if it is correctable.

When I get a chance I post a vid, I gotta get away from it for a while its driving me nuts :?
Anyways,
John

[bdemetz]

We have been retiming Fume in post extensively. This is currently required because one can obtain far more detail with the same amount of ram by raising the 'time scale' parameter. Personally I've never created a decent explosion with a 'time scale' lower than 3 to 5. The only issue, of course, is that the explosions end up moving too quickly and need to be slowed by other methods such as lower burn rate or retiming in post. It seems that optimal settings to yield the best looking detail, shape, and movement result in faster than real speed. It would be great if there was a new parameter that would simply slow the simulation down after using timescale, etc. to get the look dialed in. This was brought up some time ago and I guess I'm still pitching for it to be added/resolved in a future release. All that aside, Fume is truly a one of a kind plugin. We've used it for blasts in Die hard, Rendition, and many other features. A must have.

[bdemetz]

Not to beat a dead horse - but even a 'not-so-beautiful' solution to slow down sims is a top priority to me and my clients. They always want it highly detailed (high timescale) but they want it slo-mo overcranked. Understandably, if voxels movement is too fast, there wouldn't really be a way to interpolate that information, however if sims were not moving too quickly, and we just needed 1/4 the speed, perhaps theres a way?

Either that or if the FFX velocity channel could output the correct color gradient values that could be read by a program like Re:vision Twixtor - that might be usable as well.

[sitnisati]

Hello,

We're working on something that would allow a user to compute X-times slower simulation that will be identical to 1x sim. I hope we can make it usable for FFX 1.2.

Kresimir

[bdemetz]

Thats really awesome! By the way, I had this thought come to me yesterday, but perhaps it is really just playing catch-up with what you coding experts already understand. Since ffx is really just values propagating thru a locked grid, it seems that to slow down a sim, it would be just like doing interpolative math on the values, though if the speed was too fast, unless arc'ing of values was calculated, you'd get linear segmented interpolation (which even that would be fine in my own cases). Here's an example of what I think I'm trying to describe:

Original sim
--on frame 1:
----voxel A, density = 1
----voxel B, (right above voxel A), density = 0
--on frame 2
----voxel B, density = 1
----(density from voxel A moved to voxel B)

Now I want to slow it down 4x:
--on frame 1 (same as before):
----voxel A, density = 1
----voxel B, density = 0
--on frame 2
----voxel B, density = what used to be on frame 2 of cache divided by 4 = .25 (instead of 1)

and so on, etc.

Actually I'm sure there's more to it than this simple example. Such as that velocity also has to be taken into account since voxels at 1x that are literally skipped over and remain 0 density must be filled with a percentage of density passing thru them when the sim is being slowed down.

In any case, thanks again - the more we use ffx in our projects, the more effects I'm discovering are obtainable with it.

[Rif]

ya , something like this is the plan .. i hope that can all be done right

[bdemetz]

Shweeet. I'm also wondering if this can't just be done at render time. Or in other words, it'd be similar to simming and saving cache on every nth frame though obviously the larger the gap, the more segmented the movement.

Either way, whatever enables a user to slow down a high-timescale sim would be simply incredible, imho.

I spend about 10% of my time setting up ffx to create the initially stunning shape and movement and the other 90% trying to slow down what started as a gorgeous sim.

enough said - we're on the brink it sounds like.