Cache radiosity in montecarlo e (Fprime)?

Premessa:
-sul mio 8.3 il pannello di impostazione della GI mi dice che l'unico algoritmo che supporta la cache radiosity è l'interpolated, mentre il montecarlo e il backdrop non possono salvare i dati calcolati per velocizzare i frame successivi.

-Fprime se ha da calcolare una scena con 10 frame dove l'unica cosa che cambia tra frame e frame e la posizione della camera (tipico esempio di viste che riguardano un interno o un esterno) si calcola tutta l'illuminazione per 10 volte.

Domande:

1) Montecarlo è un algoritmo che per sua natura non permette di salvare i dati dell'illuminazione? (alla maniera di lightscape per intendersi)

2) L'interpolated è un alternativa valida?

3) E' plausibile auspicare che worley possa implementare un sistema di salvataggio dei dati dell'illuminazione dell'interna scena così da velocizzare i rendering successivi?

4) Il surface backer potrebbe essere un alternativa? ma funziona con fprime?

un pò lunghetto? scusate! :rolleyes:

1) non so se l'algoritmo in sè non permetta il salvataggio dei dati calcolati; certo è che la soluzione newtek non lo consente;

2) credo proprio di sì: è attualmente il miglior compromesso tra qualità e tempo di calcolo. inoltre, se diminuisci tolleranza e valutazione minima dello spazio, il risultato è molto simile al montecarlo radiosity, sia in termini di qualità che di tempi di calcolo. però l'interpolated lo si può salvare..

3) secondo me sì. in fondo, i file che vengono salvati con l'immagine calcolata dall'fprime renderer contengono tutte le informazioni sull'illuminazione così come sono state raffinate all'ultimo passaggio; un diverso sistema di salvataggio potrebbe consentire il salvataggio di tali informazioni anche per singolo oggetto oltre che per singolo frame; ma questa cosa è da progettare con cura, soprattutto nell'interfaccia, il che mi spaventa un po', considerando le interfacce dei plugin di worley..

4) il surface baker è sicuramente un'alternativa, ma ha parecchi problemi, e soprattutto richiede un po' di sperimentazione. nativamente, il surface baker non è supportato da fprime; certo è che, una volta bakerizzato il tutto e applicato ad una mappa uv, allora fprime lo legge benissimo, ma a questo punto non so quali vantaggi possa fornire fprime rispetto al motore nativo di lightwave..

spero di aver risposto a tutto.

vash
love&peace

Hai risposto a tutto, e con cognizione. :)

Resto sempre un pò contrariato per come Nt abbia affrontato gli aspetti della GI.
Tra l'altro proprio ieri stavo riguardandomi le features di Kray chiedendomi quanto tempo ci vorrà ancora perchè Nt si decida ad aprire quel benedetto SDK ai motori esterni.

Sob. Vedremo

Citazione:

---

Originariamente Scritto da happymilk

Hai risposto a tutto, e con cognizione. :)

Resto sempre un pò contrariato per come Nt abbia affrontato gli aspetti della GI.
Tra l'altro proprio ieri stavo riguardandomi le features di Kray chiedendomi quanto tempo ci vorrà ancora perchè Nt si decida ad aprire quel benedetto SDK ai motori esterni.

Sob. Vedremo

---

Sante parole. io però uso già Kray e con enorme soddisfazione; per l'animazione architettonica è il top. Impostare la luce e catturare la GI escludendo la luce diretta è roba da una giornata al massimo, mentre prima il setup preparatorio era un vero calvario.
Kray ha bug e limiti, ma se lo usi come GI + baking engine è imbattibile. Le procedurali, gli shaders e il MB li metti poi in LW.

Paolo Zambrini