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.