Implementazioni base si
E poi la complessita' di un algoritmo ti dice come l'algoritmo scala quando deve processare piu' o meno dati,
ma non ti dice quanto e' il costo fisso dell'algoritmo

Dalla collezione Shader X6, a febbraio compratelo cosi' mi fai diventare un po' piu' ricco!

non mi interesso di shaders al momento purtroppo, fa lo stesso se ti mando i soldi direttamente?

ciao,
Antonio

La loro implementazione e' sicuramente una delle piu' veloci che c'e' in giro, e del resto lavorano su hw non dedicato, non sarebbe realistico aspettarsi della prestazioni da GPU.
Cio' non toglie che anche con hw dedicato non starebbero dietro a un rasterizer

Aivoglia a menzionare il first hit.. ma di solito chi approva il ray tracing non sa che voglia dire "first hit speedup" e ci si ritrova ad usare argomenti invalidi: "si vabbe ma la megacompagnia XYZ dice che.."

E poi effettivamente quando qualche megacompagnia ti dice che il ray tracing e' una cosa dietro cui perderci tempo, uno comincia a dubitare della gente con cui ha a che fare, perche' o chi propone e' incompetente oppure si aspetta che chi riceve sia incompetente.
Sono al punto di aver pensato di dedicare tempo al debunking dei vantaggi del real-time ray tracing.. perche' va effettivamente a disturbare il mio lavoro.
E' possibile pero' che mi sfugga qualcosa di molto profondo, da cui il mio post...


..per quanto Marco Salvi meriti gloria, soldi, macchine e tope, concordo sulla questione degli shaders.
Da diverso tempo ho ormai deciso di aborrare i vari GPU Gems e Shaders X perche' sono dei ricettari. Non sono donna ma immagino le donne piu' dedicate comprino ricettari con gli stessi intenti: fare qualcosa di strafigo. Ma poi i ricettari finiscono in libreria e si finisce di nuovo con la pasta asciutta.
Bello avere le implementazioni, ma la questione delle "gems" e' delicata. Mettere una serie di articoli sconnessi abbassa il valore globale del libro.. cosa che tutto sommato conviene a tali libri, perche' e' meglio avere un lettore dipendente dalla prossima serie di ricette che non un lettore avviato alla creazione di proprie ricette.

zzzzzzzzzzzz ! (2:31 AM)

Bhe non e' poi tutto cosi plug&play. Le ricette di per se funzionano, il problema e' quando uno va a combinare diversi piatti.

Giusto.. pero' c'e' anche il lato negativo: hai 300 cose fatte da altri e sembra quasi che uno debba passare la vita cercando di implementare questa o quella cosa.
La quantita' di libri poi che esce fa pensare che forse c'e' qualcosa che non va. Forse andrebbero creati dei libri piu' specifici, o articoli ed esempi piu' completi.
Mentre leggendo Shader X (ho il 3) mi sembra che ci siano tante idee buttate li, alcune anche usate ma che non vale necessariamente la pena seguire... ma uno di questo talvolta se ne accorge solo dopo averci perso un po di tempo dietro...

..questo tipo di info sarebbe meglio sul web, facilmente accessibile, possibilmente con commenti di altri, piuttosto che messo nero su bianco appena si puo'.

Bello.. lo posso usare come riposta la prossima volta 8)

L'ombra rappresentata e' cio' che anche nei pacchetti 3D si cerca di ottenere. I bordi netti che vedi sono la parte di ombra generata dai punti dell'oggetto piu' vicini alla fonte di luce non-puntiforme...le parti piu' sfumate sono i punti piu' lontani. (fisicamente corretto)
L'unico appunto che ho da fare e' la distribuzione "direzionale" (piuttosto che omni) della parte soft.
Per il resto, per fare la stessa cosa con la stessa qualita' in un pacchetto 3D bisogna alzare di molto i sample del RT per una luce che casta un'ombra fisicamente realistica. (area o linear light che sia)
Spesso e volentieri se non si ha un passo di smoothing dei sample in post-processing, si ottiene non poco noise nel 3D precalcolato.

Ottenere invece le ombre che dici tu - quelle completamente morbide - e' abbastanza semplice, sia nel 3D pre-calcolato che in realtime.