Motion blur with Bercon Metaballs

[Ruairi Robinson]

Hi, I am testing out Bercon Metaballs to create the effect of streams of water running down a metal surface (it's being hit by rain) for a short film I've recently shot.

The metaball plugin is pretty amazing I gotta say. I have a few million particles running down the surface of this thing, and it looks good... BUT:

Render times are going from 90 seconds a frame to 90 minutes a frame with motion blur turned on. So either I'm doing something stupid or the plugin could do with some optimization. I am running on an 8 core Mac Pro/win7/64 bit 3dsmax 2010 setup.

I am hesitant to resort to using post motion blur. It just doesn't look as good. So I am considering that an absolute last resort. It doesn't work well for translucent wet refractive surfaces, basically.

Anyone have any suggestions for how to make this render faster?

Its weird because in other scene I have tested, motion blur didn't bring it to its knees anywhere this badly...

Thanks in Advance,
Ruairi Robinson
Writer/Director

[vlado]

It would be easier if you can post a scene that can be debugged; it's hard to say right away where most of the calculation time is spent.

Best regards,
Vlado

[jrandom]

You could certainly cut it down using per-pass camera motion blur, granted your frames will render at 90sec. X xNumPasses which is still way better than 90 minutes.

Have you tried caching your flow? I have had instances when Vray and Object motion blur the particle flow system would update for every iteration of motion blur.

Any kind of a speed up would be great though

[Ruairi Robinson]

It would be easier if you can post a scene that can be debugged; it's hard to say right away where most of the calculation time is spent.

Best regards,
Vlado

I am a little loathe to post a scene openly, since, well I am trying to keep this thing under wraps until it's finished.

I could send the scene privately if thats cool...

The prep time is really fast - its just, bucket by bucket, the actual rendering thats absurdly slow... I am caching the particles so thats pretty fast too.

[Ruairi Robinson]

might updating to the latest cray build make a difference?

Lotta particles in the scene (over 4 million)

[MasterBercon]

Are you running BerconMetaball version 1.12? You can check the version number from the "About" rollout. It has some new optimization for high particle counts.

From 90 sec to 90 min certaintly sounds wrong unless you have high value in motion blur subdivs (vray settings). Or if you run out of ram because motion blur requires at least twice as much memory compared rendering without mb.

If you set the motion blur subdivisions to 1 it should render nearly as fast as without motion blur. You should try this to see that the high render times are not caused by problem with sampling.

Since you have such high number of particles you should probably use minimum number of MB samples in metaball settings (default is 2 which is the minimum). This only affects memory and preperation time and has very little effect on the rendering time. If your particles are moving fast and nonlinearly increasing the value would actually decrease render times if you have enough ram.

You might try to adjust the Bounding Volume Hierarchy settings too. Like settings Leaf size to 15 or 40.

I'll do some tests in evening to see if there is some bug causing the high rendertimes.

- Jerry

[^Lele^]

Welcome to the chaos Forums, Ruairi

Make sure you have the BSP treating all geometry as STATIC.
In "Auto" mode, the huge amount of polys the metaballs generate (unless, of course, they regenerate it at rendertime as dynamic geo) might just be swapped to the dynamic pool, skipping the BSP prep time, and then having to deal with the dynamic memory limit.
If you feel the scene's right as it is, just try and increase the dynamic memory limit to 4gb or more (it doesn't really matter if you don't have as much ram. just crank it up for the sake of testing).
Then check if at least the first buckets (before you start swapping geometry out of the ram pool) go faster.

[Ruairi Robinson]

Are you running BerconMetaball version 1.12? You can check the version number from the "About" rollout. It has some new optimization for high particle counts.

From 90 sec to 90 min certaintly sounds wrong unless you have high value in motion blur subdivs (vray settings). Or if you run out of ram because motion blur requires at least twice as much memory compared rendering without mb.

If you set the motion blur subdivisions to 1 it should render nearly as fast as without motion blur. You should try this to see that the high render times are not caused by problem with sampling.

Since you have such high number of particles you should probably use minimum number of MB samples in metaball settings (default is 2 which is the minimum). This only affects memory and preperation time and has very little effect on the rendering time. If your particles are moving fast and nonlinearly increasing the value would actually decrease render times if you have enough ram.

You might try to adjust the Bounding Volume Hierarchy settings too. Like settings Leaf size to 15 or 40.

I'll do some tests in evening to see if there is some bug causing the high rendertimes.

- Jerry

Hey - thanks for responding. It's indeed version 1.12.

I have set mblur subdivs to 2. The metaball plugin does not allow you to set it to 1.

There is 16GB ram in the machine, and running 64 bit. So I am not running out of ram - not even close!. I can run a big afterFX session simultaniously and not have to worry about memory errors!

Some of the particles are running very fast indeed. Its an object under heavy rain. (A robot actually)

Can you explain to me what increasing or decreasing leaf size actually does?

[^Lele^]

If your dynamic mem limit is set to 400 megs, that is how much vray will ever use for Dynamic geometry (proxies, displacement, anything which is generated at rendertime, like hair, and likely Bercon's Metaballs).
If that fills up, inside a bucket, then your rendertimes WILL skyrocket.
If the default geometry type is set to Auto, as it normally is, VRay will make further decision about normal geometries in the scene, to decide what to move to the dynamic (as in dynamically swappable in and out of ram) pool.

Out of curiosity, what's it set to now? (geometry type and dyn mem limit?

[Ruairi Robinson]

If your dynamic mem limit is set to 400 megs, that is how much vray will ever use for Dynamic geometry (proxies, displacement, anything which is generated at rendertime, like hair, and likely Bercon's Metaballs).
If that fills up, inside a bucket, then your rendertimes WILL skyrocket.
If the default geometry type is set to Auto, as it normally is, VRay will make further decision about normal geometries in the scene, to decide what to move to the dynamic (as in dynamically swappable in and out of ram) pool.

Out of curiosity, what's it set to now? (geometry type and dyn mem limit?

its set to static/400 megs, which I believe is the default (I didn't change it, rarely touch these params...)

[^Lele^]

Then do try the 4000 (or more) megs setting.
I do have a feeling it may well help here.
If it does not, well, it wouldn't be the first time i'm wrong XD

[Ruairi Robinson]

Hey - thanks for responding. It's indeed version 1.12.

I have set mblur subdivs to 2. The metaball plugin does not allow you to set it to 1.

There is 16GB ram in the machine, and running 64 bit. So I am not running out of ram - not even close!. I can run a big afterFX session simultaniously and not have to worry about memory errors!

Some of the particles are running very fast indeed. Its an object under heavy rain. (A robot actually)

Can you explain to me what increasing or decreasing leaf size actually does?

sorry, motion blur subdivs is 5, samples is 2.

[MasterBercon]

Bounding Volume Hierarchy (BVH) the metaballs use divide the particles into bounding boxes. This is necessary so it doesn't have to compute the metaball field for all particles, just those that are near the given point. First box compases all particles. Then its divided into two, both boxes containing roughly half of the particles. This is continued until each box contains at maximum Leaf Size number of particles AND the size of that bounding boxes is less (in X, Y or Z axis) than the Leaf Length. If these conditions are not met, the process continues until the number of divisions exceeds the Tree Depth parameter.

So all the parameters controll the size of the groups particles are put into. If you have lots of lone particles its usually good to have small groups so the bounding boxes are small. If you have dense particle clouds its better to have slightly bigger groups to avoid ovear head caused by BVH.

In your case with the default Tree Depth being 15 you'll get on average 120 particles per group (2^15*120 = ~4 million). This is will probably slow it down. So you could rise the Tree Depth value to 20 and set Leaf Size to 15.

The fast particles might be the reason for the slowdown especially when combined with high particle count per group. If all the particles are going moving in uniform direction and at the same speed its not a problem. Howeve when the particles are moving fast in all directions then its really the worst case scenario which causes high render times no matter what you do.

Using the Tree Depth 20, Leaf Size 15 (or even <10), might do the trick. Let me know if it helps at all.

[Ruairi Robinson]

So I tried setting motion blur subdivs down to 1

with mblur off: 1min7secs
with mblur on: 23mins58secs

this is an early frame in the sequence, and the particle count goes way up later in the sequence, along with render times

Also I tried cranking up motion blur samples for the bercon metaball object, and it didn't seem to speed it up. Tried 10, and 25 samples. a 4 min render with 2 samples (and GI disabled) went up to 7 mins with 25 samples

trying the static memory limit thing next... though memory is not really the problem I dont think. Scene only uses a couple gigs of the 16GB ram I have available..

[Ruairi Robinson]

Bounding Volume Hierarchy (BVH) the metaballs use divide the particles into bounding boxes. This is necessary so it doesn't have to compute the metaball field for all particles, just those that are near the given point. First box compases all particles. Then its divided into two, both boxes containing roughly half of the particles. This is continued until each box contains at maximum Leaf Size number of particles AND the size of that bounding boxes is less (in X, Y or Z axis) than the Leaf Length. If these conditions are not met, the process continues until the number of divisions exceeds the Tree Depth parameter.

So all the parameters controll the size of the groups particles are put into. If you have lots of lone particles its usually good to have small groups so the bounding boxes are small. If you have dense particle clouds its better to have slightly bigger groups to avoid ovear head caused by BVH.

In your case with the default Tree Depth being 15 you'll get on average 120 particles per group (2^15*120 = ~4 million). This is will probably slow it down. So you could rise the Tree Depth value to 20 and set Leaf Size to 15.

The fast particles might be the reason for the slowdown especially when combined with high particle count per group. If all the particles are going moving in uniform direction and at the same speed its not a problem. Howeve when the particles are moving fast in all directions then its really the worst case scenario which causes high render times no matter what you do.

Using the Tree Depth 20, Leaf Size 15 (or even <10), might do the trick. Let me know if it helps at all.

Any chance you could take a look at the scene?