[OpenGL] Blend/Binormal/Tangent-Attribute an OpenGL senden?

[Eisflamme]

Hi,

Ich arbeite mich gerade in das Shadergedöns mit CG ein. Jetzt ist es ja so, dass man je Vertex ein paar schöne Attribute mitgeben kann. Ich möchte halt VertexBuffer nutzen, da die ja schneller sein sollen, gleichzeitig aber alles an die Shader mitgeben, was sie brauchen.

Gut, es gibt glVertexPointer/glIndexCounter/glColorPointer/glTexcoordPointer... was ich nicht finde ist: glTangentPointer, glBlendWeightPointer, glBitangentPointer, glBlendIndicePointer, glTexcoord2/3/4pointer...

Wie kann ich diese z.T. ja nun wirklich wichtigen Attribute jetzt an OpenGL übergeben und damit für Shader brauchbar machen?

Ich hab gerade 3 Ideen:
1)
Ich hab jetzt glPushClientAttrib gefunden, wo man was vom Client-Attribut-Stack hochladen kann. Ich weiß aber nicht so recht, ob das mein Problem löst...
2)
Dann habe ich noch glVertexAttrib-Funktionen gefunden, wo man anscheinend eigene Attribute festlegen kann. Das würde mir an sich ja schon Mal helfen! Aber dann müsste ich in CG andere Semantiken nutzen als BLENDWEIGHT und BLENDINDICE, was schade ist, da die doch genau für Boneanimationen gemacht ist -> custom attributes scheint nicht zu treffen, was ich will =/ Beispielsweise müsste ich CG-Shader dann umschreiben. Und wenn DX z.B. dieses BLEND-Zeug anbietet und OGL nicht, muss ich alles nach OpenGL ausrichten und zig custom attribute machen, was ja hässlich ist, oder?
3)
Dann ist die Frage, ob es irgendwelche Extensions gibt, die mein Problem lösen. Ich hab einfach Mal lustig glWeight eingegeben und MSVC hat glWeightPointerARB gefunden. Jetzt wollte ich danach googlen und hab nix gefunden, d.h. ich habe kA, ab welcher OGL-Version das geht oder ob das überhaupt geht und kriege natürlich auch nicht raus, ob das Ding weight + boneIndex möchte und automatisch für meine Shader aufschlüsselt oder ob ich noch ne andere Funktion nutzen muss. Zu glBone habe ich jedenfalls nix bekommen von wegen Indices.

Also bisher erscheint mir 2 als einzige aber auch nicht unbedingt elegante Möglichkeit. Das Problem wird kaum neu sein, wie löst ihr das? :)

Vielen Dank im Voraus!

[glassbear]

Guten Morgen,

Gut, es gibt glVertexPointer/glIndexCounter/glColorPointer/glTexcoordPointer... was ich nicht finde ist: glTangentPointer, glBlendWeightPointer, glBitangentPointer, glBlendIndicePointer, glTexcoord2/3/4pointer...

Die fett markierten gibt es auch nicht. Da mußt du andere Sachen für "missbrauchen", normalerweise glTexCoordPointer().

Wie kann ich diese z.T. ja nun wirklich wichtigen Attribute jetzt an OpenGL übergeben und damit für Shader brauchbar machen?

Du erstellst einen VBO (GenBuffers(), BindBuffer()) und kopierst die Daten da rein mittels BufferData(). Je nach Layout (interleaved oder nicht) brauchst du noch BufferSubData(). Dazu ein Vertex Array Object.

Dann ist die Frage, ob es irgendwelche Extensions gibt, die mein Problem lösen. Ich hab einfach Mal lustig glWeight eingegeben und MSVC hat glWeightPointerARB gefunden!

Das kommt aus GL_ARB_vertex_blend. Ist zumindest auf meiner Nvidia Quadro NVS 295 (ähnlich Geforce 8x00) nicht unterstützt.

[anonym]

Es gibt in OpenGL "generic vertex attributes" (glBindAttribLocation, glVertexAttribPointer und glEnableVertexAttribArray). Mit glBindAttribLocation können Indices auf der Anwendungsseite mit beliebigen Attributnamen auf Shaderseite verknüpft werden. glVertexAttribPointer und glEnableVertexAttribArray sind dann der Gegenpart zu gl(Vertex|Color|TexCoord|...)Pointer* bzw. glEnableClientState.

[Eisflamme]

Das klingt genau nach dem,was ich suche, perfekt. Vielen Dank :)

Aber glBindAttribLocation möchte als ersten Parameter ja ein GLuint, das das Shaderprogramm repräsentiert. Aber ich hab ja "nur" ein CGProgram, wie mach ich das dann? Ohne diese Möglichkeit müsste ich dann wohl ATTR0 etc. nutzen... aber ich will das BLENDINDICES nennen ^^ Oder ist dieser Wunsch heer und sinnfrei?

[anonym]

Ehrlich gesagt, habe ich keine Ahnung von nVidia cg. Aus eigenem Interesse habe ich ein bisschen nachgeforscht und habe hoffentlich nichts übersehen:
Die allgemein (alle GPUs/APIs) verwenbaren CG-Shaderprofile scheinen Generic Vertex Attributes nicht zu unterstützen. Die nVidia spezifischen, nicht-MAC oder ATI/AMD, OpenGL CG-Profile hingegen scheinen Zugriff über Generic Vertex Attributes zu ermöglichen. In den meisten Fällen ist letzteres durch diese massiven Einschränkungen wohl nutzlos. Bleibt wohl nur die TEXCOORDn-Lösung übrig.

Ein Hoch auf auf "historisch gewachsene" APIs aufbauende Frameworks. :lol:

[Eisflamme]

WAS?

Ma ehrlich, das ist doch scheiße. Texturkoordinaten reichen doch vorne und hinten nicht für alles, was ich übergeben müsste. Gut, ich kann alle Lichter durch die normalen OpenGL-Lichter realisieren, aber angenommen, ich will alle 4 Texturkoordinatenpaare nutzen, dann kann ich nix animieren!?

Mann, was für ne Enttäuschung. Oder ich schmeiß einfach CG weg. -_-

Edit:
Hm, und für MultiTexCoords, wo ich Zeiger übergebe, brauch ich dann noch ne Extension, richtig? Ok, das lässt sich machen. Und ich merk gerade, dass ich nicht Mal 3 Texturkoordinatenpaare nehmen kann, weil ich ja BoneWeights + BoneIndices brauche, d.h. float5, also aufgeteilt in TEXCOORD2 und TEXCOORD3 oder so. Es sei denn, ich trickse rum und packe immer jeweils 2 Texturkoordinatenpaare in einen float4... Mrrrrrr...

Ach und wenn ich dann Tangenten, Bitangenten etc. übergeben möchte für krassere Shader hab ich einfach verloren, richtig? Wieso stehen solche riesigen Einschränkungen nicht irgendwo klipp und klar? Dann werd ich wohl Mal direkt auf GLSL wechseln...

[glassbear]

Mhm, du kannst doch bis GL_MAX_TEXTURE_COORDS Texturkoordinaten hochladen. Ist auf meiner Quadro gerade 8.

[Eisflamme]

Na ja, aber haben ältere Karten auch so breite Möglichkeiten? 8 klingt ok. Also GL2.0 setze ich Mal voraus, weil das ja sogar Grafikchips von nicht besonders tollen Laptops mittlerweile anbieten.

[Schrompf]

Standard bei allen Grafikkarten nach ~2002 sind 16 Eingabevektoren in den VertexShader. Wie weit man die einzelnen Attribute durchnumerieren kann, weiß ich nicht, aber ich bin da noch nie an Grenzen gestoßen. Probier's einfach mal aus. Für Lichter brauchst Du die jedenfalls nicht, die lädt man eher in Arrays aus Shaderkonstanten hoch und verrechnet sie im VertexShader.

Wir unterstützen übrigens 4 Bones pro Vertex. Dafür hat jeder Vertex 4xuchar BoneIndices und 3xfloat BoneWeights - das vierte BoneWeight kann im VertexShader berechnen, weil die Summe aller Weights ja 1.0f ergeben muss. Das verbraucht also 2 Eingabevektoren von den 16 verfügbaren. Das lauert also kein Problem :-)

[Eisflamme]

Na ja, aber GL + CG unterstützt halt eben (s.o.) nur neben Vertex-, Index-, Normal- und Farbvektoren die Texturkoordinaten (wie viele es auch immer sein können). Ich prüf GL_MAX_TEXTURE_CORDS Mal. Wenn das auf dem anderen Laptop 8 ist, bin ich zufrieden.

[Eisflamme]

Ok, neues Problem:

Ich würde gerne Funktionen wie glBindBuffer() nutzen. MSVC meckert aber, dass er die Version nicht kennt. glBindBufferARB() habe ich bisher genutzt, aber ich glaube, OpenGL 1.3 wird mittlerweile jeder haben, sodass ich so weit nicht abwärtskompatibel sein muss.

Trotzdem findet der das nicht. Die Graka-Treiber sollten aktuell sein, alle möglichen Shaderbeispiele funktionieren ja schließlich auch. Muss ich irgendwas in MSVC updaten? Sind vll die <gl>-Dateien nicht aktuell oder so was?

[anonym]

gl.h aus dem Windows SDK?

Code: Alles auswählen

/*++ BUILD Version: 0004    // Increment this if a change has global effects
Copyright (c) 1985-96, Microsoft Corporation ...*/
...
/* Copyright 1996 Silicon Graphics, Inc.
...*/

Das scheint noch Version 1.0 zu sein, OpenGL 1.3 wurde am 14.08.2001 veröffentlicht.:lol: GLEW (inkl. OpenGL 4.1) oder GLee (scheint seit OpenGL 3.0 nicht mehr aktualisiert worden zu sein) bieten aktuelle Header und laden die Erweiterungen.

OpenGL 1.3 wird mittlerweile jeder haben, sodass ich so weit nicht abwärtskompatibel sein muss.

Was ist denn der Einsatzzweck der Software? Für technisch einfache Spiele (z.B. Casual, Indie) würde ich noch OpenGL 2.0 (September 2004) verwenden, um eine breite Nutzerbasis zu unterstützen. Aber für anspruchsvollere 3D-Titel dann mindestens 3.0 (Mitte 2008, Direct3D10-Äquivalent/Shader Model 4), da ältere Hardware meist sowieso nicht mehr die notwendige Leistung bringt.

[Eisflamme]

Hi,

Ah! Also lade ich Glew und alles geht. Aber welches OpenGL ich nutze, kann ich mir trotzdem noch "aussuchen" (indem ich Befehle höherer Versionen nicht nutze)?

Einsatzzweck des Spiels ist, dass es ein einfaches 3D-Adventure/Taktik/Geschlichkeitsspiel werden soll. Aber da ich mich sowieso schon mit Shadern gerade beschäftige, möchte ich vielleicht auch nette Wassereffekte, ein paar schöne Belichtungsarten (ich weiß nicht, welcher Pixel/Fragment-Shader genau was kann) und definitiv Multitexturing (weil es ohne das doch wirklich oft nicht schön aussieht, oder?), Bumpmapping und Normalmapping und all den Kram unterstützen. Wenn ein, zwei Effekte nicht auf jedem älteren Laptop funktionieren, macht das ja nichts. Und am wichtigsten ist eh der Vertexshader für 3D-Modell-Animationen, der vermutlich auf jeder Kiste läuft.

Ja... :)

[anonym]

Shader gibts seit Version 2.0. Davor nur per Extension.
Die Funktionszeiger für die einzlnen Funktionen werden über glXGetProcAddress bzw. das Windows-Pendant geholt (also das was auch GLEW und GLee machen). Wird eine Extension vom Treiber nicht unterstützt, wird NULL zurückgegeben. Möchte man sich auf eine Version beschränken, sollte man sich nur die entsprechenden Funktionen holen (GLEW unterstützt das glaube ich per #defines). Bei nicht unterstützten Extensions knallt es dann sowieso.
Ab OpenGL 3.0 wird außerdem empfohlen, anstatt (wgl|glX)CreateContext glCreateContextAttribsARB zu verwenden. Damit erhält man, sofern die Implementierung mindestens die explizit angeforderte Version unterstützt und somit die Erzeugung des Contextes durch diese Funktion nicht fehlschlägt, definitiv einen zur angeforderten Version kompatiblen Context. (wgl|glX)CreateContext scheinen zwar noch unterstützt zu werden, erfordern aber eine Prüfung, welche Version vom erzeugten Context dann tatsächlich unterstützt wird, da hier vermutlich ein Context der höchsten verfügbaren Version erstellt wird.

[joggel]

Ich mische mich auch mal kurz ein, bzw. habe auch ein paar Fragen dazu, da ich ebenfalls etwas mit OpenGL herumexperimentiere.

Wenn man nur die "gl.h" bzw. "glu.h" einbindet, kann ich ja nicht sicher stellen welche Version von OpenGL auf dem Zielrechner vorhanden ist, oder? Ich möchte auch kein GLee oder Glew verwenden.
Ich habe aber gehört, das mittlerweile auch die "einfachsten" Notebooks mind. OpenGL 2.0 unterstützen.
Also denke ich mir, ich unterstütze ab OpenGL 2.0.

Wie aktiviere ich denn da die Shader?
Desweiteren ist das Problem ja, das manche OpenGL-Funktion der FFP (zB glTranslate, glScale, ...) nicht in den Shadern unterstützt werden.
Wie bekomme ich denn heraus, welche dieser Funktionen nicht unterstütz werden?

Desweiteren:
Sollte ich, um auf nummer sicher zu gehen, die DLL's (also die 2.0er Version) von OpenGL meinem Programm beifügen?

Gruß

[anonym]

Die DLLs liefert der Hersteller der Grafikkarte im Treiber mit. Mitliefern funktioniert also nicht. Inzwischen hab ich gesehen, dass alle Deklarationen seit Version 1.1 unter Windows und 1.2 unter Linux aufgrund von Unterschieden der Platformen manuell erstellt und die Funktionszeiger manuell geholt werden müssen. Die Header gibts bei Khronos. Ob die auch die Funktionszeiger holen, weiß ich nicht. Das würde einem zusätzlich von GLEW oder GLee abgenommen.

Ich habe es zwar noch nie verwendet, aber laut GLSL-Spezifikation unter Build-in varibles and functions gibt es ein Kompatibilitätsprofil für GLSL-Shader, dass unter anderem die Transformationsmatrizen als uniform Variablen anbietet (7.4.1). Z.B. sind dann implizit deklariert:

Code: Alles auswählen

uniform mat4 gl_ModelViewMatrix;
uniform mat4 gl_ProjectionMatrix;
uniform mat4 gl_ModelViewProjectionMatrix;
uniform mat4 gl_TextureMatrix[gl_MaxTextureCoords];

Die implizit deklarierte Funktion ftransform des Kompatibilitätsprofils führt die bekannte Fixed-Function-Pipeline-Transformation durch.

Wie aktiviere ich denn da die Shader?

Meinst Du die Verwendung von Shadern unter OpenGL? glCreateShader erzeugt ein leeres Shaderobjekt, glShaderSource (er-)setzt den GLSL-Code eines Shaderobjekts, glCompileShader kompiliert den aktuellen GLSL-Code eines Shaderobjekts, glCreateProgram erzeugt ein leeres Programmobject, d.h. eine Shaderpipeline, glAttachShader fügt einen Shader der Shaderpipeline hinzu (mehrere des gleichen Typs möglich), glLinkProgram linkt die Shaderstufen (z.B. uniform Locations, Shader gleichen Typs zu einem Ganzen zusammenfügen), glUseProgram setzt ein Program, fertig

[joggel]

Vielen Dank.
Ich habe heute auch noch dies gefunden, zwecks nicht Verwendung von GLee oder Glew :
Ist von der DGL-Community. Und zwar eine Portierung ihrer DelphiHeader nach C.

[anonym]

Hallo joggel,
Was gefällt Dir an den beiden Libraries nicht? So wie ich das auf die schnelle gesehen habe, machen die auch nicht viel anderes als GLEW oder GLee. Letztere machen es dann allerdings Platformunabhängig, zumindest GLEW nach dem aktuellen Standard und bieten deutlich mehr Konfigurationsmöglichkeiten hinsichtlich verwendeter Versionen und Erweiterungen. Das ist jetzt auch nicht wirklich einer der hochinteressanten Bereiche der Programmierung, mit dem man sich allzulange aufhalten sollte. Einmal das bisschen, was da tatsächlich passiert, kurz anschauen, um zu wissen wie es funktioniert, ist in meinen Augen mehr als genug.

Mfg

[joggel]

Hi,

Du meinst die Libs Glee und Glew? Ja, das Problem ist, das ich dann die DLL's mit ausliefern muss, und dass möchte ich nicht, frag nicht warum :) ...

[anonym]

Du kannst den Quelltext problemlos in Dein Projekt aufnehmen und selbst mitbauen (Including the source files / project file). Dann hast Du eine EXE ohne DLL.

[Eisflamme]

Hab jetzt Glee im Einsatz und muss sagen: Perfekt.

Einmal initialisieren, danach einfach alle Funktionen nutzen und gut ist. OGL2.0 will ich voraussetzen, wenn ne Funktion laut Google also <= 2.0 unterstützt ist, mach ich auch keine Abfrage und darüber ne Extensionabfrage und alles ist prima. ^^ Und die zweiten und dritten Texturkoordinaten krieg ich auch noch in den Shader. Leider muss es ja nur mindestens zwei Texturkoordinatenpaare geben, sodass bei Rechnern mit genau so wenig Texturkoordinaten mit OpenGL + CG schon Schluss ist. Wenn CG das Problem nicht beseitigt, werd ich also definitiv auf GLSL umsteigen müssen.

Und wieso ist GL_MAX_TEXTURE_COORDS auf meinem Dell Studi 15 34.929? Wenn das stimmen würde, würd's fürs erste reichen.

[anonym]

34.929? Ohne Dir was unterstellen zu wollen, oder meinst Du den Wert, den glGetIntegerv(GL_MAX_TEXTURE_COORDS, &result) zurückgibt oder den Wert der Konstanten GL_MAX_TEXTURE_COORDS oder das Ergebnis einer anderen Funktion glGet*?

[Eisflamme]

ich hab einfach nur GL_MAX_TEXTURE_COORDS ausgegeben, weil ich nicht um glGetIntegerv wusste... Aber hey! Ich kann 8, das ist ja klasse :) Und mein Alienware kann 16, alles klar. Mit 8 sollte man wohl wirklich auskommen.

[Eisflamme]

Wie stell ich eigentlich dar, wenn ein Vertex einfach gar nicht von nem Bone beeinflusst wird? Soll ich einfach BoneIndex = -1 setzen und im Shader darauf prüfen? Oder ne Dummy-Einheitsmatrix als erste Bonematrix machen?

[Schrompf]

Sowas gibt's eigentlich nicht. Ich würde da einfach einen Dummybone im Mesh-Ursprung erfinden und dem alle Vertizes zuweisen, bei denen die Summe der Bone-Einflüsse weniger als 1 ergibt.

[Eisflamme]

Ah ok.

Und wenn ich in CG "uniform float4x3 BoneMatrices[60]" als Parameter angebe, meckert der, dass es zu viele Konstanten gibt. Es geht erst bei float3x3[20], was etwas wenig ist, oder? =/

[Schrompf]

Keine Ahnung, das hängt doch von Deinen Modellen ab.

60 4x3-Matrizen sollten grademal 180 Konstantenregister brauchen. Du musst ihm aber unbedingt beibringen, dass er die dann auch wirklich als 4x3 speichert. Bei DX geht das mit einem "column_major float4x3 gBoneMatrix[$gMaxNumBones];" vornedran. Bei CG könnte das auch so oder so ähnlich passen. Und es hängt natürlich davon ab, wieviele Konstanten Du sonst noch so rumfliegen hast.

[Eisflamme]

Ich hab sonst nichts. Der meckert einfach, dass ich nicht mehr als 96 Konstanten haben darf. Und eine Konstante ist anscheinend 1 Byte. Wenn ich mit dem testwuson arbeiten muss, habe ich aber so schon verloren, weil das z.T. 40 Bones pro Mesh hat und ich denke, es gibt noch weit komplexere Modelle. Und zu der Fehlermeldung "C6002" oder so finde ich bei Google GAR NIX. -_- Arbeitet niemand mit CG, berichtet niemand über seinen Ärger oder ist Google einfach ein Haufen Schrott? *sich ärger* Mich nervt's, dass mir CG ständig an den Karren fährt für eigentlich ziemlich simple Probleme, die jeder, der nicht nur zwei Lichter ändert, auch sofort zu spüren bekommt.

[Schrompf]

VertexShader 1.1 hatte eine Begrenzung auf 96 Konstanten, wobei eine Konstante jeweils ein 4xfloat-Vektor war. Entweder Du arbeitest wirklich auf antiker Hardware oder Du kannst bei der Übersetzung des Shaders evtl. ein anderes Shadermodell als Zielhardware angeben. Der Hinweis mit dem "column_major" gilt allerdings immernoch :-)

[Eisflamme]

Hmm... Also meine ATI Mobility Radeon HD 4870 sollte nicht so antik sein. Zumindest wird laut GLEW OpenGL 3.1 unterstützt (ich hätte mehr erwartet, aber ok) und damit GLSL 1.3. Aber AssimpView funktioniert ja auch oder ist HLSL irgendwie weiter als GLSL? Eigentlich läuft doch letztendlich alles auf der GPU, also dürfte das doch egal sein.

Und column_major versteh ich nicht, akquiriert der sonst mehr Speicher? Aber ich hab jetzt auch Mal float4 [100] probiert, auch das klappt nicht, also kann man das damit wohl ausschließen.

Und auch komisch ist, dass sich die Fehlermeldung ändert. Ich hab hier Mal dummy was gemacht:

Code: Alles auswählen

struct appdata 
{
	float4 position		: POSITION;
	float4 color		: COLOR0;
	float4 texCoords	: TEXCOORD0;
	float4 texCoords2	: TEXCOORD1;

};

struct vfconn
{
	float4 position		: POSITION;
	float4 color		: COLOR0;
	float4 texCoords	: TEXCOORD0;
};

vfconn main(appdata IN,
			float3 normal : NORMAL,
			uniform float4x4 ModelViewProj,
			uniform float4 BoneMatrices[100]
			)
{
	vfconn OUT;
	OUT.position = mul(ModelViewProj, IN.position);
	//OUT.color		= float4(1, 1, 1, 1);
	OUT.texCoords	= IN.texCoords;

	return OUT;
}

Wenn ich OUT.color = ... nicht auskommentiert habe, sagt er, es gäbe zu viele Konstanten. Ist es auskommentiert, kompiliert der. WTF?

So langsam glaub ich...

... es liegt an MIR!

Edit:
Und wenn ich float4(1,1,1,1) durch IN.color ersetze, geht das auch. Und wenn ich dann [100] auf [200] erhöhe, geht es trotzdem. Jetzt raff ich gar nix mehr. :( Zu hülf, zu hülf, helft einem Unverstehendem!