Hi,

wie ja in diesem Thread schon zu lesen, arbeite ich daran meine engine/lib auf OpenGL 3.0 und ES umzustellen, bzw aufzurüsten.. mein ziel ist es das ich einfach am ende auswählen kann womit ich rendern möchte, also "OpenGL < 3.0", "OpenGL 3.0" und "OpenGL ES". Vom prinzip her ist das auch recht "simpel"

Jetzt gibt es aber ja ausser dem immediate-mode noch mehr dinge die rausgeflogen sind, und da brauch ich grad ein wenig hilfe..

1) gluUnProject
Zumindest bei OpenGL ES gibt es das nichtmehr.. daher jetzt meine Frage, wie berechnet man das ganze selbst?

2) glMatrixMode
Gibt es ebenfalls bei ES nichtmehr... also kein unterschied zwischen Projection/Modelview/Texture Matrix mehr etc.
Jetzt die frage.. wie macht man das ganze jetzt? Muß man Matritzen an einen Shader übergeben und dann die im Shader einfach so behandeln wie früher die Modelview/Projection Matrix?

3) glReadBuffer / glDrawBuffer / glDrawBuffers
Scheint es laut meinem compiler auchnichtmehr in ES zu geben... wie macht man das jetzt?


Das war's erstmal... der rest meiner riesen compiler-fehlerliste sind denke ich alles dinge die unter OpenGL ES einfach nur anders heißen (weil ja praktischerweise alle konstanten aufeinmal ein _OES am ende dran haben >_>)

Aya~

1. gluUnproject
Der allerbeste Rat, den ich Dir geben kann: lade Dir den Sourcecode der Bibliothek Mesa3D herunter: http://www.mesa3d.org/, glaub mir Du wirst es gut brauchen können bei Deinem Projekt, nicht nur für gluUnproject. Die Datei, in der der gesuchte SourceCode zu finden ist, heißt >>project.c<<. Ich könnte Dir zwar den SourceCode hier reinstellen, aber ich denke mal, es ist viel sinnvoller wenn Du Dir die Bibliothek selber ziehst. Deshalb ist sie schließlich gemacht worden: damit die Leute in einer Referenzimplementierung nachsehen können.


Ich schätze schon... APIs kommen und gehen aber die Mathe dahinter bleibt . Ein Haufen hilfreiche Dinge sind im Wiki zu finden (glOrtho, glFrustum,...), aber ich glaube das weißt Du schon. Auch Mesa3D ist hier von enorm großem Nutzen.

3) glReadBuffer / glDrawBuffer / glDrawBuffers
Die Specs für OpenGL 3 nennen den Befehl "ReadBuffer", also ohne "gl". Aber ansonsten muss ich hier passen, ich kenn mich mit OpenGL ES nicht aus.

Viele Grüße
Traude

gluUnproject: ist keine OpenGL funktion und kann also aus mehreren Funktionen zusammen gebaut werden.

glMatrixMode: ist recht einfach, man muss nun die Matrizen selber verwalten und dann als uniform dem shader übergeben.

glReadBuffer und so weiter: wie schon erwähnt gibt es dies noch in OGL3 aber sollte man diese Möglichkeit nicht haben, kann man ja immer noch in ein FBO rendern und die daran gebundene Textur einfach auslesen.

Man kann OpenGL unter Version 2 nicht mit OpenGL3 kompatibel machen, da OpenGL über Version 2 den Vertex Array Funktionssatz braucht, da man sonnst nicht rendern kann und diese erst mit Version 2.0 verfügbar sind. Auf dieses Problem bin ich schon vor längerer Zeit gestossen, als ich meinen Engine auf OpenGL3 erweitert hab und ein Generisches system für alle bieten wollte.
Man benötigt definitiv 2 Renderpath, wenn man OpenGL<2 und OpenGL>2 supporten will. Neben der Pflicht, ein eigenen Shader zu stellen, die VBO's an den Shader über die Vertex Array Funktionen zu binden gibt es noch 1-2 andere Fallstricke die Probleme machen, die Kompatibilität zu wahren. Eine weitere Problematik ist das zeichnen von VBO, wärend man in OpenGL3 generische VBO's hat, also OpenGL egal ist was es ist und damit auch keine typisierung macht und man selber im Shader dann sagt, wie das zu interpretieren ist. Hat man in OpenGL<3 das Problem, dass man vertex, normal,color, index und texturecoord pointer setzen kann/muss. Man kann natürlich für jeden Typen(color,vertex,...) eine Klasse fest legen oder enum definieren aber wenn man dann OpenGL3 nutzt erzeugt das soviel overhead, dass es 0 sinn macht überhaupt OpenGL3 zu verwenden(schon ausgetestet). Ich habe mich dafür entschieden, dass Karmarama OpenGL2.0,OpenGL3.0,OpenGL3.1 und später noch D3D und co supporten wird, da OpenGL<2 sich auch von dem PS3 SDK und D3D abhebt und bei Wii SDK ledeglich die Shader Problematisch sind(gibt keine ^^) aber man dafür eh den Content anpassen müsste. Entsprechend habe ich meine Generischen Klassen schon umgestellt bzw. bin noch teilweise dabei.

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

Projekte: https://github.com/tak2004

Hab es alles hinbekommen, danke



Das man zwei verschiedene Renderpfade braucht ist klar, aber das ist auch das warum ich es jetzt umgestellt habe.



Ich weiß nicht wie du das bei dir gelöst hast, aber bei mir gibt es eine Vertexbuffer-klasse die sich einzig und allein um einen VBO kümmert. Beim erstellen wird ihr mitgeteilt ob es jetzt nen Color, Normal, Texture oder sonstwas (bzw VertexAttribute) VBO ist, und je nach renderpfad wird dann bei OpenGL2.0 dieser VBO mit glVertexPointer(..) etc gezeichnet, bzw bei OpenGL 3.0 einfach als Attribute Array.

Ich sehe da kein sonderlich großes problem und auch keinen overhead oder sonstwas.

Aya~

Das Problem war nicht die Funktionalität von VBO in eine Klasse zu verpacken, eher die Verwendung ist ein Problem.
Ich habe meine Klasse wohl so ziemlich wie deine designed gehabt.
Wärend ich bei OpenGL<2 Wissen musste, was für Daten der VBO halten muss, ist es ab 2.0 nicht mehr notwendig, da der Shader es weiß.
Genau hier liegt auch das Problem, da mein Modelformat sich aus 2 Datein aufbaut.
Die erste Datei ist ein Baum, an deren Ende Daten liegen, deren Name, Elementtyp(float,int,...) und die Anzahl bekannt ist.
In der zweiten Datei findet man ein Script, welches dann die Datenstreams in der Engine einem VBO zuweisst.
Das Problem ist nun, dass bis zu diesen Punkt nicht bekannt ist, dass ein Stream ein Vertex, Normal, Texturkoordinaten Stream ist, da diese Information auch völlig daneben liegen kann, wenn der Stream sich aus mehreren typen zusamen baut(sehr beliebt xyzrgbuv Element) oder einfach Typen sind die es in OpenGL<2 nicht gibt(z.B. Tangente, Binormale, Boneweight). Man würde sich zu gunsten des völlig veralteten OpenGL1.5-1.6 seine Flexibilität verlieren, da man sich auf sehr grob gesagt 4 verschiedene Typen festlegt(vertex,normal,color,texturcoord) und somit ein die Möglichkeiten von OpenGL2>= und D3D9>= sich verbaut und heute notwendige Datentypen(tangenten, boneweighting, vorberechnete Lichtkonstanten) aufwendig implementiert(teilweise garnicht möglich, da man nur Daten in die 4 typen reinquetschen kann, dann ist Schluss mit den Möglichkeiten von OpenGL<2).
Darum sehe ich auch die Möglichkeit, es trotzdem zu machen, nur durch ein weiteren Renderpfad gegeben.
Was sich im Datenformat dann wiederspiegelt, indem man es mit Informationen aufbläht, die völlig unbrauchbar sind und wieder bei Programmieren mehraufwand bedeuten.
Des weiterem holt man sich auch mehr Content Aufwand herrein, da man ein GLSL Shader für <2.0 und ein für 2.0 und höher bereit stellen muss.

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

Projekte: https://github.com/tak2004

Hi,

ich versteh leider deine problematik bei der sache nicht ganz..
Die VBO-Klasse ist ein template welches jeden beliebigen typ beinhalten kann, ob das jetzt color, normal oder sonstwas ist wird nur durch ein enum definiert.

Am ende wenn dann von der Mesh-Klasse (die mehrere VBOs beinhaltet) der draw-befehl kommt, kümmert sich der aktuelle renderer (OGL 2.0, OGL 3.0, OGL ES etc) darum die VBOs zu zeichnen. Der OGL 2.0 schaut halt nach "Ist das grad ein Vertex-Buffer? dann nehm ich glVertexPointer.. sonst.. etc", der OGL 3.0 renderer haut einfach alles als AttributeArrays raus etc.

Auf die art kann ich genauso mit interleaved arrays wie mit strikt getrennten arbeiten ohne mir auch nur ein bisschen mehr aufwand zu machen.

Und zu dem thema "Man muß nicht wissen was da für daten drin sind im VBO"... ich weiß nicht wie das bei dir ist, aber ich muß das wissen - allein schon für collision detection etc (ich habe nicht für jedes objekt eine collision-lowres-version. Wenn es simple objekte sind werden direkt die für die berechnung hergenommen). Wobei es bei mir sowieso anders aufgebaut ist, weil ich es so haben wollte das ich auf knopfdruck meine scene via Raytracer einfach rendern kann - ist nur ein gimmik, aber echt ganz nett wenn man seine scene hat und dann á la Screenshot das ganze mit reflektionen, refraktionen etc raytracen kann

Aya~

Es ging Darum, dass es du für OpenGL2 einen Klassenbaum programmieren musst und für OpenGL3 noch einen, da diese nicht kompatibel zueinander sind.
Das hab ich auch mehrmals geschrieben, dass man mit einen Renderpfad nicht auskommt und halt vieles neu schreiben muss, damit beides zusammen unter einen Hut passt.


Verweist darauf, wieso 2 Renderpfade benötigt weden.

Um ganz sicher zu gehen, dass du verstehst was ich meine, werde einfach mal ein bischen Pseudocode zusammen basteln und erklären.

Da das Problem schon beim erweitern von Shadern und VBO bei OpenGL3 auftrat habe ich entsprechend ein neues Konzept designed(bisher nur Teilweise implementiert).


Der SceneGraph hat nun ein neues Objekt vor der Nase, welches er Rendern soll und die Daten nocht nicht geladen sind.
Also wird bei von dem Node die LoadData Methode aufgerufen, welche in dem Fall vom Typ TKar_ModelNode ist.
Dieses sucht nun ein ModelAdapter, der das Format lesen kann, welches in m_sModelname angegeben ist.
Der Adapter wird gefunden, eine Instanz erstellt und die Loadmethode mit dem Modelname aufgerufen.
Dieser muss nun ein PhysicModel und GraphicModel erstellen, indem er entsprechend die Materials und MeshBuffer generiert.
Materials ist das gleiche Spiel wie bei Models, es wird ein Adapter gesucht und je nach Scriptsprache und Anbindung das entsprechende gewählt.
Die MeshBuffer werden von dem Aktiven GC bzw. PhysicBuffer erstellt und vom entsprechenden Modelloader befüllt under der Shader über das Material geladen. Materials sorgen dafür, dass das Model für den entsprechenden Renderpass korrekt gezeichnet wird bzw. Physikalische Eigenschaften eingehalten werden. Mein Materialformat nutzt dabei Scripte.
Nun zur Problematik mit OpenGL1.5-1.6 und darüber.
Erstmal die Shader Problematik, glsl1.2 ist nicht zu glsl1.4 kompatibel, da glsl1.4 attrib zur dateneingabe verlangt und kein gl_Color oder gl_Vertex,.. verfügbar ist. GLSL 1.3 kann zu glsl 1.4 kompatibel gemacht werden aber dies wird erst mit OpenGL2.0 supported.
Für OpenGL3 müssen Shader vorhanden sein und sollte man diese generieren wollen, dann ist man auf die Funktionalität von OpenGL1.5-1.6 beschränkt(vertex,texturcoord,color,normal) und kann die oft benötigten tangenten z.B. nicht verwenden.
Hat man ein Modelformat, welches Tangenten und andere Daten enthält, dann ist man bei OpenGL<2 aufgeschmissen, da man diese nicht verpackt und an den Shader überweisen kann. Die änderung der API für VBO, in OpenGL3, hat eine weitere Problematik aufgeworfen.
OpenGL3 erstellt für jeden Datenstream(vertice, tangenten, normalen, ...) ein VBO und packt die daten rein, später wird dann über glVertexAttribPointer ledeglich an den gleichen Streamnamen gebunden. Erst im Shader wird nun der Datenstream interpretiert und gesagt, "tangenten" ist ein array von Tangenten und muss so verarbeitet werden.
OpenGL<2 erstellt für jeden Datenstream ein VBO und packt die Daten rein, später wird dann über glVertexAttribPointer, achne gibt es ja nicht muss also glVertexPointer,glNormalPointer,glColorPointer und glTexCoordPointer herhalten, um die Daten zu binden und später zeichnen zu können. Eh moment mal, wo ist denn glTangentPointer oder glAmbientOcclussionPointer, oh gibt es nicht also wie bekomme ich nun die Vertexbasierten Daten rein ? Man kann ja im Shader Texturen und FBO's Binden packt man die zusätzlichen Daten in ein Buffer und greift über gl_VertexID auf das entsprechende Pixel in dem FBO zu. Die Maximale beschränkung liegt bei ~17Millionen Vektoren, sollte schon reichen.
Nun müsste aber unser VBO noch FBO und Shader kennen und mit diesen zusammen gebunden werden.
Damit es kompatibel bleibt, muss also in die VBO Klasse FBO implementiert werden, wenn es Custom Daten sind.
Sind es Custom Daten, dann muss der Shader das VBO als uniform binden.
Wir haben also einmal ein großen Klassensatz für OpenGL<2, ein für OpenGL2 und einen für OpenGL3 implementiert , da diese nicht kompatibel zueinander sind. Das beudetet es wurden 3 Renderpfade eingebaut.
Wenn man alle Features von OpenGL3 nutzen und abwärtskompatibel bleiben möchte, dann geht dies nur bis Version 2.0, da z.B. TransformFeedback,GLSL1.3 und Instancing(auch vor 2.0 per software emulierbar) erst ab dieser verfügbar sind.
Ergo bleiben noch 2 Renderpfade übrig, der von OpenGL2(Radeon9800/GF5xxx und höher) und der von OpenGL3(hd2xxx/gf8xxx und höher).
Wenn man wirklich noch Hardware unterstützen will, die vor R9800 und GF5 gab, z.B. GF2-4 oder R8600 der braucht nicht auf OpenGL3 setzen.
Wer OpenGL3 benuzten will, der kann mit diesen alten Karten nichts anfangen, da schon alleine die Füll- und Vertex-rate viel zu gering sind ganz geschweige von Shadern oder Framebuffern geschwindigkeit, wenn sowas überhaupt als Extension verfügbar ist.
OpenGL3 und OpenGL<2 schliessen sich also auf mehreren Wegen gegenseitig aus.

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

Projekte: https://github.com/tak2004

Pfuh,

ich hab mir jetzt mal erspart den riesen absatz am ende zu lesen.


Und ich habe auch mehrmals geschrieben das ich dir zustimme das es nur mit einem extra renderpfad klappt.

Du brauchst mir nicht erklären wie man einen renderpfad macht, oder was man dabei beachten muß - das weiß ich selbst.
Was ich mit meiner ersten antwort auf deinen post anregen wollte war nur - das ich dir zustimme das man einen extra renderpfad braucht, aber nicht verstehe warum es für dich unmöglichst ist trotzdem die selben grund-klassen zu verwenden. (Sprich, ich wiederspreche nur dem satz das man vieles neuschreiben muß damit es funktioniert)

Aber lass uns das thema jetzt einfach sein lassen und gut ist

Aya