Newsgroup: it.comp.grafica
Titolo: una info

Vorrei sapere una cosa. Sono un ignorante in materia: ne so poco e nulla. Ho
visto queste splendide immagini
http://www.irtc.org/ftp/pub/stills/2004-02-29/jhemmyth.jpg
http://www.irtc.org/ftp/pub/stills/2003-04-30/incubus_.jpg
http://www.irtc.org/ftp/pub/stills/2002-02-28/dhouse39.jpg
molto realistiche (le ultime due) e realizzate con prorammi di rendering
basati sul raytracing come POV-Ray. Spero di non aver detto fesserie finora.
Ho spulciato tra le pagine del manuale online di POV-Ray ed ho visto che non
si tratta di un software come Photoshop, ma di un linguaggio di
programmazione delle scene. Mi domando come sia possibile con sole
istruzioni formali ottenere risultati che a mio avviso possono essere
ottenuti solo con l'intervento della mano umana (mouse e tavoletta grafica)?
O forse ho capito male il funzionamento di questo programma di rendering?
Infine: potrebbero ottenersi i medesimi risultati con Photoshop? Perchč no
(o perchč sě)? In altre parole sarei molto felice se qualcuno mi spiegasse
un attimo la "filosofia" soggiacente ai due diversi software ed alle
rispettive tecniche e basi teoriche. Mi pare che Photoshop sia un Modeller
(si scrive cosě?), allora mi verrebbe da chiedere: in Computer Graphic qual
č la differenza tra "modelling" e "rendering"? Esistono altre "branche"
oltre a queste due?
Grazie a tutti

Ho il sospetto che tu abbia un saccod i confusione in testa... premetto
che non so dare una risposta approfondita alla tua rischiesta (nonc
onosco pov-ray), ma posso intanto cercare di farti una breve "intro":
- photoshop è un software adatto all'elaborazione raster bidimensionale.
Ridotto all'osso, esso si limita ad assegnare determinati valori di
colore a celle di una griglia (raster) a due dimensioni. Non sa cosa sta
disegnando, non stabilisce relazioni tra un pixel e l'altro, non
richiede nessuna "coerenza" dei vari elementi dell'immagine... insomma,
non modellizza proprio nulla... in un file di PS non esistono (quasi)
informazioni aggiuntive oltre a ciò che riesci a vedere coi tuoi occhi
guardando l'immagine che esso rappresenta.
- un software che fa rendering 3d è una cosa radicalmente diversa: esso
ha informazioni matematiche sulla geometria di un mondo tridimensionale,
più una miriade informazioni su materiali, luci, ecc... Esso fa una
"sintesi" coerente (cioò ricavata da precise regole matematiche) di
quste informazioni producendo in uscita un'immagine raster come quella
di PS, ma essa è solo un "sunto" presentabile agli esseri umani del
mondo tridimensionale che il programma sa trattare e descrivere.
- per modeller credo che tu intenda un software per fare modellazione
3d: esso è il complementare a quello che fa rendering (a dire il vero
tutti i più diffusi pacchetti 3D forniscono insieme un modellatore e un
motore di rendering, anche se poi uno può decidere di sostituire l'uno o
l'altro, del tutto o in parte, con prodotti più adatti alle sue
esigenze), e serve a preparare le geometrie che verranno poi passate al
motore di rendering...
Ciao
Giacomo

 passate al motore di rendering...
Riassumendo:
1) per realizzare le geometri che verranno utilizzate, si usa un modeller
(ma vorrei capire - vedi domanda di sopra - perchè PS non può esserlo).
2) ne segue che quelle belle immagini che ho linkato sopra non sono
realizzate solo col motore di rendering, ma sono realizzate con un modeller
ed inserite nel motore di rendering.
3) il motore di rendering fa tutte quelle belle cose che hai psiegato così
bene
Domande
1) ripeto: quali sono le carateristiche di un modellatore e pechè ps non lo
è
3) c'è differenza se ovunque, in questo mes, sostituissi a 3d 2d?
In realtà non ho neppure ben capito cosa sia la grafica 3d: le immagini sono
tutte 2d. Forse sono 3d le immagini che cercano di dare la sensazione della
3d-mensionalità con prospettive, ombre, ecc? Beh, allora la maggior parte
dei disegni e dei quadri sono 3D.
Io credevo che 3d fossero solo quelle "sensazioni" realizzato con tecniche
ed occhiali particolari.
Infine, quindi, nell'ambito della Computer Graphic, posiamo distinguere:
- programmi che disegnano pixel per pixel come PS (e credo che in teoria con
questi programmi si potrebbero relaizzare tutte le immagini possibili ed
immaginabili, 2- e 3d, con luci, ombre, prospettive, ecc; insomma si
potrebbe in teoria realizzare qualsiasi immagine prodotta da un motore di
rendering)
- programmi per la grafica vettoriale (che non disegnano pixel per pixel, ma
stabiliscono relazioni - dis oito semplici - di tipo geometrico ra gruppi di
pixel). Va bene per immagini 2d semplici.
- programmi di modellizzazione (devi spiegarmi però prima cos'è la
modellizzazione)
- motori di rendering
Ce ne sono altri?
Grazie

 - motori di rendering
Immagino di si... non me la sento di definirti il panorama completo
della CG! Chissà quanti buchi lascerei...

non conscendo pov-ray non posso certo esserne sicuro)
Le immagini a cui portano quei links non sono tutte generate con
PovRay, l'IRTC non e' specifico per PovRay anche se molte immagini
sono generate con PovRay
Per 
http://www.irtc.org/ftp/pub/stills/2004-02-29/jhemmyth.jpg
  vedi
http://www.irtc.org/ftp/pub/stills/2004-02-29/jhemmyth.txt
Per 
http://www.irtc.org/ftp/pub/stills/2003-04-30/incubus_.jpg
 vedi
http://www.irtc.org/ftp/pub/stills/2003-04-30/incubus_.txt
Per 
http://www.irtc.org/ftp/pub/stills/2002-02-28/dhouse39.jpg
 vedi
http://www.irtc.org/ftp/pub/stills/2002-02-28/dhouse39.txt
La post produzione non e' ammessa dal regolamento dell'IRTC (se non
ricordo male), ma questo non vuol dire che qualcuno possa barare :-)
PovRay non usa un Modeller, si possono pero' usare dei Modeller che
sono in grado di salvare/esportare i files nel formato usato da PovRay
o usare programmi di conversione da altri formati a PovRay (da PovRay
ad altri formati puo' essere impossibile). Al massimo in PovRay hai a
disposizione un editor di testo/IDE per scrivere le scene ed eseguire
il motore di rendering, comunque un qualunque editor di testo puo'
andare bene. 
Spesso il modeller e' usato piu' che altro per creare modelli di
oggetti da inserire nella scena non per definirla interamente. PovRay
dispone di un linguaggio di scripting abbastanza potente per cui
spesso delle scene sono definite usando degli scripts oltre ai
modelli. Per esempio: potresti usare World Machine per definire la
bitmap di un terrain da usare in un height_field nella scena, povtree
per generare modelli di alberi e convertire un modello 3DS di una
persona che cammina nel formato di PovRay, infine usare uno script in
PovRay per posizionare un certo numero di alberi e la persona che
cammina sulla superficie generata dall'height_field.
Non e' comunque insolito trovare scene o modelli in formato PovRay non
realizzate con Modeller, e non mi riferisco solo a quelle generate
tramite scripts.
'bye

tecnico-geometriche che per cavalli e criniere. Mi sbaglio? C
Sbagli :-)
Tu pensi solo ad oggetti geometrici tipo cubo, cono, sfera, cilindro,
ma questi non sono gli unici utilizzabili, ce ne sono anche altri
quali superquadric ellipsoid, bicubic patch, isosurface, NURB, Blob,
Mesh, etc. Inoltre volendo potresti modellare i singoli peli delle
criniere usando dei cilindri o sphere sweeps :-)
Tieni presente che alcune cose non sono definite a "mano" usando un
modeller, ma tramite scripts/programmi che possono anche essere
presenti come plugins in un modeller (o stand alone).
Qui non ci sono cavalli ma zebre:
http://www.oyonale.com/ldc/english/serengeti.htm
'bye

 tramite scripts.
la mia domanda è semplice: ma senza modelle è possibile realizzare immagini
"come" quelle linkate da me nel post di apertura di questo thread?
Cioè:  tramite script si può fare esattamente quello che si fa con un
modeller (disegnare un cavallo alato come quello della prima immagine)?
In altre parole tutto quello che ha scritto Giacomo rimane vero, però nello
specifico, POV-Ray, che lui aveva cmq detto di non conoscere, non fa
renedering e basta, ma svolge anche le preliminari funzioni di modelling? E
tutto solo scrivendo istruzioni??
Beh...poi ho visrto che in realtà delle sub routine di codice possono essere
inserite belle e pronte solo facendo click. Ma cmq mi aspettavo che nella
interfaccia grafica di POV-Ray vi fosse un qualcosa di analogo al modeller
Moray che semplificasse un po' il lavoro a "forza di script"
Grazie

 presenti come plugins in un modeller (o stand alone).
OK. Ma se vedi l'altro mio post, troverai una domanda che suona pių o meno
cosė: anche solo con gli script (oltre che manualmente con un modeller) si
possono disegnare i peli della criniera?? Mi sembra ovvio cmq che sia
preferibile farlo a mano col modeller che scrivendo codice, no??
Grazie

Moray che semplificasse un po' il lavoro a "forza di script"
E' un po' come scrivere una pagina Web usando un editor di testo al
posto di usare DW o FrontPage :-)
'bye

preferibile farlo a mano col modeller che scrivendo codice, no??
Ni :-)
Se per scrivere codice intenti scrivere qualcosa tipo:
#declare pelo=union{
cylinder{ <0,-1,0>,<2,1,3>,1.1
	rotate<30,20,45>
	translate<0.3,1.1,0.5>
}
...
}
Per ogni singolo segmento di ogni pelo... allora e' preferibile usare
il modeller :-)
Se invece per codice intendi un script che in automatico ti genera i
vari peli e li posiziona: se hai uno script del genere probabilmente
potrai riusarlo anche per altri oggetti quindi e' preferibile e, se lo
script e' fatto bene, potrai ottenere anche risultati migliori.
Considera il fatto che con alcuni modeller per aggiungere il pelo non
lo fai "manualmente" pelo per pelo ma con uno script/plugin/feature
del programma
Prova a vedere MayaFur 
http://www.getinfo.net/douge/downloads.htm
 uno
script che lavora in modo simile al metodo usato da Maya per il pelo
ma che funziona con PovRay.
'bye

 OK?
Si per la profonità, non per la modellizzazione (e conseguente
renderizzazione): in realtà a livello di modellazione, grafica
vettoriale 2d e grafica vettoriale 3d (di solito non al si chiama
"vettoriale" perchè non en esiste di altro genere, o almeno non è
diffusa) sono quasi la stessa cosa. Le differenze aumentano un po' a
livellod i rendering, perchè quello 3d ha in generale molti più
parametri e perchè la vista nel 2d è unica, ma le due rimangono comunque
strettamente parenti e l'approccio è il medesimo.
Infondo basta che tu pensi alla grafica 2d vettoriale come ad una
grafica 3d fatta con tre limitazioni:
- gli oggetti hanno profondità praticamente nulla
- stanno tutti su un piano
- il punto di vista è unico, e ortogonale al piano
Come vedi, la grafica veottoriale 2d è, in linea teorica, una
limitazione della 3d...
Mondo a se rispetto alle due fa invece la grafica 2d raster, come mi
pare tu abbia ormai capito...
Ciao
Giacomo

 pare tu abbia ormai capito...
Grazie di tutto!
Gentile come sempre :-)

> Beh...poi ho visrto che in realtà delle sub routine di codice


Ci siamo??
Piu' o meno :)
Un modeller ti permette di creare una scena in modo "visuale", questa
viene salvata in un file con un certo formato. La scena poi subisce il
rendering da parte di un motore di rendering per generare un'immagine.
Alcuni motori di rendering fanno uso di file che definiscono la scena
in formato testo che possono essere creati anche senza un Modeller.
Alcuni programmi fanno solo da Modeller, alcuni solo da motore di
rendering, altri hanno entrambe le possibilita'.
Se fare uso di un modeller o scrivere direttamente il codice o uno
script dipende da quello che devi fare, con PovRay puoi ad esempio
usare un Modeller per creare vari oggetti presenti nella scena ed
"assemblare" il tutto usando l'editor di testo aggiungendo altri
oggetti tramite scripts.
Per esempio, tornando ad oggetti con pelo :-), questa sfera con dello
pseudo pelo: 
http://www.webalice.it/agostino.dematteis/3d/testfur0.jpg
e' definita con una scena che contiene oltre 16000 oggeti base, e
realizzarla con un Modeller inserendoli uno ad uno e' impraticabile,
mentre con uno script la cosa e' abbastanza semplice:
========
#include "colors.inc"
#include "transforms.inc"
global_settings {
  assumed_gamma 1.0
}
camera {
  location  <0.0, 14, -54.0>
  direction 1.5*z
  right     x*image_width/image_height
  look_at   <0.0, 14.0,  0.0>
}
sky_sphere {
  pigment {
    gradient y
    color_map {
      [0.0 rgb <0.6,0.7,1.0>]
      [0.7 rgb <0.0,0.1,0.8>]
    }
  }
}
light_source {
  <0, 100, 0>
  color rgb <1, 1, 1>  
}
light_source {
  <0, 100, -100>
  color rgb <1, 1, 1>  
}
plane { y, -1
        texture{
                pigment{
                        bozo turbulence 1.00
                        color_map {
                                [0.5, Red]
                                [1.0, Green]
                        }
                }
                finish{  
                        diffuse 0.31
                        brilliance 8
                        phong 0.4 phong_size 1
                        specular 0.6 roughness 0.1
                        metallic
                        irid { 0.2 thickness 0.3 turbulence 0.1 }
                }
        }
}
#macro fur(startangle, endangle, sradius, furradius, furlen)
        #local deltaangle=endangle-startangle;
        #local anglesteps=40;
        #local i=0;            
        #local incrementangle=deltaangle/anglesteps;
        union{
        #while (i<anglesteps)
                #local j=0;       
                #local anglei=startangle+incrementangle*i;
                #while (j<anglesteps)
                        #local anglej=startangle+incrementangle*j;
                        #local rotation=<0,anglei,anglej>;
                        #local vectortorotate=<-1,0,0>;
                        #local spherenormal=vrotate(vectortorotate,
rotation);
                        #local pointonsphere=sradius*spherenormal;
                        #local k=0;
                        #local fursteps=10; 
                        #local furstartpoint=pointonsphere;
                        #local incrementfur=furlen/fursteps;
                        #local furdirection=spherenormal;
                        #while (k<fursteps)
                                #local
furendpoint=furstartpoint+(incrementfur)*furdirection;
                                cylinder{
                                        furstartpoint, furendpoint,
furradius
                                }
                                #local
normaltofur=VPerp_To_Vector(furdirection);
                                #local furdirection =
vaxis_rotate(furdirection,normaltofur,30);
                                #local furstartpoint=furendpoint;
                                #local k=k+1;
                        #end
                        #local j=j+1;                        
                #end
                #local i=i+1;
        #end
                texture{
                        pigment{ Yellow }
                        normal {
                                agate
                                turbulence 0.6
                        }
                        finish{  
                                phong 0.1 phong_size 0.5
                        }
                }  
        }
#end                     
sphere{                                          
        <0,14,0>, 10
        texture{
                pigment{
                        crackle
                        color_map {
                                [0.3, Red]
                                [0.6, Green]
                                [1, White]
                        }
                }
                finish{  
                        diffuse 0.41
                        specular 0.6 roughness 0.1
                        metallic
                }
        }
 
}
 
object{
        fur(0, 360, 10, 0.15, 10)
        translate<0,14,0>
}
========
Mentre usare un modeller e' abbastanza semplice, scrivere degli script
potrebbe essere piu' complicato e richiedere un ripasso della
matematica imparata a scuola ed ormai dimenticata :-)
'bye

         translate<0,14,0>
Quindi si può affermare che o con un modeller (modalità visuale) o con uno
script, si può cmq generare un file di descrizione della scena da passare al
motore di resa?
Il linguaggio con cui è stato scritto il programma di sopra, descrive una
scena, no? Questa scena non è stata relaizzata con un modeller, ma con un
linguaggio ben preciso (è uno script). In un altro post sostieni che un
modeller produce un file di descrizione di scena incomprensibile all'uomo
(fino ad un certo punto), mentre un file di POV-Ray è leggibile (e
scrivibile) se si conosce il linguaggio. Perciò dico che quanto scritto
sopra non può essere realizzato con un Modeller.
Ho un ultimo dubbio: ma nelle istruzioni sopra riportate, non si descrive
solo la scena, ma anche le "opzioni" di rendering, mi pare. Se ho capito
bene, il motore di resa produce l'immagine calcolando ombre, aspetto delle
superfici, ecc ecc. Questo, con un modeller puro, non si può ottenere. Un
modeller disegna forme, geometrie. Un renderizzatore calcola superfici,
luci, riflessi, ecc. Ma nelle istruzioni di cui sopra, non c'è, sotto forma
di script, solo quello che si può fare con un modeller (cioè la descrizione
della scena): ci sono anche le istruzioni di rendering vero e prorpio, come
la posizione della camera, delle luci, le texture, ecc. E' quindi giusto
dire che POV-Ray è dotato di un "linguaggio" così "potente" da descrivere
non solo gli oggetti (cosa che - sola - fanno i modeller, in modalità
visuale), ma anche il modo in cui renederizzare la scena così descritta?
Grazie ancora

 così descritta?
Ecco a cosa mi riferivo quando dicevo che secondo me sei alla ricerca di
una distinzione troppo precisa, che non esiste... e non esiste per una
serie di cose:
- i programmi tendono all'integrazione e all'aumento delle funzioni: PS
non è da tempo (forse non lo è mai stato) un programma solo raster,
prchè sa gestire, seppur in modo rudimentale, degli elementi vettoriali,
e per gli stessi motivi Illustrator non è solo vettoriale. Spesso, anche
in un flusso di lavoro complesso, le funzionalità dei vari programmi
hanno una certa sovrapposizione e in che punto del flusso eseguire una
certa operazione dipende dalla bravura e dalle preferenze
dell'operatore...
- come esemplificato sopra, nel momento in cui definisci una sfera senza
scriverne esplicitamente i vertici, hai già fatto fare a pov-ray un po'
da modeller
- per quanto riguarda in particolare luci e materiali, modeller e motore
di rendering possono essere difficilemente separati: infatti secondo al
tua visione le operazioni su questi elementi dovrebbero essere
appannaggio del modeller, ma è vero che il tipo di luci e di superfici
(materiali) utilizzabili e la loro resa dipende esclusivamente dal
motore di rendering, e non sono neanche definiti, perchè molti motori di
rendering sono programmabili per creare "shaders" (cioè il modo in cui
si comporta una superficie colpita dalla luce) persanalizzati. E' ovvio
che può essere necessaria una profondo integrazione e sovrapposizione
tra motere di renderig e modeller...
Ciao
Giacomo

 essere appannaggio del modeller,
Forse mi sono espresso male. Io sostengo esattamente il contrario.
Sempre schematizzando, dico che:
- modeller o essere umano scrivente o script ----> descrizione di scena,
ossia descrizione geometrica dei singoli oggetti
- renderizzatore ------------> luci, superfici, ombre, prospettive di scene
*già* descritte.
Poi ci sono modeller che permettono di specificare luci, texture, ecc, ma è
una "usurpazione di competenze"
In questa visione, POV-Ray non usurpa nulla ai modeller, poichè o con i suoi
script o a mano,  implementa sì un linguaggio di descrizione della scena, ma
non in modalità visuale.
POV-Ray, in realtà, non è che si metta a fare il lavoro di un altro
permettendo la descrizione di scena. E' solo che prevede un formato
umanamente comprensibile come input per le descrizioni di scena. Ecco perchè
oltre ad un modeller gli può "parlare" anche un uomo.
Il dubbio che mi sorge è uno solo:
al motore di resa bisogna fornire indicazioni su come renderizzare (dove
piazzare la camera, dove le luci, quali texture  utilizzare, ecc). Questo
tipo di info io *non* le chiamo descrizione di scena, chimando così solo la
defiizione geometrica dei singoli oggetti e la loro disposizione relativa al
riferimento. Insomma per me il modeller o il descrittore ammanuense
dovrebbero limitarsi - se puri - a descivere queste cose e non  cose che
sono *già* rendering.
Immagino quindi che se si avesse un modeller puro che producesse in output
un file incomprensibile ad un uomo e comprensibile solo ad un motore di resa
altrettanto puro, bisognerebbe comunque, in fase di renderizzazioe,
posiionare luci, camere, attribuire texture, atmosfere, ecc ecc. Quindi
anchge se descrivessimo la scena con un modeller visuale e la passassimo al
renderizzatore, cmq dovremmo poi specificare le varie "opzioni di
rendering".
In realtà POV-Ray utilizza esattamente lo stesso linguaggio anche per fare
questo. Cioè mentre descrivi la scena a mano (nell'accezione prima detta),
puoi posizionare luci, texture, fotocamere, ecc. Il linguaggio è "unico" o
meglio "integrato". E credo che sia anche questa la ragione per cui il
modeller che parla il linguaggio "POV-Ray" non abbia difficoltà a mettere
luci e texture anche lui.
Il dubbio è se questo discorso è giusto.
Grazie

 Il dubbio è se questo discorso è giusto.
E' quell'integrazione inevitabile di cui parlavo io, e non è una
peculiarità di pov-ray. Non a caso i più diffusi motori di rendering
sono forniti come plug-in per i rispettivi programmi di modellazione: la
praticità non sta solo nel poter lanciare il rendering senza uscire dal
programma di modellazione, ma soprattutto nel fatto che tale programma,
con l'installazione del plug in, "veine a conoscenza" delle sue
peculiarità, delle luci e degli shader che può usare, e ti permette di
accedervi direttamente in fase di modellazione...
Dammi retta, cerca di farti un bellos chema "teorico" del flusso di
crazione di una scena 3d e dimenstica di assegnare ai rpogrammi reali
ruoli ben deifniti: raramente ci siuscirai, e se anche ne trovi uno che
svolge un ruolo ben deifnito, probabilmente quando nè uscirà al prossima
versione, invaderà competenze altrui! :-)
Ciao
Giacomo

 limitazione della 3d...
Già!
Grazie mille!

 prossima versione, invaderà competenze altrui! :-)
Sì, hai ragione. Devo riconscere che adesso l'ostacolo è solo larigidità e
lo schematismo. I concetti li ho afferrati ed il discorso diviene sterile
attorno a schemi, classificazioni e definizioni.
Grazie davvero. Magari ne riaprliamo quando avrò fatto un po' di esperienza
diretta con questi strumenti.

 potrebbe essere anche obliquo? E così la posizione delle luci?
In un programma di grafica 2d vettoriale (moduli 3d esclusi) non
esistono luci e non esiste lo spazio tridimensionale: si sta guardando
un foglio.
Altrimenti di ritorna alla grafica 3d...
Ciao
Giacomo

 Altrimenti di ritorna alla grafica 3d...
Eggià! Qui ho preso una bella cantonata.........perdonami :-)
Grazie

 2d
Non č molto corretto quanto sopra. Non č che consideri due cose separate la
creazione delle forme da formule e la creazione di ombre, superfici, ecc.
Diciamo che sono cose che avvengono contestualmente. Si trasforma la scena
matematica, in toto, in una scena visuale: questo č rendering.
La descrizione della scena (che come giustamente mi hai spiegato include
anche luci, ecc ecc) o fatta a mano o con visualizzatori č cmq una fase
precedente ed il risultato č quello di passare un mucchio di formule al
motore (che riguardano forme, geometrie, luci, prospettive, ecc). Il motore
traduce le formule in immagini.
E' finalemnte cosě?
:-)

 E' finalemnte cosě?
Si!
Potrebbe trarre in inganno il fatto che mentre nel 3d i modellatori
visuali ti fanno veder un rendering semplificato (ma sempre rendering č)
di quella che č la scena "matematica" che stai costruendo, i software 2d
sembrano farti lavorare direttaemtne con le forme e i colori, senza
bisogno di un'elaborazione successiva. Ma si tratta solo di avere due
rendering (uno semplice e in tempo reale, l'altro complesso e lento) nel
caso del 3d, contro un solo rendering nel 2d.
Oltretutto non č neacnhe del tuto vero, perchč benchč ormai sempre piů
inutili, i programmi vettoriali 2d hanno in genere la possibilitŕ di
stabilire la qualitŕ del rendering pre garantire fluiditŕ mentre lavori
(con la mia prima versione di corelDraw, anni fa, lavoravo senza colori
nč rimepimenti n bordi, che poi "spuntavano" solo premendo un pulsante
"anteprima" e aspettando un po'...).
Ciao
Giacomo

 esperienza diretta con questi strumenti.
Ok! Buon divertimento allora!
Giacomo

visuale), ma anche il modo in cui renederizzare la scena così descritta?
Nel file .pov trovi tutto quello che server per il rendering di
un'immagine dalla descrizione di una scena.
Per rendere le cose ancora piu' incasinate :) esiste una variante di
POV-Ray (una patch) chiamata MegaPOV che e' in grado di elaborare
simulazioni meccaniche: oltre alla normale definizione della scena
puoi definire masse (con radius, density, velocity), eventuali
connessioni tra le masse (con stiffness, damping, lenght), eventuali
"facce" di un oggetto che connettono 3 masse tra di loro e l'ambiente
con cui interagiscono (oggetti che definiscono l'ambiente,
caratteristiche quali stiffness, damping, forza di gravita', friction,
vari campi di forza) e metodi di collisione tra le masse (se da
calcolare) Questo ti permette di elaborare animazioni (i singoli
fotogrammi) di come si evolve nel tempo il sistema che hai descritto.
Per esempio potresti volere l'immagine realistica di una tovaglia che
viene posata su di un tavolo, a questo punto definisci la tovaglia
come una mesh di triangoli ai cui vertici poni le masse, le connesioni
le definisci come i lati dei triangoli, ed i vertici dei triangoli
definiscono una faccia. Definisci un oggetto a forma di tavolo e lo
imposti come l'ambiente con cui le masse interagiscono ed infine dai
il tutto in pasto a MegaPOV (poi ti metti ad aspettare che finisca
l'elaborazione :-))
'bye

da modeller
Per POV-Ray questo non e' vero :-)
'bye

vertici già dichiarati
Non il file ma quello che e' "passato" dal file alla rappresentazione
della scena in memoria (senza vertici se questi non sono necessari
alla definizione di un oggetto base).
'bye

 alla definizione di un oggetto base).
Su fatto del "file" vale quello che ho detto sopra. Sul fatto della
rappresentazione dell'immagine non m insisti, dato che non consco
pov.ray, ma devo dire che sono abbastanza persuaso che prima del
rendering vero e proprio ci sia ad un certo punto un passaggio in cui i
vari oggetti (parametrici e non) vengono comunque "esplicitati"
nell'elenco dei loro vertici... Se però tu mi assicuri che non è così,
mi fido (pur sorprendendomi). :-)
Ciao
Giacomo

 Per POV-Ray questo non e' vero :-)
Neanche nel senso scritto sopra? Allora sarei davvero curioso di sapere
come funziona il motore di rendering di pov-ray! :-)
Ciao
Giacomo

mi fido (pur sorprendendomi). :-)
POV-Ray descrive la maggior parte dei suoi oggetti come entita'
matematiche. Non mi sono letto i sorgenti del programma, ma presumo
che, per una sfera l'unica cosa che gli interessi siano il centro e il
raggio che sono i due valori usati nell'equazione
sqrt((x-Cx)^2+(y-Cy)^2+(z-Cz)^2-raggio) dove Cx, Cy eCz sono le
coordinate del centro. Quindi non c'e' alcun "esplicitamento" di
vertici. Questi due valori, centro e raggio, sono anche quelli che si
usano nei files (SDL) per descrivere una sfera.
Questo e' il secondo problema per chi voglia realizzare un programma
che traduca files dal formato di POV-Ray ad altri, come si puo'
leggere nell'help:
There's also another problem: POV-Ray describes most of its objects as
mathematical entities while most of other renderers just handle
triangles (or NURBS or similar easily tesselable primitives). A
converter would have to make some tesselation in order to convert most
POV-Ray primitives to other formats. This can be a quite laborious job
for a converter to make (it would have to practically implement an
almost fully-qualified POV-Ray renderer). 
Perche' dovrebbe per forza trasformare una sfera in un oggetto con n
vertici? Usando un algoritmo di ray tracing non credo che questa
trasformazione possa giovare molto.
'bye

come funziona il motore di rendering di pov-ray! :-)
Ray tracing (backward ray tracing), semplificando molto: traccia i
raggi di luce a partire dalla camere verso la scena. Determina i punti
d'intersezione dei raggi di luce con gli oggetti nella scena. Segue
all'indietro i raggi di luce dai punti d'intersezione alla/e
sorgente/i di luce, in base a questo determina il "colore" del punto
sulla superficie dell'oggetto (intensita' della luce proporzionale al
coseno dell'angolo tra la normale all'oggetto nel punto in questione e
il raggio di luce verso la sorgente luminosa). Se l'oggetto ha
proprieta' trasparenti o riflettenti vengono tracciati (e seguiti)
altri raggi di luce a partire da quel punto per definire il contributo
della luce riflessa e/o rifratta al colore finale del punto.
'bye

 trasformazione possa giovare molto.
Mha... non so, ma per come me lo immagino io (e devo riconoscere che la
cosa non fa molto testo), un motore di rendering (che usi raytracing,
photon mapping, o cos'altro) all'ultimo stadio dovrebbe sempre avere a
che fare con superfici, normali, ecc...
Insomma, voglio dire (ma magari mi sbaglio), che probabilmente pov-ray
si tira dietro fino all'ultimo la sfera descritta come tale, ma poi per
calcolare in effetti cosa copre e cosa no, come ci batte la luce, ecc...
avrà bisogno di trasformarla in un numero finito di facce e vertici.
Comunque ripeto, magari mi sbaglio... e solo che non riesco ad
immaginare come possa fare diversamente!
Ciao
Giacomo

 della luce riflessa e/o rifratta al colore finale del punto.
Come funziona il raytracing _più o meno_ lo sapevo. Ero solo molto
convito che per un calcolo pratico ci volesse per forza una geometria
definita da un numero finito di facce e vertici.
Però a drie il vero più ci penso e più mi convinco che, in effetti,
forse questo non è necessario...
Magari qualche altra ora mi persuade!  :-)
Ciao
Giacomo

immaginare come possa fare diversamente!
Cerco di spiegarlo :-)
Prendiamo l'esempio della sfera.
Hai l'equazione della retta del raggio di luce, diciamo che la retta
passi per i punti P1 e P2 quindi un punto sulla retta e' definito da:
P=P1+u*(P2-P1)
e considerando le singole coordinate:
x = x1 + u (x2 - x1)
y = y1 + u (y2 - y1)
z = z1 + u (z2 - z1)
Una sfera con centro P3 (x3,y3,z3) e raggio r e' definita
dall'equazione:
(x - x3)^2 + (y - y3)^2 + (z - z3)^2 = r^2
Facendo una sostituzione con l'equazione della retta in quella della
sfera ottieni un'equazione del tipo:
a*u^2 + b*u + c = 0
Ove:
a = (x2 - x1)2 + (y2 - y1)2 + (z2 - z1)2
b = 2[(x2 - x1) (x1 - x3) + (y2 - y1) (y1 - y3) + (z2 - z1) (z1 - z3)]
c = x32 + y32 + z32 + x12 + y12 + z12 - 2[x3 x1 + y3 y1 + z3 z1] - r2
La soluzione dell'equzione e' data da:
(-b ± sqrt(b^2 - 4*a*c))/(2*a)
Dal valore del discriminante  b^2 - 4*a*c si ha:
1) minore di 0 - non c'e' intersezione tra la linea e la sfera
2( uguale a 0 - la linea e' tangente alla sfera e la interseca in
u=-b/2a
3) maggiore di 0 - la linea interseca la sfera in due punti u1=(-b +
sqrt(b^2 - 4*a*c))/(2*a) e u2=(-b - sqrt(b^2 - 4*a*c))/(2*a)
Nel caso 1) il raggio di luce non ci serve
Nel caso 2) si ha un solo punto che e' quello che serve
Nel caso 3) serve solo il punto piu' vicino alla camera
Altra possibilita' prendendo spunto dalla documentazione di POV-Ray:
Il raggio di luce che parte dal punto P nella direzione D ha equazione
A=P+n*D
Il raggio di luce intersechera' la sfera nel punto I=P+T*D
Definiamo con C il centro della sfera e R il suo raggio.
Il vettore che parte dal centro della sfera e giunge al punto di
intersezione deve avere lunghezza pari al raggio della sfera, quindi:
vlength(P+T*D-C) = R 
Semplificando poniamo V=P-C e abbiamo
vlength(T*D+V) = R 
Cioe':
(T*Dx+Vx)^2 + (T*Dy+Vy)^2 + (T*Dz+Vz)^2 - R^2 = 0 
Risolvendo per T:
T = (-D·V ± sqrt((D·V)^2 - D2(V^2-R^2))) / D2 
(D2 = D·D)
Anche qui, quando il discriminante e' minore di 0 il raggio non
interseca la sfera, se e' 0 abbiamo il punto che ci interessa, se e'
maggiore di 0 ci interessa solo il valore minore. Se un valore e'
positivo e l'altro negativo interessa solo quello positivo (in questo
caso la camera si trova all'interno della sfera).
A questo punto hai il punto d'intersezione I. Per essere piu' precisi:
consideri tutti i punti d'intersezione con gli oggetti della scena e
il punto d'intersezione piu' vicino alla camera determina anche quale
oggetto viene colpito dal raggio luminoso. Consideriamo che l'oggetto
colpito sia la nostra sfera
Calcoli la normale "normalizzata" della sfera in quel punto (e' il
vettore che congiunge il centro della sfera con il punto) 
N=(I-C)/R
Il raggio riflesso e' dato da 
RIF=2*N*(N·V) - V 
dove V e' in questo caso V=P-I
Per calcolare se il punto e' messo in ombra da altri oggetti si
verifica se la retta che parte dal punto di intersezione con la sfera
e raggiunge la sorgente luminosa s'interseca a sua volta con altri
oggetti della scena, in caso affermativo il punto sulla sfera e' in
"ombra" e scartato.
La componente diffusa della luce e' calcolata con il coseno
dell'angolo tra la normale N ed il vettore della luce, ovvero il "dot
product" dei due vettori. Se il valore e' negativo non viene
considerato.
La componente speculare della luce e' calcolata in base al coseno
dell'angolo tra il raggio riflesso RIF e il vettore della luce. Il
modo con cui calcolarla dipende dal modello usato. Nel caso di Phong
il valore viene elevato per il phong size (valore^p).
A questo punto, se non si e' raggiunto il massimo livello di
ricorsione, si riparte da capo usando il raggio riflesso.
Questo viene fatto per tutti i raggi di luce da elaborare.
Come vedi non serve trasformare la sfera in qualcosa d'altro, hai gia'
tutti i dati che ti servono per i calcoli.
'bye

 Cerco di spiegarlo :-)
Spiegazione magistrale del raytracing!
Ciao ad entrambi

Bella spegazione, bravo.
Il dubbio non riguardava però la capacità di determinare le intersezioni
(il problema non è sostanzialemnte diverso nel caso di una faccia
piana...), bensì la "discretizzazione" necessaria per non rendere il
calcolo virtualemtne infinito.
Immaginavo che il motore trattasse la scena a facce perchè questo era un
modo per avere un numero finito di elementi con i quali trattare... nel
caso di forme parametriche come fa? In poche parole, come stabilisci
quanti raggi mandare dalla telecamera? Una distribuzuione uniforme di
essi nell'alngoo solido del fov potrebbe non essere "ottimale", perchè
la vicinanza dei raggi necessaria a distinguere tutti i dettagli
necessari può dipendere fortemente dalla geometria locale...
Insomma, non è che voglia giarare intorno alle tue giuste risposte
(posso darne l'impressione, lo ammetto), ma come avrai capito io non so
esattamente che algoritmi implememta un motore di rendering come po-ray,
però ero piuttosto perplesso del fatto che potesse trattare con
superfici parametriche senza "discretizzarle"...
Ciao
Giacomo

 geometria locale...
Credo che più raggi mandi e più aumenti la risoluzione dell'immagine. La
risoluzione in questo caso la definirei come la capacità di far descrivere
de punti contigui da due raggi differenti. Basta aumentare il numero dei
raggi per "campionare" la scena in maniera più "fitta" e quiindi risolta.
Non ti pare?
.Infine, ti/vi domando: al di fuori del Raytracing, i renderizzatori
suppongo che funzionino prevalentemente come dici tu (tante piccole
superficie, ecc, ecc).La domanda è: come fa il programma ad approssimare
sempre più una sfera? Forse aumentando enormemente il numero delle facce
piane?
Ciao

 finito di facce, no?
Appunto, ma ha tutt'altro che un numero finito di facce... :-)


 numero delle facce piane?
Esatto, e si ottengono risultati più che soddisfacenti anche con un
numero non così enorme di facce... Infatti in genere lui calcola le
condizioni di illuminazione una volta epr una faccia (tanto è uniforme),
e poi (se richiesto) interpola il risultato da faccia a faccia: in
questo modo l'effetto della "discretizzazione" della superficie scompare
e sopravvive solo sul profilo, sul quale può risultare evidente che la
sfera è approssimata da un poliedro, se le facce sono troppo poche...
Ciao
Giacomo



Un esempio nel caso della prospettiva e semplificando:
	P
	|
	D
	|
-------------d-------------S	
	|
	|
	L
La camera e' nella posizione P e guarda in L, alla distanza  D c'e' lo
schermo virtuale S su cui viene disegnata l'immagine alla risoluzione
definita di w punti per h punti
Le dimensioni x e y di questo schermo dipendono da diversi fattori tra
cui la distanza D tra P e lo schermo (punto d), l'angolo della camera,
i vettori "right" e "up"| della camera, l'aspect ratio, etc.
I raggi di luce tracciati sono w*h, cioe' tutti quelli che partono
dalla camera e passano per i punti dello schermo.
Ogni punto dello schermo corrisponde ad un raggio di luce e quindi il
suo colore e' definito in base alle componenti fornite da tutte le
superfici nella scena con cui il raggio interagisce.
Il massimo livello di ricorsione determina quanti "rimbalzi" di ogni
singolo raggio devono essere seguiti.
In pratica hai qualcosa del tipo:
function trace(P, D, MaxTrace){
  Calcola componente del colore co per il raggio che parte da P e
  ha direzione D
  Se MaxTrace >0 e se e' stato trovato un punto d'intersezione
    co = co + valore ritornato da trace(Punto intersezione
    trovato, Direzione del raggio riflesso, MaxTrace - 1)
  Altrimenti ritorna il colore calcolato co
}
for(i=0; i++; i<h){
  calcola coordinata y sullo schermo virtuale in base a i e dimensione
  y dello schermo
  for(j=0; j++; j<w){
    calcola coordinata x sullo scermo virtuale in base a j e
    dimensione x dello schermo
    calcola D, la direzione del vettore dalla camera C al punto sullo
    schermo corrispondente a j,i di coordinate x,y,distanza schermo
    colore punto j,i = valore ritornato da trace(C, D, massimolivello
    di ricorsione)
  }
}
Un raggio interseca un primo oggetto e riceve una componente colore da
quell'oggetto, il raggio subisce una riflessione e colpisce un secondo
oggetto da cui riceve un'atra componente colore e cosi' via fino a
quanto si e' deciso di seguire il raggio all'interno della scena nei
suoi teoricamente infiniti rimbalzi. Quando abbiamo raggiunto il
limite imposto abbiamo il colore del punto sullo schermo virtuale da
cui e' passato il raggio.
Gli oggetti sono definiti da equazioni e l'unica cosa che ci serve e'
di determinare il punto d'intersezione dei raggi di luce con gli
oggetti. Il problema, al massimo, puo' essere appunto quello di
determinare questo punto d'intersezione.
In scene particolarmente complesse o con oggetti complessi puo'
inoltre essere necessario aumentare il massimo numero di ricorsione,
questo, per esempio, se dopo aver raggiunto il massimo numero di
ricorsione esiste ancora un punto d'intersezione con un oggetto. In
teoria si dovrebbe seguire il raggio fino a quando non incontra piu'
oggetti, ovvero e' stata calcolata l'ultima componente del colore, ma
non si puo' fare perche' c'e' il rischio che non ci si fermi piu',
quindi l'impostazione di un valore massimo.  Se questo e' raggiunto ci
possono essere imprecisioni nell'immagine, e se ci sono il suo valore
deve essere aumentato. POV-Ray segnala con un warning casi del genere.
In pratica la qualita' dell'immagine dipende oltre dalla risoluzione
w*h anche dal massimo livello di ricorsione.
'bye

 dalla camera e passano per i punti dello schermo.
Ma questi non sono troppi pochi per far lavorare bene, ad esempio,
algoritmi di antialiasing sull'immagine?
Ciao
Giacomo



Quelli sono quelli di "default" :-), se poi imposti l'utilizzo
dell'antialiasing il numero di raggi usati per singolo pixel
aumentano.
POV-Ray puo' usare due metodi di antialiasing, sebbene in entrambe non
avvenga per tutti i pixels l'operazione di super sampling.
Metodo 1:
Viene tracciato un raggio per il pixel, se il colore del pixel e'
differente da quello dei vicini a sinistra e sopra di un certo valore
soglia (impostabile) allora vengono tracciati un ulteriore numero di
raggi per quei pixel (valore impostabile anche questo), di default
sono 9 raggi in una griglia 3x3.
Metodo 2:
Vengono tracciati 4 raggi agli angoli del quadrato che rappresenta il
pixel, se i colori differiscono oltre un certo valore soglia
(impostabile) allora procede a tracciare ulteriori raggi in modo
ricorsivo: ogni singolo angolo del pixel viene suddiviso in ulteriori
4 punti da cui fare passare i nuovi raggi. Il numero di suddivisioni
che subisce un pixel dipende dal livello di ricorsione dell'algoritmo
(impostabile).
Il metodo 1 in base alle impostazioni potra' tracciare da 1 a 81 raggi
per ogni pixel, il metodo 2 da 9 a 263169 raggi per pixel.
Ulteriori paramentri impostabili definiscono l'uso e il valore del
"jittering", ovvero introdurre un "rumore" nel supersampling
(spostamento random da applicare ai "nuovi" raggi). Questo e' attivo
per default, ma e' consigliato di disabilitarlo in caso di immagini
usate come fotogrammi di animazioni per evitare che si possa produrre
un effetto di "flickering".
Per maggiori informazioni vedi:
http://www.povray.org/documentation/view/3.6.0/51/#s02_02_01_08_04_i14
'bye

Grazie, tutte info molto utili e interessanti!
Ciao
Giacomo