PDA

View Full Version : Cache radiosity



Salv8or
05-01-2010, 01:22 AM
Hi there,

Why is it that when using Cache radiosity the rendertimes gets higher for everyframe?
Ive tried all kind of settings, and if I clear the cahce the first render with GI takes lets say about 5 min, the second takes at least 7. If I then stop the render, hit f9 on the any of the rendered frames i still have the increased time. If I clear the cache Im back on five again, until the cache have done one precalc then the rendertimes increases again.
If I run the render without caching the rendertimes remains "constant" but then the GI flickers a bit, witch is normal.

What to do? I searched for intersecting objects, Theres nothing strange hapening in the scene. Just a turntable anim.. Static light, only one static camera.

Oh, its the GI time that raises not the acctuall renderprocess?

Hieron
05-01-2010, 04:40 AM
I suppose "animation" GI tick box on?

Exactly how it is supposed to work and it has been discussed alot of times. The animation GI cache function caches only sample positions so the solution is stable over time. Since you rotate your object versus the light this is the correct way to do it, but it does not speed up the rendering, it even slows it down since it needs to keep track of already calculated samples.

If you would hold the object still, but turn the camera around it, you could tick the animation cache box off and it would be fast again. Since now it can really cache the solution, not only the sample positions (which increase).

Check the radiosity guide for 9.6 by Tom (Except Design)

Salv8or
05-01-2010, 09:46 AM
hireon:Rotating the camera was ofcourse the way to do it in this perticular case.. Thanks for the tip m8.

But i still think its kind of wierd...

Ive read the GI guide on the Except site loads of times and its a true gem (thnx alot to the author). Every one should have it bookmarked.

erikals
05-01-2010, 11:15 AM
i'm not sure what the conclusion was, but here's a thread on it,
http://www.newtek.com/forums/showthread.php?t=98861

Hieron
05-01-2010, 03:41 PM
*longwinded mode on* :)


Normally you would expect caching to speed up the process. It would just write to cache the calculated result for a specific area on the model and keep referring to that. Quick and painless. Rendertimes may go from minutes to seconds that way if the camera doesn't see new/unseen areas much every frame.

However, that would never work when objects move or lights move. Then it would look weird if a solution stays the same, even though the object would move, the shading on it would stick. As if moving a light to the other side while the shadows stay the same more or less. In fact it even gives render errors if you move the object when it is cached.

So you can't cache it, and have to calculate the GI every frame again. Which would be fine, if we had the perfect GI solution, but we don't unless we spent days. Lightwave allows us to interpolate between samples so it doesn't have to calculate each and every pixel. But without caching, the placing of the samples that do get calculated is sort of random when stuff moves. Yikes. Because our not 100% perfect and also interpolated solution will then differ per frame. Giving "splotches" which are ugly and almost impossible to get rid of by postprocessing since they have random sizes etc. Horror!

So Newtek built the animation cache, which has absolutely nothing to do with speeding stuff up. It is about keeping samples places in memory. So when the objects or lights move about, Lightwave keeps track of where on the objects it did calculate a sample before. That way, with sample place the same, the resulting solutions do not differ so much between frames and while splotches may still be there, they will be stable over time and not be noticable so much. So it is a great option even when not speeding things up!

However, the downside is also, that it must calculate all samples ever placed (in view). Imagine this worst case scenario: Your camera is close to a wall with details on it on the first frame, and a light moves around so you have to use animation cache (or revert to a trick, but that is not being discussed here). It will need to render alot of samples for this, say about 5 pixels apart each. It will render sort of ok'ish. Now you pull the camera backwards to view a bigger part of the wall. The original samples are now spaced only say 1 pixel apart, but Lightwave must still calculate them all in order to keep a stable solution. So that part of the image will take 25x! longer.

That's what you see happening sort of. The rendertime is slightly higher than before, in some cases insanely high. But when done well, you do not have splotches jittering around while in animation! That is a good thing, right?


There are some things you can try to do to keep the issue down, and Except's guide gives great examples.

In the end I usually cache it normally or use some other way and stay away from animation cache. But sometimes there is no choice. And then, it is good NT added it for us.

(I would like them to add a whole lot more options regarding GI though)

Exception
05-08-2010, 07:15 AM
Number one pitfall when using animated GI: don't use the GI resolution multiplier. I find that one to be cause for most issues.

That said, animated cache is indeed not meant for speed increases, and often causes a slight delay. However, most scenes are optimizable so that they sort-of remain in the same ballpark as a single frame render.

Cageman
05-10-2010, 01:17 PM
Number one pitfall when using animated GI: don't use the GI resolution multiplier. I find that one to be cause for most issues.

That said, animated cache is indeed not meant for speed increases, and often causes a slight delay. However, most scenes are optimizable so that they sort-of remain in the same ballpark as a single frame render.

I use the multiplier all the time for Animated GI-cache (Monte Carlo). It is set to 10%. Works great in most cases (animated characters as in with bones or MDD-files).

:)

Nangleator
05-10-2010, 01:29 PM
I'm currently rendering an animation wherein my scene is lit wholly by two sparklers. In other words, lit by hundreds of surface voxels, all flying through the air and bouncing on the ground, etc. I tried using animation cache, and after rendering for the weekend, it still promised 122 more hours, on my quad core.

And I did not trust that promise!

Given the particulars of the animation, I think I can sell a little radiosity flicker.