Opengl vs D3D

[mapel110]

http://www.beyond3d.com/forum/showthread.php?t=22498
Zusammengefasst:
pro opengl
Linux/Mac
Schneller auf Pre-Longhorn-Systemen
nvidia und ati wollen weiter für opengl optimieren (können)

pro D3D
best supported API on Windows that all GPU vendors focus on.

Das sind wohl die wesentlichen Argumente. Liegts hauptsächlich am Treibersupport, dass D3D so stark Beachtung findet?! Die eher schlechten ATI-Opengl-Treiber erwähnt ja auch der Croteam-Entwickler.
ATi, on the other hand, have some serious issues, and not only with performance; just simple things, like conformance with some OpenGL extension they "support".

Irgendwie schiebt das die Schuld, dass Opengl auf dem Rückzug ist im Spielesektor, eher in Richtung Grafikkartenhersteller als in Richtung Microsoft.
:uponder:

[Gast]

Ich persönlich glaube eher, dass ein sehr wichtiger Grund D3D zu nutzen die mitgelieferte D3DX Bibliothek ist, die wirklich eine Unmenge von nützlichen Dingen bietet, von einfachen Funktionen, mit denen man beliebiege Texturformate laden kann bis hin zu ner PRT Engine.
Es gibt auf OpenGL Seite nichts, was da mithalten könnte, denn OpenGL ist schlicht und einfach "nur" ein Standard und kein SDK.

[looking glass]

Mhhh,

könnten das nicht noch, nun ja, nachwehen sein, das OpenGL soviel Einfluss verloren hat, ich mein, es dauerte doch ne ganze Zeit, bis OpenGL für den Einsatzbereich wieder Sachen bot, die D3D zu diesem Zeitpunkt schon, ähm, länger konnte und nun sind viele also auf D3D umgeschwenkt, haben sich eingearbeitet, warum wieder zurück gehen, sowas kostet doch immer einiges an Zeit.

Nur so eine Idee, aber es war doch sehr auffällig wie auf einmal alle auf D3D umschwenkten, als die OpenGL Technik langsam aber sicher veraltete und die Neuheiten auf sich warten liessen.

MfG
Look

[Corrail]

pro opengl
backward compatibility (für Spiele vielleicht nicht so wichtig, aber sehr wohl für Applikationen)

Das mit schneller auf Pre-Longhorn muss nicht unbedingt stimmen. Kommt auf die Anwendung an.
Das DX/D3D so viel attraktiver als OpenGL ist liegt IMHO so gut wie nur daran, dass DX mehr oder weniger eine eierlegende Wollmilichsau ist. DX bietet schon für so gut wie alles Bibliotheken und man muss sich um nicht so viel kümmern. Bei OpenGL schaut das anders aus. OpenGL ist halt eine reine 3D API.
Die Schuld, dass OpenGL derzeit in einer Krise steckt hat IMHO zu einem großen Teil das ARB. Es hat sich eine gewisse Zeit nichts Wesentliches in der Entwicklung von OpenGL getan, aus welchen Gründen auch immer.

Meine persönliche Meinung ist, dass OpenGL in nächster Zeit sehr wohl wieder attraktiver wird, auch für Spiele. Das ARB bastelt fleißig weiter an OpenGL und die Platformunabhängigkeit sollte man nicht unterschätzen.

Nur so eine Idee, aber es war doch sehr auffällig wie auf einmal alle auf D3D umschwenkten, als die OpenGL Technik langsam aber sicher veraltete und die Neuheiten auf sich warten liessen.

Das stimmt nicht so ganz. OpenGL war eine Zeit lang wirklich hinten. Ich will da jetzt nur mal kurz DX8 Shader ansprechen, wo es unter OpenGL keine einheitliche API gegeben hat. Aber mittler Weile ist OpenGL mit GLSL, Floating Point Extensions und EXT_framebuffer_object DX9 sehr wohl wieder ebenwürdig.

[Gast]

Die Schuld, dass OpenGL derzeit in einer Krise steckt hat IMHO zu einem großen Teil das ARB. Es hat sich eine gewisse Zeit nichts Wesentliches in der Entwicklung von OpenGL getan, aus welchen Gründen auch immer.

M$ saß zu der Zeit noch im ARB. Jetzt nicht mehr und es dauerte auch gar nicht mehr lange und OpenGL 2 war "fertig". ;)

[ShadowXX]

pro opengl
backward compatibility (für Spiele vielleicht nicht so wichtig, aber sehr wohl für Applikationen)


Also bei mir funktionieren auch noch DX5 und DX3 sachen mit DX9.
DX ist genauso "backward compatible" wie OGL.

Nicht die inkompatibilitäten zwischen Win98 und 2K/XP mit inkompatibilitäten von DX verwechslen.

Ach ja:
Contra OGL:
- Extension-Wirrwar (jeder Graka-Hersteller backt sich seine eigenen propitären Extensions)

Ab WGF2.0 fällt bei MS sogar das lästige Caps-Abfragen weg, da nur eine Karte, die alle WGF2.0 Specs beherscht sich WGF2.0-Komplilant nennen darf.

[TrigPe]

Hallo,

ich finde OpenGL ist um einiges einfacher zu proggen. Ist jedenfalls mein subjektiver Eindruck. DirektX ist mir ein bischen zu kompliziert.

Falls OT, Sorry




MfG

[Ganon]

Ab WGF2.0 fällt bei MS sogar das lästige Caps-Abfragen weg, da nur eine Karte, die alle WGF2.0 Specs beherscht sich WGF2.0-Komplilant nennen darf.

Ist das nicht jetzt mit DirectX nicht aus so? Wenn sie DirectX9 kann, kann sie es und es braucht einen nicht zukümmern. Das geht so lange gut, bis irgend eine Karte wieder mehr kann. Wenn sich M$ dann breit schlagen lässt kommt halt ne a, b und c Variante raus, oder was weiß ich. ;)

Das Problem jetzt scheint ja nur zu sein, das es DirectX9 a, b und c gibt und jede Karte kann von jedem etwas. Eine mehr, die andere weniger.

Geht WGF da andere Wege, oder wie ist das da?

[Demirug]

Direct3D legt nur fest wie etwas unterstützt werden muss. Ob eine Karte es dann unterstützt meldet der Treiber durch die CAPS.

Die Buchstaben an der Versionsnummer sind nur Bugfixes. Nur wenn sich die Nummer ändert wurde auch die API verändert.

Bei WGF 1.0 das ja nichts anderes als D3D9 mit minimalen Anpassungen ist bleibt erst mal alles beim alten. Bei WGF 2.0 schreibt die Spec aber nicht mehr nur vor wie etwas unterstützt werden muss sondern auch das es unterstützt werden muss. Damit werden die PCs in diesem Punkt etwas Konsolenähnlicher.

[Coda]

Hallo,

ich finde OpenGL ist um einiges einfacher zu proggen. Ist jedenfalls mein subjektiver Eindruck. DirektX ist mir ein bischen zu kompliziert.

Falls OT, SorryFalls du damit Dinge wie "glVertex3f" meinste: Das wurde aus gutem Grund niemals in D3D aufgenommen, weil die Performance damit sehr leidet.

[Ganon]

Falls du damit Dinge wie "glVertex3f" meinste: Das wurde aus gutem Grund niemals in D3D aufgenommen, weil die Performance damit sehr leidet.

Nunja. Auch wenn sowas ähnliches in Direct3D drinnen wäre, würde ja wohl kein Spieleentwickler auf die Idee kommen 1000000 Polygone mit glVertex3f zu bestimmen. ;)

[Coda]

Auch schon wenige sind nicht gerade toll. Das ganze würde man so heute in OpenGL auch sicherlich nicht mehr einbauen.

Wenn man OpenGL und D3D auf diesem Level vergleicht dann ARB_VBO vs. IDirect3DVertexBuffer9. Und da ist OpenGL erstmal schwieriger zu initialisieren.

[Asmodeus]

Meiner Meinung nach ist die Nutzung von OpenGL im Spielebereich eh nur eine Randerscheinung. Und hätte es sich bei den in OpenGL programmierten Spielen nicht gerade um MegaSeller vor allem aus dem Hause Id gehandelt, so hätte ein Großteil der User OpenGL sicher gar nicht wahrgenommen. Wenn man auf einer anderen Plattform als Windows 3D Programme entwickeln will, dann kommt man um OpenGL einfach nicht herum. Und der Schwenk auch zu Windows ist einfach historisch gewachsen. Windows hat sich auch im Profi- und Forschungssegment immer mehr verbreitet, so dass es sowohl für MS als auch für die Hersteller von Grafikkarten immer attraktiver wurde, die OpenGL Funktionalität auch unter Windows anzubieten. Das MS natürlich über die Zeit auch hier versucht, "seinen eigenen Standard" zu etablieren kennt man ja schon. Und auf dem Spielesektor ist ihnen das auch (zu Recht) gelungen. Ob es OpenGL in 10 Jahren noch gibt, keine Ahnung, momentan liegt es im Nicht-Spiele-Sektor jedoch weiterhin an der Spitze.

EDIT: Die Frage ist vielleicht einfach: Muss eine 3D-API heutzutage im Spielesektor erfolgreich und weitverbreitet sein, um weiter existieren zu können und um auf längere Sicht zu bestehen? Ich sage aus heutiger Sicht einfach mal nein.

Gruss, Carsten.

[Coda]

OpenGL wird ganz sicher nicht aussterben, darüber brauchen wir ja gar nicht zu diskuttieren allein weil D3D wohl MS-only bleiben wird.

[Demirug]

Meiner Meinung nach ist die Nutzung von OpenGL im Spielebereich eh nur eine Randerscheinung. Und hätte es sich bei den in OpenGL programmierten Spielen nicht gerade um MegaSeller vor allem aus dem Hause Id gehandelt, so hätte ein Großteil der User OpenGL sicher gar nicht wahrgenommen. Wenn man auf einer anderen Plattform als Windows 3D Programme entwickeln will, dann kommt man um OpenGL einfach nicht herum. Und der Schwenk auch zu Windows ist einfach historisch gewachsen. Windows hat sich auch im Profi- und Forschungssegment immer mehr verbreitet, so dass es sowohl für MS als auch für die Hersteller von Grafikkarten immer attraktiver wurde, die OpenGL Funktionalität auch unter Windows anzubieten. Das MS natürlich über die Zeit auch hier versucht, "seinen eigenen Standard" zu etablieren kennt man ja schon. Und auf dem Spielesektor ist ihnen das auch (zu Recht) gelungen. Ob es OpenGL in 10 Jahren noch gibt, keine Ahnung, momentan liegt es im Nicht-Spiele-Sektor jedoch weiterhin an der Spitze.

EDIT: Die Frage ist vielleicht einfach: Muss eine 3D-API heutzutage im Spielesektor erfolgreich und weitverbreitet sein, um weiter existieren zu können und um auf längere Sicht zu bestehen? Ich sage aus heutiger Sicht einfach mal nein.

Gruss, Carsten.

Eine weitgehend unbekannte Tatsache ist allerdings das vom zuständigen Team ursprünglich OpenGL als API für den 3D Teil von DirectX vorgesehen war. Direct3D war eigentlich nur die Notlösung weil man den schon vorhandenen OpenGL Teil von Windows NT nicht für Windows95 übernehmen konnte.

[marco42]

Also bei mir funktionieren auch noch DX5 und DX3 sachen mit DX9.
DX ist genauso "backward compatible" wie OGL.



Aber ist das auch Interface kompatibel? OpenGL ist immer Interface kompatibel, das heisst du kannst unter OpenGL 2.0 auch noch das 1.0 Interface programmieren, kannst du das auch unter D3D. AFAIK bringt jedes D3D ein neues Interface und so was ist Gift fuer alle langfristigen Projekte. Du kannst also nicht ein D3D 9 mit einem D3D 5 Interface mixen. Daher ist OpenGL in manchen Bereichen auch etwas krude. Und deswegen auch etwas langsamer, denn du kannst es ja nicht mit der naechsten Version aus dem Standard schmeissen.

[Demirug]

Aber ist das auch Interface kompatibel? OpenGL ist immer Interface kompatibel, das heisst du kannst unter OpenGL 2.0 auch noch das 1.0 Interface programmieren, kannst du das auch unter D3D. AFAIK bringt jedes D3D ein neues Interface und so was ist Gift fuer alle langfristigen Projekte. Du kannst also nicht ein D3D 9 mit einem D3D 5 Interface mixen. Daher ist OpenGL in manchen Bereichen auch etwas krude. Und deswegen auch etwas langsamer, denn du kannst es ja nicht mit der naechsten Version aus dem Standard schmeissen.

Die Interfaces werde bei jeder neuen Version angepasst. Allerdings sind die Änderungen mal mehr mal weniger groß. Von DX8 zu DX9 hat sich fast nichts geändert.

Bei OpenGL ES bricht man allerdings inzwischen auch mit der kompatibilität.

[marco42]

Die Interfaces werde bei jeder neuen Version angepasst. Allerdings sind die Änderungen mal mehr mal weniger groß. Von DX8 zu DX9 hat sich fast nichts geändert.


Ja, ergibt sich wohl aus dem Markt. Mir waere ein Bruch ganz lieb, aber das wollen bestimmt die nicht, die schon seit zehn Jahren an einer Anwendung stricken.

[Coda]

Und deswegen auch etwas langsamer, denn du kannst es ja nicht mit der naechsten Version aus dem Standard schmeissen.Also zumindest mit den nVIDIA Treibern trifft das nicht zu.

Ich wüsste auch nicht wo OpenGL große Mängel hätte gegenüber D3D9 außer Render-To-Texture. Der Rest kann sich ja ohne Problem per Extension einfügen.

[marco42]

Also zumindest mit den nVIDIA Treibern trifft das nicht zu.

Ich wüsste auch nicht wo OpenGL große Mängel hätte gegenüber D3D9 außer Render-To-Texture. Der Rest kann sich ja ohne Problem per Extension einfügen.

Da gibt es aber mittlerweile FBOs. Ist das unter D3D eigentlich genauso flexibel?

[Demirug]

Da gibt es aber mittlerweile FBOs. Ist das unter D3D eigentlich genauso flexibel?

Mindestens.

Jedes Surface (ein Datenbuffer in D3D) das mit einem entsprechenden Flag erzeugt wurde kann als Rendertarget bzw Z-Buffer gesetzt werden. Die Formate müssen halt passen aber dafür gibt es eine Funktion um das zu prüfen.

Man kann ein Surface direkt erzeugen oder aber eine Mipmap von einer Texture oder Cupemap nehmen. Eine Mipmap ist automatisch ein Surface.

Zum umkopieren von Daten von einem Surface zu einem anderen (Acuh ausschnittsweise) gibt es auch eine Funktion. Diese kann sogar wenn es die Karte unterstützt Formate konvertieren und skalieren. Kopiert man von einem
MultiSample Surface in ein normales wird auch ein Downscale durchgeführt (funktioniert aber leider nur bei nVidia Karten immer richtig). Das benutzt man zum Beispiel wenn man den Backbuffer in eine texture übertragen möchte für einen Postfilter Effekt.

[Demirug]

Ja, ergibt sich wohl aus dem Markt. Mir waere ein Bruch ganz lieb, aber das wollen bestimmt die nicht, die schon seit zehn Jahren an einer Anwendung stricken.

Man muss das fliesend machen.

Zudem war es bei D3D halt auch mal öfter notwendig weil die Entwickler an den ersten Schnittstellen verzweifelt sind. Wenn man die Hintergrund Geschichte kennt wundert das auch nicht.

[Corrail]

Mindestens.

Jedes Surface (ein Datenbuffer in D3D) das mit einem entsprechenden Flag erzeugt wurde kann als Rendertarget bzw Z-Buffer gesetzt werden. Die Formate müssen halt passen aber dafür gibt es eine Funktion um das zu prüfen.

Man kann ein Surface direkt erzeugen oder aber eine Mipmap von einer Texture oder Cupemap nehmen. Eine Mipmap ist automatisch ein Surface.

Zum umkopieren von Daten von einem Surface zu einem anderen (Acuh ausschnittsweise) gibt es auch eine Funktion. Diese kann sogar wenn es die Karte unterstützt Formate konvertieren und skalieren. Kopiert man von einem
MultiSample Surface in ein normales wird auch ein Downscale durchgeführt (funktioniert aber leider nur bei nVidia Karten immer richtig). Das benutzt man zum Beispiel wenn man den Backbuffer in eine texture übertragen möchte für einen Postfilter Effekt.

Ist bei OpenGL (2.0 inkl. FBO) nicht wirklich anders. Man kann an ein Framebuffer Object sowohl Texturen (Mipmapstufen, Cubemap Faces, 3D Depth Slices) als auch eigene Renderbuffer anhängen. Formate müssen hier genauso stimmen, sind aber großteils Hardware limitiert (nicht von der API). Zum Kopieren geht man hier am besten über die Extensions ARB_pixel_buffer_object gehen.
Spezialanwendungen wie du sie jetzt erwähnt hast (mit downsample oder postfilter) muss man aber selbst implementieren (Render-To-Texture, usw.), ist aber auch möglich.
Ich sehe somit nichts, wo OpenGL DirectX nachsteht.

[Chris Lux]

Ach ja:
Contra OGL:
- Extension-Wirrwar (jeder Graka-Hersteller backt sich seine eigenen propitären Extensions)

NEIN, genau das ist aber der große vorteil von OpenGL für die IHVs und generell für die Weiterentwicklung von technologien! ohne extensions müsste man warten bis neue features (von MS im falle d3d) in die API eingeführt würden, um sie nutzen zu können.
[...]Zum Kopieren geht man hier am besten über die Extensions ARB_pixel_buffer_object gehen.
Spezialanwendungen wie du sie jetzt erwähnt hast (mit downsample oder postfilter) muss man aber selbst implementieren (Render-To-Texture, usw.), ist aber auch möglich.
Ich sehe somit nichts, wo OpenGL DirectX nachsteht.
soweit ich weiss, wird bei einem copy aus einem rendertarget mit multisamplefähigkeiten der downsample durchgeführt (also glReadPixels, glCopyPixels usw). ich kann mich auch erinnern, dass es möglich sein soll einen glsl shader während eines copys ausführen zu können. da gab es im nvidia regdev forum mal einen thread zu, bloß ich der scheint leider schon gelöscht zu sein. ich schau mal nach wie das gehen sollte, wäre aber schon eine gute möglichkeit sowas wie farbkorrekturen durchzuführen.

[Corrail]

ich kann mich auch erinnern, dass es möglich sein soll einen glsl shader während eines copys ausführen zu können. da gab es im nvidia regdev forum mal einen thread zu, bloß ich der scheint leider schon gelöscht zu sein. ich schau mal nach wie das gehen sollte, wäre aber schon eine gute möglichkeit sowas wie farbkorrekturen durchzuführen.

Stimmt, da war irgendwas... Ich glaub es ist laut API so, dass der Shader selbst bei einem glDrawPixel aufgerufen wird. Somit könnte man das Render-To-Texture komplett übergehen. Das wäre dann sogar noch flexibler als "nur" ein Filter.

[Chris Lux]

Stimmt, da war irgendwas... Ich glaub es ist laut API so, dass der Shader selbst bei einem glDrawPixel aufgerufen wird. Somit könnte man das Render-To-Texture komplett übergehen. Das wäre dann sogar noch flexibler als "nur" ein Filter.
ok habs gefunden. soll laut spec gehen, doch im nv treiber wars noch nicht drin. hab mal nachgefragt ob es jetzt implementiert ist (hab grad keine zeit um es selbst zu testen).

[Coda]

Ist bei OpenGL (2.0 inkl. FBO) nicht wirklich anders. Man kann an ein Framebuffer Object sowohl Texturen (Mipmapstufen, Cubemap Faces, 3D Depth Slices) als auch eigene Renderbuffer anhängen. Formate müssen hier genauso stimmen, sind aber großteils Hardware limitiert (nicht von der API). Zum Kopieren geht man hier am besten über die Extensions ARB_pixel_buffer_object gehen.
Spezialanwendungen wie du sie jetzt erwähnt hast (mit downsample oder postfilter) muss man aber selbst implementieren (Render-To-Texture, usw.), ist aber auch möglich.
Ich sehe somit nichts, wo OpenGL DirectX nachsteht.Bis auf das FBO noch ziemlich Beta ist in den Treibern.

Deshalb habe ich FBO jetzt mal (noch) ganz bewusst ausgeklammert.

[Demirug]

NEIN, genau das ist aber der große vorteil von OpenGL für die IHVs und generell für die Weiterentwicklung von technologien! ohne extensions müsste man warten bis neue features (von MS im falle d3d) in die API eingeführt würden, um sie nutzen zu können.

Es ist ein Vor und ein Nachteil zur gleichen Zeit. Für die Spieleentwicklung eher einer Nachteil in der Forschung sowie im Profibereich eher ein Vorteil.

soweit ich weiss, wird bei einem copy aus einem rendertarget mit multisamplefähigkeiten der downsample durchgeführt (also glReadPixels, glCopyPixels usw). ich kann mich auch erinnern, dass es möglich sein soll einen glsl shader während eines copys ausführen zu können. da gab es im nvidia regdev forum mal einen thread zu, bloß ich der scheint leider schon gelöscht zu sein. ich schau mal nach wie das gehen sollte, wäre aber schon eine gute möglichkeit sowas wie farbkorrekturen durchzuführen.

Das mit dem Downsample beim Copy ist AFAIK eine Sache des nVidia Treibers und nicht vorgschrieben.

Ich erinnere mich nur an ein Beispiel bei dem erst kopiert und dann noch ein Shader angewendet wurde.

[marco42]

Mindestens.

Jedes Surface (ein Datenbuffer in D3D) das mit einem entsprechenden Flag erzeugt wurde kann als Rendertarget bzw Z-Buffer gesetzt werden. Die Formate müssen halt passen aber dafür gibt es eine Funktion um das zu prüfen.


Geht damit dann auch direktes Render-To-Vertexbuffer? Oder ist eine Surface nur eine Verallgemeinerung von Texture/Color-/Stencil-/Depthbuffer? Unter OpenGL muss man da ja nochmal mit Hilfe von PBOs kopieren.


Zum umkopieren von Daten von einem Surface zu einem anderen (Acuh ausschnittsweise) gibt es auch eine Funktion. Diese kann sogar wenn es die Karte unterstützt Formate konvertieren und skalieren. Kopiert man von einem
MultiSample Surface in ein normales wird auch ein Downscale durchgeführt (funktioniert aber leider nur bei nVidia Karten immer richtig). Das benutzt man zum Beispiel wenn man den Backbuffer in eine texture übertragen möchte für einen Postfilter Effekt.

Naja, dass geht ja unter OpenGL schon seit 1.0. Was mich an OpenGL manchmal stoert, dass manche Sachen schon nicht mehr so einleuchtend sind, vielleicht wird man mal irgendwann ein komplett neues API entwerfen(OpenStreamLibrary :).

[Coda]

Geht damit dann auch direktes Render-To-Vertexbuffer?Nein.

[Gast]

Habe mich gestern abend durch einen 3 Seiten Threat im OpenGl Forum gelesen und moechte kurz zusammenfassen:

Es ging um Windows Vista und die Beschraenkung auf OpenGl 1.4 als Wrapper bei diesem neuen Betriebssystem. Der allgemeine Tenor war: Damit ist OpenGl tot.
Die Stimmung war ziemlich gedrueckt. Ein Aspekt, den man beruecksichtigen sollte: Wenn es nur noch D3d gibt, haengt es von der Lust und Laune von MS ab, wie schnell der Fortschritt im Grafik\Spielebereich sein wird. Dann bleibt fuer OpenGl nur noch die Playstation 3, Mac und Linux uebrig.

[Demirug]

Habe mich gestern abend durch einen 3 Seiten Threat im OpenGl Forum gelesen und moechte kurz zusammenfassen:

Es ging um Windows Vista und die Beschraenkung auf OpenGl 1.4 als Wrapper bei diesem neuen Betriebssystem. Der allgemeine Tenor war: Damit ist OpenGl tot.
Die Stimmung war ziemlich gedrueckt. Ein Aspekt, den man beruecksichtigen sollte: Wenn es nur noch D3d gibt, haengt es von der Lust und Laune von MS ab, wie schnell der Fortschritt im Grafik\Spielebereich sein wird. Dann bleibt fuer OpenGl nur noch die Playstation 3, Mac und Linux uebrig.

Scheinbar hast du aber nur die Hälfte gelesen.

Windows Vista ist nicht auf den Wrapper begrenzt nur für AERO besteht dieses Limit bei der Beta 1. Das kann sich aber alles noch ändern.

Die Playstation 3 nutzt OpenGL ES 2.0. Das ist nicht 100% mit OpenGL vergleichbar.

Um den Fortschritt würde ich mir nicht so viele Sorgen machen. MS hat auch weiter Entwickelt als aus der OpenGL Richtung defakto kein Druck gekommen ist weil sich das ARB nicht einigen konnte.

[Gast]

Hier fuer alle die es auf Englisch lesen moechten der Link:

http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=12;t=000001

[marco42]

Scheinbar hast du aber nur die Hälfte gelesen.

Windows Vista ist nicht auf den Wrapper begrenzt nur für AERO besteht dieses Limit bei der Beta 1. Das kann sich aber alles noch ändern.
[QUOTE=Demirug]
Die Playstation 3 nutzt OpenGL ES 2.0. Das ist nicht 100% mit OpenGL vergleichbar.


Es ist ein Subset von OpenGL 2.0, wobei die Extensions andere Namen haben. Also kannst du ziemlich leicht von OpenGL ES nach OpenGL portieren. Was viele immer uebersehen ist collada (http://www.khronos.org/collada/), was anscheinend doch sehr erfolgreich ist.


Um den Fortschritt würde ich mir nicht so viele Sorgen machen. MS hat auch weiter Entwickelt als aus der OpenGL Richtung defakto kein Druck gekommen ist weil sich das ARB nicht einigen konnte.

Da sass aber auch noch MS im ARB, sie haben es systematisch blockiert.

[Coda]

Da sass aber auch noch MS im ARB, sie haben es systematisch blockiert.Das ist auch seit MS weg ist nicht viel besser. Ich sage nur FBO.

[marco42]

Das ist auch seit MS weg ist nicht viel besser. Ich sage nur FBO.

Also das stimmt definitiv nicht, es kam in der Zwischenzeit ne ganze Menge(GLSL, VBO, OC, ARB extensions etc.). Das mit den FBOs hat sich ja nur wegen den Superbuffers so hingezogen. Es gab in der Zeit davor praktisch Null Fortschritt. GLSL ist so weit, das es kaum ausgereizt wird. Ausserdem gab es ja immer noch die PBuffer, auch wenn die wirklich nicht das wahre sind. Ich habe manchmal in unter technischen Personen das Gefuehl, dass sie die Dynamik unterschaetzen, die echter Wettbewerb hervorbringt. Der zwischen D3D und OpenGL hat beiden Seiten gut getan. Es waere von MS oder den anderen absolut unsinnig mehr zu investieren, als unbedingt notwendig, da dieses den Gewinn schmaelert. MS ist ein sehr rationales Unternehmen, fast ein Paradebeispiel der Spieltheorie(mit einem maechtigen Schuss Paranoia). Das sah man sehr schoen am IE und an Office. Es wurde schon was getan, aber nur sehr wenig, solange keine Konkurrenz da war. Also wer sich wuenscht, das eine Partei "gewinnt", ist hinterher der Dumme, denn seine Gewinne werden dann zu dem "Sieger" umverteilt.

[Coda]

Es kommt immer auf die Betrachtungsweise an. MS steht eigentlich schon unter dem Druck der Kartenhersteller die sich sicher irgendwann eigene APIs überlegt hätten wenn D3D nicht Schritt gehalten hätte.

GLSL ist so weit, das es kaum ausgereizt wird.Definiere "ausreizen". Bei einer frei programmierbaren Sache ist das schwierig ;)

[Demirug]

Es ist ein Subset von OpenGL 2.0, wobei die Extensions andere Namen haben. Also kannst du ziemlich leicht von OpenGL ES nach OpenGL portieren. Was viele immer uebersehen ist collada (http://www.khronos.org/collada/), was anscheinend doch sehr erfolgreich ist.

collada ist nur ein Dateiformat. Völlig API neutral.

Es gibt so ein paar Sache die man bei OpenGL ES 2.0 einfach rausgeworfen hat.

Da sass aber auch noch MS im ARB, sie haben es systematisch blockiert.

Soweit mir die Abstimmungsrichtlinen des ARBs bekannt sind kann ein einzelner da gar nicht blockieren.

[marco42]

collada ist nur ein Dateiformat. Völlig API neutral.


Das ist ja das schoene und es wird breit unterstuetzt. Es geht ja darum, das es die Arbeit erleichtert, platformneutral zu entwickeln. Es ist aber auch ein API.



Soweit mir die Abstimmungsrichtlinen des ARBs bekannt sind kann ein einzelner da gar nicht blockieren.

Sie haben immer Andeutungen ueber Patente auf Shader gemacht und damit die Verabschiebung verzoegert. Ist sehr schoen nachzulesen.

[marco42]

Es kommt immer auf die Betrachtungsweise an. MS steht eigentlich schon unter dem Druck der Kartenhersteller die sich sicher irgendwann eigene APIs überlegt hätten wenn D3D nicht Schritt gehalten hätte.


Ja, aber das wuerde dauern. Ich hab nicht von ob, sondern der Geschwindigkeit gesprochen. Ausserdem muesste das API auch noch in Windows integriert werden, ohne MS geht das AFAIK nicht.


Definiere "ausreizen". Bei einer frei programmierbaren Sache ist das schwierig ;)

Du kannst bestimmt Dinge einfach nicht machen, da es nicht geht. Die Hardware macht es nicht mit.

[Demirug]

Das ist ja das schoene und es wird breit unterstuetzt. Es geht ja darum, das es die Arbeit erleichtert, platformneutral zu entwickeln. Es ist aber auch ein API.

Es gibt keine API sondern nur eine Beispiel Implementierung für einen Reader. Letzten Endes ist das aber sowieso nur XML. Im Prinzip betrifft Collada aber sowieso mehr die Asset Seite der Entwicklung.

Sie haben immer Andeutungen ueber Patente auf Shader gemacht und damit die Verabschiebung verzoegert. Ist sehr schoen nachzulesen.

Jeder der großen hat mindestens ein Shaderpatent. Ich denke aber wir sind uns einig das das ARB eben etwas langsamer ist weil es aufgrund der Extension Option ja auch nicht so wirklich den Druck gibt eine schnelle Einigung herbei zu führen.

[Coda]

Du kannst bestimmt Dinge einfach nicht machen, da es nicht geht. Die Hardware macht es nicht mit.Was unterstützt ein NV40+ denn nicht in HW was GLSL spezifiziert?

[Demirug]

Was unterstützt ein NV40+ denn nicht in HW was GLSL spezifiziert?

Noise zum Beispiel. Aber mit HLSL kann man ja auch Programme schreiben die Syntaktisch korrekt sind aber mit keinen Profile kompilert werden können. Im Prinzip ist es ja auch richtig das Shaderhochsprache nicht mit jeder neuen Hardware generation nachgebessert werden müssen.

[marco42]

Es gibt keine API sondern nur eine Beispiel Implementierung für einen Reader. Letzten Endes ist das aber sowieso nur XML. Im Prinzip betrifft Collada aber sowieso mehr die Asset Seite der Entwicklung.


Wenn du diesem
link (http://www.khronos.org/collada/presentations/collada_siggraph2005.pdf)
folgst, wirst du sehen, dass sie ein API planen, wofuer das gut ist, hab ich nicht gelesen, sah fuer mich eher wie ein XML Parser aus. Ich wollte damit nur zeigen, dass im OpenGL Bereich in letzter Zeit eine Menge passiert. Spiele sind halt nicht alles und bevor Techniken in Spielen eingesetzt werden, findet man sie in Papern(SIGGRAPH). OpenGL ist hier immer noch das 3D API.


Jeder der großen hat mindestens ein Shaderpatent. Ich denke aber wir sind uns einig das das ARB eben etwas langsamer ist weil es aufgrund der Extension Option ja auch nicht so wirklich den Druck gibt eine schnelle Einigung herbei zu führen.

Ja, das stimmt. Und weil sie ja alles im Core lassen muessen. Das mit den Extensions ist IMHO mehr evolutionaer und DX halt mehr planerisch. Ich persoenlich finde HLSL(Cg) ziemlich haesslich an manchen Stellen. zB die Varyings sind sehr krude implementiert. Aber ich programmiere auch gern in Python, wenn es sich ergibt. Da achtet man halt gern auf die "Schoenheit" des Codes. :-)

[marco42]

Noise zum Beispiel. Aber mit HLSL kann man ja auch Programme schreiben die Syntaktisch korrekt sind aber mit keinen Profile kompilert werden können. Im Prinzip ist es ja auch richtig das Shaderhochsprache nicht mit jeder neuen Hardware generation nachgebessert werden müssen.

Wird HLSL eigentlich in der neuen Schnittstelle Bestandteil des Treibers, so dass es keine Profile mehr gibt?

[Demirug]

Wenn du diesem
link (http://www.khronos.org/collada/presentations/collada_siggraph2005.pdf)
folgst, wirst du sehen, dass sie ein API planen, wofuer das gut ist, hab ich nicht gelesen, sah fuer mich eher wie ein XML Parser aus. Ich wollte damit nur zeigen, dass im OpenGL Bereich in letzter Zeit eine Menge passiert. Spiele sind halt nicht alles und bevor Techniken in Spielen eingesetzt werden, findet man sie in Papern(SIGGRAPH). OpenGL ist hier immer noch das 3D API.

Scheinbar haben sie jetzt den Reader wirklich zur API erklärt.

"Das 3D API" gibt es meiner Ansicht nach nicht. Jede hat ihere Stärken und schwächen.


Ja, das stimmt. Und weil sie ja alles im Core lassen muessen. Das mit den Extensions ist IMHO mehr evolutionaer und DX halt mehr planerisch. Ich persoenlich finde HLSL(Cg) ziemlich haesslich an manchen Stellen. zB die Varyings sind sehr krude implementiert. Aber ich programmiere auch gern in Python, wenn es sich ergibt. Da achtet man halt gern auf die "Schoenheit" des Codes. :-)

Es gab mal den Versuch ein OpenGL 2.0 Pure durchzusetzten und sich damit von enigen Altlasten zu trennen. Bei OpenGL ES 2.0 hat man das ja durchgezogen.

[Demirug]

Wird HLSL eigentlich in der neuen Schnittstelle Bestandteil des Treibers, so dass es keine Profile mehr gibt?

So war es zumindestens auf dem letzten Vortrag zu WGF 2.0 den ich gesehen habe noch. Im Gegenzug muss der Treiber aber auch jeden Syntaktisch korrekten Shader ausführen.

[Corrail]

Sorry für OT, aber wo f inde ich gute Ressourcen für Collada? Die C++ API oder so?

[Gast]

Hallo,

ich finde OpenGL ist um einiges einfacher zu proggen. Ist jedenfalls mein subjektiver Eindruck. DirektX ist mir ein bischen zu kompliziert.

Falls OT, Sorry
Hab auch das Gefühl, daß jedenfalls die Demoszene eher an OpenGL hängt. Und die Demos funzen trotz den angeblichen Extensionswirwarr zu 99.9% auf dem Cat genauso wie auf dem Forceware.