Sophie

Sophie

distrib > Mageia > 3 > i586 > by-pkgid > ad94bf76730899b09e1611bca5e0cefb > files > 82

meshlab-1.3.1-5.mga3.i586.rpm

[Snapshot]
Il tiled rendering è stato implementato direttamente all'interno della paintGL. In pratica viene settata una variabile booleana a true quando l'utente richiede uno snapshot mediante il dialog e il comportamento di paintGL cambia di conseguenza; in particolare viene alterato il frustum per inquadrare solo la porzione della scena che corrisponde al tile corrente mediante la funzione myGluPerspective. Viene quindi salvato il framebuffer corrente che mediante la funzione pasteTile viene copiato nel buffer dello snapshot (si tiene traccia delle coordinate per righe e per colonne mediante variabili private di glArea); il buffer è un oggetto QImage allocato la prima volta che pasteTile viene invocata dopo la richiesta di uno snapshot; la quantità di memoria allocata per il buffer è quella occupata dall'immagine finale; ciò è necessario in quanto la funzione di QT che salva il .png richiede (naturalmente) che l'intera immagine sia in memoria (si era pensato di fare tutto dal disco ma alla fine l'immagine deve comunque essere caricata per intero per poter essere compressa a meno di non reimplementare il salvataggio dei png); la paintGL richiama se stessa quando viene richiesto uno snapshot finchè non sono stati renderizzati tutti i tiles. Alla fine viene salvato il .png mediante le api di Qt. C'è un problema conosciuto che pensiamo dipenda da QT/driver scheda video; su alcune macchine (soprattutto con schede ati) nello snapshot finale si notano righe orizontali e talvolta interi pezzi di immagine di tiles precedenti; ciò accade sia utilizzando per la cattura del framebuffer le api di QT che usando chiamate openGL. 

[Curvature]
In curvature.h sono definite le funzioni che effettuano il calcolo delle curvature (salvando il risultato nella qualità) e le funzioni di mappatura qualità->colore. Le formule utilizzate sono state ricavate dal paper "Discrete Differential-Geometry Operators for Triangulated 2-Manifolds" di Mark Meyer, Mathieu Desbrun, Peter Schroder, e Alan H. Barr. In meshcolorize.cpp si crea un oggetto Curvature passando al costruttore la mesh; vengono calcolate immediatamente le curvature media e gaussiana mediante la funzione privata ComputeHK che opera nel seguente modo:

1) per ogni vertice di ogni faccia viene calcolata l'areamix (area di voronoi) che è comune ad entrambe le curvature e viene salvata in un SimpleTempData costruito con un oggetto di tipo AreaData
2) per ogni vertice di ogni faccia si calcolano (parzialmente) le curvature media e gaussiana che vengono salvate in un oggetto di tipo CurvData; se il vertice è di bordo si calcola l'angolo tra i due vertici adiacenti (si ricava il vertice adiacente al corrente e si calcola l'edge che li attraversa, si ricava il vertice adiacente al nuovo vertice e si cerca il suo prossimo vertice di bordo quindi si calcola l'edge che attraversa il vertice corrente e il nuovo vertice di bordo trovato e infine si calcola l'angolo tra i due edges)
3) per ogni vertice si dividono le curvature parziali per l'areamix associata al vertice ottenendo le curvature finali

Mediante le chiamate Map{Gaussian,Mean,RMS,Absolute}CurvatureIntoQuality si copiano i valori calcolati in precedenza nel campo qualità associato ad ogni vertice. In particolare, le ultime due curvature sono ricavate a partire dalle prime due, mediante ulteriori calcoli.

La funzione ColorizeByEqualizedQuality prende come parametro un oggetto di tipo Frange che viene prodotto dalla funzione histoPercentile che calcola il minimo e il massimo valore di curvatura ricorrendo all'istogramma della libreria vcg (controllabile mediante il dialog). ColorizeByEqualizedQuality colora ogni vertice utilizzando la funzione ColorRamp della VCG passandogli i valori min e max ricavati dall'istogramma e il valore di qualità.

[Smooth color]
Si tratta semplicemente dell'algoritmo di smoothing presente in VCG applicato però al colore per vertice che viene mediato con quello dei vertici adiacenti.

[Shaders]
All'avvio dell'applicazione vengono analizzati i file .gdp (il formato xml di ShaderDesigner) che rappresentano le informazioni relative agli shader.
Per ogni shader vengono salvati in una struttura dati i seguenti elementi:
- path Vertex e Fragment Program
- path delle eventuali texture utilizzate e relative variabili 
- valori dello stato OpenGL che lo shader richiede per il rendering
- nomi e parametri delle uniform variables 

Al momento della chiamata di uno shader vengono compilati i Vertex e Fragment Program. In seguito si procede al caricamento da file delle texture con i relativi parametri.
Per ogni fase di rendering dell'applicazione si procede all'attivazione delle texture precedentemente utilizzate e si impostano tutte le variabili di stato OpenGL e tutte le uniform variables con i valori attuali.

Viene inoltre creato dinamicamente un dialogo che contiene cinque distinte tab:
1) nella prima vengono aggiunti, per ogni uniform variable, i widget ad essa relativi in modo da consentirne la modifica come specificato all'interno del file .gdp (modifica diretta via campo di testo, con slider o da dialogo di selezione del colore).
2) nella seconda tab vengono elencate le eventuali texture utilizzate e caricate dallo shader con i relativi path.
Qui è possibile cambiarle sia impostando direttamente il percorso nella casella di testo, sia utilizzando il tasto Browse per selezionare il file relativo alla nuova texture.
3) nella terza tab vengono elencate tutte le variabili di stato OpenGL con i valori che lo shader ha dichiarato all'interno del file gdp
4) In questa tab viene mostrato il codice relativo al Vertex Program
5) In questa tab viene mostrato il codice relativo al Fragment Program