Hoofdcategorieën

Opengl 3.0 met gemengde gevoelens ontvangen

Door Dimitri Reijerman, dinsdag 12 augustus 2008 13:18
Submitter: The Flying Dutchman, views: 15.411

De Khronos Group, de ontwikkelaar van de Opengl-specificatie, heeft versie 3 van zijn cross-platform-api voor 2d- en 3d-toepassingen vrijgegeven. Opengl 3.0 is in de ontwikkelgemeenschap echter uiterst lauw ontvangen.

OpenglVersie 3.0 biedt onder andere vier nieuwe manieren voor het comprimeren van textures, ondersteuning voor het sRBG-kleurenmodel en een vereenvoudigde manier om vertex-objecten te maken. Verder is de nauwkeurigheid bij het renderen van textures met floating-pointoperaties vergroot naar 32bit en is Glsl opgekrikt naar versie 1.30. Met het oog op de toekomst is in versie 3.0 het deprecated model ingevoerd, een methode om aan te gegeven welke functies in de volgende Opengl-versie niet meer zullen worden ondersteund.

De derde versie van Opengl zou oorspronkelijk al in september 2007 worden opgeleverd, maar de release werd wegens 'technische problemen' een aantal keren uitgesteld. Aanvankelijk werd verwacht dat de grafische api grotendeels zou worden herschreven tot een compacter en sneller geheel, maar de Opengl-ontwikkelaars, die Opengl 3.0 omschrijven als een 'evolutionaire stap voorwaarts', zeggen dat daar vanaf is gezien omdat de api met voorgaande versies compatibel moest blijven. Daarnaast zouden te grote veranderingen grote problemen opleveren bij de software- en hardware-ondersteuning. Volgens de ontwikkelaars zouden er momenteel zestig miljoen grafische kaarten gebruikt worden die Opengl-applicaties en -games ondersteunen.

Veel ontwikkelaars zijn echter niet blij met de 'vernieuwde' api. Volgens een aantal van hen zou de architecture review board van de Khronos Group de eerder beloofde fundamentele wijzigingen niet hebben doorgevoerd en kan de nieuwe versie beter het etiket 2.2 opgeplakt krijgen. Anderen leggen op het Opengl-forum de schuld deels neer bij conservatieve cad-gebruikers, die vernieuwing zouden tegenhouden, en stellen dat zij zich gedwongen voelen om over te stappen naar Microsofts propriëtaire Direct X 10.1-api.

John Carmack, 3d-specialist en medeoprichter van id Software, kan zich deels in de kritiek vinden. Tijdens de Quakecon-conferentie liet Carmack weten dat Opengl in de loop der tijd erg rommelig is geworden en dat versie 3 daar geen verandering in brengt. Volgens de id-topman is een sterk afgeslankte 3d-api de enige juiste keuze voor de toekomst, terwijl bijvoorbeeld cad-gebruikers prima uit de voeten zouden kunnen met de huidige specificatie.

Volgende 13:51
Vorige 12:51

Reacties

«  1  2  »

open GL begint toch langzaam bestaans recht te verliezen.
direct x kan inmiddels alles wat open GL kan. maar dan makkelijker sneller en efficienter.
afgezien van het callen van acties dan.
hoop dat er inderdaad een goede afgeslankte versie van de api komt.
anders is het direct x all the way...

Uhm... op Windows wel ja. OpenGL draait op alle platforms.

Het is alleen erg jammer dat Microsoft zijn DirectX platform alleen nog maar voor Vista en hoger uitbreidt.

Vroeger was ik altijd erg happy als een spel OpenGL ondersteunde, dat ging toen mooier en sneller dan DirectX (rond versie 6.0), maar als ik tegenwoordig zie hoeveel lichter en sneller DirectX (9.0c) is, dan vind ik het ronduit jammer dat OpenGL voor op het Windows platform in ieder geval geen antwoord heeft.

Juist een project als OpenGL zou cross-platform ontwikkelen zoveel aantrekkelijker moeten en kunnen maken, aangezien het al bijna een oudgediende is in de PC wereld.

Toch een puntje voor Microsoft met deze ontwikkeling.

OpenGL is tov DX9.0C nog steeds sneller hoor, vooral op Nvidia kaarten.

DirectX is een mainstream op PC's en Microsoft consoles. Jammer dat DirectX10 verder niet vlugger is dan DX9.0c.

OpenGL is tov DX9.0C nog steeds sneller hoor, vooral op Nvidia kaarten.
Cijfers? En kom niet af met een theepot of een draaiende kubus....

Het is op zich niet zo raar. Het komt uiteraard niet door de API zelf, maar op de manier hoe de backends van beide API's in Windows door de driver aangesloten worden. OpenGL calls worden vrijwel direct naar de driver doorgegeven, en op die manier is er dus een vrij korte weg van applicatie naar GPU. Bij D3D9 en eerder zitten er echter nog een paar lagen aan abstractie en kernelspace tussen, waardoor individuele calls zoals tekencommando's en state changes veel duurder zijn. De rendering performance blijft uiteraard gelijk, maar de applicatie interfaced wat sneller met de GPU middels OpenGL dan met D3D. Met de komst van D3D10 geldt dit overigens niet meer.

[Reactie gewijzigd door .oisyn]


Daarom dat ik refereer naar die theepot of draaiende kubus, waar ik me kan voorstellen dat die lagen abstractie relatief gezien meer invloed hebben op de performance dan bij complexe scene's. (waar ik verwacht dat door vertex buffers en het gebruik van shaders er minder chatty communicatie is doorheen de API, itt tot elke vertex doorheen glVertex pleuren)

Het is nou juist andersom :). Complexe scenes vereisen veel statechanges en dus veel draw calls, terwijl een simpele kubus of theepot slechts met 1 call overweg kan.

het kan natuurlijk ook aan de implementatie liggen van Autodesk, maar op mijn Nvidia Quadro kaart loopt 3dsmax toch echt een stuk soepeler in directX mode dan OpenGL.
Daarnaast ziet het er ook nog beter uit (shadingwise) en krijg ik een betere indruk hoe mijn scene eruit gaat zien als ik hem render.

Ook zijn de Maxtreme drivers van Nvidia, speciaal voor 3dsmax ontwikkelde drivers, ook overgestapt op DirectX waar die een paar jaar terug nog juist OpenGL gebruikten.

Dit is natuurlijk alleen de ervaring met 1 programma, maar daarbij merk ik wel duidelijk verschil in het voordeel van DirectX.

Maar met een daadwerkelijke verbetering in 3.0 had OpenGL weer een stuk richting mainstream kunnen gaan. Op dit moment is het voor gamedevelopers veel aantrekkelijker om "gewoon" DirectX te gebruiken.

Het is een beetje zoals elk "Open-" verhaal, zolang het geen enorme verbetering is zal men het niet overnemen, en zolang het niet overgenomen wordt, wordt het geen algemeen goed. Zelfs als OpenGL een paar procentjes winst pakt, is het nog niet aantrekkelijk genoeg om over te stappen gezien de moeite die in een overstap gestoken moet worden.

Nu ben ik geen kenner in de diepe materie van de verschillende implementaties echter ik kan me goed voorstellen dat de CAD gebruikers vanuit hun professionele oogpunt waar precisie van belang is conservatiever zijn. Echter het doet er niet aan onder dat zij net zo graag goede support willen voor nieuwere varianten met name van het 2d naar 3d dankzij de verschillende Autodesk pakketten wat het ontwikkelen in 3d steeds makkelijker maakt.
Mij lijkt het dan ook kort door de bocht om te stellen dat deze grote groep geen belang heeft bij een nieuwere release. Het doet echter niet aan af dat deze vernieuwing misschien geen 3.0 waardig is maar of dit nou zo belangrijk is...
---edit---
@BreezahBoy, het komt inderdaad wel eens voor dat er enthousiastelingen in LISP nog oud spul draaiende houden echter een beetje bureau werkt heden ten dagen ook keurig met Acad2005 die zonder problemen de laatste OpenGL versie ondersteunt. Ik kan me dan ook moeilijk voorstellen dat zeker grote drijfveren van met name Autodesk 3.0 dwarsbomen vanwege hun software aangezien zij zeker baat erbij hebben als bv Maya of 3ds de laatste OpenGl ondersteunt.

[Reactie gewijzigd door n4m3l355]


het gaat niet zozeer om de cadgebruikers maar om de programmeurs die jarenoude software beheren voor die cad gebruikers. veel van die software zijn codebases van 20 jaar en ouder en die moeten blijven werken met opengl. die backwards compatibility houdt de vooruitgang van opengl dus tegen.

CAD gebruikers moeten gewoon OpenGL 2 blijven gebruiken. Het is niet zo dat opeens alle oude OpenGL2 specificaties van alle harddisks in de wereld gewist zijn. Bovendien, als je in die CAD programma's de nieuwe videokaart features wil gebruiken, dan werkt je CAD programma niet meer op oude workstations.


Voor nieuwe software wil je die oude cruft niet meer hebben. Het is ook niet erg dat je nieuwe games niet meer op een Pentium II werken. Ook nieuwe CAD programma's kunnen uitgaan van nieuwe hardware. Open GL3 had daarom op die groep moeten mikken.

Als bijv. driverontwikkelaar zit je er echter ook niet op te wachten dat je dadelijk twee of meer OpenGL standaarden moeten gaan blijven ondersteunen.

De CAD wereld maakt zich natuurlijk zorgen dat ze oude software dadelijk niet meer mee kunnen nemen naar nieuwe hardware, indien nieuwe OpenGL drivers niet backwards compatible zouden zijn. Dat is een terechte zorg. Je kunt niet zomaar zeggen dat de CAD-wereld "fout" zit. Het echte probleem is dat OpenGL in twee verschillende omgevingen gebruikt wordt: de CAD wereld die conservatief is en de game-wereld die snel ontwikkelt. DirectX bedient eigenlijk alleen de game-wereld en heeft dus meer vrijheid. (En het helpt dat het beheerd wordt door een monpolist die geen compromissen hoeft te sluiten.)

CAD en OpenGL zijn feitelijk niet onlosmakelijk met elkaar verbonden. Autodesk Inventor (maar ook Alibre) gebruikt bijvoorbeeld vanaf versie 2008 bij voorkeur Direct3D.

Oudere 3d CAD software (ProENGINEER, CATIA, Unigraphics, SolidWorks) zullen nog heel wat moeten doen om deze stap te gaan maken. Mogelijk dat HOOPS daarbij nuttig kan zijn.

[Reactie gewijzigd door MOmax]


stellen dat zij zich gedwongen voelen om over te stappen naar Microsofts propriëtaire Direct X 10.1-api.
Dat zou jammer zijn. Nog meer software dat moeilijker cross-platform te maken is.

Het feit dat er weinig crossplatform (als in win32 - linux - mac) games zijn, waar je waarschijnlijk op doelt, heeft echt geen zak te maken met de gebruikte API. Dat is namelijk wel het minste probleem als je een game gaat porten. Het aantal linux en in mindere mate mac gebruikers maken het gewoon oninteressant om in die platforms te investeren. Het is niet even een kwestie van een game porten. Het meeste werk gaat zitten in Q&A en support voor die platforms, en dat kost gewoon een hoop geld, terwijl je er relatief weinig voor terug krijgt. Het is niet zo dat een game niet geport wordt omdat de developers voor een bepaalde API hebben gekozen. Bij het kiezen van een API houden ze juist rekening met bepaalde factoren, waarvan het plan om te porten er een van is (de anderen zijn documentatie, support, tools en ervaring van je personeel met die API). Als je je game toch al niet uit gaat brengen op linux of mac, dan valt het crossplatform voordeel van OpenGL al meteen weg (en dat is zo'n beetje het enige voordeel dat OpenGL heeft tov D3D op de PC)

Daarnaast is het helemaal niet zo moelijk om de grafische API van een applicatie te wijzigen, zeker niet voor games die sowieso vaak al ook op de consoles draaien en dus op een degelijke manier ontworpen zijn zodat de low-level grafische schil relatief makkelijk te vervangen is. Bovendien spreken beide API's (D3D en OpenGL) dezelfde hardware aan, dus ze zijn ook vrijwel identiek aan functionaliteit.

[Reactie gewijzigd door .oisyn]


Het feit dat er weinig crossplatform (als in win32 - linux - mac) games zijn, waar je waarschijnlijk op doelt, heeft echt geen zak te maken met de gebruikte API. Dat is namelijk wel het minste probleem als je een game gaat porten. Het aantal linux en in
Ik weet dat de API niet het enige probleem is en het kan best zijn dat het niet het belangrijkste probleem is bij het porten. Mijn punt is dat dit een tegenslag is voor de motivatie om software cross-platform te maken. Het vereist namelijk niet alleen het vervangen van de API maar ook de bijbehorende know-how die dus 2x aanwezig moet zijn (DX en OGL). Verder betekent het meer testen etc. Dit goed doen kost meer tijd dan je denkt en er valt veel tijd (en geld) te besparen door het direct te schrijven met een API die op ale beoogde platformen werkt.

Voor de hele code-base geldt dat als het goed is ontworpen/geschreven met cross-platform-conversie als eis, het vervangen van API relatief weinig werk is. Dus niet alleen video. Maar nog steeds een hoop werk.

Dit opgeteld bij de overige kosten kan het erop of eronder zijn voor de keuze om het cross-platform uit te brengen. Zelfs als het uitgebracht wordt met minimale support (vnl alleen door communitie) zoals bv bij Quake III is gebeurd.

P.s. ik dacht niet alleen aan games, hoewel daaraan het meest.

[Reactie gewijzigd door ritsjoena]


Het feit dat er weinig crossplatform (als in win32 - linux - mac) games zijn
D'r wordt weinig naar Linux geport sinds Lokigames dood is, maar als ik kijk hoe 't op de mac gaat: wauw. Meestal wordt de mac poort tegelijkertijd met de windows versie ontwikkeld. (transgaming is daar erg bij betrokken geloof ik)

misschien dat samenwerking skunkworks van intel larrabee icm met apple iets nieuws kan opleveren, een soort opgeschoonde opengl maar dan wel met de nieuwe mogelijkheden van larrabee er in verwerkt.

want larrabee is welliswaar compatible met directx en opengl e.d. maar ik kan me voorstellen dat beide een beetje ouderwets zijn. larrabee schijnt toch fundamenteel anders te werken dan bestaande 3dfx afstammelingen zoals we die tegenwoordig kennen (envydia, daamit).

Mjah, hetzelfde Apple dat de traagste OGL implementatie heeft van alle OS'en? Is dat echt een goed idee? Het lijkt er niet echt op dat Apple erg veel OGL kennis en kunde in huis heeft.

Persoonlijk ontwikkel ik in beide, en vind inderdaad OpenGL een beetje rommelig geworden, maar ik vind wel dat OpenGL nog altijd 'makkelijker' te besturen is dan DirectX, opengl heeft over het algemeen een veel eenvoudigere API dan DirectX.

Nu met op opkomst van XNA, die eigenlijk DirectX wrapped en managed maakt, is het ondertussen ook weer makkelijker geworden om 'XNA'-DirectX aan te sturen.

Ik kan er volledig inkomen dat voor CAD tekenen OpenGL zoals hij nu bestaat perfect voldoende is, voor echte game/simulatie platformen vind ik DirectX dan weer beter.

OpenGL zou perfect een nieuwe API kunnen krijgen, als ze de oude bestaande houden...
En dat zou hen dan weer wat meer marktvoordeel kunnen opbrengen...

ik snap niet waarom OpenGL niet het pad van DirextX10 kiest.

De nieuwe versie supersnel en compact maken zonder rekening te houden met backwards compatibility. Vervolgens bouwen ze een OpenGL-Legacy-Wrapper zoals de dx9>dx10 wrapper die in vista zit.

Deze Legacy-Wrapper kan ook snel en compact gemaakt worden maar deze keer met 100% backwards compatibility.
Na de release vraag je de community om over te stappen op de nieuwe OpenGL versie.

De nieuwe OpenGL versie zou de capaciteiten van de videokaart kunnen uitlezen of uit een database halen en op die manier de juiste calls maken.

Met een Hype erachter over de FPS increase zouden veel mensen willen mee helpen lijkt mij

Dat was het originele plan achter OpenGL 3: om eerst de hele API op te schonen, en vervolgens de nieuwe functionaliteit erin te bouwen. Die nieuwe API zou object oriënted zijn, en geen fixed function pipeline meer hebben. De fixed function pipeline zou echter wel beschikbaar zijn voor backwards compatibility, alleen zou deze geïmplementeerd zijn op de nieuwe API.

Enerzijds is het jammer dat de beloofde api, die modern, object georienteerd, dichter bij de hardware en eenduidiger zou zijn, er nog niet gekomen is. Aan de andere kant maakt deze versie wel de weg vrij om een hoop oude functionlaliteit te verwijderen in een volgende versie. Je kunt nu in OpenGL 3.0 een forward-compatible profiel gebruiken waarbij je geen gebruik maakt van depricated functies. Programma's die gebruik maken van zo'n profiel hebben mogelijk wat performance voordeel, omdat de drivers op dat moment niet alle oude (nu depricated) functies hoeven te ondersteunen.

Wel blijft het zo dat de api veroudert is en niet kan tippen aan DirectX 10. Wel heb je DirextX 10 hardware nodig om OpenGL 3 te kunnen draaien (vanaf Ati R600 of nVidia NV80). Veel nieuwe functionaliteit zit nu standaard in OpenGL 3. Wat wel in de core mist zijn geometry shaders, deze zijn echter beschikbaar via het systeem van OpenGL extensies. Nadeel hier weer van is, dat hardware fabrikanten niet beslist driver ondersteuning hoeven te geven op de extensies. Het is dus maar afwachten of geometry shaders op hardware van alle fabrikanten beschikbaar zal zijn.

Daarnaast hebben enkele leden van Khronos (de instantie die OpenGL beheert) aangegeven dat de nieuwe moderne object georienteerd api nog niet van de baan is. Het vertrouwen bij de community is echter vrijwel verdwenen omdat Khronos een jaar lang niets van zich heeft laten horen over de vertraging die OpenGL 3.0 heeft opgelopen en vervolgens met iets heel anders komt dan in eerste instantie beloofd.

Het is echter ook nog afwachten wat er de komende dagen bekend wordt gemaakt over OpenGL 3.0, de toekomst van OpenGL en driver ondersteuning van hardware fabrikanten tijdens Siggraph 2008 in Los Angelos (een conferentie voor graphics developers en graphics hardware fabrikanten).

Het probleem lijkt mij hier dat de Khronos Group probeert twee volledig verschillende doelgroepen blij te maken met hetzelfde product, terwijl ze beide heel andere wensen hebben.

Zoals John Carmack al zegt: cad gebruikers kunnen prima uit de voeten met de versie 2. Een aantal extra features en wat updates zou leuk zijn, maar de basis van openGL 2 is goed. Dan heb je aan de andere kant de (game) developers die graag from scratch een volledig nieuwe API gebouwd zien. Er is hier geen gulden middenweg, het is kiezen of delen.

Ik weet niet wat voor (financiele) middelen de Khronos Group tot zijn beschikking heeft, maar anders zou ik zeggen opsplitsen die handel en verder gaan met twee API's.

Ze hadden beter in een paar maand tijd OpenGL 2.2 gespecifieerd, en rond deze tijd een echt nieuwe OpenGL 3.0 gepresenteerd dat in grote mate breekt met de oude troep.

Grote ontgoocheling, en de shuld ligt bij het hoger management dat geen ballen heeft.

Iets een volledig jaar te laat uitbrengen kan niet enkel aan het management liggen. Ofwel zijn de developers vreselijk incompetent in het werk, ofwel zijn er slechte keuzes gemaakt bij de start waar veel te laat de problemen van zijn gevonden.

managers kunnen anders gigantisch vertraging (terwijl ze nou juist betaald worden om dat te voorkomen).

maar ook de beslissings cultuur daar zal tegenwerken, en de nodige dwarsliggende leden.

Als gaming op andere platformen dan windows echt wil doorbreken wordt het wel dringend tijd dat opengl echt doorbreekt. Ik hoop dan ook echt dat er nog veel zal veranderen bij opengl...

OpenGL heeft terrein verloren door niet snel genoeg door te ontwikkelen en dat heeft verder niets te maken met DX van MS. De schuld ligt bij hunzelf aangezien ze niet aan de eisen van gameontwikkelaars konden voldoen naarmate de er steeds meer eisen werden gesteld.

Dan moet OGL ophouden met zijn 'designed by commitee' methodiek, dat werkt dus niet.

Ook toen opengl beter was dan direct3d werd het relatief weinig gebruikt helaas (direct3d is dan destijds ook gemaakt met het oog op het voorkomen van portabiliteit), gamen op andere platformen kan prima, het is helaas de keuze van de gamedevelopers om hun games slechts voor een gedeelte van de markt te maken, waardoor je als gamer al snel gedwongen wordt om windows te installeren (of een console aan te schaffen, al is een console helaas nog geen vervanger voor de pc wat betreft veel populaire spelvarianten)
«  1  2  »

Op dit item kan niet meer gereageerd worden.

Volgende 13:51
Vorige 12:51
VNU Media logo Powered by True

© 1998 - 2008 Tweakers.net - Alle rechten voorbehouden

Uitgever van: