Rendering grafico mediante accelerazione 3D

StackOverflow https://stackoverflow.com/questions/219872

  •  03-07-2019
  •  | 
  •  

Domanda

Generiamo grafici per enormi set di dati. Stiamo parlando di 4096 campioni al secondo e 10 minuti al grafico. Un semplice calcolo rende 4096 * 60 * 10 = 2457600 campioni per riga. Ogni campione è un FP di precisione doppio (8 byte). Inoltre, eseguiamo il rendering di più grafici a linea su uno schermo, fino a circa un centinaio. Questo rende il rendering di circa 25 milioni di campioni in una singola schermata. Usando il buon senso e semplici trucchi, possiamo ottenere questo codice performante usando la CPU disegnandolo su una tela 2D. Performant, ovvero i tempi di rendering scendono al di sotto di un minuto. Dato che si tratta di dati scientifici, non possiamo omettere alcun campione. Seriamente, questa non è un'opzione. Non iniziare nemmeno a pensarci.

Naturalmente, vogliamo migliorare i tempi di rendering usando tutte le tecniche disponibili. Multicore, pre-rendering, memorizzazione nella cache sono tutti abbastanza interessanti ma non lo tagliano. Vogliamo un rendering 30FPS con questi set di dati al minimo, preferibilmente 60FPS. Ora questo è un obiettivo ambizioso.

Un modo naturale per scaricare il rendering grafico è usare la GPU del sistema. Le GPU sono progettate per funzionare con enormi set di dati ed elaborarli parallelamente. Alcuni semplici test HelloWorld ci hanno mostrato una differenza di velocità tra il giorno e la notte, usando la GPU.

Ora il problema è: le API GPU come OpenGL, DirectX e XNA sono pensate per le scene 3D. Pertanto, usarli per eseguire il rendering di grafici a linee 2D è possibile, ma non ideale. Nella prova dei concetti che abbiamo sviluppato, abbiamo riscontrato che dobbiamo trasformare il mondo 2D in un mondo 3D. Improvvisamente dobbiamo lavorare con il sistema di coordinate XYZ con poligoni, vertici e molto altro ancora. Questo è tutt'altro che ideale dal punto di vista dello sviluppo. Il codice diventa illeggibile, la manutenzione è un incubo e molte altre questioni si risolvono.

Quale sarebbe il tuo suggerimento o idea a questo in 3D? È l'unico modo per farlo per convertire effettivamente i due sistemi (coordinate 2D contro coordinate 3D e entità)? O c'è un modo più elegante per raggiungere questo obiettivo?

-Perché è utile eseguire il rendering di più campioni su un pixel? Dal momento che rappresenta meglio il set di dati. Dì su un pixel, hai i valori 2, 5 e 8. A causa di alcuni algoritmi di omissione del campione, viene disegnato solo il 5. La linea andrebbe solo a 5, e non a 8, quindi i dati sono distorti. Potresti anche sostenere il contrario, ma il fatto è che il primo argomento conta per i set di dati con cui lavoriamo. Questo è esattamente il motivo per cui non possiamo omettere i campioni.

È stato utile?

Soluzione

Un toolkit molto popolare per la visualizzazione scientifica è VTK e penso che soddisfi le tue esigenze:

  1. È un'API di alto livello, quindi non dovrai usare OpenGL (VTK è basato su OpenGL). Esistono interfacce per C ++, Python, Java e Tcl. Penso che questo manterrebbe la tua base di codice abbastanza pulita.

  2. Puoi importare tutti i tipi di set di dati in VTK (ci sono tonnellate di esempi dall'imaging medico ai dati finanziari).

  3. VTK è piuttosto veloce e puoi distribuire pipeline grafiche VTK su più macchine se vuoi eseguire visualizzazioni molto grandi.

  4. Per quanto riguarda:

      

    Questo rende il rendering di circa 25 milioni di campioni in una singola schermata.

         

    [...]

         

    Dato che si tratta di dati scientifici, non possiamo omettere alcun campione. Seriamente, questa non è un'opzione. Non iniziare nemmeno a pensarci.

È possibile eseguire il rendering di set di dati di grandi dimensioni in VTK campionando e utilizzando i modelli LOD. Cioè, avresti un modello in cui vedi una versione a risoluzione più bassa da lontano, ma se ingrandisci vedresti una versione a risoluzione più alta. Questo è il modo in cui viene eseguito un grande rendering del set di dati.

Non è necessario eliminare i punti dal set di dati effettivo, ma è possibile perfezionarli in modo incrementale quando si ingrandisce l'utente. Non è utile eseguire il rendering di 25 milioni di punti su una singola schermata quando l'utente non può elaborare tutti quei dati. Ti consiglio di dare un'occhiata sia alla libreria VTK che alla guida dell'utente VTK, in quanto ci sono alcune informazioni preziose lì su come visualizzare grandi set di dati.

Altri suggerimenti

Vorrei commentare la tua affermazione secondo cui non puoi omettere campioni, sul retro della risposta di tgamblin.

Dovresti considerare i dati che stai disegnando sullo schermo come un problema di campionamento. Stai parlando di 2,4 milioni di punti di dati e stai provando a disegnarli su uno schermo di poche migliaia di punti (almeno suppongo che lo sia, poiché sei preoccupato per le frequenze di aggiornamento di 30 fps)

Ciò significa che per ogni pixel nell'asse x stai eseguendo il rendering nell'ordine di 1000 punti che non è necessario. Anche se segui il percorso di utilizzo della tua gpu (ad es. Attraverso l'uso di opengl), è comunque una grande quantità di lavoro che la gpu deve fare per le linee che non saranno visibili.

Una tecnica che ho usato per presentare i dati di esempio è generare un set di dati che è un sottoinsieme dell'intero set, solo per il rendering. Per un dato pixel nell'asse x (cioè una determinata coordinata dello schermo dell'asse x) è necessario eseguire il rendering di un assoluto massimo di 4 punti, ovvero il minimo y, il massimo y, l'estrema sinistra ye l'estrema destra y . Ciò renderà tutte le informazioni che possono essere utilmente rese. Puoi ancora vedere i minimi e i massimi e mantieni la relazione con i pixel vicini.

Con questo in mente, puoi calcolare il numero di campioni che cadranno nello stesso pixel nell'asse x (pensali come dati "bin"). All'interno di un determinato contenitore, è quindi possibile determinare i campioni particolari per massimi, minimi ecc.

Per ribadire, questo è solo un sottoinsieme utilizzato per la visualizzazione - ed è appropriato solo fino alla modifica dei parametri di visualizzazione. per esempio. se l'utente scorre il grafico o ingrandisce, è necessario ricalcolare il sottoinsieme di rendering.

Puoi farlo se stai usando opengl, ma poiché opengl usa un sistema di coordinate normalizzato (e sei interessato alle coordinate dello schermo del mondo reale) dovrai lavorare un po 'più per determinare con precisione i tuoi bin dati. Questo sarà più facile senza usare Opengl, ma non otterrai il massimo beneficio dal tuo hardware grafico.

In realtà non devi preoccuparti dell'asse Z se non vuoi. In OpenGL (ad esempio), puoi specificare i vertici XY (con Z implicita = 0), girare lo zbuffer, usare una matrice di proiezione non proiettiva e hey presto sei in 2D.

Mark Bessey ha menzionato che potrebbe mancare i pixel per visualizzare il grafico. Ma date le tue spiegazioni, suppongo che tu sappia cosa stai facendo.

OpenGL ha una modalità ortogonale che ha una coordinata z all'interno (0; 1). Non esiste alcuna proiezione prospettica, i poligoni disegnati saranno planari nell'area di ritaglio dello schermo.

DirectX avrà simili. Su OpenGL, si chiama gluOrtho2d ().

OpenGL è felice di rendere 2D se si imposta la proiezione su Orto (no z). Inoltre dovresti decimare i tuoi dati. Il rendering dello stesso pixel 1000 volte è uno spreco di GPU. Trascorri il tuo tempo in anticipo con un decimatore multi-thread performat. Assicurati di far esplodere array di grandi dimensioni nella GPU usando array di vertici o oggetti buffer di vertici (chiaramente sono un tipo OpenGL di tipo)

  

Questo rende il rendering di circa 25 milioni di campioni in una singola schermata.

No, non a meno che tu non abbia uno schermo davvero molto grande . Dato che la risoluzione dello schermo è probabilmente più simile a 1.000 - 2.000 pixel, dovresti davvero considerare di decimare i dati prima di rappresentarli graficamente. La rappresentazione grafica di un centinaio di righe a 1.000 punti per riga probabilmente non sarà un grosso problema, dal punto di vista delle prestazioni.

Se il tuo codice diventa illeggibile perché hai a che fare direttamente con le cose 3D, devi scrivere un sottile strato adattatore che incapsula tutte le cose 3D OpenGL e prende i dati 2D in un formato conveniente per la tua applicazione.

Perdonami se mi sono perso qualcosa e sto predicando al coro un design di base orientato agli oggetti. Sto solo dicendo ...

  

Non è necessario eliminare i punti dal set di dati effettivo, ma è possibile perfezionarli in modo incrementale quando si ingrandisce l'utente. Non è utile eseguire il rendering di 25 milioni di punti su una singola schermata quando l'utente non può elaborare tutti quei dati. Ti consiglio di dare un'occhiata sia alla libreria VTK che alla guida dell'utente VTK, in quanto ci sono alcune informazioni preziose lì su come visualizzare grandi set di dati.

Grazie mille. Questo e 'esattamente quello che stavo cercando. Sembra che VTK utilizzi l'hardware per scaricare anche questo tipo di rendering. A proposito, immagino che intendi prezioso ;). In secondo luogo, l'utente ottiene informazioni sull'esempio che ho fornito. Tuttavia, non molto conciso, la panoramica dei dati può davvero essere oro puro per lo scienziato. Non si tratta di elaborare tutti i dati per l'utente, si tratta di ottenere informazioni preziose dal rendering. Gli utenti sembrano farlo, anche nella rappresentazione molto "ridotta" del set di dati.

Altri suggerimenti?

Volevo sottolineare che oltre a utilizzare direttamente VTK ci sono altri due prodotti basati su VTK che potrebbero interessarti.

1) ParaView (paraview.org) è un'interfaccia utente basata su VTK che semplifica notevolmente i prodotti di visualizzazione scientifica. È possibile eseguire il rendering di tutti i dati desiderati, purché si disponga dell'hardware per gestirli e supporta MPI per più processori / core / cluster. È estensibile tramite plugin creati dall'utente e utilizza strumenti automatizzati per la creazione e la compilazione di progetti.

2) ParaViewGeo (paraviewgeo.mirarco.org) è un derivato di esplorazione geologica e mineraria di ParaView prodotto dalla società per cui lavoro. Ha un supporto integrato per la lettura di formati di file che ParaView non possiede, come Gocad, Datamine, Geosoft, SGems e altri. Ancora più importante, spesso lavoriamo con altri gruppi che hanno un interesse per la scienza, con un risultato vagamente vincolante per il mining, come il nostro recente lavoro con un gruppo che sta realizzando modelli di elementi finiti / discreti. Potrebbe valere la pena dare un'occhiata.

In entrambi i casi (PV e PVG) i tuoi dati sono considerati separati dalla tua visione di tali dati e, in quanto tali, non potrai mai "renderizzare" tutti i tuoi dati (dal momento che probabilmente non avresti un monitor abbastanza grande per farlo) ma ti assicuro che saranno tutti " essere li " elaborato dal set di dati come previsto. Se esegui filtri aggiuntivi sui tuoi dati, solo ciò che può essere visualizzato sarà "reso" " ma i filtri verranno calcolati su TUTTI i tuoi dati, che sebbene potrebbero non essere tutti visibili contemporaneamente, tutti saranno presenti in memoria.

Se stai cercando numeri, oggi ho calcolato tre griglie regolari di 8 milioni di celle in PVG. Uno conteneva una proprietà vettoriale di 7 tuple (7x 8 milioni di valori doppi), gli altri due contenevano ciascuno una proprietà scalare (1x 8 milioni di valori doppi ciascuno) per un totale di 72 milioni di valori doppi in memoria. Credo che il footprint di memoria fosse vicino a 500 MB, ma avevo anche un set di 400.000 punti in cui ogni punto aveva una proprietà vettoriale a 7 tuple e alcuni altri dati disponibili.

Non sei sicuro che sia utile, ma potresti usare il tempo come dimenion? cioè un fotogramma è uno z? Ciò potrebbe rendere le cose più chiare, forse? Quindi forse potresti effettivamente applicare delta per costruire (cioè sull'asse z) l'immagine?

  

No, non a meno che tu non abbia uno schermo davvero grande. Dato che la risoluzione dello schermo è probabilmente più simile a 1.000 - 2.000 pixel, dovresti davvero considerare di decimare i dati prima di rappresentarli graficamente. La rappresentazione grafica di un centinaio di righe a 1.000 punti per riga probabilmente non sarà un grosso problema, dal punto di vista delle prestazioni.

Prima di tutto, non possiamo omettere alcun campione durante il rendering. Questo è impossibile. Ciò significherebbe che il rendering non è accurato rispetto ai dati su cui si basa il grafico. Questa è davvero un'area vietata. Periodo.

In secondo luogo, stiamo eseguendo il rendering di tutti i campioni. È possibile che più campioni finiscano sullo stesso pixel. Ma lo stiamo ancora eseguendo. I dati di esempio vengono convertiti sullo schermo. Quindi, è reso. Si può dubitare dell'utilità di questi dati visualizzati, ma gli scienziati (i nostri clienti) lo stanno effettivamente chiedendo, lo facciamo in questo modo. E hanno un buon punto, IMHO.

Avvolgi la libreria in una libreria 2D più delicata e più gentile con la Z e le rotazioni tutte impostate su 0.

-Adam

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top