Hi, mal ne kurze Frage in die Runde, an diejenigen, die WebGL nutzen (eigentlich weiss ich ohnehin nur von 2 ^^)
Wieviel sind bei euch so durchschnittliche FPS Raten im Verhältnis zur Szene?
Ich habe momentan einen einfachen Shader, der ein Quad im 3D-Raum rotieren lässt und eine Textur drauf anbringt, und die FPS Zahl variiert zwischen meinem (sehr leistungsfähigen) Desktoppc mit 75fps bis zu 100fps auf einem (eigentlich viel schwächeren) Mac...


Wenn ich allerdings dazu im Vergleihc meine normale GL-Engine nehme und 30.000 vertices ohne Frustums usw einfach nur als VBO zeichnen lasse, bewegen sich die FPS jenseits der 1000. Liegt die geringere Zahl bei WebGL am Browser? 100 ist ja vollkommen okay, ich will nur mal wissen, ob das normal ist

Also das wesentliche Problem liegt darin, dass der Browser das Bild per Software zusammensetzen muss. Der WebGL-Canvas ist ja nur ein HTML-Element, d.h. es könnte andere HTML-Elemente darüber geben (*). Du kannst im wesentlichen rendern was du willst....echte Auswirkungen hat nur die Größe des Canvas.

(*) wie z.B. die Menüs in UC/WGT, oder einen transparenten 2D-Canvas um Text zu rendern.

_________________
Yeah!

Es läuft aktuell die Entwicklung kommender JavaScript Interpreter, welche ernsthaft für Webbased Games genutzt werden können.
Google's v8 ist in Chrome2 so stark verbessert worden, dass man sogar software renderer und raytracer vollständig auf javascript basiert laufen lassen kann und bei 240x160 hat der raytracer bei mir mit 180ms pro Frame auf ein Centrino vPro 2 schon ordentlich gerockt. 2D Physik und andere dinge kann man bei Chrome auf der seite finden.

FireFox3.6 hat ihren javascript interpreter auch ein bisschen verbessert aber Mozilla ist nicht ohne Grund der beliebteste Browser im Weltweitem Ranking und entwickelt seit kurzem ein Jit für javascript und der ist jetzt schon in den ersten tests 3mal schneller als der v8, welcher aktuell der schnellste javascript interpreter im netzt ist.

Safari 4 hängt nicht weit weg vom FireFox 3.5 aber ist teilweise 20x langsamer als z.B. v8 aber im Vergleich zu IE7 und IE8 ist safari 4 ein F11 Jäger.
IE8 hatte zu IE7 stark verbessert aber liegt so weit abgeschieden von der Konkurrenz, dass es fraglich ist ob man WebGL-Games ernsthaft drauf entwickeln kann(was eh noch fehlt).

Javascript hat seine stärken im Number chrunching, wärend viele scriptsprachen beim numer chrunching vergleichsweise wesentlich langsamer sind als z.B. bei logik oder IO.
v8 ist aktuell die offiziell 3 schnellste Scriptsprache, wärend auf Platz 2 Lua liegt(wen verwundert es) und man glaube es kaum aber auf Platz 1 liegt auch Lua ^^ aber nicht mit der Lua library interpretiert sondern mit der LuaJit library. Diese Bibliothek nutzt ein Jit und ist in den meisten standard Benchmarktest so schnell wie FreePascal und schneller als Java Server 6. Die Bibliothek ist in Version 2.3 beta und wird von einem Deutschen Programmierer entwickelt und gepflegt. lua und luaJit sind komplett kompatibel zueinander der Entwickler sagt, dass er noch einiges an Performance gewinnen wird, mit der Release version. Google ist der größte Geldsponsor von diesem Projekt und laut eigenen angaben nutzt Google diese Bibliothek auch selber.
Google will auch noch ihren v8 um Jit erweitern, um wieder an der Spitze der Javascript Interpreter zu sein.
Lua und Javascript Syntaxmässig ja recht unterschiedlich, wärend Javascript den typischen Java/c mischung hat geht Lua ein c stiel aber auf tabellen basis.
Daher ist lua sehr beliebt, weil man sagt, dass ein Programmierer ca 2h und ein nicht programmierer ca 1 Tag zum einarbeiten braucht. Tabellen sind logisch und Lua ist nicht zwingend Klassenbasiert und hat auch nur ne Handvoll datentypen(Zahl(double),String(cstring),Userdata(pointer),function und Metadata(tabelle zum überladen von operatoren um klassen und numerische arethemtik zu verändern)). Lua ist ausserdem für sein kleinen footprint(LuaJit 120KB speicher mit allem drum und dran) und extrem schnelle function call bekannt(stack aufbau und abbau werden in c und in der Sprache an der die lib angebunden wird gemacht). Solche Möglichkeiten kann man natürlich auch in anderen Scriptsprachen prima um setzen und damit könnte man ernsthaft games mit WebGL und Javascript entwickeln. Ich denke, dass Mozilla ihr Javascript Interpreter, auf Jit basis, und der künfitge Chrome v8 konkurrent durchaus ähnliche Leistung erreichen werden und damit schneller als java und c# sind, welche aktuell als Lösungen für 3D Webapps genutzt werden.

Interessant wird es allerdings erst werden, wenn FF3.6 released.
FF ist der Weltweit meist genutzt Browser(laut w3c statistik Dezember 2009) und ist auf allen OS verfügbar.
Chrome2 ist zwar jetzt schon verfügbar aber nur auf windows und hat auch nur einigen IE und opera User bewegt hin zu wechseln(FF hatte mehr anteile zum vorjahr gewonnen also nichts an die konkurrenz verloren), IE6-7 sind langsam am aussterben und wird fast nur noch in England genutzt(ohne witzt dort wird IE6-8 mit den höchsten anteilen gezählt), IE8 hat sich größe Anteile von 6 und 7 geholt aber insgesammt hat IE6-8 Anteil abgenommen und ist nur noch so ernst zu nehmen wie safari oder opera.
Safari Nutzer haben allerdings schon eine weile den Genuss von WebGL, dank des WebKit.
Insgesammt kann man sagen, mit FF3.6 und Safari 4 wird man ca 3/4 der Nutzer auf HTML5 bringen und eh IE9 mit HTML5 kommt ist wohl schon HTML6 auf dem weg -_- .
Man sollte sich auch mal fragen, wieso es mehr IE6/7 Nutzer als IE8 gibt, wo Microsoft einen gerade zu IE8 aufzwingt, wenn man Updates zieht und dies sogar mal ein gutes Update wäre in anbetracht auf Leistung und Sicherheit.
Diese Nutzer kann man dann auch getrost als nicht Potenzielle Zielgruppe für WebGL basierte Apps sehen.

Aktuell gibt es noch das Problem, dass man keine s3tc bzw. die neuen compressed texture in WebGL nutzen kann. Dies würde viel Performance bringen, da bei GPU supported compression es nicht um die Filegröße geht sondern um den Speicherplatzverbrauch und den Fakt, dass das Texturelookup schneller läuft und somit höhere Framerates mit sich bringt.
Ein Problem was ich noch nicht gelöst gesehen habe ist der schutzt des Javascript Codes, da er ja auf dem Client geladen, interpretiert und ausgeführt wird.
Das würde Kommerzielle Nutzung ein Dorn im Auge sein, da die Konkurrenz auf den Code bauen kann.
Procedurale Generierung und GPU basierte Generierung von Ressourcen wird wohl ein starkes Thema werden, da Traffic nun mal auch Geld kostet und im Gegenteil zu zur Boxed version immer und immer wieder vom Server geladen werden wird.
Ich hab im Web auch schon Prozeduralen Content mit WebGL und Javascript gesehen also beschäftigen sich schon einige aus der Demoscene mit.

edit: Wenn sich wer fragt wieso ich von Release FF 3.6 rede, unter Fedora12 z.B. ist FF3.6 noch nicht frei gegeben. Er ist für alle Platformen verfügbar aber in einigen Linux Distro noch nicht im Package Manager. Unter Windows hatte die ff 3.6 die WebGL Implementierung noch nicht drin, was mich verwundert. Die Minefield Version musste ich mir dort extra laden. Bei Fedora hänge ich wie gesagt noch auf der 3.5.8 rum :\ Also scheint wohl erst mit 3.7 die WebGL aktiviert zu sein *stöhn*.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Offtopic:

Weil 3.6 ein bisher nicht geschlossenes Sicherheitsloch hat.

_________________
Yeah!

Oh, danke für die Info.
Ich hab mir noch für Linux Minefield gezogen aber da aktuell die ATI Treiber nicht mit X.org 7.5 kompatibel sind, kann ich kein WebGL nutzen.
Meine RadeonHD Treiber supporten bisher nur OpenGL1.5 mit fragment programmen und man braucht ja schon GLSL 120 :\
Die aktuelle Minefield Version(FF3.7.x) scheint schon den jit drin zu haben, der Raytracer, welcher unter 3.5.8 mit 220ms pro Frame lief, mit 3.6 mit 190-200ms pro Frame braucht in der aktuellen Minefield version sage und schreibe 22-37ms pro Frame O_o
http://jupiter909.com/mark/jsrt-anim.html

Google fährt aktuell mehrere Wege, das O3D Team ist auch für WebGL in chrome zuständig und dann gibt es noch native client plugin, welches erlaubt c,python,lua,perl,java code auf dem client aus zu führen, wenn die entsprechenden binaries dort installiert sind. Ich denke, wer auf 3D Plugin basierten kram steht sollte die Finger von den Lösungen lassen und besser mit Firebreath http://code.google.com/p/firebreath/ bekanntschaft machen. Firebreath ist ein Framework zum erstellen von Plugins, die auf allen größeren Browsern laufen(ActiveX und NPAPI).
Sobald man es geschafft hat ein RenderContext vom Browser zu bekommen kann man sein normalen gl kram nutzen. Das Framework bastelt ein basiscode per script zusammen und man fügt dann nur noch an den bestimmten funktionen sein code rein, um es mit dem eigenen code zu verbinden. Augrund von C++ compilat ist die Sache um ein Vielfaches schneller aber man hat ein Plugin :\

Wenn ich keine Lösung für den offene Javascript code finde, werde ich wohl ein Plugin schreiben und über dieses arbeiten, statt WebGL mit javascript zu nutzen.
Im Prinzip wäre das dann neben Unity3D, Shiva3D, O3D, UE3 Webplayer, ID-QuakeLive Webplayer und so weiter noch eine Plugin basierte Lösung, was ich eigentlich vermeiden wollte :\
Jemanden dazu zu bringen ein Plugin zu installieren ist echt schwer und wenn man es ihm noch so einfach macht.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004