PDA

View Full Version : Raydiosity caching and render farms



larkis
05-24-2009, 09:50 PM
I want to render an animation that is quite long and quite complex geometry wise, the plan is to use a render farm. How is the raydiosity cache handled when working with a render farm or screamer net ? Do i have to pre cache it on my end ? A big part of the scene render time is the raydiosity so if i can't have the render farm speed that process up using one would be useless. Can anyone who has done something like this comment on this ?

Thanks.

jay3d
05-24-2009, 11:12 PM
Review this guide http://www.except.nl/lightwave/RadiosityGuide96/index.htm made by Tom Bosschaert, it contains everything you want to know including some tips on how to use caching properly.

Cheers
J

joelaff
05-25-2009, 08:36 PM
I want to render an animation that is quite long and quite complex geometry wise, the plan is to use a render farm. How is the raydiosity cache handled when working with a render farm or screamer net ? Do i have to pre cache it on my end ? A big part of the scene render time is the raydiosity so if i can't have the render farm speed that process up using one would be useless. Can anyone who has done something like this comment on this ?

Thanks.

You discovered the problem with caching. If you have a render farm it generally doesn't benefit you, as you have to cache on a single machine, and the caching is the slowest part of the render.

Use non interpolated Monte Carlo and see the other thread don this topic here: http://www.newtek.com/forums/showthread.php?t=98861

jayroth
05-26-2009, 12:35 PM
You discovered the problem with caching. If you have a render farm it generally doesn't benefit you, as you have to cache on a single machine, and the caching is the slowest part of the render.

Use non interpolated Monte Carlo and see the other thread don this topic here: http://www.newtek.com/forums/showthread.php?t=98861

This is not recommended for animation results that involve objects in motion. I know that you are having some issues Joe, but more reliable results have been achieved by using the animated cache.

Render speeds were not the primary reason for the animated cache (as indeed, they may actually be a bit slower in certain cases involving many additional samples -- many objects in motion -- throughout a shot), but rather consistency of the sampling. There is a caveat in which Joe's advice does apply, and that is where you have deformations, as that cache does not currently work with them.

Larry_g1s
05-26-2009, 12:58 PM
You discovered the problem with caching. If you have a render farm it generally doesn't benefit you, as you have to cache on a single machine, and the caching is the slowest part of the render.What I've done in the past, is just cache the animation on my fastest machine (dual Quad-Core xeon) with step mode of X (depending on the speed of the camera, objects in motion, etc.), with no AA applied. Then use that file for the other machines on the farm.

joelaff
05-26-2009, 01:15 PM
You can certainly cache like that, Larry_g1s, and that works. But it is still slow. My main concern was the speed. I want to do everything on the farm, not on a single machine.

JayRoth: I am not having any troubles. I have been using non interpolated monte carlo in production for years. It works great, but it can be slow. However, the multitude of machines on the render farm makes up for the speed difference vs. using caching.

I'd really love to see you guys solve the single machine cache issue. Perhaps there is just too much data to do it any other way, but it sure would be nice. It could certainly be two passes still. One pass for the cache (using multiple machines) and one pass for the render. Just need to figure out some way to get multiple machines to help out.

I know most renderers do not do this yet and suffer from the same limitations as the current implementation. Don't get me wrong. I am not unhappy with LW. This is the best LW ever! I just think it could be improved in this area... and that could be an industry first that might help retain users, and attract more users to use LW at least for rendering.

jay3d
05-26-2009, 01:38 PM
I used interpolated MC combined with motion blur passes (4 passes and above) to reduce flicker in animations that contains deformable characters in the days of 9.2 - 9.3.1 implementation, and it works pretty well. as it average the variations to smooth out the final solution on each frame.

Cageman
05-26-2009, 01:38 PM
You can certainly cache like that, Larry_g1s, and that works. But it is still slow. My main concern was the speed. I want to do everything on the farm, not on a single machine.

LWs caching is quite fast imho. I recently did a cache in 1080p, where the GI was set to 4 Secondary Bounces, 500 RPE, 40 Secondary rays,0.5/50 MPS. It took around an hour to cache 200 frames. Rendertime / frame is around 40-60 minutes (which can be rendered on the farm btw).

I really don't see how a farm would be able to evaluate GI-samples and also stay consistent at the same time, however, I do belive that distributed rendering could indeed work with a farm (where a single machine still handles all the data, but where farm-machines takes chunks to calculate). But then again, people that I've talked to who has tested this with Modo (splitting up a render so that several machines are co-rendering the same frame) has reported that, in many cases, it ends up being slightly slower, or not fast enough to pay off in the long run.

Single-machine caching will probably be around long enough to warrant a computer with 16 or 32 cores to tackle this problem.

:)

Larry_g1s
05-26-2009, 02:22 PM
You can certainly cache like that, Larry_g1s, and that works. But it is still slow. My main concern was the speed. I want to do everything on the farm, not on a single machine.I'm not following you Joe, the way I mentioned allows you to do it all on the farm, minus the initial cache. But like Cageman and I our saying it is fast (turn off AA). So yeah, you have to take a step or two back to do the initial cache, but you get a faster start. What's the alternative not caching? Sure you save a couple of "wasted" hours (depending on the length of the animation) on the initial cache, but you can speed past after it's shared across the farm then with out. :thumbsup:

joelaff
05-26-2009, 03:24 PM
It is the actual caching that is slow. It may "only" take an hour, but that would mean that the scene would take <5 mins on the farm if it could distribute.

As our workstations get more cores so do the render nodes. The render farm, will always be the fastest way to render things.

The point is that in my tests at least the caching (Bake Scene) took around 50-90% as long as a full render. Thus the GI calculations in the caching are themselves slow. So you are putting the slowest operation on a single machine instead of 10-1000 machines or whatever.

I can instead switch to non-interpolated Monte Carlo and just hit render. The frames finish up faster than using the caching method because they are being processed on multiple machines. Even though a single frame my take 2-4 times longer with non interpolated monte carlo the *group* of frames still finishes faster. Non interpolated also has no limitations; it always just works. You save a lot of time testing cache settings. You have fewer settings to adjust.

You don't have to take the time to make the cache either. With non interpolated monte carlo I can hit render at the end of the day. With the caching method I would have to sit around and wait for the single machine to build the cache to then hit render on the farm for the main render (I would end up writing a script that watched the cache files and started the render when the cache was built).

I also don't find the cache to be that useful as a cache... In other words it doesn't save a lot of repeat calculations. Because if you change the lights, or the animation, or almost anything... you have to re-cache. Sure, you could up the AA without re-caching, but most other changes require a reworking... (I am assuming you are animating things in your scene, and those things require realistic GI interaction.)

I understand that a lot of people get really good results with the caching. It makes sense, and it is a cool feature. I just don't find it as helpful in a production environment with access to a decent render farm. I think people should take a look at the alternative as well, especially if they have a render farm (even a small one).

Cageman
05-26-2009, 04:37 PM
The point is that in my tests at least the caching (Bake Scene) took around 50-90% as long as a full render. Thus the GI calculations in the caching are themselves slow. So you are putting the slowest operation on a single machine instead of 10-1000 machines or whatever.

That sounds totaly wierd! The first frame when caching can take a couple of minutes (depending on settings and resolution), but that drops dramaticly. I have had scenes where the first frame takes 2-3 minutes and then drops down to 10-20 seconds / frame for the following frames.