Copertura - difetto dell'algoritmo - come sbarazzarsi del suo utilizzo?

introduzione

Molti dei principali motori di rendering della grafica vettoriale presentano un difetto algoritmico. Rendono ciascuna forma separatamente e antialias calcolando la copertura dei pixel e quindi componendoli uno sopra l'altro. Sì, è semplice ma le soluzioni corrette sono ancora più semplici.

Ciò porta a un problema di conflazione in quanto unisce la copertura alla trasparenza. La fusione alfa segue una regola che non rappresenta la situazione in modo accurato, ad esempio prendi un pixel coperto al 50% che è adiacente a un pixel che è anche coperto al 50% complementare non finisce con una copertura del 100% finisce con una copertura del 75% . Ciò che sembra dipende da come è sintonizzato l'algoritmo e da altri dettagli, ma in sostanza si tratta di un errore noto. Qualcuno ha anche affrontato il problema di documentare i diversi errori del motore insieme a scrivere un documento che mostra come si potrebbe fare meglio.

Immagine 1 : campione totalmente non rappresentativo, di rendering di una forma fatta di triangoli che mostrano un errore ingrandito nella riga superiore. Fonte SVG

Il problema ha una semplice soluzione ingenua * basta un super campione senza calcolo della copertura e filtrare l'immagine verso il basso. Come bonus, puoi usare algoritmi di ricostruzione delle immagini migliori del filtro box (leggi A Pixel is Not a Square ³ ). Esistono anche soluzioni che hanno una velocità comparabile rispetto alle soluzioni attuali e queste soluzioni sono molto più facili da fare nelle pipeline di rasterizzazione hardware (e raramente vedi questo errore sulla GPU perché è stato costruito per evitare proprio questo problema).

Anche questo non è un problema senza costi. Ci sono molte persone che lavorano nella progettazione grafica che trascorrono una quantità non banale di tempo nel tentativo di aggirare questo problema manualmente assicurandosi che ci siano sovrapposizioni qui e nessuna sovrapposizione lì per risolvere il problema che il computer dovrebbe fare per loro. E fallendo in modo spettacolare in molti casi. Ma ai loro clienti non importa perché l'errore è lì, devono ripararlo.

Domanda

Come si propaga l'errore? Dato che stanno tutti facendo lo stesso errore, si potrebbe concludere che usano la stessa fonte per il loro algoritmo. Cosa avrebbe potuto indurre i progettisti a scegliere questo algoritmo? Perché solo i programmatori 3D hanno riconosciuto questo errore e hanno persino codificato la sua parte nelle API e nell'insegnamento, mentre i programmatori 2D no?

Come garantire che questo errore smetta di propagarsi ulteriormente?

Addendum (ma non sto chiedendo questo)

* Apparentemente la mia affermazione che il super campionamento funziona senza difetti è straordinaria e richiede prove straordinarie. Ok, quindi la chiave del funzionamento del super campionamento è che il super campionamento non esegue l'elaborazione della copertura. In sostanza, il super campionatore tratta ogni campione come un campione puntuale. Dal momento che il campione di punti non fa ipotesi sull'area sottostante, non sta causando un confronto alfa dove non accade.

Perché funzioni in modo coerente, come descritto in una delle risposte. Dobbiamo fare in modo che i campioni vengano elaborati con il campionamento intero per coerenza. Questo ci assicura che ogni punto trasformato nello spazio dello schermo ottiene esattamente la stessa soluzione per coordinate uguali e che nessun campione è ombreggiato da un bordo di pixel 2 volte. Per fare ciò un campione potrebbe non attivare un pixel ot è esattamente attivo se è ad esempio il campione in basso a sinistra (quindi facciamo una regola che i bordi esatti vengano elaborati in> vs <=). Tutte le schede grafiche tranne una funzionano in questo modo. Assicura che non è necessario memorizzare nella cache dati aggiuntivi e che non è necessario eseguire ulteriori test nelle vicinanze. Questa soluzione è stabile, più generale e coerente delle soluzioni basate sulla copertura.

L'algoritmo è esattamente lo stesso dell'originale con un po 'meno codice e leggermente più campioni. È quindi coerente se non più dell'algoritmo basato sulla copertura. Lo sappiamo perché abbiamo usato tali metodi per secoli in quasi tutti gli altri campi di elaborazione del segnale e nelle schede grafiche.

Quindi questo metodo ha un aspetto negativo? Bene, è un po 'più lento se si dovesse solo fare un'ipotesi ingenua. Ha teoricamente un comportamento asintotico più veloce rispetto al rasterizzatore di copertura, un po 'come un raytracer è ancora alla pari nelle scene tipiche. Inoltre potrebbe rendere più doloroso implementare l'uso degli effetti basati sulla convoluzione.

Il sovracampionamento, se fatto in modo ingenuo, è computazionalmente costoso, poiché se si utilizza ad esempio metà della dimensione dei pixel del display, è necessario quattro volte la memoria e la larghezza della banda. Wikipedia menziona questo e nomina anche il supersampling adattivo come una possibile soluzione. Ma questo inizia a rendere l'algoritmo molto più sofisticato, complesso e più difficile da implementare.

E immagino che sia questo il motivo che stai cercando: se vuoi un algoritmo che non ha bisogno di molta memoria e tempo di esecuzione, le cose stanno diventando molto più complicate rispetto all'approccio ingenuo "trasparenza".

Il supercampionamento non risolverà il problema in generale: lo renderà semplicemente meno evidente. Con pixel della metà delle dimensioni, il problema sarà la metà evidente ma non andrà via.

Il punto architettonico alla base di questi progetti è che vogliamo che il comando "rendering triangolo ABC" abbia un significato definito. Non vogliamo che sia ambiguo, tranne se considerato come parte di una raccolta di comandi di disegno - ad esempio, avendo un significato quando "rendering triangolo BCD" è anche nella raccolta (con lo stesso o un colore diverso) e un altro significato quando non lo è.

Considerando, ad esempio, un migliaio di triangoli, anche trovare tutti i triangoli che condividono un lato o una parte di un lato con ABC è pesante dal punto di vista computazionale (ricordando che deve essere rifatto mille volte). Ci sono anche molti altri problemi pratici: in particolare che tutte le richieste di rendering originali devono essere mantenute in giro, anche se sono state disegnate molto tempo fa, nel caso in cui debbano essere rivalutate a causa di una nuova richiesta aggiuntiva.

La linea di fondo è che una soluzione perfettamente coerente non è praticabile. Rimane la domanda: dovremmo cercare di migliorare la situazione attuale quando possiamo? In generale, la risposta a questa domanda è No. Un'implementazione perfettamente coerente di un modello è sempre migliore, anche se il modello stesso ha i limiti che hai illustrato. L'alternativa sarebbe un'implementazione che a volte fa meglio e talvolta no, senza che il programmatore possa sapere quale di questi due si terrà in un caso particolare. Inoltre, può passare da "fa meglio" a "non fa meglio" a causa di piccole modifiche apportate dal programmatore - o anche a causa di quelle al di fuori del controllo del programmatore. La prevedibilità, in un contesto di programmazione, è lontana,