arcano Cache radiosity!!!

Scusate, ma la "cache" del radiosity...non serve per risparmiare sul tempo dei rendering??
Ma forse ho mal interpretato e non è così?
Io credevo che la cache servisse...in quelle scene in cui non vi è variazione nell'illuminazione (luci che si spostano o cambiano intensità) o non vi sono oggetti in movimento (che quindi ne alterano l'illuminazione)...a risparmiare il calcolo "radiosity" che fa all'inizio nella versione "interpolata".
Quindi quel calcolo lo fa una volta, lo salva nella cache e te lo risparmia nei frames successivi facendo risparmiare tempo nei rendering....E' COSI'??

Non perchè se è così come ho detto, a me non funziona affatto. Ho notato che se spunto la cache in un'animazione, ho un leggero vantaggio nei pochi rendering successivi al primo, per poi aumentare il tempo di resa man mano che renderizza. In un'animazione è arrivato a calcolare in circa 5 minuti e mezzo un frame al 300esimo fotogramma, mentre lo stesso fotogramma senza cache me lo calcolava con metà del tempo. Com'è possibile?
E cresce sempre...questo che significa, che al 600esimo fotogramma mi starà calcolando i rendering in 10-20 minuti a frames contro i 2-3 minuti che impiegherebbe senza la cache?
Chiaritemi questo aspetto per cortesia, grazie, Marcello.

lo spiega questo bravo utente su questo manuale , alle ultime pagine mi sembra
http://www.except.nl/lightwave/RadiosityGuide96/

Citazione:

---

Originariamente Scritto da giacob

lo spiega questo bravo utente su questo manuale , alle ultime pagine mi sembra
http://www.except.nl/lightwave/RadiosityGuide96/

---

anche qui tradotta da vashts

http://www.lwita.com/tutorials/radio...rial.php?pag=7

Grazie per il link, ho letto, ma non mi ci ritrovo...
Era come dicevo io, ma non capisco allora il motivo per cui i rendering abbiano un tempo superiore di calcolo a quello che avrebbero senza cache...ma più del doppio!!
Visto che la cache serve a far risparmiare tempo nel calcolo rendering con il radiosity!!!

strana sta cosa, in kray, deselezionando la cache i tempi aumentano vertiginosamente, e nel caso di kray servono per il calcolo in modalità QMC per intenderci.
riguardo l'animazione, ma non riesci a salvare il calcolo della gi cosi ogni frame lo utilizza senza ricalcolarlo?
non so se con lw sia possibile e se sei nella condizione di usarlo (no variazione di luce)

C'è anche un'altra cosa da dire:
con l'interpolato si hanno degli artefatti, causati dall'approssimazione del calcolo, specialmente visibili in zone monocromatiche piatte (tipico esempio il ripiano su cui poggia un'automobile in grigio chiarissimo o bianco). Più il radiosity è preciso, minore è la dimensione di questi artefatti fino a diventare addirittura invisibili, ma i tempi di calcolo logicamente aumentano. Se il problema potrebbe essere poco evidente o irrilevante sui singoli frames, diventa OSCENO sulle animazioni in cui gli artefatti sono riprodotti CASUALMENTE ad ogni singolo frames. "Cachando" (non è una parolaccia!) il radiosity si va invece a "bloccare" questi artefatti, pertanto ogni singola macchia avrà sempre la medesima posizione in tutti i frames. Tuttavia sorgono altri problemi legati a tutti gli elementi che non sono visibili nel frame di partenza.... a volte è tutto accettabile, a volte si creano delle striature incomprensibili.

Inoltre, per esperienza, ho visto che facendo il passaggio di calcolo di sola cache e solo successivamente renderizzando tutto, si hanno tempi notevolmente ridotti rispetto a cachare e renderizzare insieme (se poi si è mangiato piccante sono dolori.... hem.... non ho resistito alla battuta!).

Ciao

Citazione:

---

Originariamente Scritto da nico

... ma non riesci a salvare il calcolo della gi cosi ogni frame lo utilizza senza ricalcolarlo?
non so se con lw sia possibile e se sei nella condizione di usarlo (no variazione di luce)

---

E' appunto quello che fa la cache.

ma hai letto questo passo (tieni conto che la traduzione in italiano non sembra completa e. se non mi sbaglio non lo contietne) ... sembra che faccia al caso tuo

Animated Cache Notes




The actual working of the animated cache has been described above. However, there are some things you want to consider when you work with it a lot, or in specific scenes. First, you won't save much render time with it like the static cache does. It's really only preventing flicker. That's usually fine as LW's radiosity is really fast. There are also several circumstances in which the animated GI does not work well. Here's the list so far:

• <LI class=easyread>Deformed objects (creates millions of sample points, renders very slow, and eventually might run out of memory) Small very bright luminous objects can cause flickering due to the rays being too dispersed creating too large a variance per shading point <Increase sample density if possible.
• Do not use the GI resolution multiplier with animated GI. It causes increasingly longer render times and possible flicker.

Truly understanding how the cache system works might allow you to understand these items more, but also might make you aware of potential problems. If your animated cache (to a limited degree this is valid for the static cache as well, but there it isn't as noticeable) goes increasingly slower... eg a long animation takes four times as long per frame after baking than without a baked solution. This would seem like a bug, but it actually makes a lot of sense, and it works as it's supposed to, and you can control for this as well.
The below scene had this problem at some point.
Except's Wesleyan Museum using animated Radiosity. Click here to view the test movie.





Understanding the caching process you can see why this happens. When baking, it places sample points only. However, it does so for the entire animation. If you zoom into a wall or objects turn, swivel and reveal parts of the scene that was previously unseen, more sample points are generated. On some complex objects with a lot of irregular geometry, or very complex scenes, these sample points might start to accumulate a fair bit (see example image below). So, after the scene bake, every frame has considerably more sample points than rendering a direct frame. There are several ways you can solve this.

• You can increase the MPS settings (example: 1.0-50.0 to 3.0-200 perhaps). While for a single frame this might be ugly, once the bake is done, it likely has plenty of sample points accumulated.
• You can bake using a frame step larger than one (my preferred method). For slow movements you can increase this quite a bit, as not a whole lot is revealed in the meantime. I have had scenes where this was set at 20. this means new sample points will only be generated every 20th frame, resulting in much less cluttering. Setting this too high, however, leads to flickering, because sample points are missing where they are needed, and LW fills them in on the fly to prevent gaps. So be careful, run a test if possible.

http://www.except.nl/lightwave/Radio...rs_samples.jpgRender showing sample points without bakingRender showing sample points after baking 200 frames


Cache Tips




There are many ways to use the cache. Here are some tips that might indicate some uses, and some tips:

• <LI class=easyread>Bake a cache of a scene, then set the preprocessing to 'locked' and now play with the colors and surfaces of the scene. You see that you can still change them, except that their color cast does not update. Usually color cast and bleed is subtle and for previewing is not necessary. This is a great way to discuss material selections with a client without doing a lengthy radiosity render over and over again. Just use the cache and once selections have been defined, re-render the cache to make sure all color bleeds and casts are performed using the correct surfaces. <LI class=easyread>Do not use the animated radiosity when you do not need it. Firstly, it has more restrictions, and second, illumination is not stored, only sample placement, thus you might not have much speed gain compared to normal non-cached rendering. <LI class=easyread>The cache frame step is remembered once a cache has been baked, even though you change it, which can be a bit confusing, as it won't actually perform that change. <LI class=easyread>Even when doing random test renders, keep the cache on. You can always hit 'clear cache' to reset it fast, and it does not cost any render time to save the cache file. <LI class=easyread>Cache data is saved to the cache even when a render is aborted, therefore you can pick it up where you left off, and it will reuse the data that was already rendered. This does mean you'll have to clear the cache if you make a significant change to your scene before rendering again or it might use incorrect cache data.
• If you have very highly irregular objects in your scene, it might be that the cache system keeps adding new samples because areas are per frame seen that were unseen, like grass, trees and so on. The cache may get choked, rendering goes increasingly slower and eventually might become unworkable. In these cases, reduce the problems by using high Angular Tolerance, and make sure 'use bumps is off. If that's not enough bake out just a few frames of the animation, enough to have full coverage of all large objects, and then set preprocessing to 'never'. That works well and you'll get a constant render time without choking. The samples will still be generated but discarded afterwards, and thus not create congestion further down. You do risk flickering here, so make sure you do a test run.

Trouble ShootingYou have this one scene where you just can't get rid of the splotchies, and it's driving you mad. We know this scene. We've got one too. Juggling values is then bound to happen with many tests and many results. I've done this personally many times and the knowledge I gained from this is all over this guide. However, I wanted to re-iterate some important concepts. This test scene can be downloaded below.
Undefined or crude GI: MPS setting
First thing to set right is your MPS range. Depending on the scene you might want to lower your max-value. This forces more samples to be placed in the scene. This will also slow down rendering. Setting this too low does NOT lead to splotchies or artifacts usually, it will lead to undefined radiosity. The example below (click on it) shows the difference between a decent and a too low MPS setting. Note that it is still smooth. A very high RPE setting was used to discard this as a factor.
3000r - 100s - 10.0-200.0 MPS: 52s3000r - 100s - 1.0-40.0 MPS: 5m20s

caspita giacob, grazie per la segnalazione. Leggerò con calma (inglese permettendo)..:):).

Citazione:

---

Originariamente Scritto da nico

anche qui tradotta da vashts

http://www.lwita.com/tutorials/radio...rial.php?pag=7

---

Quella traduzione mi sembra sia riferita a LW9.2 o LW9.3; le cose con la 9.5/9.6 sono molto cambiate.