2010-02-18 12 views
13

Sto lavorando a un problema di visione del computer che richiede il rendering di un modello 3d utilizzando una fotocamera calibrata. Sto scrivendo una funzione che rompe la matrice calibrata della telecamera in una matrice modelview e una matrice di proiezione, ma mi sono imbattuto in un fenomeno interessante in opengl che sfida la spiegazione (almeno per me).Perché il segno è importante nella matrice di proiezione opengl

La breve descrizione è che se si annulla la matrice di proiezione non viene eseguito alcun rendering (almeno nella mia esperienza). Mi aspetto che moltiplicare la matrice di proiezione con uno scalare non abbia alcun effetto, perché trasforma le coordinate omogenee, che non sono influenzate dal ridimensionamento.

Di seguito è riportato il mio ragionamento per cui ritengo che questo sia inaspettato; forse qualcuno può indicare dove il mio ragionamento è difettoso.

Immaginate la seguente matrice di proiezione prospettica, che dà risultati corretti:

[ a b c 0 ] 
P = [ 0 d e 0 ] 
    [ 0 0 f g ] 
    [ 0 0 h 0 ] 

moltiplicando tale da coordinate telecamera produce fermaglio omogenea coordinate:

[x_c] [ a b c 0 ] [X_e] 
[y_c] = [ 0 d e 0 ] * [Y_e] 
[z_c] [ 0 0 f g ] [Z_e] 
[w_c] [ 0 0 h 0 ] [W_e] 

Infine, per ottenere normalizzati coordinate del dispositivo, si divide x_c, y_c e z_c di w_c:

[x_n] [x_c/w_c] 
[y_n] = [y_c/w_c] 
[z_n] [z_c/w_c] 

Ora, se neghiamo P, le coordinate di clip risultanti dovrebbero essere negate, ma poiché sono coordinate omogenee, moltiplicando per qualsiasi scalare (ad es. -1) non dovrebbe avere alcun effetto sulle coordinate del dispositivo normalizzate risultanti. Tuttavia, in openGl, la negazione di P risulta in nulla resa. Posso moltiplicare P per qualsiasi scalare non negativo e ottenere lo stesso risultato di rendering, ma non appena mi si moltiplica per uno scalare negativo, non viene eseguito il rendering. Che cosa sta succedendo qui??

Grazie!

risposta

10

Ebbene, il succo è che i test di clipping avviene attraverso:

-w_c < x_c < w_c 
-w_c < y_c < w_c 
-w_c < z_c < w_c 

Moltiplicando per negativo pause valore questa prova.

+1

Bella risposta! Supponevo che il test di clipping fosse: -1

2

Ho appena trovato questo bocconcino, il che rende il progresso verso una risposta:

Da Libro rosso, appendice G:

Evitare l'uso negativo w coordina vertice e negativi coordinate q texture. OpenGL potrebbe non ritagliare correttamente tali coordinate e potrebbe fare errori di interpolazione quando ombreggia primitive definite da tali coordinate.

inversione della matrice di proiezione causa negativo W clipping coordinate, e apparentemente OpenGL non come questo. Ma qualcuno può spiegare PERCHÉ opengl non gestisce questo caso?

riferimento: http://glprogramming.com/red/appendixg.html

0

Motivi posso pensare:

  • invertendo la matrice di proiezione, le coordinate saranno più all'interno delle zNear e zFar piani del tronco vista (necessariamente maggiore di 0).
  • Per creare le coordinate della finestra, le coordinate del dispositivo normalizzate vengono convertite/ridimensionate dal viewport. Quindi, se hai usato uno scalare negativo per le coordinate della clip, le coordinate normalizzate del dispositivo (ora invertite) traducono il viewport in coordinate della finestra che sono ... fuori dalla tua finestra (a sinistra e in basso, se vuoi)

Inoltre, poiché hai menzionato l'utilizzo di una matrice di telecamere e di aver invertito la matrice di proiezione, devo chiedere ... a quali matrici stai applicando cosa dalla matrice della telecamera? Operare sulla matrice di proiezione salva near/far/fovy/aspetto causa tutti i tipi di problemi nel buffer di profondità incluso tutto ciò che usa z (test di profondità, eliminazione del volto, ecc.).

La sezione Domande frequenti su OpenGL su transformations ha ulteriori dettagli.

+0

Dopo la conversione da coordinate omogenee a non omogenee (vale a dire dividendo per w_c), le coordinate cadono ancora tra zNear e zFar, perché il segno negativo di w_c annulla il segno invertito di {x, y, z} _c. quindi penso che non sia così. Per lo stesso motivo, le coordinate normalizzate del dispositivo non sono, invero, invertite. Sto solo usando la matrice di proiezione per i parametri della fotocamera intrinseca (fovy, aspect, axis skew, etc); i parametri estrinseci stanno entrando nella matrice modelview. Quindi penso che anche questo non sia il problema. –

+0

Non conosco i dettagli di implementazione del driver, ma suppongo che in realtà non sia il caso di zNear e zFar. Probabilmente il test della clip non è il range ma la profondità e quindi il valore numerico è testato per essere maggiore di zNear (per prima cosa occulta il requisito positivo). Se l'intero sistema di coordinate e la matrice sono invertiti, il test fallisce come indicato da bahbar. – charstar

Problemi correlati