OpenGL versie 1.5 aangekondigd

Op de site van SGI is een aankondiging geplaatst van OpenGL 1.5, naar eigen zeggen de belangrijkste release sinds de originele versie elf jaar geleden werd opgesteld. De grootste verbetering is het toevoegen van de OpenGL Shading Language. Het programmeren van een modere GPU gebeurt namelijk met een vorm van assembler. Voor kleine programma's is dit geen probleem, maar nu de chips steeds grotere en complexere shaders gaan ondersteunen wordt het een steeds lastiger en tijdrovender karwei. Dit wordt nu opgelost door een taal op een hoger niveau te introduceren, waardoor het makkelijker wordt om gebruik te maken van de nieuwste features.

Hoewel dit idee als revolutionair bestempeld wordt, werd de eerste implementatie van de voor hetzelfde doel ontwikkelde ontwikkelde HLSL-standaard in juni vorig jaar al gepresenteerd in de vorm van nVidia Cg. Deze taal is samen met Microsoft ontwikkeld en dus primair gericht op de DirectX API, maar hij is daarnaast ook gewoon te gebruiken voor de ontwikkeling van OpenGL-shaders. Hoewel nVidia wel deel uit maakt van de groep die de OpenGL-standaard onderhoudt, is niet duidelijk in hoeverre de talen onderling compatible zijn. Uit oudere bronnen kunnen we echter opmaken dat Microsoft - dat eerder dit jaar uit de ontwikkelgroep stapte - en nVidia hun taal in eigen beheer willen houden:

The OpenGL 1.5 specification evolved with input from the OpenGL ARB-an independent consortium-and interested participants to reflect predominant trends in the graphics industry. The ARB's process of enhancing OpenGL includes jointly developing specifications of features proposed by ARB members, to be incorporated and officially supported within the API. In OpenGL 1.5, several additional features and functions have been ratified, including the following:

• Vertex Buffer Object: vertex arrays for higher performance rendering
  
• Shadow Function: additional comparison functions for shadow mapping
  
• Occlusion Query: asynchronous occlusion test for better culling
  
• Non power-of-two Textures: for more efficient use of texture memory, including mipmaps
  
• OpenGL Shading Language v. 1.0: as official extensions more specifically, shader objects, vertex shaders, and fragment shaders, all for use of programmable shader hardware .

"The continuing evolution and advancement of the OpenGL API is important to network computing and graphic applications," said Manish Bhuptani, director, Market Development, Sun Microsystems, Inc. "With Sun's commitment to open, standards-based technologies, we are excited to see this new specification and believe that it will lead to exciting changes in how people develop and use visual applications"

Reacties (60)

Ik zat eigenlijk te wachten op OpenGL 2.0, maar de tussenrelease 1.5 was wel nodig om DirectX bij te houden. Maakt trouwens geen hond uit welke grafische kaart je net gekocht hebt, OpenGL (of DirectX) ondersteuning is een kwestie van drivers; beide grote producenten updaten hun drivers regelmatig dus gewoon even in de gaten houden wie het eerst 1.5 ondersteund.

Overigens is het grote voordeel van OpenGL dat het een industrie-standaard is, niet een MicroSoft-standaard, daarbij is de API van OpenGL veel helderder en flexibeler. OpenGL kent het concept van extensies (de welbekende ARB's bijvoorbeeld) waardoor over het algemeen nieuwe functionaliteit veel sneller in OpenGL zit dan DirectX, in ARB-vorm bestaat dat hele HLSL al een flinke tijd bijvoorbeeld.

DirectX heeft te maken met releaseschedules waardoor enkel al vanwege marketing redenen niet elke maand de nieuwste features beschikbaar zijn. NVidia ziet het belang van OpenGL zelf ook in, ze hebben niet voor niets enkele kopstukken (zoals Mark Kilkegard) uit de OpenGL wereld in dienst.

Overigens zijn shadertalen absoluut niet nieuw te noemen; professionele raytracers e.d. kennen het concept al vele, vele jaren. Het verschil is de hardwareimplimentatie.

klopt, opengl is beter van opzet dan directx, echter het grote voordeel van directx tov opengl is dat het zoveel simpeler is om voor te programmeren, en dat is jammer want directx is puur windows, terwijl opengl games simpel te porten zijn naar linux en bijv mac, zoals quake 3

Welk van de twee het beste te programmeren is, daar kan je flamewars mee beginnen (kijk er maar eens een spelprogrammeurs-site op na )! De één geeft de voorkeur aan DirectX, de ander OpenGL, allemaal erg subjectief dus.
Het belangrijkste verschil is performance (DX is sneller) versus compatibility (OGL werkt op zowat elk platform), welk vind je het belangrijkst?
Tuurlijk, er zijn projecten die de DX API om OGL heen plakken zodat je DX calls kan doen op elk willekeurige platform dat OGL ondersteund, maar dan verlies je het grote pluspunt van DX; de snelheid.

Nah Dankjewel. Dit is een antwoord op mijn vraag. De Doom-reeks heeft trouwens altijd wel zwaar geleund op OpenGl. Ben benieuwd welke kaarten ( nu en in de nabije toekomst) hier het meest geschikst voor zullen zijn.

De Doom-reeks heeft trouwens altijd wel zwaar geleund op OpenGl.

Eerder de Q3 engine .

Eerder de Q3 engine

En de Quake 1 en Quake II engines (QuakeGL anyone?)

het grote verschil tussen OpenGL / DX is dat DX op een iets hoger niveau kan werken - ie er worden veel technieken die je in OpenGL zelf zou moeten maken al opgelost. Maar ook erg low-level calls kan die aan. OpenGL is en blijft wat het altijd is geweest een triangle-pusher, en DX is meer een volwaardige 3D API. (note OpenGL == C, DX = C++). Beide hebben voordelen maar het grootste is dat OpenGL zowat overal werkt zolang het een scherm heeft.

Wat vaak over het hoofd wordt gezien is het volgende:

OpenGL = Graphics
DirectX = Graphics, Input, Sound & nog wat minder interessante zaken

OpenGL moet dus eigenlijk NOOIT vergeleken worden met DirectX. OpenGL moet je vergelijken met Direct3D(de Graphics API van DirectX).

Direct3D heeft inderdaad wat meer hulp middeltjes(matrices wordt uitstekend ondersteund bv, iets wat bij OpenGL wat minder ondersteund wordt). Maar er zijn voor OpenGL voldoende library's te vinden die een soort gelijke support bieden, het wordt alleen niet standaard meegeleverd.

Om OpenGL zomaar een simpele tris-pusher te noemen vindt ik erg gewaagd, en vooral door erna te zeggen dat DirectX(je bedoelt Direct3D) meer volwaardig is als API. Indrukwekkende games zijn gemaakt met OpenGL, en dus volwaardig is het zeker. DirectX in zijn geheel is nog maar recentelijk volwassen. Tot DX8(beetje DX7) stelde het eigelijk weinig voor.

Zowel OpenGL als DirectX zijn in C en in C++ te gebruiken. OpenGL is gebasseerd op function calls, en DirectXis gebasseerd op COM.

Cross-platform is inderdaad een pre aan de kant van OpenGL. Dit wordt ook vaak als sterkste punt genoemd van OpenGL, maar dan vraag ik je het volgende: Hoeveel PC games worden er daadwerkelijk geport naar bv Linux? Loki-games is ten ziele, andere serieuze partijen ken ik niet. Het grappige is dat Wine bezig is met het porten van DirectX. Er zijn al bepaalde spelletjes die de DirectX gebruiken en op Linux onder Wine draaien Het enige voordeel wat er dan nog overblijft is niet-games, wat imho een kleiner voordeel is dan er algemeen ons door diverse mensen wordt voorgehouden.

OpenGL of DirectX(Direct3D)?

Voor gamers: boeit niet
Voor game developers: persoonlijke smaak. De 1 vindt OpenGL makkelijker in gebruik/fijner werken, de ander DirectX(Direct3D).

Denk aan UT2k3, Neverwinter Nights, ET etc. Opzich niet schrikbarend veel nee, maar het is wel zo dat hoe meer games OpenGL gebruiken, hoe meer games er op non-windows OS'en zullen verschijnen.

Ik heb wel een vraagje: Wat is nu precies het voordeel van OpenGL tegenover DirectX (voor de gamer, niet voor de developer). Moet ik denken aan betere beeldkwaliteit of meer fps?

geen voordeel. Mja, hooguit scheelt het 70mb downloaden(directx).

Qua kwaliteit of snelheid maakt het niks uit. Er zijn mensen die menen dat er wel verschil is. Dat is er niet! Ook al worden er hele stapels met 'bewijzen' geleverd, het is en blijft een gevoel van die mensen.

Er is tussen developers(voornamelijk de amateurs) van games wel wat ruzie gemaakt welke de beste is. De strijd is onbeslist, en zal ook onbeslist blijven. Het maakt gewoon niet uit.

Jammer, OpenGL-programma's maken (onder Windows) nog altijd gebruik van DirectDraw, dus je zult nog steeds DirectX moeten downloaden.

Pardon??????

Mag ik vragen hoe je aan deze wijsheid komt? En dan graag met een linkje erbij. En geen www.WeThinkItWorksLikeThis.com achtige websites...

Op dat punt zit je dus helemaal fout

OpenGL communiceert direct met de graphics hardware:

Under Windows, OpenGL provides an alternative to using the Graphics Device Interface (GDI). GDI architects designed it to make the graphics hardware entirely invisible to Windows programmers. This provides layers of abstraction that help programmers avoid dealing with device-specific issues. However, GDI is intended for use with applications and thus lacks the speed required for games. OpenGL allows you to bypass GDI entirely and deal directly with graphics hardware.

(bron: www.developer.com/tech/article.php/947051)

Voor de gebruiker maakt het niet zo heel veel uit of de applicatie DirectX of OpenGL gebruikt.
Alleen als je bijvoorbeeld Linux gebruikt is het prettiger dat er OpenGL word gebruikt, omdat je dan meer kans hebt dat je de applicatie met Wine kunt draaien (Half-Life bijv.).
De beeldkwaliteit is volgens mij even hoog, dus dat maakt niet uit.
Verder is voor de developer een voordeel dat als je je progje wil porten naar een ander OS je minder werkt hebt van het grafische gedeelte.

OpenGl is puur een taal om 3D data op je scherm te knallen. En de meeste 3D-videokaarten ondersteunen openGL.

DirectX is een taal, die naast het grafish deel ook, veel ondersteuning bied aan andere factoren zoals geluid, joysticks etc. Voor een game developer dus wel handig.

Bij een aantal games (of bijv. shockwave3D) heb je de optie om te kiezen tussen directX(versie x,y) en openGL En je kan het verschil vaak zien oa. in fps en rendering.

(Als developer heb ik op windows met de opensource 'gcc' en sdl www.libsdl.org openGL software geschreven, en zonder de code te veranderen dit ook kunnen compileren op linux.)

Hmmm, ik denk niet dat je OpenGL en DirectX moet defineren als een taal. Het is en blijft een API. En een API is een set functies die toegang biedt tot een ondergelegen 'iets'. En dat 'iets' kan zijn een driver(geluidskaart, video kaart etc) of een stukje software(zoals windows bv, de bekende Windows API). API staat voor Application Programming Interface. Wat gewoon inhoud dat er 1 interface is waar je als programmeur tegen aan werkt, en dat de API de juiste calls verzorgt in het onderliggende verhaal.

SDL combineert dus eigenlijk het beste van OpenGL (platform-onafhankelijkheid) met het beste van DirectX (een complete API, ook voor geluid, input, enz.). Delen ervan zijn in assembler geschreven, zodat het ook erg snel is.

HET voordeel voor de gamer van opengl is het gebruiksgemak(hoewel vaak directx met een game wordt meegeleverd) en de crossplatform mogelijkheid.

stel dat jij een mac hebt...nou veel succes met directx games, een opengl game is moeiteloos te porten, zelfde als voor linux. dat moet de developer dan wel doen maargoed de mogelijkheid is er wel, en het werkt dan ook nog goed

Zoals al gezegd maakt het voor de gamer niks uit. Het verschil zit hem niet in de API. Dit is gewoon een manier voor de programeur om van zijn programmatje naar het scherm te komen. De verschillen in fps /eyecandy heeft meer met de programeur dan met de api's te maken.

En nu de ham-vraag : Hoe is de compatibiliteit met de huidig verkrijgbare DX9 kaarten ?

Of eerder: heb je eigenlijk nog wel wat aan OpenGL? DirectX heeft regelmatig updates met vertex shaders, bump mapping, you name it. Kan OpenGL dat eigenlijk wel bijhouden?

Heeft OpenGL eigenlijk nog voordelen, behalve dat het open is, en dus ook op linux kan draaien enzo. Het schijnt dat het ietwat sneller is dan DirectX, maar zijn er daar ook benchmarks van?

Heeft OpenGL eigenlijk nog voordelen, behalve dat het open is, en dus ook op linux kan draaien enzo. Het schijnt dat het ietwat sneller is dan DirectX, maar zijn er daar ook benchmarks van?

ik zal je een klein voorbeeld geven: OpenGL is zo krachtig dat Hollywood 't gebruikt om SFX te maken. (de matrix films hebben bijvoorbeeld hun SFX te danken aan OpenGL en een FreeBSD render farm)

't is sneller dan DirectX, maar da's nog geen doorslaggevend argument (misschien voor echte die hard gamers wel), maar vooral MOOIER.

ik zal nou niet direct beweren dat DirectX lelijk is, integendeel. Maar als ik de grafische kwaliteit bekijk van de Unreal Tournament 2003 demo onder Windows (directX rendering) of onder Linux (OpenGL rendering) dan zit ik toch net iets liever onder Linux te spelen dan onder Windows.

Wie zegt dat OpenGL perse op hardware moet worden gemapped? OpenGL is een API. Of het resultaat nu met 100fps naar het beeldscherm wordt gestuurd, of met .001fps naar de HD maakt niks uit. Waarom zou de 'plaatje genererende programmatuur' er ook anders uitzien? Alleen het output device is anders (en natuurlijk de randvoorwaarden. voor beeld telt fps, terwijl voor prerender juist de kwaliteit geld. Daar maakt het niet uit of het filmpje met 0.0001 fps draait omdat dit toch pas later achter elkaar gezet wordt.)

OpenGL wordt dus weldegelijk gebruikt voor het resultaat en niet alleen de previews.


edit nav ppro:

Een Application Programming Interface is niks anders dan een afspraak over hoe iets aan te spreken en wat daar het resultaat van zou moeten zijn. In die api staat bijvoorbeeld een 'teken een driehoek op positie x met afmeting y'. Of dit nu door een dikke GeForce word gedaan of door een kabouter met een potlood maakt voor de API niks uit. Een opmerking als "OpenGL kan wel in software, maar dat is niet snel en niet flexibel, daarom mag je aannemen dat als er OpenGL gebruikt, dat het icm hardware is." is, naast onwaar, ook een heel erg vreemde oorzaak gevolg conclussie. Waarom zou OpenGL minder flexibel worden waneer het software gebruikt? Het is dan juist meer flexibel aangezien je dan geen last meer hebt van de beperkingen van de Hardware! OpenGL, zoals eerder aangegeven, juist heel flexibel door de extensions structuur. Tuurlijk kan OpenGL wel raytracing. Sterker nog, de nieuwe windowmanager van Apple werkt met OpenGL (om maar ff wat flexibelheid aan te geven).

Je zal als ontwikkelaar maar compleet vanaf scratch een 3d applicatie van die renderfarm moeten ontwikkelen. Veel makkelijker is het om juist een gedistribnueerd rendersysteem gebaseerd op OpenGL te maken. Je maakt dus een 'achterkant' aan de OpenGL standaard. Dat is precies hetzelfde als een driver schrijven, maar in plaats van het mappen van OpenGL functies op hardware calls wordt er nu een stukje gerendert op de framebuffer in het werkgeheugen.

Op die manier hoeft een andere (of dezelfde) ontwikkelaar voor zijn render applicatie alleen maar OpenGL te kennen en eventueel de extenties die die specifieke renderfarm implementatie gebruikt.

Het is duidelijk te merken dat tweakers.net een hardware site is. Van software (development) hebben veel mensen hier weinig kaas gegeten. Om het dus ook ff voor de hardware mensen duidelijk te maken: Op een renderfarm wordt gewoon een GeForce 9000 of ATI 15000 gesimuleert met een OpenGL driver die van elk gerenderde frame een screenshotje naar de schijf stuurt.

Als ik iets doms zeg moet je het maar zeggen, maar ik denk dat de belangrijktse reden dat in films als de Matrix de SFX gerenderd zijn in openGL met freeBSD renderfarms meer te maken heeft met het realiseren van de renderfarms (lijkt me niet voor de hand liggen om Windows renderfarms te bouwen) dan met OpenGL op zich.

't is sneller dan DirectX, maar da's nog geen doorslaggevend argument (misschien voor echte die hard gamers wel), maar vooral MOOIER.

Dat is onzin, ze draaien allebei op dezelfde hardware. Een videokaart wordt niet ineens mooier of sneller als je een andere API gebruikt.
Beide APIs zijn prima in staat om de hardware snel aan te sturen, en de maximale image-quality eruit te toveren, mits goed gebruikt.

Verder wordt het renderen voorzover ik weet nog steeds in software gedaan (vandaar dat je er zo'n grote farm voor nodig hebt), omdat daarmee hogere kwaliteit te behalen is door hogere precisie, en het gebruik van raytracing (dingen die de OpenGL API dus niet ondersteunt, Janoz. OpenGL kan wel in software, maar dat is niet snel en niet flexibel, daarom mag je aannemen dat als er OpenGL gebruikt, dat het icm hardware is). OpenGL zal waarschijnlijk in de modelers worden gebruikt, en voor snelle previews, niet voor het eindresultaat.

Oh, en voor de mensen die bang zijn dat ze een nieuwe videokaart moeten kopen: OpenGL 1.5 houdt in feite niet meer in dan een driver-update.
De features zitten al in de hardware (D3D ondersteunde ze immers grotendeels al, en ook proprietary de OpenGL extensies). OpenGL 1.5 is gewoon een API-update die de features op een uniforme manier aan de programmeur aanbiedt, alleen software dus. Binnenkort zullen er nieuwe videokaart-drivers uitkomen, en die zullen gewoon OpenGL 1.5 ondersteunen, en klaar.

Een Application Programming Interface is niks anders dan een afspraak over hoe iets aan te spreken en wat daar het resultaat van zou moeten zijn. In die api staat bijvoorbeeld een 'teken een driehoek op positie x met afmeting y'.

Hier zeg je zelf al waarom het niet flexibel is.
De API legt een bepaald rendermodel vast. In het geval van OpenGL zit je al vast aan triangles en blendmodes, of hooguit fragment programs.
Dingen als raytracen gaan in OpenGL heel lastig worden, support voor volumes is er sowieso al niet, dus volume caustics ed kun je wel vergeten.

Tuurlijk kan OpenGL wel raytracing. Sterker nog, de nieuwe windowmanager van Apple werkt met OpenGL (om maar ff wat flexibelheid aan te geven).

Wat heeft een windowmanager nou met raytracing te maken?
Ik zeg ook niet dat OpenGL raytracing onmogelijk maakt, maar het is wel heel lastig... Sowieso werk je liever niet met rauwe triangles in een raytracer, want dat is niet efficient. Subdivision surfaces bv zijn veel aantrekkelijker. Maar OpenGL heeft daar geen support voor.

Je maakt dus een 'achterkant' aan de OpenGL standaard.

Dat is bijna net zoveel werk als ook de 'voorkant', want zo boeiend is de OGL-interface zelf niet. Verder ben je nu afhankelijk van die 'voorkant', waardoor het dus niet flexibel is, want die is puur gericht op het direct renderen van triangles, iets waar hardware overigens erg goed in is.

Het is duidelijk te merken dat tweakers.net een hardware site is. Van software (development) hebben veel mensen hier weinig kaas gegeten.

Wel ff dimmen, ik ben toevallig zelf 3d developer, ik schrijf ook software voor dit soort 'special cases'. Software renderers, raytracers ed. En D3D en OGL heb ik ook vaak genoeg gebruikt. En ik ben vast niet de enige hier die software developer is.

Om het dus ook ff voor de hardware mensen duidelijk te maken: Op een renderfarm wordt gewoon een GeForce 9000 of ATI 15000 gesimuleert met een OpenGL driver die van elk gerenderde frame een screenshotje naar de schijf stuurt.

Onzin. Op zich zou het mogelijk zijn, maar dat is niet hoe het werkt. Je kunt het beter uitleggen als '3dsmax (of je eigen favoriete renderer) in het groot'.
Een modeler-interface (meestal via OpenGL, soms ook software of D3D) waarmee je de modellen maakt, en daarna een custom offline-renderer. Meestal is dit een hybride rasterizer die de eerste bounce direct als triangles tekent, en de rest via raytracing voor reflectie en refractie (ook iets wat je niet goed in OpenGL kunt doen, alleen envmap-hacks, maar dat is niet goed genoeg voor films).
Daarna post-processing (ook weer zoiets dat lastig is in OpenGL, je hebt alleen maar render-to-texture, leg mij eens uit hoe je een recursieve radial-blur doet?), en dan opslaan op disk.

Het heeft weinig met een 3d accelerator te maken, efficiente en kwalitatief goede raytracing is met het huidige hardware-model onmogelijk, en dit zal in de nabije toekomst niet veranderen.
Er wordt wel een alternatieve raytrace-chip ontwikkeld trouwens, zie www.saarcor.de, maar ook deze gebruikt geen OpenGL-interface, wederom omdat dat niet handig is. Daarom is OpenRT ontwikkeld.

Om een lang verhaal kort te maken: een 3d accelerator werkt heel anders dan een fotorealistische renderer. Daarom is het niet handig om een 3d accelerator in software te emuleren, en via een realtime-3d aan te sturen. Het is veel handiger om een eigen systeem te maken (vaak zit daar een C-achtige shadertaal in, voor die ontwikkelaars die jij al noemde). We zien dan ook de trend dat 3d hardware evolueert naar fotorealistisch renderen toe, en niet andersom, zoals jij probeert uit te leggen.

Hier zeg je zelf al waarom het niet flexibel is.
De API legt een bepaald rendermodel vast. In het geval van OpenGL zit je al vast aan triangles en blendmodes, of hooguit fragment programs.
Dingen als raytracen gaan in OpenGL heel lastig worden, support voor volumes is er sowieso al niet, dus volume caustics ed kun je wel vergeten.

Voor realtime applicaties kan ik me dat voorstellen (geen volumes) maar daarvoor zou je een extensie kunnen schrijven. Ik zelf heb voor een project een (medische) volume renderer moeten schrijven (word over enkele dagen geshowed in Barcelona) en het zit er misschien niet standaard in, maar dat betekend niet dat je het niet kun maken.

Wat heeft een windowmanager nou met raytracing te maken?

Dat zijn twee loststaande opmerkingen die idd verkeerd gelezen kunnen worden. Ik bedoel het meer als 'je kunt zelfs een windowmanager maken die OpenGL gebruikt' om aan te geven dat het niet alleen een polypusherapi is.

Subdivision surfaces bv zijn veel aantrekkelijker. Maar OpenGL heeft daar geen support voor.

Dat is nog geen reden om het voor de rest helemaal niet te gebruiken.

Dat is bijna net zoveel werk als ook de 'voorkant', want zo boeiend is de OGL-interface zelf niet. Verder ben je nu afhankelijk van die 'voorkant', waardoor het dus niet flexibel is, want die is puur gericht op het direct renderen van triangles, iets waar hardware overigens erg goed in is.

Klopt dat het net zo veel werk is (waarschijnlijk nog wel meer), maar door die tussenstap heb je gelijk een aansluitingspunt voor een heleboel andere applicaties. Hierdoor heb je voor je systeem gelijk een enorme berg 3rd party tools beschikbaar.

Wel ff dimmen, ik ben toevallig zelf 3d developer, ik schrijf ook software voor dit soort 'special cases'.

Dat was niet specifiek tegen jou bedoeld, maar meer als algemene reactie op wat voor reacties ik hier zie. Ik geef idd toe dat het op deze manier nogal persoonlijk lijkt waarvoor mijn excusses.


Het 3D accelerator verhaal wat ik daar neer heb gezet is meer een 'kort door de bocht uitleg'. Vooral omdat veel mensen hier denken dat OpenGL op een chipje staat oid. Ik weet zelf ook wel welke kant het op gaat . En wie zegt trouwens dat de nextnextnextgen kaarten nog steeds met surface fitting werken ?

het zit er misschien niet standaard in, maar dat betekend niet dat je het niet kun maken.

Je kunt ook een nieuwe snelweg aanleggen die van Rotterdam via Tokio naar Amsterdam gaat. Maar waarom neem je niet de makkelijke weg?

Ik bedoel het meer als 'je kunt zelfs een windowmanager maken die OpenGL gebruikt' om aan te geven dat het niet alleen een polypusherapi is.

Ook niet als je nagaat dat die windows in feite gewoon getextureerde quads zijn, dus polys?

Dat is nog geen reden om het voor de rest helemaal niet te gebruiken.

De geometrie lijkt me toch wel het allerbelangrijkste. Zonder geometrie valt er niets te renderen. En zonder efficient georganiseerde geometrie valt er niet snel te renderen. Jij lijkt het nut van OpenGL boven het nut van het renderen te plaatsen, het is nou net andersom

door die tussenstap heb je gelijk een aansluitingspunt voor een heleboel andere applicaties. Hierdoor heb je voor je systeem gelijk een enorme berg 3rd party tools beschikbaar.

Daar heb je geen drol aan. Renderfarm-software is niet bepaald in bergen beschikbaar. Bovendien moet je maar net iets kunnen vinden wat op jouw renderfarm hardware/software draait, en doet wat jij wil.
Dat is er dus niet, en daarom ontwikkelen bedrijven als Pixar hun eigen software (en sowieso is er het punt van "wij zijn beter dan jullie", dus iedereen wil/moet met betere software komen, daar haal je ook je geld mee binnen, het is je visitekaartje).

En wie zegt trouwens dat de nextnextnextgen kaarten nog steeds met surface fitting werken

Daar gaat het niet om. Ik weet ook wel dat we uiteindelijk ofwel hybride-hardware krijgen, of pure raytracing. De vraag is echter: wie zegt dat die hardware nog steeds via OpenGL aangestuurd wordt?
Wat we wel weten iig is dat die hardware nu nog niet bestaat, en dat OpenGL daar nu nog niet geschikt voor is. En dat het daarom ook niet handig is om OpenGL nu te gaan gebruiken, en dan in feite er een hele hybrid-renderer omheen te gaan bouwen.
Je bent beter af zonder OpenGL. Bovendien is bij de meeste graphics-software de gebruikte API nog wel van het minste belang. Er zit relatief weinig code in die direct met de graphics-API communiceert (dit is ook een aardig argument tegen het belang van portability en het nut van OpenGL daarin. Doom 3 is een leuk voorbeeld, er komt ook een XBoX versie uit die op D3D draait).

Je kunt ook een nieuwe snelweg aanleggen die van Rotterdam via Tokio naar Amsterdam gaat. Maar waarom neem je niet de makkelijke weg?

Het ene sluit het andere niet uit. In OpenGL kun je ook rechtstreeks bij de verschillende framebuffers. Zoals ik eerder al aangaf kun je ook een extentie schrijven.

Ook niet als je nagaat dat die windows in feite gewoon getextureerde quads zijn, dus polys?

Klopt, maar een window manager is meer dan vierkanten tekenen. Wat ik maar aan wil geven is dat OpenGL helemaal niet een beperking hoeft te wezen, maar gewoon een toolset is die je een berg functionaliteit aanbied die je kunt gebruiken of waar je langs heen kunt werken.

De geometrie lijkt me toch wel het allerbelangrijkste. Zonder geometrie valt er niets te renderen. En zonder efficient georganiseerde geometrie valt er niet snel te renderen. Jij lijkt het nut van OpenGL boven het nut van het renderen te plaatsen, het is nou net andersom

Er is in OpenGL sowieso geen efficiente geometrie structuur geimplementeerd, dit zul je dus sowieso zelf moeten doen. Maar waarom zou je dan gelijk ook maar niet bv de matrix stack gebruiken? Zoals ik eerder ook al zei, het sluit elkaar niet uit. Door OpenGL te gebruiken leg je jezelf niet plots allerlei beperkingen op.

In OpenGL kun je ook rechtstreeks bij de verschillende framebuffers. Zoals ik eerder al aangaf kun je ook een extentie schrijven.

Welke framebuffers? We hebben het hier over een offline-renderfarm. Die renderen niet naar een framebuffer op een videokaartje. Die gebruiken een gedistribueerd systeem (wat OpenGL niet ondersteunt), waar iedere CPU een onderdeel van de scene rendert, en dat doet ie in een float danwel double precision framebuffer (wat OpenGL niet ondersteunt). Een framebuffer in software implementeren is trouwens kinderlijk eenvoudig. Arraytje alloceren en klaar, daar kan OpenGL niet tegenop.
Je hebt gewoon niets met OpenGL te maken. En ik zou niet weten waarom je dat zou willen. Het heeft geen nut. Als je een extensie voor OpenGL zou schrijven, zou je toch eerst OpenGL zelf moeten implementeren voor je renderfarm 'device'. En dan die extensie... En dan blijkt dat je eigenlijk 99% van de tijd ALLEEN die extensie gebruikt. Wat moet je in godsnaam dan nog met OpenGL?

Wat ik maar aan wil geven is dat OpenGL helemaal niet een beperking hoeft te wezen, maar gewoon een toolset is die je een berg functionaliteit aanbied die je kunt gebruiken of waar je langs heen kunt werken.

Het originele punt was dat The Matrix met OpenGL gerenderd zou zijn... En nu wil je adhv een windowmanager laten zien dat dat heel goed mogelijk is ofzo?

Er is in OpenGL sowieso geen efficiente
geometrie structuur geimplementeerd, dit zul je dus sowieso zelf moeten doen.

Okee, dus ik heb niets aan OpenGL. Want ik implementeer dan bv NURBS, en die ga ik raytracen... Waar heb ik OpenGL dan nog voor nodig? Hooguit voor previews, maar dat hadden we al lang gezegd hierboven.

Maar waarom zou je dan gelijk ook maar niet bv de matrix stack gebruiken? Zoals ik eerder ook al zei, het sluit elkaar niet uit. Door OpenGL te gebruiken leg je jezelf niet plots allerlei beperkingen op.

Poe, een matrix stack, daar zit ik echt op te wachten... Ik moet een hele distributed software hybrid renderer implementeren, maar ik kan de OpenGL matrix stack gebruiken!
Woei, dat scheelt me weer 10 minuten coden! Nog maar 983284903 uur te gaan!
Punt is WEL dat OpenGL beperkingen oplegt. Daar kun je dan wel omheen werken met uitbreidingen etc... Maar waarom zou je OpenGL gebruiken? Het heeft praktisch geen nut, dus je doet jezelf ook niet tekort door het niet te gebruiken.

Ik dacht dat OpenGL juist meer up-to-date was dan DirectX omdat er continue van die extensies voor verschenen (die helaas wel weer kaart-specifiek zijn, zoals de NV_-extensies voor de nvidia kaarten). Ik weet dit niet 100% zeker, maar meende zoiets gelezen te hebben.

En verder is het meer een manier van programmeren. OpengL werkt qua programmeren weer ietsje anders dan DirectX. Ik geloof dat oudere versies van DirectX lastiger en omslachtiger waren om te programmeren, maar dat schjnt (geloof ik?) inmiddels wel ingehaald te zijn en verbeterd te zijn.

euhm het word onwijs veel gebruikt in profi applicaties, maar ook in spellen dus openGL is nog lang niet uitgefaseerd..

DirectX werkt alleen op windows (officieel gesupport) en is geoptimaliseerd voor game-development. Alle andere mensen gebruiken openGL. Dit is ook de reden dat het langzamer gaat. Miscrosoft hoeft alleen rekening te houden met zichzelf. Bovendien moet je onderscheid maken tussen 'directX, de specificatie' en 'directX, de API'.

heeft het dus voordelen? ja, want het werkt namelijk overal. Dat games makkelijker ontwikkeld worden in directX is een gemis van de openGL dev kit, niet de specificatie

Dan krijg je van mij de kaas erbij...

Ten eerste heeft DX9 niks met openGL te maken, en ten tweede is het zoals bij elke nieuwe versie van DX. Je zal er een nieuwe kaart voor moeten kopen om er volledig gebruik van te kunnen maken.

Al is het bij OpenGL iets minder omdat ze meer in de software oplossen. Maar je zal denk ik toch een nieuwe kaart nodig hebben.

Valt wel een beetje mee. Alleen nieuwe drivers die de mogenlijkheden van je kaart mapt op de mogenlijkheden van OpenGL.

Ehm,

Wazig dat ze nu 1.5 uitbrengen, terwijl iedereen zit te wachten op 2.0

Naar mijn idee hadden ze beter even kunnen wachten... Al kan ik nergens vinden wanneer 2.0 wordt verwacht, ik weet alleen dat er vele mensen op zitten te wachten.

ach, het is maar een nummertje.
Zelfde discussie kun je voeren over of Linux 2.6 niet 3.0 had moeten heten...maakt het feitenlijk wat uit? Volgens mij niet.

Mja, het nummertje interesseert me ook geen ruk. Waar het meer om gaat is dat iedereen zit te wachten op de features die aangekondigd zijn voor 2.0. Misschien is dit een teken dat 2.0 nog wat langer op zich laat wachten

zou er nu op korte termijn een OpenGL update komen van Apple voor OSX? Of is het wachten op Panther?

Op zich is Apple meestal wel up to date met OpenGL, maar ik denk dat 1.5 pas met Panther komt. Als ik het goed begrijp hebben ze alleen de specificaties aangekondigd, het implementeren zal misschien wat tijd kosten.

Ik kan het mishebben, maar worden OpenGL spellen niet sneller naar consoles geport dan DirectX/Direct3D games?

Dan zou het nl nog een voordeel zijn voor de developers om OpenGL te gebruiken. Niet alleen porten naar non-Windows OS'en, maar ook de consolemarkt en die is toch aanzienlijk te noemen.

Op de XBOX draaien spellen onder DirectX, en aangezien MS de xbox koste wat het kost de grootste wil laten zijn(zal ze ook wel lukken, zucht) zou je misschien zelfs wel kunnen stellen dat het interessanter is om spellen met DirectX te ontwikkelen omdat je dan later makkelijk naar DE console(xbox) kan porten...

Laten we ondertussen maar hopen dat de Playstation/Gamecube etc etc voldoende weerstand zal bieden

De peetvaders van de CG Industrie Alias|Wavefront weigeren directX te gebruiken en prefereren openGL zwaar boven directX om verscheidene redenen.

Ik denk dat dit meer dan genoeg zegt.


Het vreemde is wel dat directX meer aanhang heeft gekregen.
Naar mijn mening komt dit omdat de gamesindustrie aan het "ver-newbien" is.
Jan en alle-man zet tegenwoordig een gamesbedrijf op en omdat het maken van een game een ware kunst is en erg moeilijk is kiest jan liever voor directX, omdat dat dat bijv. ook geluid geintegreerd heeft en dan hoeft jan niet zijn eigen sound engine te schrijven.

DirectX is feature-rich zoals ze het noemen, maar is slechts een API voor de massa.
Microsoft popt nieuwe versies van DX uit alsof het broodjes worst v/d Hema zijn.
openGL daarentegen doet dat heel zelden en alleen als er echt revolutionaire en goed doordachte implementaties kunnen worden verwezenlijkt die de graphics industrie bij de wortel verbeteren.

Pro gosu guru's zoals John Carmack houden zich ook niet met directX bezig.
openGL is het serieuze werk.
Het kennen v/d openGL API geeft je ook meer en beter inzicht in de 3D CG industrie en is eigenlijk 1 van de fundamenten waar de industrie op rust en waardoor het groot is geworden.

Geef mij eens een uitspraak van 1 van de figuren die jij noemt waarin ze duidelijk en onderbouwt aangeven dat DirectX niks is...

En dat Carmack alleen OpenGL doet: al zijn kennis is daarop gebasseerd. Hij heeft eerder geen zin om te ontwikkelen met DirectX of zijn persoonlijke voorkeur gaat uit naar OpenGL. Tevens is mijn persoonlijke mening dat Carmack een grote mond heeft, waardoor ik aan zijn uitspraken niet veel waarde hecht(ik zeg niet dat hij niet kan programmeren of!)

DirectX doet het met frequent updates, OpenGL doet het met extensions....

Feitelijk gezien zie ik het verschil niet zo.

De reden dat professionele bedrijven, anders dan spelletjes-producenten, zich bezig houden met OpenGL is omdat OpenGL cross-platform is, en OpenGL een rijke historie heeft waardoor veel kennis in huis is van OpenGL bij de desbetreffende bedrijven.

Enne... ver-newbien??? Dat komt eerder doordat informatie over DirectX EN OpenGL uitgebreid op internet te vinden is, waardoor velen een poging wagen. Heeft niks met de kwaliteit van OpenGL of DirectX te maken.

Overigens: wanneer een game OpenGL gebruikt, wil dat niet zeggen dat de input & sound code volledig door de makers zelf zijn gemaakt! Er zijn meer lib's dan DirectSound en DirectInput en die worden ook ruim gebruikt door OpenGL jongens(en soms ook meisjes)

Als ik het goed begrijp kunnen hiermee de rendertijden met 3dprogramma's omlaag?

Misschien kun je wat special effects sneller previewen, maar de uiteindelijke rendertijd wordt volgens mij volledig door de CPU gedaan, en dus zal die tijd niet afnemen.

Wat mij wel gaaf lijkt is OpenGL in Java, dan hoef je programma's met 3D graphics helemaal niet meer te poorten en zijn ze eenvoudig voor alle systemen tegelijk bruikbaar.

"Developers can easily incorporate high-quality, scalable, platform-independent 3D graphics into Java technology-based applications and applets. The Java 3D application programming interface (API) provides a set of object-oriented interfaces that support a simple, high-level programming model. This enables developers to build, render, and control the behavior of 3D objects and visual environments. By leveraging the inherent strengths of the Java language, Java 3D technology extends the concept of "Write Once, Run Anywhere" to 3D graphics applications."

(java.sun.com/products/java-media/3D)

Het bestaat dus al