Webkit bouwt 3d-versnelling in met WebGL

De motor van onder meer Google Chrome en Safari beschikt sinds kort over 3d-versnelling. De ontwikkelaars van de Webkit-engine hebben daartoe ondersteuning voor WebGL toegevoegd, een 'javascript-tussenlaag' voor OpenGL.

Webkit, de browser-engine die door onder meer Safari en Google Chrome wordt gebruikt, beschikt sinds korte tijd over ingebouwde 3d-versnelling. De functionaliteit is al beschikbaar in 'nightly versies' van de opensource-engine. De Webkit-ontwikklaars kozen hiertoe voor WebGL, dat is bedoeld om 3d-functies te bieden zonder dat het installeren van een plugin noodzakelijk is. WebGL is feitelijk een tussenlaag die het mogelijk maakt om de OpenGL ES-api, die is bedoeld voor gebruik op mobiele apparaten, via javascript aan te roepen.

Waarschijnlijk gaan ook Mozilla en Opera WebGL in hun browsers implementeren. Eerder gaf Google al aan van plan te zijn om, door middel van de eigen O3D-api, 3d-support aan Chrome toe te voegen. Met de komst van WebGL in Webkit zal Google Chrome over twee verschillende 3d-functies beschikken; de developers van O3D hebben al aangegeven dat hun api niet uit Chrome zal verdwijnen, aangezien javascript volgens hen ongeschikt is voor het renderen van ingewikkelde 3d-graphics.

Reacties (65)

[Faust]

Als firefox gewoon ook de (vele malen geavanceerdere) webkit-render engine in gebruik neemt, dan hoeven ze het niet erin te gaan poorten en kunnen ze de nieuwe ontwikkelingen veel makkelijker implementeren.

Het zou ook wel prettig zijn voor het webkit browser-aandeel, het zou in 1 keer kunnen verdriedubbelen

edit: goed gelezen inderdaad, ik zei 'geavanceerdere', en niet 'beter'.

[Reactie gewijzigd door Faust op 3 augustus 2024 00:59]

[David Mulder]

... eh... nee... ooit gehoord dat webkit xul ondersteund... en dat is toch wel het allergrootste voordeel van firefox (xul maakt de addons van firefox mogelijk). Daarnaast is het enige voordeel van de webkit render engine dat ie wat sneller is, maar geavranceerder... hoezo? (Maximaal eerder met het toevoege van experimentele css3 en html5 tags).

Maar daarbuiten betwijfel ik of het gebruik van WebGL de slimste optie was, de reden daarvoor is dat ikzelf als javascript programmeur toch moet zeggen dat javascript absoluut geen taal is voor ingewikkelde systemen en eigenlijk zouden firefox/webkit/opera om de tafel moeten gaan zitten en een totaal nieuwe taal moeten ontwikkelen. Javascript is 1 grote rommel geworden en zover ik zie gaat WebGL ook niet echt helpen.

[_Thanatos_]

WebKit heeft bijna geen CSS3 (en Gecko ook niet trouwens). Ze implementeren vendor-specific properties, en dat mag je daardoor ook CSS1 noemen. Dat het sterk op CSS3 lijkt, maakt het nog geen CSS3.

Wat dat betreft zit er meer CSS3 in de Presto 2.2 engine (die van Opera 10).

[Reactie gewijzigd door _Thanatos_ op 3 augustus 2024 00:59]

[cmegens]

Technisch gezien heb je helemaal gelijk.

In de praktijk kan ik echter met webkit en gecko al wel CSS3 styling toepassen op mijn sites, waar dat in Opera nog niet veel doet. Round-borders en shadows besparen me nu al echt heel veel tijd en divitis op sites waar ik het kan gebruiken.

Het feit echter dat IE8 nog niks met CSS3 doet wil dus zeggen dat het zeker nog 5 jaar gaat duren voordat we echt op CSS3 kunnen gaan vertrouwen en het implementeren. IE9 zal waarschijnlijk voorzichtig de eerste CSS3 gaan ondersteunen, en eer dat IE9 de populairste browser is tegenover IE7 en IE8 ben je ook al weer een paar jaar verder. Het wordt tijd dat ze bij Microsoft eens een transparante en lichte update functie gaan inbouwen, want dit duurt te lang.... (vandaag de dag nog steeds 10% IE6 bezoek is te gek voor woorden). CSS3 kan ook in IE8.1 ondersteund worden, mits dat je mensen aan het updaten krijgt....

Als er dus van mij iemand over mag op de webkit engine, dan is het Microsoft. Ze hadden de kip met het gouden ei in huis (Tantek Cilek) maar die hebben ze weggewuifd.

[kozue]

Zolang de spec nog niet compleet is, zit er in geen enkele browser ook maar iets van css3, ook niet in opera. Hoogstens iets wat er veel op lijkt of wat ooit css3 gaat worden.

[RobertMe]

Zoals Anne ook al zegt, dit is volledig appels en peren vergelijken. Niet alleen het WebGL/Javascript gedeelte. Maar wat heeft xul tegenwoordig met Gecko te maken? Het enige wat Webkit en Gecko doen is HTML renderen. Dat er toevallig een schil om die render engine is die een extensie systeem heeft heeft niks met de render engine te maken. Wine gebruikt ook Gecko, maar ik kan je verzekeren dat ik in wine niks met xul kan doen.

[Little Penguin]

Het enige wat Webkit en Gecko doen is HTML renderen.

Mozilla Firefox maakt gebruik van Gecko om XUL te renderen, zonder Gecko kan men echt geen XUL renderen. Gecko doet dus meer dan HTML renderen (dat geldt overigens ook voor WebKit, beiden renderen ze namelijk ook SVG).

Wine gebruikt ook Gecko, maar ik kan je verzekeren dat ik in wine niks met xul kan doen.

Dat men vanuit Wine niets aanbied op het gebied van XUL dat is niet zo vreemd. Men kan het namelijk d.m.v. een compiler-directive weggeconfigureerd hebben. Ten slotte is het doel van Gecko onder Wine het aanbieden van een alternatief voor de standaard Win32-render engine en XUL kan niet door die engine gerenderd worden.

[Reactie gewijzigd door Little Penguin op 3 augustus 2024 00:59]

[kozue]

Wine gebruikt ook Gecko, maar ik kan je verzekeren dat ik in wine niks met xul kan doen.

Onzin. Wel eens in wine's gecko gekeken? Hiero zit er een 17.8MB grote xul.dll bij...
Standaard wordt het niet gebruikt omdat de gecko component puur een vervanging is voor de embedded trident engine van IE, en die ondersteund dat natuurlijk niet.

[Verwijderd]

Hmm. Appels en peren. WebGL is een API, JavaScript is een programmeertaal. Wat is er zo'n grote rommel in JavaScript?

[Kiphaas7]

Vele malen geavanceerdere? Ze zijn het snelste met het implementeren van nieuwe features, maar als je met geavanceerd ook direct de beste bedoeld, zet nogal een gedurfde uitspraak neer...

[Little Penguin]

Waarom zou men bij Mozilla over moeten stappen op WebKit? Het is juist goed dat er verschillende concurerende render engines zijn, op die manier houdt men elkaar scherp...

Verder is er ook het een en ander af te dingen op WebKit, dus laten we het qua keuze op het gebied van render engines maar zo houden als het nu is. (Verder is de UI van Fx ook nog eens gebaseerd op de Gecko engine en zou men die volledig moeten herschrijven als men op WebKit over zou stappen).

[DelTorro]

Wat moet ik me hierbij voorstellen? Kunnen hier alleen zelf getekende objecten mee worden getoond? Ik stel me namelijk voor dat je zo meteen bijvoorbeeld artikelen in een webshop in 3d kunt bekijken of zit ik dan helemaal verkeerd?

[.oisyn]

Het zijn gewoon javascript bindings voor OpenGL. Met andere woorden, je kunt javascript gebruiken om polygonen te renderen op een canvas element binnen een webpagina. Daaruit volgt dat je idd 3d objecten kunt tonen, maar dan moet die webshop uit je voorbeeld wel alle 3d modellen voor die artikelen aanleveren, dus dat zie ik eerlijk gezegd niet snel gebeuren...

Maar feitelijk is het hiermee mogelijk om een complete 3D game te maken. Het probleem is echter dat het geen 3D engine is - het is slechts een rendering API. Je moet dus zelf nog alle geometrie processen voor visibility en belichting en dat soort zaken, en dat zijn nou niet echt dingen die je in Javascript wilt doen.

[Reactie gewijzigd door .oisyn op 3 augustus 2024 00:59]

[Antipater]

Opengl ES 2 doet kan wel wat meer dan polygonen renderen, onder andere belichting. Je hebt ook de mogelijkheid shaders te programmeren dus je kan zelfs natuurkundige meuk aan de graka uitbesteden.

[.oisyn]

OpenGL doet helemaal niets, behalve je GPU aansturen. En de GPU is niets anders dan een veredelde polyfiller. Dat je daarbij dingen als shaders kunt gebruiken om bepaalde dingen uit te rekenen op vertex- of pixelniveau (zoals belichting) of dat er in de API bepaalde utilities zitten om die shaders en constants voor je in te stellen, wil niet zeggen dat het daarmee een 3d engine wordt. Je moet aangeven welke lichten actief zijn, en vervolgens worden alle polygonen met die lichten gerenderd.

Wat een 3D engine doet is op basis van alle informatie in de wereld een selectie maken van wat er op het beeld te zien is en met welke lichten objecten getekend moeten worden. Zonder dit voer je namelijk alle data gewoon aan de GPU, en dat wordt zo traag als stront door een trechter.

De CPU is dus een belangrijke factor in het hele proces, en javascript is niet bepaald de taal bij uitstek om dat allemaal in te implementeren.

[Reactie gewijzigd door .oisyn op 3 augustus 2024 00:59]

[kozue]

Voor zover ik weet kun je dat soort taken allemaal door je videokaart uit laten voeren tegenwoordig, en is je cpu helemaal niet zo belangrijk meer. Een videokaart een veredelde polyfiller noemen is wel wat kort door de bocht, je kunt er zelfs video mee laten decoderen (bv VDPAU).

[.oisyn]

Voor zover ik weet kun je dat soort taken allemaal door je videokaart uit laten voeren tegenwoordig

Sorry, maar dan heb je een totaal verkeerd beeld wat een videokaart precies kan, namelijk pixels plotten waarbij per pixel een programmaatje uitgevoerd wordt. Als je echter alle polygonen en alle lichten naar de GPU stuurt dan verzuipt ie in de data. Daar is aansturing voor nodig vanaf de CPU. Waarom denk je dat er 3D engines gemaakt worden, als de videokaart het toch allemaal zelf kan? Visible surface determination is een heel belangrijk proces in een 3D engine. Ik zal eens een globale omschrijving geven hoe dat er in Tomb Raider en Deus Ex 3 aan toe gaat, aangezien ik die code heb geschreven.

De wereld is effectief opgedeeld in cells, die weer verbonden zijn middels portals. De cell structuur staat opgeslagen in een bsp tree, zodat je makkelijk voor een willekeurig punt uit kunt vogelen in welke cell hij staat. Dit wordt oa gedaan voor alle objecten in de wereld, zodat deze in de cells geplaatst kunnen worden. Ook voor de camera en de lichten. Vervolgens wordt er vanuit het camerapunt door de cells heen getraced. In eerste instantie begin je met view volume die gelijk is aan het view frustum in de start cell. Vervolgens wordt, voor elke cell die je tegenkomt, het view volume aangepast aan de hand van de occluders die in de cell staan (dit zijn grove objecten waar je niet doorheen kunt kijken - handig voor bepaalde muurtjes die niet groot genoeg zijn om de cellstructuur daarvoor aan te passen). Dan wordt met dat volume alle objecten in die cell getest, en alle objecten waarmee het volume snijdt worden aangemerkt als 'zichtbaar'. Vervolgens worden alle portals in de cell langsgelopen, en wordt het viewvolume aangepast zodat alleen het gedeelte dat door de portal gaat overblijft, en met dat nieuwe volume begint het hele proces in de aansluitende cell van voor af aan. Net zo lang tot je niet meer verder kan. Zo'n zelfde proces gebeurt ook voor de lichten in de wereld. Natuurlijk zijn er tal van optimalisaties die ervoor zorgen dat er dingen niet meerdere keren berekend hoeven te worden, zodat de boel snel blijft draaien.

Nou kun je voor een dergelijk proces ook wel deels een GPU inzetten, maar dat gaat wel ten koste van je daadwerkelijke graphics en daarnaast is een CPU veel beter in al die hierarchische structuren en het aanspreken van geheugenplekken op willekeurige locaties (waar de GPU het meer moet hebben van gelijkwaardige parallelle berekeningen met geheugen waarin alles mooi bij elkaar staat)

Een videokaart een veredelde polyfiller noemen is wel wat kort door de bocht, je kunt er zelfs video mee laten decoderen (bv VDPAU).

Ja duh, weet je hoe ze dat doen? Meerdere passes een full-screen quad tekenen met de decoding logic in de pixel shader. Wellicht dat dat voor jou allemaal zo bijzonder is, maar wat mij betreft niet heel erg

[Reactie gewijzigd door .oisyn op 3 augustus 2024 00:59]

[DCK]

Hopen dat Mozilla en Opera dit ook implementeren inderdaad. Als dit een webstandaard wordt betekent dat een duwtje in de rug van OpenGL die het wel kan gebruiken.

[RobertMe]

Hoe het bij Firefox zit weet ik niet, maar Opera is hier hoogst waarschijnlijk mee bezig, gezien hun nieuwe grafische backend Vega Dit komt hoogst waarschijnlijk in de Opera versie na 10.10, waarvan we de eerste builds misschien nog dit jaar kunnen verwachten.

[ultimasnake]

Helaas gaat dit de webdeveloper alleen maar meer ergenissen oproepen ben ik bang, vooral omdat er nergens IE wordt genoemd. Ook zie ik wel weer voor me dat je dan dus nog meer rekening moet houden met browser/ openGL(webGl) versie/ systeem specs..

Verder wel gaaf, de laatste tijd ben ik niet meer zo bezig met flash maar kan die dergelijke 3dobjecten al proper renderen? En dan bedoel ik ook echt een model, niet zoals swift3d vroeger (vrij slim) deed.

[Rynus_Rein]

Ben blij dat IE niet wordt genoemd (denk aan Microsoft-only 'standaarden' uit het verleden die niet door andere browsers geaccepteerd worden)!
Als de rest van de browsers het implementeert komt Microsoft vanzelf over de brug (vroeg of laat) met een IE implementatie. En gezien de snelle ontwikkeling van IE de laatste jaren is dat nog niet eens zo'n gek idee.

Leuke ontwikkeling overigens, alleen vraag ik me af of JavaScript snel genoeg is voor volwaardige games binnen de browser. Daarvoor gebruik ik liever zoiets als Unity3D: http://unity3d.com/ (wat overigens nog cross-platform is ook), het nadeel is natuurlijk wel weer dat Unity niet gratis is.

Zie voor de web-demo van Unity3D die er overigens helemaal niet slecht uit ziet: http://unity3d.com/galler...ex.html#tropical-paradise (je hebt wel een plugin nodig).

[Reactie gewijzigd door Rynus_Rein op 3 augustus 2024 00:59]

[Verwijderd]

Waarschijnlijk gaan ook Mozilla en Opera WebGL in hun browsers implementeren.

Sterker nog, ze hebben al delen geïmplementeerd. Zie hier:

• https://bugzilla.mozilla.org/show_bug.cgi?id=513156
• https://bugzilla.mozilla.org/show_bug.cgi?id=513156

Het is dus, net als bij Webkit, work in progress... Voorlopig nog alleen in de nightly-builds van Minefield 3.7.

[Reactie gewijzigd door Verwijderd op 3 augustus 2024 00:59]

[DiSiLLUSiON]

Waarom gaan de meeste mensen er vanuit dat de enig mogelijke toepassing van deze technologie het realiseren van volwaardige 3D spellen in de browser is?

De gedachte die het eerst bij mij op komt is dan: ho; back up a bit. 3D spellen? Leuk, maar daar is de brower nog lang, lang niet klaar voor. Maar, dat betekent niet dat de technologie geen toekomst heeft.

Ik zie het meer als een verrijking aan de bestaande mogelijkheden; je kunt nu al 2D (en, met wat truukjes 2.5D) polygonen renderen en bewerken via SVG. Wat deze technologie (zowel WebGL als de andere) hier aan toe kan voegen is een relatief snelle implementatie van 3D. Oké, geen 3D spellen, maar wel interresante 3D effecten die, mits juist toegepast, een website een extra dimensie (pardon the phun) kunnen geven.

Een browser is nog altijd een applicatie dat documenten laat zien, hoe interactief die documenten dan ook zijn. Ik denk dat je ontwikkelingen als deze dan ook in dat licht dient te zien.

[Reactie gewijzigd door DiSiLLUSiON op 3 augustus 2024 00:59]

[.oisyn]

Ook best wel 3D spellen. Dingen als wolfenstein en doom zijn prima te realiseren (sterker nog, Wolfenstein is momenteel al te implementeren met DOM manipulatie), en iets complexer kun je ook wel gaan (Quake 1 wellicht). Maar idd, een Crysis zal het niet worden, maar die moet je ook helemaal niet willen spelen in een browser

[!null]

Echt alles verhuist tegenwoordig naar de browser. Ik ben benieuwd waar het ophoud.

[VNA9216]

Ze zullen dit door blijven zetten. Straks kan je op die manier al je applicaties via de site van het bedrijf dat het ontwikkeld hebt gebruiken, en dan kunnen ze je doodeenvoudig laten betalen peer keer dat je het opent of per uur dat je het gebruikt enzo.
Straks dus geen duur office pakket meer, maar 5 cent per uur dat je dr mee bezig bent betalen, of 10 cent per document en dergelijke.

Bedrijven kunnen het dan afnemen en op hun eigen servers in het bedrijf te zetten. Dan hoeven ze alleen de browser nog maar te patchen, net als het core OS er onder (dat steeds minimalistischer zal worden), en de applicaties kunnen dan gewoon in 1X op de server voor alle clients bijgewerkt worden.

Tevens ben je langs die weg ook minder hardware gebonden, immers als de functionaliteit van de browser geport is, kan je dat zo om gooien naar een andere processor architectuur. In theorie zou je dan bij grote bedrijven al snel naar een paar zware servers kunnen, en verder gewoon 4-5 watt ARM processortjes kunnen gebruiken voor de workstations. Stel je alleen de stroombesparing eens voor op 10 000-20 000 pc's

[Little Penguin]

Straks kan je op die manier al je applicaties via de site van het bedrijf dat het ontwikkeld hebt gebruiken (...) Straks dus geen duur office pakket meer, maar 5 cent per uur dat je dr mee bezig bent betalen, of 10 cent per document en dergelijke.

Maar zitten wij als gebruikers daar op te wachten, voor een groep mensen lijkt Office gratis (omdat het bij de PC zit) en een andere groep betaald een paar honderd euro voor een MS-Office licentie en hoeft daarna niet meer te betalen.

Ik denk niet dat zoiets een erg hoge vlucht zal gaan nemen, zeker niet zolang er paketten zijn die voor de consument helemaal gratis zijn (denk o.a. aan OpenOffice.org). Op zich kunnen veel gebruikers daar goed mee uit de voeten en is het net zo compatible als de online oplossing - maar dan 100% gratis.

Bedrijven kunnen het dan afnemen en op hun eigen servers in het bedrijf te zetten. Dan hoeven ze alleen de browser nog maar te patchen,

Voor bedrijven kan het mogelijk wel een interessante oplossing zijn, maar moet men wel hard werken op te voorkomen dat die server (of groep van servers) het single point of failure wordt. Op korte termijn zie ik dus eerder een mengelmoes ontstaan van klassieke client-applicaties en web-applicaties, dan dat men hier direct op over zal stappen.

[VNA9216]

"Ik denk niet dat zoiets een erg hoge vlucht zal gaan nemen, zeker niet zolang er paketten zijn die voor de consument helemaal gratis zijn (denk o.a. aan OpenOffice.org). Op zich kunnen veel gebruikers daar goed mee uit de voeten en is het net zo compatible als de online oplossing - maar dan 100% gratis"

Maar vergis je niet, microsoft heeft bijv een behoorlijke machtspositie, als windows 7 de laatste "normale" windows release zou zijn, en ze daarna alleen nog maar een kernel+browser zouden leveren.. En dan voor compatibiliteit met oude programma's een omslachtige manier dr in bouwen om via een web app windows te emuleren voor oude programma's (dat het niet te gemakkelijk gaat) dan zouden de meeste mensen zo overstappen hoor, met name als microsoft het een beetje eenvoudig maakt om die web apps te gebruiken.

Apple heeft in princiepe die infrastructuur ook al een beetje liggen met het feit dat bijna alle mac gebruikers al een .mac account (zo heet het geloof ik) hebben en ze dus geleidelijk aan web apps kunnen introduceren. En met bijv google zn "plugin" om X86 code in de browser te draaien, is dat ook al een stap richting de backwards compatibility die je nodig zou hebben om "oude" programma's nog te kunnen gebruiken.

Eigenlijk zijn alle benodigde technieken er wel al (al zijn ze soms nog niet af/goed uitgewerkt).

Uiteraard zullen ze niet gelijk beginnen met per keer/per uur laten betalen, ze laten je er eerst aan wennen, en dan na 2-3 jaar.. KASSA!
Immers de gratis applicatie servers kunnen ze dan in 1X plat leggen en dan MOET je wel betalen om verder te kunnen werken. Tevens is het ook een mooie manier om opensource software weg te werken (in ieder geval om het te proberen) want iets installeren op je core OS+ browser zal niet meer kunnen, en kleine open source projectjes hebben het geld niet om een applicatie via het web aan te bieden (hosting kosten ed)

[2playgames]

Maar een opensource volledig OS gebruiken kan dan natuurlijk nog steeds

[fevenhuis]

In het geval van 3D is het echter een zeer nuttige implementaie die eigenlijk veelst te laat komt. 3D modellen hebben zeer weinig bandbreedte nodig en bieden de mogelijkheid voor indrukwekkende en geavanceerde webgraphics. Vrijwel alle computers hebben inmiddels redelijke 3D acceleratie, dus CPU cycles heeft het ook niet echt nodig.

Als Google ook nog een gratis design programma maakt voor 3D webgraphics zal het zeer hard gaan met de populariteit van Chrome vermoed ik (mits er ook plugins voor de ander browsers komen).

[.oisyn]

3D modellen hebben zeer weinig bandbreedte nodig

De modellen wel, het is wat dat betreft in feite ook gewoon vectorgraphics, maar dan in 3D. Maar de textures niet. En vandaag de dag, met diffuse, specular, normal en ambient occlusion maps loopt het dataverbruik nogal de spuigaten uit .

[kozue]

Dat lijkt me makkelijk op te lossen door zowel low-res en high-res textures aan te bieden, en bepaalde layers uit te kunnen zetten als je bandbreedte wilt besparen. De meeste games zijn prima te spelen zonder al die lighting maps, alleen ziet het er idd niet zo mooi uit.
Voor breedband gebruikers is het echter geen issue. Niet in NL iig, waar datalimieten ondertussen vrijwel verdwenen zijn.

[kozue]

(mits er ook plugins voor de ander browsers komen)

Het idee is juist dat je geen plugins meer nodig zou moeten hebben. Plugins zijn zo jaren 90. Plugins zijn platform specifiek, en daarom niet altijd beschikbaar (denk bv aan de brakke flash ondersteuning voor linux tot aan versie 9, of het compleet ontbreken van flash op de iPhone), dus ontwikkelen voor een plugin is voor een webdev een risico.

De embedded video functie van gecko is een verademing voor webdevs die video willen gebruiken, zolang tenminste andere browsers dit ook oppakken (voor IE zal het waarschijnlijk alsnog via een plugin moeten omdat MS allergisch is voor de open standaarden die ze er voor gebruiken, zoals theora video). WebGL is hier blijkbaar de tegenhanger van, voor 3d toepassingen, zodat java games op de lange termijn kunnen verdwijnen en gewoon direct in JS gemaakt kunnen worden, direct gerendert door de browser.

Ik hoop dat Mozilla en Opera hier ook snel mee aan de slag gaan. Hopelijk nog voor firefox 3.7? Ik verwacht niet al te veel uit het MS kamp, vooral omdat dit OpenGL gebaseerd is, terwijl MS OpenGL liever zou zien verdwijnen voor Direct3D, maar voor IE kan er dan altijd nog een plugin komen, want ik heb het idee dat IE gebruikers niet zo erg zitten met het installeren van extra software als ze dat opgedragen wordt.

[Rob Coops]

Ik moet de mensen achter Chrome gelijk geven ik ka me niet echt voorstellen dat je complexe 3D weergave in javascript wil af handelen het is nooit bedoelt om dit te doen en is er naar mijn gevoel ook echt niet geschikt voor.
Jammer alleen wel dat het uiteindelijk alleen waarschijnlijk Chrome zal zijn die O3D ondersteunt en dus dat het niet gebruikt zal worden door wie dan ook, maar javascript voor 3D... dat lijkt me bijna net zo slecht als excel voor 3D (kan wel maar je wil het eigenlijk niet)

[Antipater]

Niet in javascript, maar in opengl. Javascript wordt alleen gebruikt om de functies van de videodriver aan te roepen, data door te sturen etc. Als je meuk eenmaal daar is aanbeland speelt javascript geen rol meer.

Javascript heeft beperkingen qua performance en modulariteit, maar is als programmeertaal lang niet zo slecht als iedereen steeds loopt te beweren. Op de implementatie van IE na dan

[.oisyn]

Als je meuk eenmaal daar is aanbeland speelt javascript geen rol meer.

Als je een goede 3d engine wilt opzetten dan speelt programmacode weldegelijk een heel erg belangrijke rol. Je kunt niet zomaar je virtuele wereld aan de graka voeren en zeggen waar je camera staat en dat de GPU vervolgens de rest doet. Je programma moet een grove selectie maken van wat te zien is. Je programma moet bepalen welke objecten naar de shadowmaps getekend moeten worden, en welke objecten belichting van welke lichten ontvangen.

Natuurlijk kom je met de enorme rekenkracht van tegenwoordig wel weg met content van jaren terug, daar hoef je idd nog maar weinig voor te doen om het snel te krijgen. Maar voor een beetje 3D engine wordt je javascript code heel belangrijk.

[Reactie gewijzigd door .oisyn op 3 augustus 2024 00:59]

[Rynus_Rein]

Daarnaast, bepaalde gaming code wil je niet met geïnterpreteerd JavaScript doen, denk aan dingen als AI/pathfinding of berekeningen met matrices. Daarvoor heb je het liefst native gecompileerde code (hoewel .NET ook aardig in de buurt kan komen qua snelheid).

[kozue]

En dan zit je al meteen weer platform specifiek te werken, wat dus volledig tegen het idee achter het web in gaat.

[.oisyn]

Nee niet echt, er is maar weinig platform-specifieks aan dat soort berekeningen. De uiteindelijk gecompileerde programmacode natuurlijk wel, maar de programmacode zelf niet. In native talen als C++ gebruik je daar gewoon cross-platform libraries voor. Een matrixvermenigvuldiging ziet er hetzelfde uit op de PC als op de Xbox 360 en de PS3. De achterliggende machinecode is echter een ander verhaal, maar daar zorgt de compiler / JITter wel voor.

Derhalve zijn dat soort dingen ook wel in Javascript te doen. Waar Javascript echter last van heeft is dat het een dynamische taal is. Waar je met een static taal als C++, C# of Java werkt met vaste klassedefinities, waarin variabelen zich altijd op een vast geheugenadres vanaf het begin van het object bevinden, moet in een taal als Javascript of PHP een variabele worden opgezocht in een object aan de hand van z'n naam, omdat je überhaupt niet van tevoren kunt weten of een variabele wel bestaat. Meestal gebeurt dat middels een hashtable en eventueel wat stringcompares, maar het brengt dus nogal een inherente overhead met zich mee. Met complexe analyses kun je wel heel veel optimaliseren, maar door de dynamiek die de taal in zich heeft is het onmogelijk om het niveau van een statische taal te behalen. En vooral bij processen waarin je met heel veel data werkt, zoals in een 3D engine (path finding, physics, culling, etc.) wil je dat typisch niet in een dynamische taal doen. Een 3D engine ingebakken in een browser waarmee je zou kunnen communiceren (zoals Google enigszins doet met O3D), is dan wel een zinnigere aanpak waarmee je veel complexere dingen kunt doen, omdat je het echte werk op een native niveau aanpakt.

[.oisyn]

Ik moet de mensen achter Chrome gelijk geven ik ka me niet echt voorstellen dat je complexe 3D weergave in javascript wil af handelen

Dat klopt, maar dat wil niet meteen zeggen dat OpenGL bindings voor javascript in een browser niet nuttig zijn. Je kunt er wel gewoon simpele dingen mee weergeven, en ook leuke snelle 2D effecten kun je ermee voor elkaar krijgen.

[wvdburgt]

Hoe ver ligt ie nu inmiddels achter? Webkit is vrolijk 3d css en andere technieken aan het inbouwen terwijl micrsoft een trieste 30/100 scoirt in standaard 2d tecnieken in de acid 3 test. Zelfs mobiele apparaten scoren beter. De iphone haalt al zelfs 100 hoewel nog met fouten.

[Verwijderd]

Webkit is nog niet eens volledig CSS 2.1 complient maar besteed wel tijd aan het inbouwen van ondersteuning speciaal om een acid test te halen.

[Little Penguin]

Op zich heb je hier een punt, aan de andere kant zijn er ook nog browsers die nog steeds niet de diverse DOM-standaarden naar behoren implementeren. En hetzelfde geldt ook voor SVG...

Het zou eigenlijk en-en-en moeten zijn. Dus en het halen van de Acid-test, maar dat kun je bereiken door het volledige implementeren van de standaarden (dat is de 2e 'en') en de laatste dat is het samenwerken aan nieuwe standaarden onder de paraplu van het W3C.

[Verwijderd]

Ow great, OpenGL banners...

[Verwijderd]

GIVE ME A BREAK, hoop t niet

[kozue]

Op wat voor manier is dat anders dan flash, behalve dan dat het hardware accelerated is, dus geen cpu-tijd meer verspilt aan je banners?