Hi ihr
Ich bin leider erst vor einer halben Woche auf diese Seite gestoßen und war erstaunt, wieviel kondensierte Informationen man hier kompakt vorgeknallt bekommt mit allem wichtigen, wo man sonst öfter mal erst viele Stunde Datamining betreiben müsste.

In einem eurer Tutorials ist das mit alt bekannte Format TGA aufgefallen, das manfür Texturen verwenden sollte, da dort im BGRA Format gespeichert werden würde.
Nachem ich kein Glück hatte einen selbstgeschriebenen TGA Loader zum laufen zu bekommen, weil mir die C++ Syntax völlig neu ist, habe ich mr gedacht ich recherchiere noch ein wenig herum.
C++ Syntax ist für mich noch völlig neu, wir wurden vor nur ein paar Wochen ins kalte Wasser geschmissen und sollen ein C++/Glut Programm in Code::Blocks schreiben, in dem man in 3D durch die Uni laufen können soll. 3 Wochen hab ich ja noch Zeit...
Jedenfalls steht schon die halbe Engine mit Beschleunigung, 5 verschiedenen Perspektiven, Wetter wie Schnee usw,
...
aber ich muss irgendwann demnächst anfangen die Texturen einzubauen.
Deshalb hier die Fragen:
- eine Grafikkarte bevorzugt BGRA, richtig?
- OpenGL möchte bevorzugt mit RGBA gefüttert werden?
- Liegt das am switchen der vertikalen Achse(y-Koordinaten), dass das Bild verkehrt herum gelesen wird?Im Internet behaupten manche sogar *.bmp wäre bgra...

In eurem Tutorial steht zwar es wäre für Anfänger am ehesten *.tga zu empfehlen wegen dem BGRA Format, aber es wird nirgendwo deutlich, ob das jetzt das ist was die GPU möchte oder das was OpenGL will...

Schönen Gruß, Skel

Moin,
wenn du Texturen in den Grafikspeicher lädst (mit glTexImage2D), tust du das eigentlich immer im RGB(A)-Format. Das ist Konvention, wobei Grafikkarten wahrscheinlich mit BGRA genau so gut umgehen könnten. Das TGA-Format speichert BGRA und ist in der Tat eines der einfachsten Dateiformate, solange dort keine Kompression eingesetzt wird.

Du musst das Texturen-laden übrigens nicht alles selbst implementieren, dafür gibt es jede Menge Libraries. glBitmap kommt aus der Community, ist aber (afaik) nicht C++-kompatibel. Stattdessen kann man auch SDL_image nehmen oder allgemein SDL, was wenn ich mich richtig erinnere auch immerhin BMPs laden kann.

Dass die Texturen bei dir kopfstehen, liegt wahrscheinlich daran, dass du den (Textur-)Koordinatenursprung in der linken oberen Ecke vermutest. Er ist aber in der linken unteren Ecke. (Ich hoffe, ich verwechsel jetzt nicht selber was - habe lange nicht mehr mit manuell eingegebenen Texturkoordinaten gearbeitet.)

_________________
So aktivierst du Syntaxhighlighting im Forum: [code=pascal ][/code], [code=cpp ][/code], [code=java ][/code] oder [code=glsl ][/code] (ohne die Leerzeichen)

Du darfst hier nicht internes format und format verwechseln. Das interne format beschreibt nur welche Komponenten deine Pixel haben, aber nicht in welcher Reihenfolge diese Komponenten sind. Waehrend das normale format die Daten beschreibt du uebergibtst. Mit anderen Worten:
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA8, width, height, 0, GL_RGBA, GL_UNSIGNED_BYTE, pixels);

wird moeglicherweise vom Treiber nach BGRA umgewandelt. Du kannst zwar rein theoretisch seit OpenGL 4.3 das native Format vom Treiber abfragen, aber das halte ich eher fuer unwichtig. Schliesslich ist es ja eh ein relativ teurer Prozess und da macht das bisschen auch keinen groessen Unterschied. (In den DX Foren sagt man so 5%).

Uebrigens ist folgende Kombination die haeufigste da die meisten GPUs BGRA nutzen:
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA8, width, height, 0, GL_BGRA, GL_UNSIGNED_BYTE, pixels);

_________________
Meine Homepage

Tun sie nicht, ich dachte nur das Y-flipping der Y Koordinaten der Textur wird vielleicht gerade deshalb in tutorials angeführt, weil die Reihenfolge von RGBA nach BGRA schneller durchgeführt werden kann.

Ich bezog mich auf folgenden Satz aus


Quelle: https://www.opengl.org/wiki/Common_Mistakes in Artikel unter Punkt 3 "Texture upload and pixel reads"

Habe meinen Texture-Loader für TGAs jetzt zum laufen bekommen, danach gelöscht und durch die auf Sean Barretts Orginal basierende Soil.h von lonesock.net ersetzt.

Danke allen für die Hilfe.
Wie gesagt, ich dachte der Treiber hat vielleicht weniger zu tun, wenn es bereits in einem Format vorliegt, den zumindest die meisten GPUs bevorzugen. Deshalb fiel die Wahl auf BGRA, was letztlich nur bei TGAs so bereits vorliegt. ich glaube in einem Tutorial hier wird auch TGA empfohlen, allerdings aus dem anderen Grund, dass man dann Y-Koordinaten nach dem Laden nicht erst noch vertauschen muss.


Allerdings kamen mir dann auch Zweifel, da ich anderweitig gelesen habe, dass die meisten GPUs zwar RGBA bevorzugen, aber OpenGL die Dinger in RGBA bevorzugt, weil es "gewohnt sei" diese erst umkonvertieren zu müssen für die GPU.

Das hieße für mich kurz gefasst:
Open GL bevorzugt RGBA, wandelt es für die GPU aber in GBRA um, welches die GPU will.
Komisch, dass bei mir unter freeglut BGRA gar nicht als Parameter zur Auswahl steht wie ich aber erst später festgestellt hatte...

Bedauerlich, dass wir mit einer völlig veralteten Version arbeiten sollen...

ja das kommt immer mal wieder auf. GL_BGRA war früher die Extension GL_BGRA_EXT und kam erst später in den Standard. Daher findest du GL_BGRA in der Regel in "glext.h" und GL_BGRA_EXT in "gl.h".

Wenn du nicht gerade eine Grafikkarte aus grauer Vorzeit besitzt kannst du vorraussetzen das es existiert (der Kram ist älter als Multitexturing).

_________________
Meine Homepage

Ich verweise auf eine der wenigen Quellen dies bzgl.
http://http.download.nvidia.com/developer/Papers/2005/Fast_Texture_Transfers/Fast_Texture_Transfers.pdf
BGRA ist das Format der wahl, alles andere swizzled vor sich hin.
NV hat RGBA Extensions, die auf der GPU dann andere Routinen zum lesen verwenden und dann nicht swizzle(hard wired swizzle).

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Danke, sehr informativer Link.
Schade, dass das Volumen an zu verarbeitenden Informationen so groß ist und ich das nicht in den nächsten 2 Wochen alleine verarbeiten kann.
Immerhin muss man noch die funktionsweisen von VBOs, PBOs, VAOs, MipMaps usw miteinander noch gliedern.
Vielleicht mache ich noch einen Thread auf, falls ich die Informationen nicht nach längerem lesen finde.
Schönen Gruß, Skel