RAYTRACING, COME GODO :-) Corso di Ray-Tracing per principianti Parte 2/7 di Alfonso Martone (alfmar) Faccio prima un po' di debug dello scorso articolo: avevo citato la texture { Bronze_Texture }, senza dirvi pero' che per usarla dovreste #includere "textures.inc". Il linguaggio di POVray (Persistence Of Vision raytracer, POV per gli amici) e' come ho gia' detto, un linguaggio descrittivo. In pratica serve per dire a POV, in ordine sparso, quali sono gli oggetti, dove sono, e come sono. In questo messaggio pero', piu' che dilungarmi sulle caratteristiche degli oggetti, preferirei fare qualche considerazione sulla potenza di calcolo e poi dare un'occhiatina ai parametri da command-line di POV. Personalmente mi sono preparato due batch files POV e POVFAST che, manco a dirlo, renderizzano rispettivamente a 640x480 in massima qualita' e a 128x96 in minima qualita' (ho scelto 128x96 perche' e' esattamente 1/25 dello schermo). Occhio! I parametri che si usano sotto Linux sono gli stessi che si usano sotto DOS. L'unico serio inconveniente sotto DOS puo' essere la mancanza di memoria RAM - all'epoca con qualche giochetto strano riuscivo a "sfondare" i 640k (VGARAM, DESQview, etc: 704k col primo e 735k col secondo, altro che 640k!); non ho visto finora tra i demo nessuno richiedere piu' di 700k (perlomeno sotto Linux), pero' non posso giurare che sia sempre cosi'. Dicevo: anche se avete un Pentium/120 renderizzare un'immagine puo' costarvi ore di CPU. Un Pentium/120 dovrebbe essere non piu' di 3 o 4 volte piu' veloce di un 486/66, che dovrebbe essere non piu' di 3 o 4 volte piu' veloce di un 386+387/33, che dovrebbe essere non piu' di 5 volte piu' veloce di un 386/40. Un rapido e pagnottesco conto ci dice che un Pentium/120 e' 80 volte piu' veloce del mio 386/40 senza 387 che e' poco meno di due ordini di grandezza. In parole povere, se a me ci mette 15 giorni di cpu (normale, per certe immagini con molti specchi e parecchie luci - altre sono anche peggio), sul Pentium/120 ci mettera' 4 ore e mezza. Se commettete un errorino nel .POV, ve ne accorgerete dopo 4 ore e mezza... grunt! Morale della favola: uno script "veloce" e' indispensabile per avere un "preview veloce" dell'immagine senza morire di noia. Nel frattempo cominciamo a far lavorare le macchine che abbiamo, sarebbe ora di sfruttare piu' dell'uno per mille della *vera* potenza di calcolo di questi arnesi - a che pro una directory velocissima, mega di memoria, transfer rate elevati e... e poi li sottosfruttiamo sotto DOS o li lasciamo sprecare a Windoze e OS2/Purp? POV non ha una fissata risoluzione, gliela specifichiamo noi. Il consiglio che ovviamente do' per le immagini di qualita' (quelle "definitive") e' di considerare la massima risoluzione che avete sulla scheda video quando scegliete un modo a 16 milioni di colori (truecolor, 24-bit o come volete chiamarlo). La mia scheda video supporta in truecolor solo il 640x480, quindi non ho che l'imbarazzo della scelta. Alcune schede se non sbaglio fanno anche gli 800x600 - inutile dire che i rendering dureranno il 60% in piu' perche' ci sonoil 60% in piu' di pixels rispetto alla precedente risoluzione. Il massimo numero di colori distinguibili dall'occhio umano e' intorno ai trecentomila; i "16 milioni di colori per punto" sono un abbondante sovradimensionamento che in ogni caso "imbroglia" l'occhio e da' delle immagini spaventosamente perfette. Anche a 320x200 dovrebbe essere cosi', pero' la "grana grossa" dei punti vi farebbe scorgere qua e la' qualche piccola differenza, per cui considerate soltanto le risoluzioni 640x480 e superiori. Anche se in fin dei conti la 640x480 e' gia' una "fotografia", per cui forse la 800x600 non aumenta veramente di tanto la qualita'...Dicevo prima: i preview a risoluzione inferiore li ho fatti a 128x96 perche' e' esattamente un venticinquesimo dello schermo. Se avessi scelto 320x240 (meta' larghezza e meta' altezza; non conviene usare rapporti diversi per l'asse x e l'asse y altrimenti l'immagine viene falsata), avrei ridotto ad un quarto i tempi di calcolo (che su 15 giorni e' ancora un po' troppo). Il minimo accettabile e' dunque (per me) un rapporto di un quinto sull'asse x ed un quinto sull'asse y, che risolve in tempi abbastanza brevi e da' perfino un'idea di quanto sara' lungo il calcolo dell'immagine a 640x480. POV dunque accetta i parametri sulla risoluzione: povray +w640 +h480 ... I parametri da command-line cominciano per "+" (enable) o "-" (disable); per alcuni non e' necessaria questa distinzione (come per i citati comandi w ed h), per cui ho messo il "+" che mi piace di piu'... Un altro comando e' il +V (occhio alle maiuscole e alle minuscole!), che abilita una visualizzazione a video del tipo "calc line 306 of 480", comodissima per sapere a che punto e' arrivato. Abbiamo poi i comandi +Q9 e +A0.3 che io uso per le versioni definitive (quelle di qualita'): quality 9, cioe' massima (max numero di iterazioni, etc), ed antialiasing 0.3, cioe' valore piu' o meno ottimale per tutte - l'antialiasing e' quello "sfasamento medio" sui pixel per evitare delle rapide "cadute" del contrasto: se un pixel bianco ed un pixel nero sono adiacenti, con l'antialiasing il primo diventera' grigio chiaro ed il secondo grigio scuro, cosi' l'effetto "scaletta" (rogna infame di chi nell'88 usava Autocad 2.17 con la CGA a 640x200) sparisce. Inutile dire che questi comandi non li useremo nello script POVFAST... ;-) Il parametro +FT specifica che l'output sara' un file Targa-uncompressed (che consta di un header di 18 bytes seguito dalla descrizione esatta dei pixel uno per uno, tre bytes per ogni tripla R/G/B). Il formato +FR (raw file) pare che sia lo stesso del .TGA suindicato, senza i 18 bytes citati. Il guaio e' che Cshow vede solo i .TGA, non ne capisce niente di "raw" o di "dump" (che e' l'altro ed ultimo formato supportato da POV). Aggiungiamo poi il parametro +C ("continue image"), per cui se interrompiamo il calcolo (manca la corrente o resettiamo noi), ricomincera' dall'ultima linea salvata su disco (se l'immagine non esiste, protestera' con una riga a video e comincera' daccapo, per cui io lo uso sempre e comunque... usare -C significherebbe far ripartire daccapo il calcolo dell'immagine). Mancano soltanto i comandi per i files: +L/povray/include/ +I/povray/prova.pov +O/povray/output/prova.tga il primo dice qual e' la directory dove sono contenuti i files .INC (avevamo esaminato "colors.inc" nello scorso messaggio e abbiamo citato "textures.inc" in questo); il secondo dice qual e' il file di input ed il terzo qual e' il file di output. In Linux lo slash per le directories e', come in Unix, il carattere '/'; ovviamente nel DOS dovrete usare il backslash. Dunque gli script sono: POV.BAT: povray +C +V +FT +w640 +h480 +Q9 +A0.3 +L/povray/include/ +I/povray/$1.pov +O/povray/output/$1.tga POVFAST.BAT: povray +C +V +FT +w128 +h96 -A +L/povray/include/ +I/povray/$1.pov +O/povray/out-fast/$1.tga (notate che la shell di Linux usa "$1" per il primo parametro da command-line mentre il DOS usa "%1"; notate inoltre che ho messo in due directories separate gli output 640x480 di qualita' e quelli 128x96 senza qualita' e senza antialiasing). Una volta creato il citato PITTURA.POV, possiamo avere un preview lanciando POVFAST PITTURA (l'estensione .POV e .TGA ce la mette il batch file) e possiamo renderizzarlo alla perfezione con POV PITTURA. Questo e' tutto per oggi... buon divertimento; la prossima volta cominciamo a smanettare sul serio col linguaggio di POV.