Hi-poly scene, Hi-ram usage issues

I have a scene with just over 1 billion polys, with lots of 3d displacement (grass) and hundreds of vray proxies (trees). At 2400x1800 px, during LC (default values w/glossy acceleration), ram usage is around 6-7gb, which seems reasonable. I have tried to do DR stills via BB, but the scene keeps timing out at 600 minutes. I have tried doing DR locally but the two nodes we have with 16gig ram (besides my workstation) keep dropping out when LC is calculated (and coming back on, dropping out, etc.). If I try IR/brute force, the nodes display their IR as black buckets, and then I get an unhandled exception error. I am not exceeding my ram amount on the machines in question, so I am wondering what the problem is…

I think if I pre-calc locally, or on one of the nodes, then do DR with the loaded lightmaps it will work, but of course thats slower than using DR to get through the IR pass. Any ideas?

i ve experienced some crazy ram usage last week also when doing large stills, and the only way i found to try to control the ram was to increase the 3d displacement edge length…

exacly :slight_smile: same here.. increase the edge do the trick here u should try.. and psl report back , maby is different issue..

Hey, thanks. I’ll try the edge length. I did get the IR and LC to calculate on one node, but the render pass doesn’t work. I get an error saying “Warning: Camera FOV is too small, possible round-off errors” AFter that it just renders a black frame buffer.

WTF? How is 24mm too small? Its never been too small before. I think there’s a bug here somewhere. I can hear it scurrying around in the wall, but can’t see it…

yeah…that sounds mega weird!
but i ve seen crazy stuff latelly when ram goes sky high!

follow-up: I increased edge length to 6 and it helped. But what helped even more was globally disabling displacement. I have 6 renderings due on Thursday, so no time to keep screwing around with long render times. I’ll have to work into the grass and gravel in photoshop.

yeah…i know the feeling…:frowning:
i ve been managing to get the displacement done by disabling the camara dependency and increasing the edge lenght to values between 8-20 (!!)
with satisfactory results. Nontheless it looks like displacement is becoming way too much memory hungry then i d guess at high output dimensions.

I love 2d displacement. It doesn’t eats your memory during rendertime with its “precomputing displacement”.

I can’t even get 2d displacement to work in such a complex scene. Max just crashes immediately upon pressing render.

Would it not be possible to calc the lc and irmap with displacement off and turn them on for the actual render? Or will the slight differences in object shape cause major inaccuracies? Could you sub in a push or normal max displace as a go between in the calc stages?

i know paul…but some (bad) meshes just don t like the 2d disp…:wink:

If you are only displacing by a small amount, it might be possible to calculate the light cache/irradiance maps without displacement and only turn this on for the final render.

Best regards,
Vlado

We use this trick all the time and it works very well. Some time ago, we suggested the possibility to add a switch whose purpose would be ignoring displacement during IM and LC passes. For some technical reason, I see it’s hard to implement, so turning off disp, precalculate, turn on displacement, render would be our only option.

Attach all your displaced objects to each other in one editable poly and make them use the same modifier - it’s a bit of effort, but ive found it starts crashing because of the number of displacement modifiers before anything else becomes a factor.
If youve got one or two different displacement maps but 50 objects that its spread over, it’ll make such a massive difference.

Nice tip. I’ll give it a try. Grass just looks like ass without it…

I wanted to also mention, but I am sure you have it set, to crank your memory in the VRAY settings up very high to 3G or so. ALso we have scenes that required 12G of ram to render so VRAY would crash on an machine with 8G what we ended up doing is setting the Virtual memory to a fixed amount of 16G and it worked fairly well without slowing down the render much compared to the machines with 16G of real ram. The biggest ting is it stops it from a hard VRAY memory crash.