Motion blur with Bercon Metaballs

[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.

I set it to tree depth 20, leaf size 10, and the render went from

23mins58secs

to

22mins 50 seconds...

(still mblur subdivs only at 1)

[MasterBercon]

Yeah if you can email me the scene I'll take a look at it to see whats going on, those render times certainly don't sound right.

- Jerry

[Ruairi Robinson]

Yeah if you can email me the scene I'll take a look at it to see whats going on, those render times certainly don't sound right.

- Jerry

Email sent. Thanks!

R.

[^Lele^]

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..

Well at this point i'm curious: let me know how it goes if/when you try it.

The fact that the scene isn't using up more than 2gb of ram might be exactly what your problem is.
If the metaball fields are rendertime Geometry, then they are likely treated as Dynamic.
In which case, having a higher Dyn Mem Limit would most definitely speed it up a lot.
If the render was fast without moblur on, further down this line of reasoning, it was because per bucket you had half the geometry.
Geometry doubles (or more), and the RAM swapping insues.

How are the CPUs behaving at rendertime?
Are they flat at 100%, for all cores? Or there is fluctuation?
If there is, that might be a good indicator VRay's waiting more on the data to be passed around the system, than on doing the actual raytracing.

[MasterBercon]

The metaballs are not meshed geometry and I belive they are not affected by any of VRay's standard memory settings.

Anyway, I found the problem: http://www.ylilammi.com/BerconMetaball/bug_found.jpg

I don't yet know the exact reason whats causing this problem but it does cause the massive slowdown with motion blur.

- Jerry

[^Lele^]

Glad to hear it was good old PF creating issues.
But i'm curious now.

Well, however they are generated, they can only be pre-meshed (which you excluded), or generated at rendertime.
From the SDK (but of course i stand to be corrected) i infer they can either sit in the static pool, or in the dynamic one.
Anything else that in vray is generated at rendertime sits in the dynamic geometry pool, and is hence affected by the amout of RAM assigned to the pool, which is shared amongst all the dynamic geometry types.

How does the metaball surface gets interpreted by Vray, then?

[joconnell]

You'd wonder was it an issue with vray getting fed bonkers motion vectors and it being the blur causing the issues or bercon meta trying to calculate substeps when working out its surface.

[Ruairi Robinson]

Yep. Faster with spawning off. Much faster. Infinitely faster. Even if you crank the particle way up so its got the same amount of particles that were being spawned.

So, at least we know the problem now!

R.

[MasterBercon]

I think that the metaballs sit in static pool but I'm not 100% certain about that.

Anyways, I wrote a workaround for the problem. Here is 2010 64bit version: http://www.ylilammi.com/BerconMetaba...10_64_BETA.dlo

If there are no problems with it I'll compile other versions too.

Change MB samples to 1 (in metaball options) and it enables the fix and should render as fast as it normally does.

It reads pflows velocity channel to compute motion blur instead of evaluating the particle position to compute the velocity. This has some problems, like if you use Postion Object and have the particles stick to the object and then move this object around it does not cause motion blur. It also does not produce motion blur cause by change in particle size, it only producdes motion blur from movement. If you can avoid these two situations it should work just fine.

EDIT:
Another workaround is delaying the particles 1 frame before they are rendered after the Spawn: http://www.ylilammi.com/BerconMetaba...Number_Two.jpg

[Ruairi Robinson]

I think that the metaballs sit in static pool but I'm not 100% certain about that.

Anyways, I wrote a workaround for the problem. Here is 2010 64bit version: http://www.ylilammi.com/BerconMetaba...10_64_BETA.dlo

If there are no problems with it I'll compile other versions too.

Change MB samples to 1 (in metaball options) and it enables the fix and should render as fast as it normally does.

It reads pflows velocity channel to compute motion blur instead of evaluating the particle position to compute the velocity. This has some problems, like if you use Postion Object and have the particles stick to the object and then move this object around it does not cause motion blur. It also does not produce motion blur cause by change in particle size, it only producdes motion blur from movement. If you can avoid these two situations it should work just fine.

EDIT:
Another workaround is delaying the particles 1 frame before they are rendered after the Spawn: http://www.ylilammi.com/BerconMetaba...Number_Two.jpg

So its rendering now (FAST!)

Thanks so much! Really appreciate your fast response

Quick question: the sequence crashed 40 frames in last night - it ran out of memory. FIrst time I've seen those errors on 64 bit/16 GB ram hahaha!

I've set it go again, and the ram usage goes up, and up, and up as it renders bucket by bucket - does the MB samples 1/velocity channel increase ram useage significantly? (theres a few other possible culprits, like the several million particles being cached, and the fact that I just switched to light cache for secondary rays to speed up renders a bit...) just wanted to rule things out...

There's always something!

Best,
R.

[sandykoufax]

Unfortunately, I cannot load this plugin. I don't know why.
Anyone has no problem?

[tryharder]

make shure you install the new plugin into:
plugins\vrayplugins
hope that helps

Edit:
Just run into problems myself ...

[instinct]

Check the other thread. You need the vc redistributables most likely

[tryharder]

your instinct was good! Thanks

Strange, because i had it installed and working .. but after installing the beta and then reinstalling the 1.21 it did not load anymore

anyway ...

[sandykoufax]

Oh, yes. it works.
Thanks.