Vray fur with light cache and moblur, render extermely slow

Hi,

I am doing a fur test. The fur mesh/character has about 0.5 million polygon faces. The fur mesh is attached with VrayFur, 5 fur per face. I assume the fur number is about 2.5 million-ish. VrayMtlHair3 is assigned to the fur mesh.
It takes about 8 minutes to rendered at 1k with BF+LC and NO Moblur. But when the Moblur is ON, it only finishes 18% after 12 hours. The Light Cache phase took significantly longer to finish also.

Version: Vray 2.30.01, Maya 2013, Windows
Setting: Image Sampler 1, 10; Threshold 0.01

Is this normal or a bug?

Thanks.

Can you get me a scene to profile?

Best regards,
Vlado

Hi Vlado,
I will see if it’s possible to pass the scene out to you. Meanwhile what would be the potential causes for this slow down. If you need more info of the scene settings, I can type it up here to help you diagnose. Everything is fine without MoBlur. It’s just when MoBlur is turned on, it slows down dramatically.

I’m not sure what’s slowing it down, that’s why I need a scene :slight_smile:

One question thought, what is your dynamic memory limit for the raycaster settings?

Best regards,
Vlado

I created a simple scene with a sphere and VrayFur assigned. Without moblur, the fur is rendered in 3 mins or so. With Moblur it stuck at 8% for after 10 minutes.

edit: after 20 minutes, the rendering is not going anywhere and stuck at 8%.
fur_moblur_issue.zip (9.34 KB)

Hey Vlado,
Did you find out the cause for the long hanging fur render when Moblur is on? I hope it’s not just on my machine.

error log from the output when the render is hangingaat 8%. The “drive not mount” keeps repeating since 8%.

--------------
[2013/Jan/17|11:05:50] V-Ray debug: Light cache time interval is (-1.500000, 0.500000)
[2013/Jan/17|11:06:45] V-Ray: (Estimated time remaining: 0h 8m 13.1s): 10 % completed
[2013/Jan/17|11:06:54] V-Ray: (Estimated time remaining: 0h 4m 12.3s): 20 % completed
[2013/Jan/17|11:06:57] V-Ray: (Estimated time remaining: 0h 2m 35.9s): 30 % completed
[2013/Jan/17|11:07:01] V-Ray: (Estimated time remaining: 0h 1m 45.3s): 40 % completed
[2013/Jan/17|11:07:03] V-Ray: (Estimated time remaining: 0h 1m 12.8s): 50 % completed
[2013/Jan/17|11:07:06] V-Ray: (Estimated time remaining: 0h 0m 50.6s): 60 % completed
[2013/Jan/17|11:07:08] V-Ray: (Estimated time remaining: 0h 0m 33.4s): 70 % completed
[2013/Jan/17|11:07:09] V-Ray: (Estimated time remaining: 0h 0m 19.5s): 80 % completed
[2013/Jan/17|11:07:11] V-Ray: (Estimated time remaining: 0h 0m 8.9s): 90 % completed
[2013/Jan/17|11:07:13] V-Ray debug: Qt threads completed
[2013/Jan/17|11:07:13] V-Ray debug: Merging light cache passes.
[2013/Jan/17|11:07:13] V-Ray: Merging light cache passes…
[2013/Jan/17|11:07:13] V-Ray: Light cache contains 1438 samples.
[2013/Jan/17|11:07:13] V-Ray debug: Light cache samples collected; compiling lookup tree.
[2013/Jan/17|11:07:13] V-Ray debug: Prefiltering light cache.
[2013/Jan/17|11:07:13] V-Ray: Prefiltering light cache…
[2013/Jan/17|11:07:13] V-Ray: Saving light cache to file “”…
[2013/Jan/17|11:07:13] V-Ray: Light cache saved successfully
[2013/Jan/17|11:07:13] V-Ray debug: Rendering image.
[2013/Jan/17|11:07:13] V-Ray: Rendering image…
[2013/Jan/17|11:07:13] V-Ray debug: Setting up 16 thread(s)
running
11:04.49 26462 Drive not mounted
11:04.54 26463 Looping before Zumo is running
11:04.54 26464 Drive not mounted
11:04.59 26465 Looping before Zumo is running
11:04.59 26466 Drive not mounted
11:05.04 26467 Looping before Zumo is running
11:05.04 26468 Drive not mounted
11:05.09 26469 Looping before Zumo is running
11:05.09 26470 Drive not mounted

We debugged this a bit further, and it seems to definitely be a lightcaching bug. with BF on for primary and secondary we dont get any errors. This particular part of the log seems really weird… which is right where the light cache breaks

11:04.49 26462 Drive not mounted
11:04.54 26463 Looping before Zumo is running
11:04.54 26464 Drive not mounted
11:04.59 26465 Looping before Zumo is running
11:04.59 26466 Drive not mounted
11:05.04 26467 Looping before Zumo is running
11:05.04 26468 Drive not mounted
11:05.09 26469 Looping before Zumo is running

As far as I know we have nothing called Zumo on our network here at shade.

Thanks!
Bryan

These don’t look like V-Ray messages. I don’t know where they come from either.

Best regards,
Vlado

The scene renders here in about 4 mins. This is on Windows though; I have to check Linux.

Best regards,
Vlado

Btw, ZumoDrive seems to be some software for cloud storage…

Best regards,
Vlado

i will re-create the scene on another machine to see if the scene is corrupted.

Hello there,

I manage to reproduce your issue - it appears if I have lower value for Dynamic Memory Limit(DML).
Once Vray reaches the amount of RAM specified in Dynamic Memory Limit - and Maya freezes and the render stops.
Here are two examples:
Here I have set DML to 10GB - and render stops at 56%
Same settings with DML = 11GB - and it renders correctly.

How much memory does your workstation have , and how much DML you have set in Vray Render Settings ?


Hey Svetlozar,
Thanks for doing the test. I have 32GB of RAM. In the production scene, I set DML to 28GB. Maya actually takes less than 10GB of memory when rendering. Anyway, with LC and moblur, the LC phase took more than 15mins and crawling really slow after 90% (still going). If I switch to BF+BF, the whole render finished in about 15 mins.

Still can’t reproduce this here. Btw what hardware are you rendering on (i.e. how many processors and what kind)?

Best regards,
Vlado

Render tests have been done on machines locally and on the farm with different specs. Sometimes the render hangs; sometimes it finished with much longer render time than using BF+BF. Maybe it has to do with hardware issues internally, but we can’t point our finger to something specifically at the moment.

Does it always hang with the Zumo drive message?

Best regards,
Vlado

On couple boxes I have tested locally, yes. It appears in Maya output window with VRay Log level set to “all messages”. I can’t say that for rendering on the farm though.
I thought it has to do with accessing/saving LC files, but I got the same issue when I specify a dedicated file path for saving LC file or disable auto-save completely.

Ok, so what happens if you disable or uninstall that Zumo stuff?

Best regards,
Vlado

AFAIK, there is nothing called Zumo in our infrastructure. BTW, I got this looping before Zumo is running thing with BF+BF too and the render finishes normally.