DirectX/OpenGL

quote:

abort_ schreef op woensdag 14 mei 2008 @ 17:22:
de online games met de beste feeling zijn toch echt games gebasseerd op opengl (q3 engine)!

Dat is jouw persoonlijke mening, het zegt NIETS over de kwaliteiten van OGL of D3D !!!

Waarom willen mensen dit nou nooit snappen

quote:

abort_ schreef op woensdag 14 mei 2008 @ 17:22:
de online games met de beste feeling zijn toch echt games gebasseerd op opengl (q3 engine)!

Waar CS1.6 weer kut liep op OpenGL en prima op D3D

OpenGL of D3D heeft niets te maken met Online Game feeling, alles wat kan in OpenGL is mogenlijk in D3D en omgekeerd, het is dezelfde hardware, alleen Dx10.1 voegt wat nieuwe truuks toe die je waarschijnlijk ook wel kan doen met wat extra code werk (Alleen geeft dat misschien teveel overhead)

Dus..

quote:

Ilmar schreef op woensdag 14 mei 2008 @ 16:49:
[...]


Ik weet niet wat Nintendo doet, maar de PS3 gebruikt OpenGL ES. Het voordeel is natuurlijk dat het op iedere console geïmplementeerd kàn worden.

Maar wat niet het geval is, waardoor je dus alleen op de PS3 in OpenGL ES gebruikt. Dit nog even naast het feit dat zelfs als de andere consoles ook OpenGL ES zouden gebruiken, en de PC ook, dan nog heb je geen crossplatform code omdat de hardware niet gelijk is. Je optimaliseert namelijk voor de hardware, waardoor keuzes die je voor de PS3 maakt niet dezelfde keuzes hoeven te zijn als die voor de Xbox 360.

Jouw argument zou ook opgaan voor Direct3D. Dat draait immers op de PC en op de Xbox 360. Toch is dat niet zo, om de redenen die ik zojuist gaf.

quote:

OpenGL loopt alleen met de nieuwe D3D10 features achter de feiten aan omdat die door MS bedacht zijn en pas later door GPU fabrikanten overgenomen

Wat is nou het punt dat je wilt maken? Het blijft toch gewoon zo dat OpenGL achter de feiten aanloopt? Dat kun je wel gaan verdedigen maar dat verandert de situatie niet. Ik ben verder ook niet pro-D3D of anti-OpenGL dus een fanboy discussie hoeven we niet te beginnen. Mijn stelling is echter dat Direct3D op de PC vaak praktischer is dan OpenGL.

Bovendien is het niet puur MS die de koers zet hoor. Ze zitten echt wel met nVidia en ATi om de tafel. MS is namelijk geen hardware fabrikant en hebben de expertise helemaal niet om te bepalen wat wel kan en wat niet kan.

quote:

maar de hoeveelheid 'dubbele extensies' is zeer gering, aangezien de fabrikanten liever elkaars ontwerp overnemen (zie de lange lijst GL_EXT_ extensies).

Ja dat verklaart ook wel waarom elke developer klaagt over dat ze nieuwe vergelijkbare features N keer moeten implementeren omdat ze nog vendor-specifiek zijn

.oisyn wijzigde dit bericht 15-05-2008 14:18 (4%)

quote:

.oisyn schreef op donderdag 15 mei 2008 @ 14:17:

Jouw argument zou ook opgaan voor Direct3D. Dat draait immers op de PC en op de Xbox 360. Toch is dat niet zo, om de redenen die ik zojuist gaf.

Wat ik hier bedoel is dat OpenGL een open standaard is en D3D niet, waardoor het voor Sony, Nintendo (en tegenwoordig ook Nokia en consorten) etc. te implementeren is, zonder juridisch getouwtrek met MS.

quote:

Wat is nou het punt dat je wilt maken? Het blijft toch gewoon zo dat OpenGL achter de feiten aanloopt? Dat kun je wel gaan verdedigen maar dat verandert de situatie niet. Ik ben verder ook niet pro-D3D of anti-OpenGL dus een fanboy discussie hoeven we niet te beginnen. Mijn stelling is echter dat Direct3D op de PC vaak praktischer is dan OpenGL.

[...]

Ja dat verklaart ook wel waarom elke developer klaagt over dat ze nieuwe vergelijkbare features N keer moeten implementeren omdat ze nog vendor-specifiek zijn

Mijn punt is dat OpenGL op het moment achter de feiten aan loopt, een situatie die over een jaar ofzo best anders kan zijn (zomaar een voorbeeld: ik zou mij kunnen voorstellen dat je kiest voor een OpenGL applicatie met wel/niet gebruik van een aantal extensies ipv een volledige abstraction layer voor D3D9/D3D10 om D3D10 features te kunnen gebruiken, zonder Vista te vereisen - als AMD nu eens opschiet met die features ook in hun OpenGL driver te stoppen ).

Ik ben het verder wel met je eens dat D3D vaak praktischer is, maar naar mijn idee omdat het minder flexibel is en je als developer dus met minder verschillende situaties rekening hoeft te houden (ook een van de voordelen van ontwikkelen voor consoles). Ik vind het voordeel van OpenGL dus juist die flexibiliteit en probeer aan te geven dat OpenGL meer is dan een bij elkaar geraapt zooitje en er dus zeker wel redenen zijn om voor OpenGL te kiezen ipv. D3D.

quote:

Ilmar schreef op donderdag 15 mei 2008 @ 17:28:

Wat ik hier bedoel is dat OpenGL een open standaard is en D3D niet, waardoor het voor Sony, Nintendo (en tegenwoordig ook Nokia en consorten) etc. te implementeren is, zonder juridisch getouwtrek met MS.

En wat ik bedoel is dat je daar vrijwel niets aan hebt omdat je toch wel voor dat platform gaat optimaliseren, waarbij het voordeel van een gelijke API zo goed als wegvalt.

Overigens spreken wij voor een groot deel direct de hardware aan op de meeste platforms. Onze Xbox 360 renderer backend lijkt in de verste verte niet op onze PC renderer backend, ookal is Direct3D op beide platforms beschikbaar.

Juridisch getouwtrek is trouwens een nonargument. Er is niets wat je tegenhoudt om een API te implementeren. Sterker nog, ik ken een bedrijf dat dat met D3D op de PS3 gedaan heeft

.oisyn wijzigde dit bericht 15-05-2008 18:03 (12%)

quote:

.oisyn schreef op donderdag 15 mei 2008 @ 14:17:
[...]

Wat is nou het punt dat je wilt maken? Het blijft toch gewoon zo dat OpenGL achter de feiten aanloopt? Dat kun je wel gaan verdedigen maar dat verandert de situatie niet. Ik ben verder ook niet pro-D3D of anti-OpenGL dus een fanboy discussie hoeven we niet te beginnen. Mijn stelling is echter dat Direct3D op de PC vaak praktischer is dan OpenGL.

Bovendien is het niet puur MS die de koers zet hoor. Ze zitten echt wel met nVidia en ATi om de tafel. MS is namelijk geen hardware fabrikant en hebben de expertise helemaal niet om te bepalen wat wel kan en wat niet kan.

Nou, daar sla je de plank mis. opengl32.dll is al jaren niet geupdate door MS naar opengl2.0. Dit is om een reden en die kunnen we allemaal wel raden.
De ARB heeft al jaren geleden een geupdate opengl32.dll naar MS gestuurd, maar het nadeel wil dat de binding van de rendercanvas aan een Hdc nu juist proprietary code is en je dus dat niet zelf kunt releasen als ARB zijnde. (voor de leken: opengl32.dll is essentieel om iets met OpenGL te doen op windows, het regelt de verbinding tussen de opengl driver en het windows window, waar de render canvas op ligt)

Het gevolg is dus dat iedere OpenGL programmeur met lijsten met function pointers en typedefs zit om die extensions aan te spreken. Maar zo'n ramp is dat nou ook weer niet, want veelal is dat 1 keer oplossen en dan is het eigenlijk gelijk aan een api callen.

Dat MS de hardware op de PC stuurt door hun design van DX is een realiteit, dat zegt overigens niets over de functionaliteit van OpenGL op andere platforms, immers, hoe je het ook wend of keert: veel spullen zit tegenwoordig in shaders en het zware werk is echt 3D api generic spul. Polies pompen door een 3D api is nog wel realiteit maar niet dermate zwaarwegend dat dat nou een significante stempel drukt op een beetje project.

EfBe wijzigde dit bericht 15-05-2008 22:02 (4%)

Misschien ligt het aan mij maar ik zie totaal niet de relevantie van jouw post met die van mij

quote:

Het gevolg is dus dat iedere OpenGL programmeur met lijsten met function pointers en typedefs zit om die extensions aan te spreken

Daar heb je libraries voor. Volgens mij zelfs van de OpenGL site zelf te downloaden

quote:

Dat MS de hardware op de PC stuurt door hun design van DX is een realiteit

Dat ontken ik ook niet. Maar wat ik beweer is dat MS dat heus niet in zijn eentje doet, en daar hulp van de grote hardware vendors bij heeft. Of denk jij dat het concept shaders (een van de fundamentele vernieuwingen in hardware rendering land) puur en alleen door MS bedacht is?

.oisyn wijzigde dit bericht 15-05-2008 23:19 (46%)

quote:

.oisyn schreef op donderdag 15 mei 2008 @ 23:16:
Misschien ligt het aan mij maar ik zie totaal niet de relevantie van jouw post met die van mij

De ARB (en ik deel die mening) is van mening dat de acceptatie van OpenGL op windows voor een groot deel is tegengewerkt door MS dmv het niet updaten van hun opengl32.dll, waardoor het lastiger wordt om opengl te programmeren op windows dan Dx. Het leek alsof jij van mening bent dat het aan OpenGL zelf ligt dat de acceptatie van OpenGL op windows niet zo groot is.

quote:

[...]
Dat ontken ik ook niet. Maar wat ik beweer is dat MS dat heus niet in zijn eentje doet, en daar hulp van de grote hardware vendors bij heeft. Of denk jij dat het concept shaders (een van de fundamentele vernieuwingen in hardware rendering land) puur en alleen door MS bedacht is?

Geen idee, ik denk het eerlijk gezegd niet (nvidia was dacht ik de 1e).

EfBe wijzigde dit bericht 16-05-2008 10:31 (6%)

quote:

EfBe schreef op vrijdag 16 mei 2008 @ 10:30:
[...]

De ARB (en ik deel die mening) is van mening dat de acceptatie van OpenGL op windows voor een groot deel is tegengewerkt door MS dmv het niet updaten van hun opengl32.dll, waardoor het lastiger wordt om opengl te programmeren op windows dan Dx. Het leek alsof jij van mening bent dat het aan OpenGL zelf ligt dat de acceptatie van OpenGL op windows niet zo groot is.

Daar ben ik het ook wel mee eens. Maar dit staat los van het feit dat OpenGL een nogal log consortium achter zich heeft waardoor updates sowieso lang op zich laten wachten. Ik bedoel, hoe lang heeft het wel niet geduurd voordat OpenGL 2.0 er was? Maar goed, dat is natuurlijk ook inherent aan het feit dat het open is en daardoor iedereen een zegje kan (en wil) hebben. Dat zie je bijvoorbeeld ook met C++. Maar welk argument je er ook bij plaatst waarom het zo is, het feit blijft wel dát het zo is, en dat is in het nadeel van OpenGL .

quote:

.oisyn schreef op vrijdag 16 mei 2008 @ 10:47:
[...]

Daar ben ik het ook wel mee eens. Maar dit staat los van het feit dat OpenGL een nogal log consortium achter zich heeft waardoor updates sowieso lang op zich laten wachten. Ik bedoel, hoe lang heeft het wel niet geduurd voordat OpenGL 2.0 er was? Maar goed, dat is natuurlijk ook inherent aan het feit dat het open is en daardoor iedereen een zegje kan (en wil) hebben. Dat zie je bijvoorbeeld ook met C++. Maar welk argument je er ook bij plaatst waarom het zo is, het feit blijft wel dát het zo is, en dat is in het nadeel van OpenGL .

Nou, dat van dat logge is wel een beetje waar, maar laten we ook niet vergeten dat MS ook lid is van de ARB

1 van de laatste opengl games is toch wel Enemy Territory Quake Wars en daarin zie je dat je met opengl zeker mooie games kan maken. Ik vind zelf opengl stuk fijner gamen, heb ervaring met Q3 engine vooral en nu dan Enemy Territory Quake Wars. Wat ik wel groot nadeel vind van opengl is dat het stuk minder en goed werkt met ATi kaarten, dat ligt eigelijk aan ATi vind ik maar het is toch een nadeel wat niet goed is voor OpenGL.

quote:

Zenix schreef op vrijdag 16 mei 2008 @ 15:33:
1 van de laatste opengl games is toch wel Enemy Territory Quake Wars en daarin zie je dat je met opengl zeker mooie games kan maken. Ik vind zelf opengl stuk fijner gamen, heb ervaring met Q3 engine vooral en nu dan Enemy Territory Quake Wars.

Sorry maar dat heeft toch echt geen zak met OpenGL te maken, maar alles met de gebruikte engine (id tech 4 als ik me niet vergis) . Met D3D kun je exact hetzelfde plaatje met exact dezelfde feel tevoorschijn toveren. 't Is de hardware die het werk doet, niet de gebruikte API.

quote:

Zenix schreef op vrijdag 16 mei 2008 @ 15:33:
1 van de laatste opengl games is toch wel Enemy Territory Quake Wars en daarin zie je dat je met opengl zeker mooie games kan maken. Ik vind zelf opengl stuk fijner gamen, heb ervaring met Q3 engine vooral en nu dan Enemy Territory Quake Wars. Wat ik wel groot nadeel vind van opengl is dat het stuk minder en goed werkt met ATi kaarten, dat ligt eigelijk aan ATi vind ik maar het is toch een nadeel wat niet goed is voor OpenGL.

Een groot probleem is denk ik dat review sites totaal geen aandacht besteden aan OGL performance als ze een kaart reviewen. Ik gebruik zelf OGL vrij veel in mijn eigen en 3rd-party applicaties (cross-platform), en daarom zou ik het enorm op prijs stellen als ik kaarten op die punten kan vergelijken. Dankzij m'n werk aan de 3D engine weet ik nu dus dat ATI inderdaad knap waardeloos is als het op OpenGL aankomt, wat ook komt omdat ze bijvoorbeeld een suggestie voor een nieuw onderdeel van OGL te laat verzonden hebben, zodat nVidia ermee aan de haal is gegaan, en ATI nu met een net niet helemaal compitable implementatie zit. Ook zijn hun tools voor shader programming en zo niet echt flitsend.

Er is een reden waarom ATI voornamelijk met Windows systemen gebruikt word

quote:

leonpwner1 schreef op woensdag 07 mei 2008 @ 23:11:
[...]


Quake 4, Prey
[...]

Serious Sam!

quote:

Elledan schreef op vrijdag 16 mei 2008 @ 16:07:
[...]

Er is een reden waarom ATI voornamelijk met Windows systemen gebruikt word

Je moet het anders stellen: Er is een reden waarom ATi vaak niet op Linux systemen wordt gebruikt. Wel een verschil

quote:

EfBe schreef op vrijdag 16 mei 2008 @ 10:30:
[...]

De ARB (en ik deel die mening) is van mening dat de acceptatie van OpenGL op windows voor een groot deel is tegengewerkt door MS dmv het niet updaten van hun opengl32.dll, waardoor het lastiger wordt om opengl te programmeren op windows dan Dx. Het leek alsof jij van mening bent dat het aan OpenGL zelf ligt dat de acceptatie van OpenGL op windows niet zo groot is.


[...]

Geen idee, ik denk het eerlijk gezegd niet (nvidia was dacht ik de 1e).

Wat let videokaart fabrikanten om in hun drivers een nieuwere versie van opengl32.dll mee te leveren? Of games zelf om die mee te leveren?

*Krom voorbeeldje*: MS update ook de "PhysX" dll files niet, en toch krijg je daar telkens nieuwere versie van

quote:

EfBe schreef op vrijdag 16 mei 2008 @ 10:30:
Geen idee, ik denk het eerlijk gezegd niet (nvidia was dacht ik de 1e).

Shaders is een begrip die al zo oud is als de weg naar rome. Het stamt al uit de tijd van de eerste 3D animatie experimenten. In 3D land is een shader eigenlijk een oppervlakte/materiaal beschrijving... Dus hoe reageert deze op licht? Hoe ziet de texture er uit? Hoe wordt het object gedeformeerd, of hoe wordt het licht gedeformeerd op het moment dat dit door het object schijnt?

Nvidia en ATI hebben echter de eerste stappen genomen om dit alles in realtime te doen binnen de consumenten markt.

quote:

roy-t schreef op vrijdag 16 mei 2008 @ 18:01:
[...]


Wat let videokaart fabrikanten om in hun drivers een nieuwere versie van opengl32.dll mee te leveren? Of games zelf om die mee te leveren?

Omdat daar ook custom windows code in staat (de wgl* functies), die dan gerepliceerd moet worden in de custom dlls maar waar de hardware vendors uiteraard geen rechten van hebben.

Maar zoals ik al zei, je kan gewoon linken met een library die alle extensies voor jou uitzoekt en direct die functies beschikbaar maakt, zonder dat je moeilijk hoeft te doen met allerlei typedefs en functiepointers.

quote:

EvilB2k schreef op vrijdag 16 mei 2008 @ 18:04:

Shaders is een begrip die al zo oud is als de weg naar rome. Het stamt al uit de tijd van de eerste 3D animatie experimenten. In 3D land is een shader eigenlijk een oppervlakte/materiaal beschrijving... Dus hoe reageert deze op licht? Hoe ziet de texture er uit? Hoe wordt het object gedeformeerd, of hoe wordt het licht gedeformeerd op het moment dat dit door het object schijnt?

Duh . Met "shaders" bedoelde ik de vertex en pixel shader programma's die uitgevoerd worden door de videokaart, wat tov de fixed function pipeline, die nogal lineair en gelimiteerd was, een hele vooruitgang was. Ook die dingen heten shaders, en ik had het dus niet over de algemene wiskundige benadering van bepaalde shading

.oisyn wijzigde dit bericht 16-05-2008 18:22 (38%)

Ik denk dat het in deze discussie eerlijker is om dx10.n te vergelijken met OpenGL 3.0>

Historisch gezien is elke interface binnen de IT industie maar beperkt houdbaar. Het is mooi als een interface backwards compatible is bijvoorbeeld maar meestal zorgt het voor nieuwe problemen. Ik 'geloof' dus bijvoorbeeld niet tussen goed/slecht bij OpenGL en D3D, maar ik prefereer OpenGL wel omdat het gewoon *meer* platformonafhankelijker is. En van alle personal computers met 3d-toepassingen is het PC-platform wel het meest gebruikt.

Bij OpenGL/D3D is het nog zeker pikant dat het een zware hardware based interface is. Over 20 jaar is je Geforce 9800 helemaal niets meer waard en waarschijnlijk stuk en heb je dus ook niets meer aan software die geschreven is op OGL3/D3D10.

Net zoals je nu met veel pijn en moeite via emulators de games van 20 jaar geleden kan draaien.

Een voorbeeld van een veel duurzamere interface is denk ik QT. Dit is pc-platform onafhankelijk (Win32/64,linux,bsd,darwin etc) maar is wel een extra abstractielaag (en dus overhead).

Uiteindelijk moet je dus kijken hoe lang je je spel wil gebruiken. Voor de meeste spellen zal het 2-3 jaar zijn en dan is het geen probleem om met de dan actuele 3D-interface te programmeren.

quote:

EfBe schreef op donderdag 15 mei 2008 @ 22:00:
Het gevolg is dus dat iedere OpenGL programmeur met lijsten met function pointers en typedefs zit om die extensions aan te spreken. Maar zo'n ramp is dat nou ook weer niet, want veelal is dat 1 keer oplossen en dan is het eigenlijk gelijk aan een api callen.

Ik durf je daar wel op tegen te spreken eigenlijk. Al een aantal maanden ben ik bezig met een redelijk geavanceerd programma om 3d modellen mee te maken, en ik vind het werkelijk een ramp.

Op zich heb je gelijk en is het niet zo moeilijk om de extensies aan te spreken. Zeker niet als je een spelletje maakt en het maar 1x hoeft te doen. Maar wanneer je meerdere contexts tegelijkertijd gebruikt, en ervoor moet zorgen dat de functies van de extensies samen met de bijbehorende context gebruikt worden, dan wordt het al snel een heel geregel met overbodig gezeur om de boel op de juiste manier aan de praat te houden. Heerlijke manier ook om meer zinloze bugs mee te introduceren.

Tuurlijk, je kan kant-en-klare oplossingen als glew gebruiken, maar dat levert verschrikkelijk smerige code op, waarbij je variabelen als "GLEW_MX" moet definieeren om een andere variant van die bibliotheek te bouwen, en daarna met GLEWContext's en een berg macro-shit aan de slag moet om het aan het werk te krijgen.

Een redelijke kick, maar volgens mij wel een interessant onderwerp en dus reageer ik er toch nog even op.

quote:

Stukfruit schreef op zaterdag 17 mei 2008 @ 10:21:
Tuurlijk, je kan kant-en-klare oplossingen als glew gebruiken, maar dat levert verschrikkelijk smerige code op, waarbij je variabelen als "GLEW_MX" moet definieeren om een andere variant van die bibliotheek te bouwen, en daarna met GLEWContext's en een berg macro-shit aan de slag moet om het aan het werk te krijgen.

Dit probleem herken ik persoonlijk niet. Toegegeven ik ben een (in mijn eigen ogen) beginnend OpenGL programmeur (heb de Superbible door gewerkt, daarnaast heb ik een paar redelijk geavanceerde gpgpu programma's geschreven waarvan één OpenGL/GLSL om vortex detection te doen en de ander OpenGL/Cg die fluid simulation deed. Daarnaast ben ik bezig geweest met een eigen 3d bestandsformaat, met exporter vanuit Blender en een OpenGL viewer), maar ik vind Glew fijn werken. Het enige wat je doet is een functie aanroepen om te checken of OpenGL 2.0 ondersteunt wordt en glew initialiseren. Ik doe niets met variabelen definieren of macro's gebruiken en het werkt prima.

Met DirectX heb ik geen enkele ervaring, ik programmeer alleen onder Linux dus dan kom je toch uit bij OpenGL. Wat ik vooral jammer vind is dat OpenGL 3.0 nog steeds niet het levenslicht heeft gezien. Deze nieuwe API zou al een jaar geleden tot standaard verheven zijn, maar is nog steeds niet verschenen en het is angstvallig stil. Misschien dat er over een aantal weken op Siggraph 2008 iets naar buiten komt, laten we het hopen. Voor zover ik weet zou OpenGL 3.0 een schonere en consistentere api op moeten leveren, waardoor het programmeren in OpenGL wat eenvoudiger wordt.

Overigens zijn games lang niet het enige meer waarvoor je een 3d api nodig hebt. Vooral in de wetenschappelijke wereld wordt voornamelijk OpenGL gebruikt (voor bijvoorbeeld visualisatie van grote hoeveelheden data of voor gpgpu).

Ik kan me overigens goed voorstellen dat game ontwikkelaars DirectX gebruiken vanwege de ondersteuning die je erbij krijgt, de (waarschijnlijk iets) betere drivers en omdat 95% van de games nu eenmaal onder Windows draait of op een console. Afgezien van het feit dat OpenGL 3.0 nu al veel te lang op zich laat wachten, denk ik dat de opzet van OpenGL best goed zou kunnen werken. Nieuwe functies in hardware kan direct ondersteunt worden via een extensie en de extensies die door de grote hardware fabrikanten ondersteunt worden en die door de developpers veel gebruikt worden kunnen in een volgende standaard tot de verplichte kost behoren. Dus werkt het juist andersom als bij DirectX: de hardware bepaald de standaard, hoewel je door het systeem van de extensies niet tegengehouden wordt om de nieuwste hardware te gebruiken als de nieuwe functies nog niet in de standaard zitten.

Ik hoop dat OpenGL met versie 3.0 weer eens flink van zich laat horen en dat er weer wat meer beweging komt in 3d api land. Zelf blijf ik voorlopig in ieder geval OpenGL programmeren, met als redenen dat ik onder Linux werk (en dat ik het eventueel naar Windows kan porten als ik dat zou willen), dat ik er al bekend mee ben en omdat ik een beetje een idealist ben .

Overigens net even op de Siggraph pagina gekeken, dit zal ik met veel belangstelling volgen (hopelijk lukt dat een beetje via internet):
http://www.khronos.org/ne...08_los_angeles_california

quote:

Khronos BOFS & BOF Socials

Get the inside scoop on OpenGL from the ARB and leading OpenGL companies:

* OpenGL 3.0 Specification Overview
* OpenGL hardware and driver plans - AMD, Intel, NVIDIA
* Developer's perspective on OpenGL 3.0
* The new Khronos Compute Working Group and how that affects OpenGL
* and more...

quote:

The Flying Dutchman schreef op donderdag 24 juli 2008 @ 12:06:
Overigens zijn games lang niet het enige meer waarvoor je een 3d api nodig hebt. Vooral in de wetenschappelijke wereld wordt voornamelijk OpenGL gebruikt (voor bijvoorbeeld visualisatie van grote hoeveelheden data of voor gpgpu).

Volgens mij zijn 3d api's in eerste instantie niet voor games ontwikkeld maar voor ontwerpers (CAD, auto ontwerp etc) en wetenschappelijke doeleinden.

Direct3D (DirectX in het algemeen) is volgens mij wel in de eerste plaats voor games ontwikkeld (Niet dat er geen andere applicaties mee gemaakt kunnen worden).

OpenGL dient nog steeds het eerste doel, en is nog steeds de main api voor veel 3D ontwerp programma's (denk aan 3ds MAX, maya, autocad, solidworks etc).

Een pluspuntje voor OpenGL vind ik dat het netwerk transparant is, op unix met X-Window. (vroeger op een SGI server software gedraaid waarvan de output inclusief OpenGL op een client draaide).

quote:

epic007 schreef op dinsdag 29 juli 2008 @ 13:34:
[...]
Een pluspuntje voor OpenGL vind ik dat het netwerk transparant is, op unix met X-Window. (vroeger op een SGI server software gedraaid waarvan de output inclusief OpenGL op een client draaide).

Nu ben ik wel benieuwd. Wat bedoel je met netwerk transparant?

Onder unix (linux) kan je standaard remote applicaties naar je lokale display redirecten.

Zo werkten wij (ergens in het jaar 2000) met een duur 3d ontwerp pakket waarvoor we maar 1 licentie hadden. Ieder werkte achter een SGI werkstation, en de applicatie werd gewoon 4 keer opgestart op onze server. De display (+ OpenGL output) werd lokaal zichtbaar, zo konden we met zn vieren van een licentie gebruik maken.

Ik weet niet of dit onder linux ook out of the box werkt maar dat zou wel moeten.

http://en.wikipedia.org/wiki/GLX