Hi,
ich habe noch einige Fragen, möchte das Forum jetzt aber nicht zig Threads aufmachen, also stell ich mal alles hier rein
Und da ich mich noch zu den Einsteigern zähle, kommt das auch ins Einsteigerforum.

Zuerst einmal hab ich das Problem, das die PointSprites meines Partikelsystems sich nicht verkleinern, wenn man weiter weg geht. Wie stelle ich denn so etwas ein?

Das nächste ist, das überall die Rede von "Renderpfaden" ist. Was genau ist ein Renderpfad?

Und dann sind da noch ein paar Fragen zu OpenGL3:
Gibt es noch eine Trennung zwischen ModelView und Projection Matrix? Oder sind beide rausgeflogen?
Welche Berechnungen stecken hinter glRotatef und glTranslatef (Die muss ich mir bei OpenGL 3 ja selbst schreiben)?
Welche Folgen hat es noch, das der Matrix-Kram rausgeflogen ist? Funktionieren glViewport, gluPerspective usw. noch?
Soweit ich das gesehen habe, ist das eine 4x4 Matrix. Wieso 4? Und wie benutze ich die Matrix dann im Shader?

Ich hab schon ein bisschen in der OpenGL 3.2 Spezifikation rumgelesen, aber mir ist eines immer noch nicht klar: Ist es jetzt möglich einen OpenGL 3 Kontext zu erzeugen, ohne vorher einen OpenGL 2 Kontext erzeugen zu müssen?

Dann hab ich auch schon einiges über HDRR gelesen. Aber was genau gehört denn da alles dazu? Und wie wird das ganze realisiert?

Ich hoffe ihr könnt mir da mal etwas helfen

Hallo darksanity,

alle Fragen kann ich leider nicht beantworten, aber die genauen Berechnungen für glRotate und glTranslate findest du hier :

http://www.opengl.org/sdk/docs/man/xhtml/glRotate.xml
http://www.opengl.org/sdk/docs/man/xhtm ... nslate.xml


Viele Grüße
dj3hut1

_________________
Wenn Gauß heute lebte, wäre er ein Hacker.
Peter Sarnak, Professor an der Princeton University

glRotate und glTranslate sind auch in unserem Wiki erklärt.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Vor OpenGL 3 gab es diverse Variabeln an denen man schrauben konnte. In OpenGL musst du das höchstwahrscheinlich selbst im Shader berechnen. Geht aber relativ leicht, einfach in gl_PointSize die gewünschte Größe in Pixeln reinschreiben.


[glsl]// Vertexshader
uniform vec4 eye; // Position der Kamera
uniform float viewportHeight; // Höhe des Viewport in Pixeln

// ...

void main()
{
vec4 position = vec4(gl_Vertex.xyz, 1.0); // Partikelposition
float size = gl_Vertex.w; // Partikelgröße
if (size < 0.1) {
size = 0.1;
}

// transform position
gl_Position = gl_ModelViewProjectionMatrix * position;

// calculate pointsize
vec4 tmp = position-eye;
float distSQ = dot(tmp, tmp);
gl_PointSize = viewportHeight * size * inversesqrt(distSQ); // <-- hier der interessante Teil
gl_PointSize = clamp(gl_PointSize, 0.01, 64.0); // Partikel max. 64 Pixel groß

// ...
}[/glsl]

_________________
Yeah!

Renderpfade waren vor OpenGL3 notwendig. OpenGL1 bis 2 benutzen sogennante fixed pipelines, also man stetzt einen Schalter und hinter den Kulissen wurde dann entsprechend ein Programmcode oder später Shadercode generiert und für den User transparent durchlaufen. Damit konnte man dann z.B. Fog, Texturen, Lichter und so weiter ohne Shader realisieren, da es der Treiber selber generiert hat. Jeder Kombination aus den verschiedenen Schaltern wäre ein Renderpfad und das artet in so riesige Möglichkeiten aus, dass die Entwickler teilweise über Monate hinweg Bugs mit geschleppt haben. Allerdings wird das Wort auch ausserhalb des Treibers verwendet hier wird folgendes gemeint. Die Unterstützung von z.B. OpenGL3 und OpenGL2 benötigen unterschiedlicher Programmabläufe, da sie unterschiedliche APIs haben, die sich nicht vollständig überdecken. Man muss also einen Programmcode für OpenGL3 und einen für OpenGL2 schreiben, um die gleiche Sache zu zeichnen. Diese beiden Programmcodes nennt man Renderpfad.
Wenn man in den Professionellen Bereich guckt, da gibt es dann einen Renderpfad für OpenGL, Direct3d, jegliche Console jeweils einen und dann für Direct3d und OpenGL auch noch diverse wie z.B. DirectX9,DirectX10, DirectX10.1 und DirectX11. Vorteil hier hat man , wenn man erst jetzt anfängt zu entwickeln, da so nur noch ein OpenGL3.2 und DirectX11 Direct3D Renderpfad auftauchen und beide sind von Funktionalität nahezu gleich und erleichtern einiges. Consolensoftware entwickeln die wenigstens aber wenn man dies müsste, dann muss eh für jede einzelnen Konsole ein eigener her, da alle eigene Grafikbibliotheken verwenden, die nur stark mit OpenGL2 bzw. Direct3D 9 verwand sind.

Ich kann dir da folgenden Wiki Artikel empfehlen, welcher die ganze Lineare Algebra Problematik für OpenGL3.x klärt.
Am Ende findest du die benötigten Berechnungen, um ab OpenGL3.0 die Matrizenarbeit zu erledigen.
http://wiki.delphigl.com/index.php/Tutorial_OpenGL3_Lineare_Algebra

Ein paar wichtige Allgmeininformationen zu OpenGL3 gibt es in dem Übersichtsartikel für die OpenGL3 Artikel Reihe http://wiki.delphigl.com/index.php/Tutorial_OpenGL3

Wie die Kontext erstellung abläuft und wieso man einen alten OpenGL<2 Contex benötigt ist auch in diesem Artikel erklärt http://wiki.delphigl.com/index.php/Tutorial_OpenGL3_Zeichenkontext. Wobei hier eine kleine unaktualität drin ist. Die mit OpenGL3.2 erhoffte Kernimplementierung für OpenGL3 Kontext erstellung ist nicht rein gekommen, scheint wohl auch nicht so schnell zu passieren. Letzten Ende entscheidet das Khronos, wann die ARB Funktion mit in den Kern hinein kommt. Du kannst aber seit einiger Zeit wenigstens erfahren, welche OpenGL Version nun über Version 3 unterstützt wird. Das war bei der ersten OpenGL3 Implementierung von Nvidia nicht der fall, da hatte folgendes noch 2.0 und ähnliches angegeben.


Zu HDR gehört ein Framebuffer mit mehr als 8Bit Farbtiefe pro Farbkanal und fertig ist das ganze. Sinnvoll ist es allerdings nur, wenn man auch Texturen mit 48Bit RGB bzw. 64Bit RGBA zur verfügung hat also 16Bit pro Kanal, sonnst hat man nicht wesentlich viel von der Möglichkeit gewonnen, Überbelichtungen und Unterbelichtungen besser dar zu stellen. Shader würden sich nur verändern ,wenn man zwischendrin nochmal den Normalisierten Farbwert(0-1.0) in den 8Bit aka 256Farben umgewandelt hat.

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

Projekte: https://github.com/tak2004

Ok,
erstmal danke für die Antworten die haben schon mal sehr geholfen

Also, ich weiß jetzt wie ich die ganzen Matrixberechnungen durchführe. Aber mir ist noch nicht so ganz klar, wie ich das bei OpenGL 3 dann verwende.
Ich hab also zwei Matrizen, übergebe ich die jetzt einfach beide als uniform an den Shader und multipliziere den Vertex damit, oder wie geht das?

Wie sieht es mit Bloom aus? Das gehört nicht zu HDR? Und wie funktioniert das mit den Über-/Unterbelichtungen?

Was musste ich denn bei OpenGL < 3 machen, dass die PointSprites automatisch kleiner werden?

Folgender Shadercode ist OpenGL2 und OpenGL3.1 kompatibel.

Im Vertexshader wird die ProjektionsMatrix und ModelviewMatrix übergeben, man kann natürlich auch die Matrix vorher mit der eigenen Math Bibliothek multiplizieren aber das macht kein Performanceunterschied, da CPU langsamer ist als GPU aber das schicken von 64byte über den Bus und dann gpu multiplizieren nicht mehr oder weniger dauert. Der Vorteil hierbei ist, man hat Modelview und Projectionview getrennt und man hat mehr Flexibilität.
Als Vertexattribute übergebe ich in diesem Shader Position und Farbe eines Vertex.


Damit das ganze ab OpenGL3 sauber kompiliert, muss man gl_FragColor als out selber definieren, da ging bei den Specs was schief und es wurde als deprecated makiert aber nicht die Erklärung gegeben, wie man es nun macht. Da diese Variante Problemlos auf OpenGL3.1 lief, gehe ich davon aus, dass ein vec4 als Rückgabewert erwartet wird und dieser als Farbe genutzt wird.

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

Projekte: https://github.com/tak2004

ok, danke

Hab mir jetzt auch mal die Spezifikation von der neuesten GLSL angesehen. Aber eines verstehe ich nicht: Woher weiß OpenGL, welchen Wert (Position, Farbe, usw.) ich in welcher in-Variable erwarte?
Und weshalb muss das jetzt alles über "in" gemacht werden?

In deinem Programmcode aktivierst du die einzelnen Attribute eines Shaders und dann kannst du einem Attribute ein BufferObject zuweisen.

Erst wenn ein Attribute aktiviert wurde, kann man diesem im Shader überhaupt nutzen, sonnst wird alles aus den code geworfen, wo das Attribute mit vor kommt.

In und Out sind Steinkohle und wurden schon mit den 120 Shadern also von OpenGL1.5 unterstützt aber keiner hat diese verwendet. Mit OpenGL3 wurden die dazugehörige GLSL Version erleichtert, indem man einiges deprecated makiert und entfernt hat. So verwendet man nun In/Out und dies ist verständlicher und schafft auch Sprachgleichheit zu HLSL von DirectX.

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

Projekte: https://github.com/tak2004

Oha, du machst mir gerade wieder mal deutlich wie wenig ich von den Spezifikationen verstanden hab.
Auch nach dem lesen des Wiki-Artikels zu "glVertexAttribPointer" und diesem Dokument (http://www.opengl.org/sdk/docs/tutorial ... ibutes.php) verstehe nicht für was diese Attribute gut sind.
Ich stecke momentan einfach die Vertices und die Texturkoordinaten in ein VBO und zeichne das. Wo kommen jetzt die Vertexattribute ins Spiel?

OpenGL3 hat VertexBufferObject's, diese kann mit allem möglichen belegt werden. Dabei können die Daten als 2 Typen übergeben werden, Indices und Vertex-Attribute. Indices sind zum Platz sparen und besseren nutzen des Caches, da schon bekannt ist welche Vertice noch gebraucht werden und welche vorher schon bekannt sind. Die Vertex-Attribute werden Vertexweise abgerufen also immer wenn der Vertexshader ein Vertex weiter rückt, dann werden alle Vertex-Attribute geladen(z.B. Position, Normale, Texturkoordinate, Tangent,...). Sinnigerweise packt man eine Position als Attribute mit hinein, da man sonnst alle Vertice auf einer Position hätte bzw. wenn man Mathematische Funktionen in Kombination mit VertexID verwendet braucht man auch diese nicht(das wären Prozedurale Meshes). Da man nicht, wie bei vorigen VBO's und VertexArrays auf typen fest gelegt ist, wie vertexpointer, normalpointer, colorpointer, sondern generic VBO's hat, kann man nun auch wesentlich einfacheren OpenGL Code schreiben und muss sich nicht mehr um zuordnungen von vorher fest gelegten Vertex-Attributen kümmern. Du kannst auch völlig abgefahrende Informationen in ein VBO packen und dann im Shader wird das ganze erst definiert. Du arbeitest also von der Datei bis zum Shader mit völlig unbekannten Daten und erst im Shader wird erst fest gelegt was es nun überhaupt ist und wie es verarbeitet wird. Du kannst also deine Modeldaten in einzelne Streams in deine Datei packen und musst nur noch sagen wie groß und was für ein Typ es ist aber es ist nicht mehr notwendig zu sagen, das sind Vertice, das Texturkoordinaten oder ähnliches. Alle Streams sind gleichwertig man lädt sie einfach, packt sie in ein entsprechend großen VBO und bindet sie an freie Shader Attribute. Welchen Stream man an welches Shader Attribut verbindet ist dann noch eine Information die man braucht, die ist aber von Shader zu Shader unterschiedlich und sollte dann doch eher in eine extra Datei bzw. man macht ein 1zu1 binding und bindet ein Stream immer auf das Attribute mit den Namen des Streams. Wenn also die Farbinformationen in Stream "Hawai" liegen müsste man im Shader ein Attribute Hawai anlegen und dieses entsprechend verarbeiten. Seit OpenGL3 und DirectX10 sind alle bisherigen Modellformate hinfällig geworden und deswegen habe ich mit Oc2k1 auch schon laut über neue Möglichkeiten der Lagerung zur Diskussion aufgerufen.

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

Projekte: https://github.com/tak2004

ich hoffe du wolltest mit



eigentlich sowas sagen wie :" Seit Opengl3 und DirectX10 ist noch kein Modelformat erschienen, dass der OpenSource-Entwickler frei benutzen darf, welches die neuen Features auch optimal ausnutzt", denn immerhin ist es ja nicht so, dass die bisher bekannten offenen Formate mit OpenGl3 und DirectX10 nicht mehr verwendet werden können. mag sein, dass deren Aufbau mittlerweile etwas suboptimal ist, aber nutzbar sind sie trotzdem. Außerdem bin ich eh der Freund von "bastel es dir selbst, wenn es laufen soll, wie du es willst". Von daher empfehle ich jedem sich die elende Suche nach einem passenden Modelformat einfach zu sparen und schlicht weg in der Zeit ein eigenes, optimierteres Format zu entwickeln. Man muss sich halt ersteinmal dazu überreden nicht so faul zu sein, wie man es im OpenSource-Bereich gerne ist und ständig bei anderen gucken. Dabei kommt dann nur ein WirrWarr von Formaten, Spezifikationen und Bibliotheken bei rauß, dass man im schlimmsten Fall nicht mehr überblickt und im nachhinein alles wegschmeißt. Außerdem sollte man auch keine Angs vor Binary-Files haben. Wer meint es ist ja praktisch, wenn man ein lesbares Model-format hat, der soll mir doch bitte erklären warum er sein Modelfile im Editor lesbar haben möchte. Ich versteh das nähmlich einfch nicht, was daran prakisch sein soll.

_________________
Klar Soweit?

Ja, so in etwa ist es gemeint. Die Formate sind einfach nicht mehr Zeitgemäß, zuviele Informationen und dann auch oft nicht in guter Form gespeichert.

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

Projekte: https://github.com/tak2004

Sellman, oftmals sind Binärformate aber viel anfälliger, wenn man Erweiterungen einbauen möchte, aber kompatibel zu vorherigen Versionen bleiben will. Dann muss man sich schon überlegen, wie man das anstellt. Oder man speichert eine Versionsnummer mit und muss dann je nach Version eine komplett andere Laderoutine verwenden. Ganz zu schweigen davon, was passiert, wenn man bei einer Längenangabe einfach mal nen 7FFFFFFF reinschreibt ... Die wenigsten (selbstgeschriebenen) Loader fangen es ab, wenn ein String plötzlich 2mrd Bytes groß sein soll.
Textbasierte Formate sind da oftmals weniger Anfällig (zumindest fliegt er dir nicht mit nem OutOfMemory oder alike raus), und halt auch erweiterbarer.

greetings

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Binärformate und Textformate haben ihre Vor- und Nachteile aber das gehört meiner Meinung nach in ein anderen Thread, als diesen.

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

Projekte: https://github.com/tak2004