Zukunft von OpenGL

[Controller Khan]

Sowohl ATI und Nvidia unterstützen OpenGL 3.0 vollständig. Jetzt noch auf Snow Leopard warten und der Verbreitung von OpenGL steht nichts mehr im Wege. :)
Sorry war ein Fehler von mir. Dann ist es wahrscheinlich Bloom.


Nvidia:

http://developer.nvidia.com/object/opengl_3_driver.html


ATI:

http://www2.ati.com/drivers/linux/catalyst_91_linux.pdf
https://a248.e.akamai.net/f/674/9206/0/www2.ati.com/gamesite/Catalyst_91_release_notes.pdf

Angesichts der Fehler und Support des Ati Linux Treibern bringt das unter Linux wenig. Bleibt nur Nvidia für OpenGL unter Linux.

Bei Intel und den OSS-Treiber wird gerade das Fundament für GLSL gelegt.

=> Für die paar Linux Nvidia User machen sich wenige den Aufwand werden OpenGl zu verwenden.

=> Direct3D verwenden und nicht-Windows User auf Wine etc verwenden.


Liegt denke ich daran, dass die Xbox 360 auf DX9 basiert und kein DX10 kann, und Windows XP noch die Oberhand behält. Da lohnt es sich einfach nicht, für DX10 zu programmieren.


PC/Konsolen only Spiele sind ja echte Mangelware geworden.


Aber wie du schon sagst, solang es unter Mac OS X und X11 (Linux, ...) keine Alternativen gibt, kommt man um OpenGL nicht herum.


Leider ist es so. EA portiert die Games auf den Mac ja mit Cider (Wine-Derviat). Die Performance kann man ausmalen.

Mangels Middleware und Entwickler Support seitens Apple wird das nicht besser werden.

[Gast]

Leider ist es so. EA portiert die Games auf den Mac ja mit Cider (Wine-Derviat). Die Performance kann man ausmalen.

Mangels Middleware und Entwickler Support seitens Apple wird das nicht besser werden.Man sollte bzw. muß das auch nicht aus der reinen Spielersicht betrachten. So langsam sind die [u]Anwendungen[u/] die auf OpenGL setzen weder unter OSX noch unter Linux noch unter Unixen.

Wenn man vom Anfang an damit loslegt ist das auch auf Winpcs alles andere als lahm oder Effektarm. Man darf nicht vergeßen daß mindestens bis 2008 die meisten großen Szenedemos in OpenGL waren. Sowas wird schon seine Gründe haben.

[Gast]

Liegt denke ich daran, dass die Xbox 360 auf DX9 basiert und kein DX10 kann, und Windows XP noch die Oberhand behält. Da lohnt es sich einfach nicht, für DX10 zu programmierenNatürlich wird es schon so sein. Ich meinte das nur wegen den manigfaltigen Gründen die soetwas haben kann. Die pure technische Sicht wie wir sie hier pflegen ist nicht immer ausschalggebend. Wenn man das real betrachten möchte darf man sich nicht immer nur an den technischen Features aufgeilen ;)

Und darf es auch nicht am Support von ATI messen. Wer nicht will der hat schon.

[lumines]

Liegt denke ich daran, dass die Xbox 360 auf DX9 basiert und kein DX10 kann,[...]

DX wird doch afaik sowieso nicht auf der 360 benutzt.

[Demirug]

DX wird doch afaik sowieso nicht auf der 360 benutzt.

Natürlich wird es benutzt. Das DX der XBox 360 ist nur in Teilen etwas Hardware näher.

[Exxtreme]

Unixoide haben keine andere Wahl als das Zeug weiter zu verbessern. man war auf den quasi Bankrott von SGI leider nicht wirklich vorbereitet. Ob sich das auf WinPCs durchsetzt das bezweifle ich auch sehr stark, aber ausgerottet wird es wohl nie ;) Das ist auch besser so. Sich zu etablieren reicht schon seit etlichen Jahren und wird auch in der Zukunft ausreichen.

Es gibt extrem starke Interessangruppen die OpenGL nicht verkommen lassen werden. Übrigens, DX10 hat sich übrigens nach 3 Jahren noch nicht durchgesetzt ;)
Mich wundert eher, daß die Opensourc'ler selbst nichts auf die Beine stellen wollen. Normalerweise sind sie immer irgendwo dabei. Bei einem 3D-Grafik-API hingegen...

Die sollten soch selbst sehen, daß Khronos nix auf die Reihe kriegt.

[Coda]

Die können da gar nichts machen. OpenGL muss im Treiber implementiert werden, und da haben einfach nur ATI und NVIDIA die nötigen Resourcen/Wissen um konkurrenzfähiges zu programmieren.

[Exxtreme]

Ich meine jetzt was komplett Neues. Weder OpenGL noch Direct3D. Bei Direct3D bekommt man u.U. Probleme mit Patenten und bei OpenGL auch wegen Khronos. Klar müssten AMD und NV mitziehen.

[Coda]

Es wurde doch mit OpenGL 3.0 etwas neues vorgeschlagen, was ziemlich gut aussah - hat nur niemand interessiert.

[DaBrain]

Interessiert schon... nur kam mit OpenGL 3.0 einfach nich das, was vorher noch so "gut aussah".

Und ich kann mir wirklich nicht vorstellen, dass AMD und Nvidia hier gepennt haben.

[Gast]

Ich meine jetzt was komplett Neues. Weder OpenGL noch Direct3D. Bei Direct3D bekommt man u.U. Probleme mit Patenten und bei OpenGL auch wegen Khronos. Klar müssten AMD und NV mitziehen.Sollte doch klar sein. Beide wollenn sich mit MS nicht verscherzen. Es reicht doch nur, daß MS mitbekommt, daß ATI bei NV zuerst nachfragt, ob sie sich diesbezüglich nicht stärker gemeinsam engagieren können und schon steht für mich fest welcher Chip in der folgenden XBox werkeln wird.

Diese Typen sind einfach die Seuche. Ich will nicht wissen wo wir heute technologisch schon wären, wenn sie nicht überall ihre Krallen drin hätten.

[lumines]

Natürlich wird es benutzt. Das DX der XBox 360 ist nur in Teilen etwas Hardware näher.

dann hab ich das wohl falsch verstanden. meinte jedenfalls irgendjemand hier im thread.

[Exxtreme]

Sollte doch klar sein. Beide wollenn sich mit MS nicht verscherzen. Es reicht doch nur, daß MS mitbekommt, daß ATI bei NV zuerst nachfragt, ob sie sich diesbezüglich nicht stärker gemeinsam engagieren können und schon steht für mich fest welcher Chip in der folgenden XBox werkeln wird.

Diese Typen sind einfach die Seuche. Ich will nicht wissen wo wir heute technologisch schon wären, wenn sie nicht überall ihre Krallen drin hätten.
Als ob MS was zu melden hätte bei derartigen Entscheidungen. ;)

Ich würde dir recht geben wenn es schon so ein API gäbe und sich AMD/NV weigern würden Treiber zu bringen. Aber ausser OpenGL und Direct3D gibt es leider nichts weit und breit. Und es ist durchaus ein Wunder, daß die Opensource-Fritzen wirklich Null Initiative in diese Richtung zeigen. Denn OpenGL in der derzeitigen Verfassung ist kein zufriedenstellender Zustand.

[_DrillSarge]I[]

Und es ist durchaus ein Wunder, daß die Opensource-Fritzen wirklich Null Initiative in diese Richtung zeigen.
schau dir doch mal die grafikabteilung unter linux an - Xorg - X-D
baustelle

[Coda]

Sollte doch klar sein. Beide wollenn sich mit MS nicht verscherzen. Es reicht doch nur, daß MS mitbekommt, daß ATI bei NV zuerst nachfragt, ob sie sich diesbezüglich nicht stärker gemeinsam engagieren können und schon steht für mich fest welcher Chip in der folgenden XBox werkeln wird.
Die Entscheidung wurde vom ARB gefällt, und da ist Microsoft schon lange nicht mehr Mitglied.

Diejenigen die geblockt haben waren Autodesk und Konsorten.

[Exxtreme]

I[;7184300']schau dir doch mal die grafikabteilung unter linux an - Xorg - X-D
baustelle
Wobei Xorg sogar noch geht. Das kämpft aber wiederum mit anderen Problemen, welche aber eher auf die Ideologie einiger Opensource-Gurus zurückzuführen sind.

[Gast]

Denn OpenGL in der derzeitigen Verfassung ist kein zufriedenstellender Zustand.Aus welcher Sicht? OSX hat kein Kummer damit. auf vielen unixoiden Desktops sieht es nicht anders aus. Wobei da sowas eben nicht in dem Masse gebraucht wird wie unter Linux. Außer jetzt GPU für Compiz unter Linux.

Viele von den Sachen bei welchen wir uns hier unter DX9/DX10 einen ... ist nicht wirklich relevant unter OpenGL. Wie auch immer man das wirtschaftlich gegenüber Winpc hin und her rechnen mag, was das profesionelle Ergebnis angeht ist unter OpenGL genauso "alles" möglich. Was man auch gelegentlich hier und da in Echtzeit bewundern kann.

Irgendwie ähnlich wie zwischen XPsp3 und VistaSP1 seinerzeit. So ein wunderbarer moderner Kernel bei Vista. Und? Es gibt nicht ein RL-Lastszenario bei dem man signifikante Vorteile feststellen kann.

Wobei ich damit nicht sagen will daß OpenGL3 schon total toll so ist wie es ist :usweet: Die brennenden Bäume sehe ich da aber noch nicht. Nichtsdestotrotz sollten sie in Zukunft wohl nicht mehr so verfahren wie bis jetzt.

@Coda
Was hat Autodesk mit welcher Argumentation geblockt?

[Controller Khan]

Die Entscheidung wurde vom ARB gefällt, und da ist Microsoft schon lange nicht mehr Mitglied.

Diejenigen die geblockt haben waren Autodesk und Konsorten.

Macht irgendwie keine Sinn; wenden die einiges an Ressourcen fürs Testen von OpenGl Treibern auf ?

Wobei Xorg sogar noch geht. Das kämpft aber wiederum mit anderen Problemen, welche aber eher auf die Ideologie einiger Opensource-Gurus zurückzuführen sind.

Im Linux/Unix Lager wird mit Servern Geld gemacht. Red Hat ist mit der GNU Toolchain / Linux Kernel geschäftigt. Novell mehr mit Mono & Co.

An X.org arbeiten verglichen zu Nvidia/Ati Treibern kaum Leute.

Nvidia hat bei professionellen *nix Usern sowieso ein Monopol, und die sind zufrieden damit.

[dust]

Paul Martz hat ein paar interessante sachen auf lager!

http://www.skew-matrix.com/bb/viewtopic.php?f=3&t=2&sid=f8c13badb04333f7e064fbab1a17c7c2
Conclusion

To summarize, there are no feature or performance difference between OpenGL and D3D. Porting to a new API with no feature or performance benefit has a prohibitive cost.

D3D runs on one platform, OpenGL runs on several. OpenGL drivers are probably more robust, because building and testing on multiple platforms uncovers issues that might not be found in a homogenous environment.

End users shouldn’t fear installing OpenGL device drivers, just as they fearlessly click OK when prompted to install, for example, Adobe Flash Player.

Graphics hardware vendors should create a mechanism to install OpenGL device drivers automatically.

Microsoft should eliminate D3D development and add full support for OpenGL to future operating systems.

The debate between D3D and OpenGL has gone on longer than any API war I’ve witnessed. I’m not going to delude myself into believing that this blog makes any significant difference in that debate. All I can do is tell you how I see it, as someone who has developed 3D software for over 20 years, long before either API existed.

OpenGL 3.1 Released at GDC, March 2009
http://www.skew-matrix.com/bb/viewtopic.php?f=3&t=4
If OpenGL 3.0 failed to impress you, it’s time to take a look at OpenGL 3.1.

Pitchforks and Torches

OpenGL 3.0’s unveiling at the SIGGRAPH 2007 OpenGL BOF was greeted with profound excitement. After all, the dramatic new object model interface was simple and clean, and the removal of outmoded and inefficient commands and concepts marked the first break with backwards compatibility for the 15-year old API. OpenGL’s future looked bright.

In the months that followed, the reality of a compatibility break started to set in. The OpenGL ARB (the Khronos working group responsible for the OpenGL specification) realized that software vendors who are unable to immediately port to the new API would be stuck without new features for possibly years.

And while the reality of modern graphics hardware and device driver development required the new design promised at SIGGRAPH 2007, perhaps a sudden design change wasn’t the way to meet that goal. In the past, new features were only promoted to core functionality after testing and vetting as extensions. New paradigms introduced directly into core would risk requiring radical adjustments and tweaks down the road.

The ARB needed to satisfy both software vendors and cutting-edge developers, and a break with compatibility and paradigm shift, though initially appealing, was looking like a losing proposition all around.

The reworked OpenGL 3.0 unveiled at the SIGGRAPH 2008 OpenGL BOF satisfied the needs of both software vendors and cutting-edge developers. However, it bore little resemblance to the OpenGL 3.0 promised a year earlier. There was no compatibility break, no bold new object model interface. The final OpenGL 3.0 was completely backwards compatible with OpenGL 2.1. To the casual observer, there didn’t appear to be anything new here. A vocal few in the graphics community were disappointed to the point of anger, wielding pitchforks and torches to destroy the monster, jokingly labeling it “OpenGL 2.2”.

Hidden in the final OpenGL 3.0 specification were a couple of critical and important new features that failed to receive the attention they deserved. These features form the basis of an elegant and graceful paradigm shift that simultaneously allows access to state-of-the-art hardware and continues to meet the needs of software vendors with 1.x/2.x applications.

The Deprecation Model

The deprecation model is a design mechanism to allow OpenGL to eventually remove outdated features and commands. In concept, this innovative feature is the reverse of the extension mechanism. Core features are first marked as deprecated, then moved to an ARB extension, then eventually to an EXT or vendor extension, or removed entirely. The OpenGL 3.0 specification marks several features as deprecated, including the venerable glBegin/glEnd mechanism, display lists, matrix and attribute stacks, and the portion of the fixed function pipe subsumed by shaders (lighting, fog, texture mapping, and texture coordinate generation).

Many developers might be tempted to ignore the fact that a feature has been marked deprecated. After all, deprecated features will be available in the future via an extension. However, the ARB marks features as deprecated (and eventually removes them from the OpenGL core) for a reason. They are often the least efficient ways to perform a task, and OpenGL provides newer mechanisms that enhance performance. Furthermore, the new features available on cutting-edge hardware, which the ARB actively adds to the evolving OpenGL 3.x specification, might be incompatible with old deprecated functionality.

Forward-Compatible Contexts

The OpenGL 3.0 specification also introduces the concept of a forward-compatible context. Applications that explicitly create a forward-compatible context lose all deprecated functionality, allowing developers to have confidence that their applications will function with future revisions of the specification. Think of the OpenGL 3.0 forward-compatible context as early access to OpenGL 3.1, like getting into a time machine and emerging nine months into the future.

Minus the features removed in 3.0, OpenGL is a leaner, more flexible and empowering API. Enabling OpenGL’s flexibility is its set of new features that broaden the tools for data storage and access in shaders. Features such as integer and half-float texture formats, depth textures, host data mapping, floating-point color buffers, and packed depth/stencil formats allow shaders to perform high-fidelity rendering and GPGPU tasks.

One of the most notable new features is the promotion of framebuffer objects (FBOs) to the core feature set. FBOs have matured as an extension for some time now. As a core feature, they are a full-featured platform-independent offscreen rendering solution with support for multisample, packed depth/stencil, and blit operations.

Revision 1.30 of the OpenGL Shading Language (GLSL) accompanied OpenGL 3.0’s release, and it follows the OpenGL deprecation model. Predefined variables are deprecated if their OpenGL analogues are deprecated. For example, the gl_projection and gl_modelview predefined uniforms don’t exist in GLSL 1.30. New features added in GLSL 1.30 include native integer support, switch statements, explicit texture LOD control, and several new built-in functions.

If you’ve never had the opportunity to develop with an OpenGL 3.0 forward-compatible context, you can still do so with current hardware and drivers from AMD/ATI, NVIDIA, and S3. Or you can use OpenGL 3.1.

OpenGL 3.1: Shaders Take the Front Seat

Programmable graphics hardware is now the norm, and the graphics API requirements to support it are clear. The API must enable both high-end rendering and GPGPU through programmable control and efficient data access. Announced at GDC in March 2009, OpenGL 3.1 addresses these needs with new state-of-the-art features.

Anyone who has written a shader-based application has undoubtedly found it tedious to send more than a small handful of individual uniform variables to the hardware. More complex shaders require a more efficient mechanism to swap large groups of uniform variables. OpenGL 3.1 addresses this need with the new uniform buffer object ARB extension, which allows applications to group together heterogeneous uniforms and enable or disable them with a single bind command. You can share buffer objects between different program objects, and update uniforms within the block of data using the existing buffer object API (glMapBufferRange, glBufferData, etc.).

OpenGL 3.1 includes enhancements to the copy buffer API to efficiently copy data between buffer objects. It also adds the primitive restart feature to efficiently draw meshes using triangle strips, a key piece of functionality if you want to take advantage of the vertex cache available on most modern graphics hardware.

OpenGL 3.1 also adds instanced rendering, which lets applications render multiple instances of a single group of primitives using an instance ID accessible from the vertex shader. The shaders have complete control over each instance’s appearance and orientation. Because the host only issues a single draw command, instanced rendering performs at the limits of the hardware and your shaders. (OpenSceneGraph 2.8 contains support for OpenGL’s draw instanced feature.)

Also unveiled at GDC, GLSL 1.40 supports OpenGL 3.1’s new features, such as the uniform buffer object extension and instanced rendering. It also supports texture rectangle. Long available as an extension, texture rectangle is now part of the OpenGL 3.1 / GLSL 1.40 core feature set, allowing applications to access textures with non-normalized texture coordinates. This feature allows shaders to cleanly and easily retrieve specific texels from texture maps.

OpenGL 3.1 provides additional support for GPGPU by allowing buffer data transfers between OpenGL and OpenCL. Applications that store data on the GPU can easily copy data between OpenGL buffer and texture objects and the analogous OpenCL buffer and image objects. This API interoperability allows applications to use the API of their choice to tackle the compute problem at hand and enables efficient GPU-based visualization of OpenCL computation results.

This Is Not Your Father’s OpenGL

I hope you weren’t using glRect or color index mode.

OpenGL 3.1 uses the deprecation model to streamline the API and remove features for the first time in its 17-year history. It is OpenGL 3.0’s forward-compatible context cast in concrete. Everything marked as deprecated in OpenGL 3.0 was removed from the OpenGL 3.1 core (including glRect and color index mode—no one was using them anyway).

Based on my experience with the 3.0 forward-compatible context, developing with OpenGL 3.1 will be a rush. There are no matrix stacks, no modelview or projection matrices. The glNormalPointer, glTexCoordPointer, and even the glVertexPointer commands are gone. What you have left is a lean and mean, completely configurable interface for efficiently sending data to the graphics hardware. At first, it’s terrifying. All your old crutches are gone. But you quickly learn to use OpenGL’s new programmability and data access features to transmit and operate on only the data you need. You are unshackled from the API rules, and supplied with a set of empowering tools. It’s a freeing and altogether exhilarating sensation.

OpenGL continues to support software vendors with large extant code bases. OpenGL 3.1 features the GL_ARB_compatibility extension, which restores the old OpenGL 1.x/2.x functionality removed in OpenGL 3.1. Additionally, several OpenGL 3.x features are now available as ARB extensions in OpenGL 2.1. This eases the task of porting large applications away from the fixed function pipeline.

Conclusion

OpenGL is continuing to move toward the buffer model described at SIGGRAPH 2007. But in many ways, the new OpenGL 3.1 is a better API.

I’ve been an OpenGL developer since the early days. I wrote a book, OpenGL Distilled, and I’m even a fringe member of the ARB working group. You could make a good case that I’m a tad biased. However, as a programmer who has gained objectivity through years of experience, I know a well-designed API when I see it, and OpenGL 3.1 looks as clean, simple, straightforward, lightweight, and empowering as the original OpenGL 1.0 did 17 years ago.

As the blogosphere samples and digests OpenGL 3.1, you’ll see a variety of comments. Some will say OpenGL 3.1 is all about feature deprecation. Others will say it’s about new features that allow access to modern hardware and enable shader-based rendering and GPGPU. Both are valid viewpoints. But OpenGL 3.1 is about more than that. It’s about doing both of those things at the same time.

A few years after OpenGL 1.0 hit the streets in 1992, OpenGL 1.1 was released with that cool new vertex array feature, and OpenGL developers quickly became accustomed to seeing new functionality in every OpenGL release while continuing to maintain backward compatibility.

Inevitably, scraping off the accumulated barnacles from the OpenGL API hull became a necessity. To move forward, old features had to be removed. Many other APIs, graphics or otherwise, both past and present, have either ignored this issue or simply broken backward compatibility. These are the easy choices, you either support your existing user base at the expense of new features, or you drop the old features and force existing applications to port.

The OpenGL ARB chose to address feature obsolescence in a bold new way that demonstrates a commitment to both existing users and continued API evolution. I don’t know of any other API that has managed to do this.

The graceful and innovative deprecation model, combined with a proven track record of support for modern GPU development, shows that OpenGL is ready to tackle the graphics programming challenges of the next 17 years.

und noch ein statement von ihm
Interoperability (in terms of being able to copy data directly between
analogous OpenGL and OpenCL buffers) is a feature of the new OpenGL 3.1.

und die specs
This is the OpenGL 3.1 spec, with all 3.0-deprecated features removed.
http://www.opengl.org/registry/doc/glspec31.20090324.pdf

This is a version of the 3.1 spec that includes the finctionality of the
GL_ARB_compatibility extension, as if the features had never been removed.
http://www.opengl.org/registry/doc/glspec31undep.20090324.pdf

This is the GLSL 1.40 spec.
http://www.opengl.org/registry/doc/GLSLangSpec.Full.1.40.05.pdf

opengl wächst und gedeiht also. :deal:

[Coda]

Jo, und hinkt D3D damit immer noch 2 Jahre hinterher. :uclap:

Was er da in den Himmel lobt, ist eine schlichte Kopie von dessen was mit Version 10 dort eingeführt wurde.

Mal ganz abgesehen davon, dass das mit den "robusteren Treibern" einfach nur gelogen ist.

[dust]

ich glaube paul martz aber bei weitem mehr als dir, da liegen welten dazwischen...

[Coda]

Ganz ehrlich: Dann stirb einfach dumm. Wir sind hier in einem Technikforen, da regieren Fakten und nicht was du glaubst.

[ScottManDeath]

Wer ist eigentlich Paul Martz?

[Demirug]

Ich fürchte der Präsident einer Firma die auf OpenGL und OpenSceneGraph Dienstleistungen spezialisiert ist dürfte ein wenig voreingenommen sein.

Da verlasse ich mich doch lieber auf Aussagen von Firmen/Leuten die beides einsetzen.

[dust]

na dann beug dich den fakten die jemand geschrieben hat der über 20 jahre in der 3d branche erfolgreich arbeitet.
I’ve been an OpenGL developer since the early days. I wrote a book, OpenGL Distilled, and I’m even a fringe member of the ARB working group. You could make a good case that I’m a tad biased. However, as a programmer who has gained objectivity through years of experience, I know a well-designed API when I see it, and OpenGL 3.1 looks as clean, simple, straightforward, lightweight, and empowering as the original OpenGL 1.0 did 17 years ago.

All I can do is tell you how I see it, as someone who has developed 3D software for over 20 years, long before either API existed.

[Coda]

Das ist schön für ihn, macht sein eindeutig eingefärbtes Geschreibsel aber auch nicht wertvoller.

Faktum ist z.B: Instancing gibt es in D3D seit 9 (!) und er redet davon so als wäre es eine bahnbrechende Neuerung.

[robbitop]

Aber immerhin mal nach langer Zeit ein Fortschritt bei OpenGL. Blöd nur, dass es bei D3D bald wieder einen großen Schritt nach vorn gibt. Für Spiele wird es anscheinend Stück für Stück eh immer unwichtiger.

[Coda]

Es scheint wieder in Fahrt zu kommen, ich denke zusammen mit OpenCL wird es D3D11 lange nicht so weit hinterherhinken wie bisher D3D10.

Die API-Konzeption ist bei D3D11 ja auch größtenteils unverändert geblieben.

[DR.ZEISSLER]

Für Spiele wird es anscheinend Stück für Stück eh immer unwichtiger.

das bedarf einer kurzen erläutung.
zielt d3d auf die profi-anwendungen ab ? cad oder filmindustrie ?

[robbitop]

das bedarf einer kurzen erläutung.
zielt d3d auf die profi-anwendungen ab ? cad oder filmindustrie ?
OpenGL zielt darauf ab. Der Bedarf ist dadurch breiter gefächert als bei D3D und es sitzen wohl auch daraus resultierend zu viele Leute mit zu vielen Interessen an Board.

[Coda]

Weder OpenGL noch Direct3D zielen von der API auf irgendetwas ab, sondern bilden nur die Architektur der Grafikkarte nach außen ab.

Es ist falsch, dass OpenGL besser für Anwendungen oder Direct3D besser für Spiele geeignet ist. Beide sind für alles gleich gut oder schlecht verwendbar.

[Exxtreme]

das bedarf einer kurzen erläutung.
zielt d3d auf die profi-anwendungen ab ? cad oder filmindustrie ?
Nein. Aber du kannst das für diese Zwecke auch problemlos verwenden wenn dich die Gebundenheit an Windows nicht stört.

[Gast]

Kleine Schritte, aber immerhin:

Khronos Releases Streamlined OpenGL 3.1 Specification (http://www.khronos.org/news/press/releases/khronos-releases-streamlined-opengl-3.1-specification/)

[dust]

andere argumente von anderen leuten die sich auskennen
Go read the specs the OpenGL specs. Direct3D doesn't anything like
extension has had from it's inception, and nothing like deprecation
mechanism that OpenGL 3.0 has.

With OpenGL you can migrate steadily from one rev to the next, an
application written back in 1992 is still runable today, if you your
application lives any period of time - like successful software does then
longivity is good thing. Also with long lived successful software people
wanted it ported to new platforms as the industry evolves, and again OpenGL
comes to support you again with it's unique feature of portability.

Please reflect on the fact that the OSG itself is a decade old, and it's
migrated from OpenGL 1.1 to OpenGL 2.1 + latest extensions without any major
rewrite. Not only has it be pretty straight forward for us to roll in new
support for new hardware features, but we've also been able to port any
desktop/workstation out there.

Go try that trick with Direct3D.... Erhhh DirectX10 is only available under
Vista. Too hard to port to WinXP? No just MS playing games manipulating the
marking. Now Vista only has ablout 15% of the desktop market, shame that
the rest of the 85% ain't and won't ever be server by DirectX10. Um...
which is backwards and years behind serving the needs of industry? OpenGL
which covers 100% of the availabe platforms, or Direct3D??

Time to stop sucking up the MS cool-aid there kid as it seems to have eroded
your ability to think about the wider needs of the graphics industry.


http://store.steampowered.com/hwsurvey
Steam Hardware Survey

24,75% dx10 system, dx10 gpu and vista
27,28% dx10 gpu on xp
27,60% dx9 sm 2b & 3.0
7,25 dx9 sm2 gpu
13,12 dx8 gpu and below

also welches d3d soll ein spiele entwickler jetzt verwenden?

[Coda]

Was redest du eigentlich "von sich auskennen". Im Gegensatz zu dir führen wir hier (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=450968) schon seine produktive Diskussion über 3.1 ohne dein Bla-bla.

Und ja, ich kenne den Steam-Survey, und nein, ich würde OpenGL trotzdem nicht anfassen wollen ;)

[Exxtreme]

andere argumente von anderen leuten die sich auskennen
Go read the specs the OpenGL specs. Direct3D doesn't anything like
extension has had from it's inception, and nothing like deprecation
mechanism that OpenGL 3.0 has.
Tja, das ist Absicht da MS verhindern will, daß es nachher ein Extension-Wirrwarr gibt wo man für jeden Hardwarehersteller und Betriebssystemversion extra Code schreiben muss.


Go try that trick with Direct3D.... Erhhh DirectX10 is only available under
Vista. Too hard to port to WinXP? No just MS playing games manipulating the
marking. Now Vista only has ablout 15% of the desktop market, shame that
the rest of the 85% ain't and won't ever be server by DirectX10. Um...
which is backwards and years behind serving the needs of industry? OpenGL
which covers 100% of the availabe platforms, or Direct3D??
Da bin ich gespannt ob es OpenGL 3.1-Applikationen geben wird, die unter Windows 3.1 laufen werden. Laut diesem Absatz sollte das eigentlich möglich sein.
http://store.steampowered.com/hwsurvey
Steam Hardware Survey

24,75% dx10 system, dx10 gpu and vista
27,28% dx10 gpu on xp
27,60% dx9 sm 2b & 3.0
7,25 dx9 sm2 gpu
13,12 dx8 gpu and below

also welches d3d soll ein spiele entwickler jetzt verwenden?
Gegenfrage, welches OpenGL + welche Extensions + welches Betriebssystem darf es sein?

[Gast]

...Da bin ich gespannt ob es OpenGL 3.1-Applikationen geben wird, die unter Windows 3.1 laufen werden...

Windows 3.1 is ein bisschen übertrieben ;)

[Exxtreme]

Windows 3.1 is ein bisschen übertrieben ;)
100% sind 100%. :D

Wenn man sich so weit aus dem Fenster lehnt dann sollte das auch einhaltbar sein. OK, nehmen wir mal ein anderes Betriebssystem, welches neuer ist: OS/2 Warp. :D

[Tesseract]

Da bin ich gespannt ob es OpenGL 3.1-Applikationen geben wird, die unter Windows 3.1 laufen werden. Laut diesem Absatz sollte das eigentlich möglich sein.

schlechter vergleich weil windows 3.1 im gegensatz zu windows xp schon lange tot ist.
du wirst aber keine großen probleme haben OGL-3.1-programme auf XP zum laufen zu bringen.

und wenn du seine aussage nur auf den OGL-teil des programms beziehst und window-routinen usw. mal ausklammerst stimmt das sogar. besonders bei unixoiden systemen die ihre grundarchitektur seit jahrzehnten kaum verändert haben.

kurz gesagt: wie weiter- und wiederverwendbarkeit ist enorm groß.

[albix64]

Da bin ich gespannt ob es OpenGL 3.1-Applikationen geben wird, die unter Windows 3.1 laufen werden. Laut diesem Absatz sollte das eigentlich möglich sein.
Wenn du die Hardwarehersteller dazu überredest, entsprechende Treiber für das OS zu programmieren, sollte das kein Problem sein.

[Ectoplasma]

Wenn du die Hardwarehersteller dazu überredest, entsprechende Treiber für das OS zu programmieren, sollte das kein Problem sein.

Setzt OpenGL nicht wenigstens ein 32-Bit OS voraus? Mit OS2 Warp also kein Problem denke ich. Mit dem 16-bittigen Win 3.1 glaube ich schon. Oder meintest du Windows NT 3.1?

[Coda]

Für die Buffer-Objects wird das auf jeden Fall nötig sein.

[Exxtreme]

Wenn du die Hardwarehersteller dazu überredest, entsprechende Treiber für das OS zu programmieren, sollte das kein Problem sein.
Genau daran wird es eben scheitern. :D

Mag sein, daß das ganze Gebilde in der Theorie funktioniert. Es wird aber in der Praxis definitiv scheitern. Und einen ganz anderen Eindruck erweckt der Autor. Sorry, für mich ist das Bauernfängerei.

[ScottManDeath]

Soviel zum Thema CAD und OpenGL ;)

http://www.solidsmack.com/solidworks-opengl-direct3d-gpu-comparison-cad/2008-09-01/

[Gast]

Also jetzt klotzen sie doch noch kleinwenig ;)

Keine "Welten" aber sie haben den Kompatibilitätsspagat endlich annehmbar hinbekommen. somit können sie jetzt ab 3.1 machen was sie wollen. Alte Zöpfe werden weder abgeschnitten noch stören sie. Wie DX9 unter Vista.

http://winfuture.de/news,46119.html

[Gast]

24,75% dx10 system, dx10 gpu and vista
27,28% dx10 gpu on xp
27,60% dx9 sm 2b & 3.0
7,25 dx9 sm2 gpu
13,12 dx8 gpu and below

also welches d3d soll ein spiele entwickler jetzt verwenden?Jetzt? DX9 wie bis jetzt. Wo ist das Problem? Rennt doch alles bestens.

[Gast]

Soviel zum Thema CAD und OpenGL ;)

http://www.solidsmack.com/solidworks-opengl-direct3d-gpu-comparison-cad/2008-09-01/So schlau war ich auch schon. Ich hab das letztens mit einer 4670 und Cat 8.10 versucht. Die Soft wollte aufs Verrecken nicht ohne hier und da zu flackern. Was den Mitarbeiter so nervte daß er auch mich nervte. Den Hersteller nervte es nicht. Mit der Konfig nicht getestet. Nichtmal interessenshalber. Haben auch so genug zu tun.

Dann kam eine V5600 rein. Die Software läuft Sahne, der Mitarbeiter strahlt. Ich hab im Namne der Firma ;) für den RV630 GL / 512MB / 128bit 370€ ausgegeben. Was solls? Es läuft sauschnell, es läuft leise, es läuft zuverlässig. Mehr brauchen unsere CAD/CAM Arbeitsplätze auch in 5 Jahren nicht.

[dust]

http://www.heise.de/newsticker/Noch-ein-Standard-fuer-3D-Inhalte-im-Web-Update--/meldung/135201
Noch ein Standard für 3D-Inhalte im Web
Noch ist unklar, wie die kommende "Accelerated 3D"-Schnittstelle arbeiten wird. Die Arbeitsgruppe soll mehrere Ansätze untersuchen, eine der Ideen besteht darin, Attribute von OpenGL (bei Desktop-Rechnern, Net- und Notebooks) beziehungsweise OpenGL ES 2.0 (bei Handys, Smartphones oder etwa kommenden ARM-Netbooks) über ECMAScript zugänglich zu machen, also letztlich via JavaScript.

"Mit zunehmender Performance positioniert sich JavaScript als taugliche Programmiersprache für Applikationstypen, die zurzeit in C und C++ geschrieben werden", heißt es in der Khronos-Pressemitteilung dazu. Hervorgehoben wird auch das Potenzial der Verschmelzung von OpenGL- und OpenGL-ES-Funktionen für Web-Anwendungen.

Fraglich ist aber, ob ein zusätzlicher Standard für 3D-Web-Inhalte deren Verbreitung tatsächlich fördert, denn eigentlich herrscht diesbezüglich kein Standard-Mangel: Bereits 2001 hat das Web3D-Konsortium X3D als Nachfolger des noch viel älteren VRML verabschiedet, seit 2004 ist X3D ein ISO-Standard. Browser-Plug-ins für X3D beziehungsweise VRML sind ebenfalls verfügbar; manche nutzen 3D-GPUs via OpenGL oder DirectX aus.

mal schauen was daraus wird, opengl im internet.

[albix64]

Dann kam eine V5600 rein. Die Software läuft Sahne, der Mitarbeiter strahlt. Ich hab im Namne der Firma ;) für den RV630 GL / 512MB / 128bit 370€ ausgegeben. Was solls? Es läuft sauschnell, es läuft leise, es läuft zuverlässig. Mehr brauchen unsere CAD/CAM Arbeitsplätze auch in 5 Jahren nicht.
Wie soll denn das gehen? Es wird doch bei beiden die gleiche Treiberbasis verwendet, oder? Oder verwendet ATI für die FireGL/FirePro etwa fehlerfreie Treiber? :|

[Gast]

Die Profikarten haben eben nicht genau den gleichen Treibercode, das ist ja der Witz an der Sache ;)

[Exxtreme]

Wie soll denn das gehen? Es wird doch bei beiden die gleiche Treiberbasis verwendet, oder? Oder verwendet ATI für die FireGL/FirePro etwa fehlerfreie Treiber? :|
Ob die Treiber "fehlerfrei" sind oder nicht, das steht in den Sternen. Die FireGL-Treiber haben für die gängigsten CAD-Programme spezielle Profile. Wird so ein Programm geladen dann interpretiert der Treiber die Aufrufe anders.

Da es für OpenGL keine Kompatibilitätstestsuite gibt, müssen sich der CAD-Softwarehersteller und die Treiberprogrammierer zusammen tun und gucken, daß das funktioniert. Das entfällt bei Direct3D halt da MS eine Testsuite hat.

[dust]

http://www.xreal-project.net/wordpress/

Features

XreaL is based on a heavily modified IOQuake 3 engine. Some of the new features are listed here:

* access to the OpenGL driver through a new interface designed like OpenGL ES 2.0 with additional support for OpenGL 3.1
* clever usage of vertex buffer objects (VBO) to speed up rendering of everything
* avoids geometry processing at render time using the CPU (worst bottleneck with the Q3A engine)
* renders up to 500 000 - 700 000 polygons at 50-60 fps on current hardware
* GPU accelerated skeletal animation system that outperforms all current CPU based implementations
* Doom 3 .MD5mesh/.MD5anim skeletal model and animation support
* Unreal Actor X .PSK/.PSA skeletal model and animation support
* true HDR directional light mapping with adaptive tone mapping
* projective and omni-directional soft shadow mapping methods like VSM and ESM
* optional deferred shading
* relief mapping that can be enabled by materials
* optional uniform lighting and shadowing model like in Doom 3 including globe mapping
* supports almost all Doom 3 material shader keywords
* usage of frame buffer objects (FBO) to perform offscreen rendering effects
* improved TrueType font support that does not require external tools
* replaced Gladiator bot by the Quake2 ACEBot with waypoints navigation
* customized XreaLRadiant level editor based on DarkRadiant
* advanced XMap2 map compiler based on the popular Q3Map2 compiler by Randy ydnar Reddig

http://www.phoronix.com/scan.php?page=article&item=xreal_engine&num=1
XreaL: The Most Advanced Open-Source Game Engine?

das erste spiel mit opengl 3.1 support.

achja, sie suchen artists!

[Stebs]

Dann spiele ich mal den Totengräber EDIT: mit der Aufgabe der Exhumierung :wink:
(Der Thread ist aber selbst schuld, mit so einem Titel wird er wohl nie in Freiden ruhen...)

On Topic: Die Jungs rund um die Unigine machen weiter Dampf, ihre Engine hat nun OpenGL 3.2 Support (neben DX11): http://unigine.com/devlog/71/
OpenGL 3.2 support
Recent changes:

* Support of OpenGL 3.2 (MSAA on scattering and SSAO; support of signed textures for normal maps).
...

Was glaubt ihr, ob diesmal auch zeitgleich mit den Nvidia GF100 (aka G300) Karten dann OpenGL-Treiber mit Extensions für die D3D11-Spezializäten kommen? Also z.B. für (DX11-Level) Tesselation etc.
Tesselation (wenn auch nicht DX11-Level) ist unter OpenGL nur auf Ati-Karten machbar (logisch, bis jetzt hatten nur Karten von Ati solche Hardware).
PS. Ob ich DX11 oder D3D11 schreibe (was ist korrekter, viele Devs schreiben selbst DX11 im Bezug auf Grafik), gemeint sind hier immer die 3D Teile von DX11.

[Gast]

Mal eine kurze Frage:
Der 3.2 Kram ist prinzipiell auch mit älteren OpenGL Versionen möglich, hat nur den Nachteil, dass es kompliziert wird und man dann auf proprietäre Extensions ausweichen muss, was eigentlich nicht im Sinne von OpenGL ist?