OpenGL: 2007 geht's vorwärts!

[Expandable]

Es scheint sich was zu tun bei OpenGL: http://www.opengl.org/pipeline/vol002/

Endlich wurde offiziell bestätigt, dass Khronos das neue Object-Modell akzeptiert. Im Sommer 2007 soll dann das neue Object-Modell kommen, im Oktober dann eine weitere OpenGL-Version mit Geometry Shadern und dem ganzen neuen Zeug.

Na denn: Bring it on! :)

[ollix]

Sehr schön -freue mich schon richtig drauf. =) Vielleicht hole ich mir dann auch doch noch früher einen G80.

[Coda]

Die Geometry-Shader gibts doch jetzt schon als EXT-Extensions :)

[Expandable]

Die Geometry-Shader gibts doch jetzt schon als EXT-Extensions :)

Ja, aber dennoch ist es schön zu sehen, dass in etwa einem Jahr (hoffentlich) alle wichtigen DX10-Features im OpenGL-Core sind.

[Gast]

Und am besten "extensions free" :(

[ScottManDeath]

Das muss ich erst sehen, bevor ich es glaube. Ich habe im Sommer während des Praktikums mit DX10 angefangen zu arbeiten, und will es gar nicht mehr missen. Erst war ich skeptisch (hab zuvor exklusiv 5+ Jahre OpenGL gemacht), aber irgendwie mag ich es*.:redface: Es ist eine schöne, schlanke API, die inzwischen auch stable ist, so dass man nicht bei jedem neuem SDK Drop den Code anpassen musste.

OpenGL dagegen ist über die Jahre zu einem Flickwerk verkommen. :frown: Auch wenn Framebuffer Objects angenehmer sind zu nutzen als Pbuffer, so ist es doch nichst im Vergleich zu device->SetRenderTarget(...)

Wie es aussieht, werde ich wohl auch DX10 für meine Forschung verwenden.


*OK, COM alá DX stinkt mich immer noch an, da es nicht mit den Visual C++ COM Compiler Erweiterungen zusammenarbeit. :mad:

[Demirug]

Die Smartpointer funktionieren doch. Es wäre allerdings schön wenn man sie wie bei Direct3D 9 direkt in den Header mit einbinden würde.

Oder meinst du jetzt den Teil des COM Supports mit dem man Type Libs importieren kann?

Da OpenGL ja nun vollständig ein neues Objectmodel bekommen soll erbarmt sich wohl hoffentlich auch jemand und schreibt ein ordentliches Objektorientiertes C++ Binding dafür. Zudem hoffe ich das die teilweiße schlimmen Vergewaltigungen vorhandener Calls durch einzelne Extension aufhören. Ich sage nur Zeiger werden zu Offsets wenn ein Buffer Objekt an der entsprechenden Stelle gebunden wurde. Nichts gegen eine Statemaschine aber teilweiße geht das doch zu weit.

[ScottManDeath]

Ja, ich meinte #import typelib, so dass ich dann Exceptions bekommen, anstelle von dauernd HRESULTs zu checken. Oder Properties, anstelle von Set/Get Methoden =)

[Chris Lux]

Und am besten "extensions free" :(
na ich hoffe doch nicht! extensions sind einer der großen vorteile von opengl, so kann man features nutzen, die in der hardware bereitstehen aber von der eigentlichen api nicht zur verfügung gestellt werden.
Da OpenGL ja nun vollständig ein neues Objectmodel bekommen soll erbarmt sich wohl hoffentlich auch jemand und schreibt ein ordentliches Objektorientiertes C++ Binding dafür. Zudem hoffe ich das die teilweiße schlimmen Vergewaltigungen vorhandener Calls durch einzelne Extension aufhören. Ich sage nur Zeiger werden zu Offsets wenn ein Buffer Objekt an der entsprechenden Stelle gebunden wurde. Nichts gegen eine Statemaschine aber teilweiße geht das doch zu weit.
ja da hast du leider sehr recht. ich hatte mich ja damals so auf pure opengl2.0 gefreut. doch naja das ARB... aber das ist jetzt vergangenheit. so wie die planungen für das neue object model aussehen sollte eine kapselung in classen wirklich einfach werden. es geht einen gesunden schritt weg vom state machine konzept und lässt es so zu ohne exzessives state management objekt properties zu behandeln.

ich für meinen teil bleibe bei opengl, einfach wegen der portierbarkeit, den extensions und kleinigkeiten wie quad buffer stereo... sonst glaube ich auch daran, dass man mit beiden apis dasselbe tun kann und es nur auf andere sachen wie ein effektframework oder dcc tools (plus natürlich die zielplattform) ankommt für welche api man sich entscheidet.

[muhkuh_rs]

Abwärtskompatibilität war ja bisher immer die heilige Kuh bei OpenGL. Wird die jetzt also wirklich geschlachtet?

[Asmodeus]

Abwärtskompatibilität war ja bisher immer die heilige Kuh bei OpenGL. Wird die jetzt also wirklich geschlachtet?

Naja, was heißt geschlachtet. Wenn ich es richtig verstanden habe, dann laufen alle alten Sachen doch auch weiterhin. Nur wenn man neue Features und das neue Objektmodell nutzen will, dann muss man natürlich umsteigen, und seinen alten Code dementsprechend anpassen/neu programmieren. Im Grunde ist es also genauso, wie bei DX10, DX9 wird weiterhin unterstützt, nur für DX10 Features muss man natürlich in DX10 programmieren.

Wie sieht die Sache, bezogen auf OpenGL nun eigentlich von der Hardwareseite aus? Wird es auf den älteren Karten (7900 und Co.) auch möglich sein Geometry Shader, Texture Arrays etc. zu nutzen, oder bleibt das (wie bei DX10) nur den neuen Grafikkarten (8800 und Co.) vorbehalten?

Gruss, Carsten.

[ScottManDeath]

Ich geh mal stark davon aus, das es nur auf DX10 hardware laufen wird....

[Asmodeus]

Ich geh mal stark davon aus, das es nur auf DX10 hardware laufen wird....

Also ist davon auszugehen, dass der momentane Split bei den Treibern (Treiber für 8800 und Treiber für alles andere davor) auch bestehen bleibt?

Gruss, Carsten.

[Demirug]

Ich geh mal stark davon aus, das es nur auf DX10 hardware laufen wird....

So wie ich es verstanden habe deckt „Long Peak“ den D3D9 Funktionsumfang ab und „Mt. Evans“ fügt dann die D3D10 Funktionalität hinzu. Um die Kompatibilität zu alten OpenGL Anwendungen aufrecht zu erhalten soll es einen Wrapper geben der diese alten Calls nach „Long Peak“ umsetzt.

[Chris Lux]

So wie ich es verstanden habe deckt „Long Peak“ den D3D9 Funktionsumfang ab und „Mt. Evans“ fügt dann die D3D10 Funktionalität hinzu. Um die Kompatibilität zu alten OpenGL Anwendungen aufrecht zu erhalten soll es einen Wrapper geben der diese alten Calls nach „Long Peak“ umsetzt.
jap genau so ist das. es wird zwei profile geben das 'lean and mean' welches für die neue api steht und dann der kompatibilitätslayer genannt 'full profile'. so bekommt man für die treiber entwickler eine viel schlankere api, welche dann viel einfacher zu implementieren ist. darüber kommt dann das full profile, welches allein auf dem lean and mean profile aufsetzt und so im treiber keine direkte hardware unterstützung mehr braucht.

Hier (http://www.khronos.org/developers/library/siggraph2006/OpenGL_BOF/ATI_-_OpenGL_3_Directions.ppt) kann man auch schön nachlesen, welche diese layered features alles sein werden. ich find es wirklich gut, endlich die api mal richtig sauber zu machen. ich bin auch gespannt, wann das neue objektmodell als extension kommt. denn ich glaube es wird vorher schon wie doe FBOs einen testlauf bekommen ehe es in den long peaks core kommt.

[pajofego]

Da ihr so schön auch am Diskutieren seid von DirectX/SDK (sorry wenn ich hier so reinplatze mit meinen Fragen), habe ich mal in diesem Zusammenhang eine Frage bzgl. des aktuellen SDK (2006 DirectX SDK). Es soll ja wieder HLSL Shader Debugging können, auch für VS2005 Express Edition besitzer oder doch nur doch nur mit dem profesionell VS2005?

Danke,

Gruß

pajofego

[Demirug]

Da ihr so schön auch am Diskutieren seid von DirectX/SDK (sorry wenn ich hier so reinplatze mit meinen Fragen), habe ich mal in diesem Zusammenhang eine Frage bzgl. des aktuellen SDK (2006 DirectX SDK). Es soll ja wieder HLSL Shader Debugging können, auch für VS2005 Express Edition besitzer oder doch nur doch nur mit dem profesionell VS2005?

Danke,

Gruß

pajofego

Wenn du vom DirectX SDK sprichst reicht inzwischen das Jahr als Angabe nicht mehr. Es gibt ja alle zwei Monate ein neues. Der Shader Debugger ist jetzt ein Teil von PIX und hat mit dem VS nichts mehr zu tun.

[pajofego]

Wenn du vom DirectX SDK sprichst reicht inzwischen das Jahr als Angabe nicht mehr. Es gibt ja alle zwei Monate ein neues. Der Shader Debugger ist jetzt ein Teil von PIX und hat mit dem VS nichts mehr zu tun.

O.K. Ich habe mich schon seit über einem Jahr nicht mehr mit DirectX beschäftigt. Das letzte Mal war irgendetwas mit Summer SDK 2005. Ich weiss nur noch, dass ich in VS2005 keinen Shader Debugger mehr hatte...danach wie gesagt habe ich mich nicht mehr damit beschäftig, s.d. ich eine gewisse Wissenslücke aufweise. Ich habe nur in meiner Neugier mal wieder gefragt ob's mittlerweile geht. Auf der Homepage von DirectX steht, dass das wieder mit dem aktuellen SDK gehen soll, aber was PIX sein soll...tut mir leid, ist wohl spurlos an mir vorbeigegangen. Meine Frage zielt eigentlich darauf hinaus ob ich heute wieder Shader Debuggen kann, wenn ja, reicht mir das aktuelle DirectX SDK aus, oder muss ich noch zusätzliche Tools - wie diese PIX - installieren, erwerben oder wie auch immer.

Danke,

Gruß

pajofego

P.S.: Was ist eigentlich dieses PIX?

[Expandable]

PIX wird mit dem SDK installiert, ist kostenlos, und sowas wie der gDEBugger für OpenGL mit zusätzlichem HLSL-Shader-Debugger (hmm, ein Shader-Debugger für OpenGL wär aber auch mal was nettes. Gibt's da was?)

[Gast]

na ich hoffe doch nicht! extensions sind einer der großen vorteile von opengl, so kann man features nutzen, die in der hardware bereitstehen aber von der eigentlichen api nicht zur verfügung gestellt werdenIch bin dafür, daß die Entwicklung von OpenGL der Entwicklung von Grafikchips nicht mehr hinterherrennt...

[pajofego]

Hi,

habe soeben das aktuelle DirectX SDK installiert. Aus VS2003 kenne ich, dass man einen Eintrag in der IDE hatte um Shader Debugging zu starten. In VS2005 hat sich nichts geändert. :confused: Habe ich da jetzt etwas misverstanden?

Danke,

Gruß

pajofego

[Expandable]

Du musst Deine Anwendung mit PIX debuggen, nicht mit VS.

[Demirug]

PIX findest du bei den DirectX Utilities im Start Menü.

[pajofego]

Ich fand die Integration in die VS2003 IDE ziemlich praktisch. Wieso muss ich bzw. man heute eine externe Anwendung benutzen? Welche Gründe gab's gibt's dafür?


Danke,

Gruß

pajofego