Formato immagine migliore (più popolare?) Per texturing [chiuso]

Va bene, quindi sto usando C ++ con OpenGL e ho intenzione di creare un caricatore per caricare trame per il mio gioco 3D. (Ma le trame sono in 2D). Voglio l'opzione della trasparenza, anche se decido di non usarla. Ho bisogno di una qualità decente, anche se non deve essere di prim'ordine. Cosa suggerite voi ragazzi per il formato (PNG, TGA, ecc.). Inoltre, forse rendilo qualcosa per cui è facile creare un caricatore (non ne userò uno già creato). Inoltre, se si dispone di collegamenti / suggerimenti per aiutare con il caricatore, sarebbe apprezzato.

Non capisco perché non vorresti usare un caricatore standard. PNG , ad esempio, è una buona scelta per un formato ma è complesso scrivere un caricatore per scopi generali (e probabilmente non vale la pena scriverne uno che carica solo il sottoinsieme specifico dei formati PNG che ti interessano).

Dato questo requisito alquanto insolito, TGA è probabilmente la soluzione migliore. TGA 2.0 ha un canale alfa ed è relativamente semplice rispetto al PNG.

Anche il formato della trama dell'immagine è una scelta prestazionale. Ti consiglio di usare le trame compresse il più possibile. Su piattaforme mobili, può migliorare notevolmente le prestazioni (40% o anche più), l'utilizzo della memoria e il caricamento del tempo.

Considera una trama 1024 * 1024:

• RGB o RGBA (16 bit): 2Mo (.5s da caricare su SGS)
• RGBA (32 bit): 4Mo (1s da caricare su SGS)
• PVRT (4bpp): 512ko (.125s da caricare su SGS)
• ETC1 + Alpha: 1,5Mo (.4s da caricare su SGS)

Nei nostri giochi, abbiamo risorse (trame) in molti formati:

• Formato DDS per trame DXTC (piattaforme desktop: OS X, Linux, Windows e Tegra)
• Formato DDS per trame ATC (GPU Andreno)
• Formato PVR per formato PVRT (GPU PowerVR)
• Formato PKM per texture ETC1 (compatibile con tutti i dispositivi OGLES 2.0)

Alla fine, utilizziamo il formato non elaborato per la compatibilità, ma per compatibilità o elementi della GUI

• Formato PNG per trama grezza. È per trame RGBA 16, 24 o 32 bit (usiamo un caricatore con licenza MIT). Sono trame non compresse.

Le trame ETC1 non hanno canali alfa, quindi utilizziamo uno shader speciale con due trame (trama rgb e trama alfa). I formati compressi sono molto facili da caricare (100 o 200 loc).

Sul desktop, DXTC (S3TC) è presente su molte schede. Quindi, dovresti usarlo.

Trame compresse

professionista

• Fillrate della trama migliorato
• Caricamento trama (4x o più)
• Facile da caricare

contro

• Non supportato su tutte le piattaforme
• artefatti

Le trame sono raccolte di una o più immagini. Ciò significa che una trama può essere rappresentata da un TGA o PNG, ma nessuno dei due formati è in grado di rappresentare tutte le possibili caratteristiche delle trame. Perché?

Perché ognuno può contenere solo una singola immagine. Non ci sono mipmap. Non ci sono trame 3D possibili. Nessuna trama di matrice. Nessuna mappa cubica. Ognuno di questi file è solo una singola immagine 2D. Possono far parte di una trama, ma a meno che tu non stia usando il mipmapping (e sconsiglio vivamente di non usare le mipmap a meno che tu non abbia esigenze specifiche), un singolo file di immagine in questi formati non può essere una trama.

Sono formati di immagini fini, ma creano formati di trama scadenti .

DDS è il front-runner dei formati di texture perché in realtà supporta le esigenze di texture. Supporta mipmap e cubemap. Supporta trame 3D. DDSv10 supporta trame di array. È possibile impacchettare una singola trama all'interno di un DDS in un modo impossibile con PNG o TGA.

DDS supporta dati di trama non compressi e compressi. Finché il formato di trama compresso è uno dei formati di trama DXT / BC.

PKM è utile per il confezionamento di immagini compresse con ETC1, ma come con PNG, non supporta le funzioni di trama effettive.

I file PVR sembrano essere l'equivalente mobile di DDS (anche se il motivo per cui non potevano semplicemente usare DDS, non lo so). Supportano varie tecniche di compressione, ma mancano di funzionalità DDSv10 avanzate come trame array e supporto per le trame 3D.

Quindi DDS vince in termini di supporto completo per le texture.

Il gruppo Khronos consiglia il formato di file KTX per la memorizzazione di trame per le applicazioni OpenGL e OpenGL ES. Puoi usare libktx per lavorare con questo formato.

Caratteristiche:

• Crea un'istanza di una trama OpenGL da un file KTX
• Decomprime un'immagine di trama compressa ETC1 quando l'hardware non ha il supporto ETC1.
• Costruisci una tabella hash di coppie chiave-valore dal file KTX mentre viene caricata la trama
• Scrivi un file KTX da una matrice di immagini sorgente e una tabella hash opzionale di coppie chiave-valore.
• Costruisci e popola una tabella hash di coppie chiave-valore.

Sembra che DDS (DirectDraw Surface) sia la scelta più popolare per le texture al momento. Ha diversi formati di pixel, trasparenza e compressione. È supportato in OpenGL tramite l'estensione GL_ARB_texture_compression.

Ad esempio, c'è un caricatore OpenGL qui .

Ci sono una serie di considerazioni qui:

1. Quanto velocemente puoi ottenere la trama dal disco e nella memoria di sistema.
2. Quanto velocemente puoi ottenere la trama dalla memoria di sistema alla GPU (tramite glTexImage2D nel tuo caso).
3. Quanto spazio su disco e memoria RAM video è nel tuo budget.
4. Performance e qualità.

TGA è una buona scelta perché nei casi non compressi a 24 e 32 bit è possibile leggere i dati in una singola testata / qualunque cosa e inviare il risultato direttamente tramite glTexImage2D senza ulteriore elaborazione. È una scelta sbagliata perché può avere la dimensione del file più grande e se l'I / O del disco è un collo di bottiglia, le letture saranno lente.

PNG è una buona scelta perché conserva la qualità delle immagini con una dimensione del file ragionevolmente piccola. È una cattiva scelta perché i PNG possono essere lenti a decomprimersi - se questo è il tuo collo di bottiglia allora - beh, lo sai.

JPG è una buona scelta perché in genere ha le dimensioni del file più piccole e verrà rimosso dal disco molto velocemente (doppiamente buono se è necessario inviare il file su una rete). È una cattiva scelta a causa dei passaggi intermedi di decompressione del software e della perdita di qualità (anche se è possibile ottimizzare le impostazioni di qualità per mitigarlo). Neanche un canale alfa.

DDS (o altri formati compressi) sono buone scelte a causa delle dimensioni del file più piccole e della possibilità di includere una catena mipmap precompilata. Se è un formato supportato in modo nativo nell'hardware (e DDS è supportato in modo nativo sulla maggior parte dell'hardware del PC di consumo - lo è stato anche per molto tempo) ottieni lo stesso vantaggio del TGA: un vantaggio, un po 'di frugamenti nell'intestazione per capire alcune proprietà dell'immagine, quindi inviare i dati direttamente senza passaggi intermedi. Le trame compresse renderanno il tuo programma più veloce e utilizzeranno meno RAM video. Sono scelte sbagliate perché usano la compressione con perdita (che a volte può essere davvero evidente) e potrebbero non essere supportate su tutto l'hardware.

Se fossi in me, creerei il supporto per tutti e 4 questi formati (TGA e DDS sono abbastanza banali per cui scrivere caricatori, con JPG e PNG userei una libreria di immagini) in modo che i creatori di contenuti possano scegliere il formato più adatto su una base per trama.

E ovviamente puoi sempre andare con il vecchio BMP a 32 bit che è davvero facile da caricare (specialmente se la dimensione è una potenza di 2 (in realtà, un multiplo di 8 byte IIRC)).

Altrimenti sembra strano che tu voglia un solo formato, jpg è davvero bello per le belle trame ad alta risoluzione del mondo reale (jpeg fa meraviglie con spazio su disco e (down) tempi di caricamento), png per la trasparenza e il BMP occasionale a 32 bit per le trame dei controli (facile da creare da uno script o uno strumento 'veloce e sporco').