Recently I've been working with Three.js in order to render 3D scenes in WebGL. As a fallback, I've also maintained versions using Three's CanvasRenderer that, while they do not have as many polygons, lighting techniques, or effects, can still run in browsers that do not have WebGL capability (and can also run in Safari if the user refuses to enable WebGL themselves).
However, today I realized that compatibility is not merely a question of whether or not the user's browser supports WebGL, but also whether the user's hardware is even rigorous enough to perfectly render WebGL in the first place (i.e. run at 60 fps). While there is a lot of data out there illustrating what percentage of the population uses which web browser, I had trouble finding distributions of users who are running computers more than capable of running WebGL.
What exactly is the percentage of the population that -- assuming they are using a WebGL capable web browser -- can run your average WebGL page at 60 fps? And if it is a large amount of the population who struggle with rendering in WebGL, what would be the best way to detect such shortcomings in hardware? A javascript solution would be ideal since we are already working with Three in that language.
It is very possible that I may be misunderstanding the situation as this does not seem to be a widely discussed issue in the world of WebGL development. If such is the case please let me know so I may better understand how to work with Three in the future.
I had the same issue professionally working with Android - we had a 3D intensive app prior to release of a hardware accelerated Android OS, it ran smoothly on some phones and horribly on others. This issue crops up on any open platform like Android or Windows. iPhones/iPad have a very explicit hardware set, but on the PC you will be getting a range of video cards.
If you use Cg/HLSL shaders you compile to a specific hardware profile which describes the lower bound of the vertex, geometry and pixel shaders. However I'm guessing you're using GLSL shaders and compiling at runtime? GLSL does not target hardware profiles and will simply fail to compile the shader if the hardware in incapable of running it.
Of course, this only gives you an idea of whether the program can execute, not how well it can execute. A shader can compile just fine and run at 5fps.
I was worried about users seeing a bad graphics experience so for our app on the first run I rendered a model to an offscreen target for a brief time and took an average FPS, then disabled the 3D section if the score was too low. You know what? THE USERS HATED IT. Plenty of them had 3D-capable phones and felt cheated that they couldn't see the 3D sections that were in the screenshots. I pushed an update to remove the check, so now if you have bad hardware you'll see the 3D scene running slowly. And we actually had fewer complaints with that experience, even though I hated how inelegant it seemed.
On the positive side, both OS X and Windows (since Vista) support hardware accelerated compositing in the OS (GL/D3D renders all your windows to the screen now). This has pushed most every PC vendor to include 3D acceleration in their computers. So I think it's a safe bet to assume people have a 3D card - whether they have WebGL will be more of a limiting factor. The variety of hardware and drivers also gives you wacky rendering bugs on one machine that appear nowhere else - PC game developers test on a range of cards prior to release in an attempt to mitigate that issue. But these wacky bugs are going to be a tiny fraction of your users at most and are often trivial, so it isn't worth worrying about unless users are complaining.
If you're still worried about performance, the standard solution on the PC is to allow the user to adjust the graphics settings to reduce the complexity of the pixel shader / number of triangles on the screen / etc. Make sure to look at real-world data about what hardware most of your customers own and use that range for targeting and testing.
Anyway, there's a real-world anecdote, HTH.
if you work with three.js you can query for extensions:
gl = renderer.getContext();
exts = gl.getSupportedExtensions();
so if you don't get something like float textures, you get some idea of what you're working with. WebGL is built around the lowest common denominator.
Related
In webgl, a long running glsl code can freeze all the computer.
When browsing shadertoy, some examples especially in fullscreen mode have frozen my mac like this one:
Path Tracer MIS (progressive)
Is there any way to detect whether a shader is taking too much and then to auto-kill it from the javascript level? Or this is above developer reach and needs to be handled by browser developers?
Another question: is there a way (plugin or external application in mac or linux) which prevents a long chrome GPU access from freezing the computer?
It's not just WebGL, all GPU code can freeze the computer. The problem is, unlike CPUs, current GPUs are non-preemptable. That means if you give them 30 minutes of work to do they will execute that work for 30 minutes and there's no way to preempt them to do something else like you can with a CPU. (no multi-tasking)
The solution on a good OS is the CPU runs a timeout and if the GPU takes too long the OS resets the GPU (effectively it reboots it). Windows has done this since Windows Vista. macOS has only kind of added it recently and the issue for them is they didn't design the OS to recover from those kinds of situations like MS did so it's taking them longer to get it all working.
The good thing is there's not much incentive to do it on purpose. If you visit some website that locks your computer you're probably going to stop visiting that site so the problem is usually self correcting since people want you to visit their site.
On the other hand it's a problem for sites like shadertoy where people write extremely long and complicated shaders that are really only designed to run on top end GPUs and not common notebook GPUs.
As far as what you can do about it.
Ask to Apple to fix their drivers and OS so it can't be crashed.
Ask Shadertoy to not automatically run heavy shaders
Maybe they could add some timing info or other heuristic to decide
whether or not to warn the user the shader might be too heavy for
their machine.
Ask to GPU companies to make their GPUs preemptable.
Otherwise there's not much even the browser can do. The browser has no idea if the shader is going to be fast or slow before it runs it.
I have a JavaScript application, which works fine, but certainly needs some memory / CPU performance (it is based on top of Google maps).
So basically it runs fine on a Desktop / Laptop PC, iPad works OK. But with all these different devices nowadays, smaller devices are definitely overloaded.
So basically I want to determine the available runtime and decide whether I start my JavaScript application, or display a message instead.
OK, I could check the browser, but this is a never ending story
I could check on the OS information, but again this is very tedious. Also some OS run on high performance devices as well as low end hardware.
I could check on the screen size and rule out mobile phones, but then it gets difficult
So is there a way to determine the performance of the client? Just to make it clear, I do not care whether it is a tablet for instance, but if it is a low performance tablet with little CPU performance / memory (so Detect phone/tablet/web client using javascript does not help).
In javascript You could check list of features and based on that do conclusion if device is low memory.
For example:
Check core count with window.navigator.hardwareConcurrency
(For better coverage add Core Estimator polyfill)
Check WebGL support (I like user2070775 suggestion): Proper way to detect WebGL support?
Check if its desktop or mobile. Most likely desktop will not have any problems with memory.
Check resolution of screen - most likely small resolution will be on low memory devices.
I want to know what are the minimum system requirements to run a webGL application smoothly?
I know this is a broad question,so what would be the minimum requirements to run the following experiments?
1.) http://www.ro.me/
2.) http://alteredqualia.com/three/examples/webgl_loader_ctm_materials.html
I would have done this myself,but i don't have a machine with low specs,and yes i did try google.
There are no minimum requirements in terms of system specs. I guess if you wanted to be really pedantic you could claim that a system needs a GPU capable of processing shaders (roughly DX9 level) but that basically describes every device with a GPU these days. (Except the Wii. Go figure...)
On a more practical level, you must have a device who's drivers have not been blacklisted due to instability issues. You can typically find the blacklist for a given browser by following the "visit support site" link on http://get.webgl.org/
Beyond that, however, it's all a matter of what the WebGL app is trying to render and what the device's bottlenecks are. For example: I've tried several WebGL demos on a Galaxy Tab with Opera and Firefox, and the framerate is limited to 10-12 FPS no matter what I'm rendering. A full, complex scene renders at the same speed as a single cube. This suggests that the device is probably getting stuck on the compositing phase (where it places the WebGL canvas in the page itself) and as such while the device may be capable of some very complex rendering the limitations of the browsers are holding it back. In comparison, I've seen highly detailed scenes running on iOS devices (with a hacked browser) of similar power at a solid 60FPS. So the exact hardware you have is only one part of the overall equation.
But really the best answer you can possibly get at this point is to pick up a device and try it!
I'm creating a web-based online game and am trying to find the best fit in terms of a framework for the front end of the game. The back end of the game is currently using asp.net mvc 2. Given that I could take the controller actions and turn them into WCF service actions the choice in the back end should not affect my options of a front end.
One thing that is certain, it does need to play in a browser. I have done some research on an HTML 5-only front end as part of this process and am probably leaning in this direction but I have a few concerns:
Assuming this game is completed this time next year, what kinds of difficulties will I have with current HTML 5 adoption levels? Specifically I'm worried about Firefox 3.6 and IE 7/8 still having a large install base. I have looked at Chrome Frame to solve the IE problem but am not sure if there are drawbacks to that I am unaware of either (other than the installation requirement).
I'm used to doing C# with a nice IDE complete with realtime information about whether the code compiles and intellisense reminding me of symbol names. Am I going to run into a problem with Javascript where my code becomes big and difficult to manage? The accessibility problem that a Javascript only engine solves for my users is more important than convenience for me but it of course can't be unmanageable either.
Are the HTML 5 engines on the market right now mature enough to trust with my time investment? Am I at high risk of adopting a framework that will fall into disrepair in a year from now? Of the engines I have looked at, none seem to have really great community support, am I wrong? Are there others out there that do?
here are those I have found thus far:
CraftyJS (http://craftyjs.com/api/Sprite.html)
ImpactJS (http://impactjs.com/)
PropulsionJS (http://www.propulsionjs.com/)
The Render Engine (http://www.renderengine.com/demos.php)
RPG JS (http://rpgjs.com/)
EaselJS (http://easeljs.com/)
Does anyone know anything of the community with these or have any reason to trust that any of these will be well maintained or available for at least the next several years? Does anyone know of another framework that's out there? ImpatJS has the most impressive demo of them all and it's also the only one that isn't free.
Thanks for any help / advice. I'm just worried I'll choose a front-end that I regret and I don't want to have to start from scratch 4 or 5 months down the road.
This is a 2D browser-game. It's not targeting mobile now, but it will be moving to mobile immediately after first launch. One hope is that it will work on mobile fine if I do HTML 5. I may have to tweak it for display size but if I don't have to port it to mobile that would be a definite plus.
This is my two cents having just been through the same decision making process for my company.
Our goal was to create as broad a game as possible that means it needs to run on as many browsers as possible. I ruled out html5 right away because the adoption is not there and seems to be at least a couple years until it reaches more than 60% penetration.
This left me with Flash vs. Silverlight. Flash's installed base is huge and there are many game engines available for it. Flash is a safe bet unless you have specific requirements for video or 3d.
I choose Silverlight because I wanted a good installed base (60%) and I wanted to leverage my companies’ in-house .Net expertise. I also wanted to use WCF for the backend and did not want to mix environments.
Keep in mind that SL5 is going to support most of XNA which is a big deal. There are a ton of XNA engines and source code that you can use to start with.
Here's a great site for looking at html5 browser support:
http://caniuse.com/
I can't speak with expertise on the particulars of HTML5 and Canvas, but...
As far as support goes, you'll still have probably a large bunch of IE7-8 users. IE is a little different than other browsers because you have to DO something to install updates. (i.e, go to the Install Updates in Control Panel or visit ie.microsoft.com). Other browsers (like firefox) just tell you and make the update easy. So your FF 3.6 users should be gone, but IE will still probably be a problem. Keep in mind, though, that much of the old IE browser share is due to IT depts. keeping their users on older versions - something you won't need to worry about.
This could be a problem. However, developing JS in Visual Studio or a similar IDE isn't so bad - there's still IntelliSense and other helpful things, as well as realtime debugging. It's definitely going to be a bit more difficult than C#, especially as many of the new JS api's haven't been implemented into the Autocomplete's of many IDE's.
I don't think you need be afraid of this. At this point, HTML5 and Canvas have gotten far enough that they won't be revoked, only improved. There may be a few modifications of the APIS and such, but not enough to keep you from using it.
Is HTML5 going to replace Flash? No, because games and RIA that require more out of javascript cannot be done until enough of the world is using IE 15 (which is about 5 10 years). Safari, Chrome, FF (maybe), will be up to par here soon but their js engines are going to require good hardware and that's not always going to be there.
Silverlight is a good option but it's not as well supported as Flash. This is why flash will still be around. The next version will support video controllers. It' called Project Mole hill and you can check out my SO question here.
If you want to make super simple games without good graphics try out one of those services you suggested. impact.js is $100, the others look free. In the future we will be able to use node.js to handle request with servers, but in the meantime Flash is certaily the way to go!.
I would much much much rather use javascript but after you start coding and realize the limitations compared flash will make your application standout.
Then for mobile devise, iPad, iPhone, Android, etc.. If you really think your audience is there build the game in the their language. It's more epensive and and harder, but Objective C, Java, they are much faster than HTML, JS, CSS etc...
I did some trial runs with YUI3, Burst engine & Raphael for SVG animation - everything seemed to run well; YUI's dragdrop module even detects the same drag operations on Mobile without adding a single line of code.
I can only imagine that if I had the time, a YUI3 instance available on a Node.js server with Raphael SVG animation would be my choice. You could drop the SVG aspect and use more standard graphic techniques, or perhaps serve up alternate quality graphics for those User Agents with fewer testes. Maybe it could be that your alternate quality version is just another implementation of your game engine - and you might choose to develop games using non-SVG anyway.
Just thoughts mostly, that doesn't help with your real-time IDE debugging...
impact.js has a great community and documentation. It is well worth checking out. I believe iosimpact.js is part of the package (although beta???) allowing for the development of native games for the iphone/ipad.
Yes, indeed you will lose a large user base. But how relevant that user base will be to you will depend on what your target is. Every-day-RPG players are much more likely to have the latest browser than Sunday-Morning-Sudoku users.
Give Eclipse + Web Tools + Aptana a try. It worked really nice for me.
No experience there.
There are certainly people out there who think that HTML5 is going to replace flash in online games. Here is an HTML/Javascript based engine that I heard about few days ago
http://www.youtube.com/watch?v=_RRnyChxijA
I haven't actually used it but it looks really promising and It's designed for similar set of requirements that you've put. It lets you design 2D / 2.5D ( isometric projections ) games. And it does look promising.
I am developing a web application that is supposed to display land traffic in real time in any part of the world. For a couple months I've been developing it using JavaScript and OpenLayers (http://www.openlayers.org) framework.
Unfortunately, this solution appears to be inefficient. There are hundreds (200-300) of objects on the map that are updated every couple minutes. The sheer operation of refreshing and rendering them takes significant amount of time that makes the
application less usable (slow responsivity to user actions).
At the moment I am considering changing the technology. Adobe Flex seems to be the most reasonable solution. There is at least one application written in it that does similar things to mine (http://casper.frontier.nl/).
However, I have a couple of concerns regarding Flex:
can it be easily integrated with the
HTML/CSS/JavaScript based part of the
application (for example, the
graphical interface should be
coherent when it comes to styles and
colors)?
I get an impression that
with latest browsers (mainly Chrome
9.0) JavaScript and CSS becoming more efficient. What are the chances that
in a couple of months JavaScript+CSS
will make it possible to implement
efficient, flash-like rich internet
application? (A note is needed here:
famous Canvas tag is not a solution
for my problem, at least not for now.
Rendering objects on map with canvas
proved to be less efficient than with
traditional SVG because the size of
the canvas is really big - a whole
browser window)
What are the chances
that Flash technology will be
abandoned (Apple policy, HTML5
growing support etc.) in
not-so-near-future (a couple of
years)?
There is a possibility that my client would like to view this application on mobile devices, including iPhone.
Any other solution for web-based interactive maps?
Can anybody address these issues?
Lazy comment repost:
I've used Google Maps JavaScript API + a custom canvas tile layer (see here and here) to draw maps with 10k+ markers, really quickly. Perhaps you just need to rethink your particular approach rather than totally rewriting your maps.
JavaScript running on a modern browser (say, IE7 or later) should easily be able to handle 200 or 300 object updates every few minutes. Granted, if you want to do all 300 updates at the same time, things might get a little slow. But if those updates occur spread out over that period, then you shouldn't have any trouble.
There are Asteroids games and 3D shooters written in JavaScript and that are very playable. They do dozens of updates per second.
I would suspect your framework (I know nothing about OpenLayers) or the way in which you're doing the updates before I suspected the platform.
My experience with Flash has been less that positive. Although it will interoperate with JavaScript, there are some strange edge cases that will trip you up. And my experience is that it's almost impossible not to trip over those edge cases unless what you're doing is truly trivial. And, of course, the lack of Flash support on the iPad and iPhone will make supporting those platforms impossible.
I think it's unlikely that Flash will be abandoned any time soon, as there are too many customers who continue to believe the silly notion that Flash is the way to build interactive Web apps. Although that was almost certainly true four years ago, browsers, computers, and JavaScript techniques have advanced to the point that the only use I currently have for Flash is to play video. And that use will go away in the next few years when HTML5 video becomes more prevalent. With Google's WebM video format and the expected high-quality tools to build WebM, Flash becomes almost irrelevant as a movie player, except for older content.
My advice would be to take a long hard look at your current implementation, study some other JavaScript applications that do frequent updates, and determine if it's really the platform rather than the way you're using it that is causing your performance problem.
No idea how many objects you can manage and update in js, but in my company (flashmaps.com) we have built flash-based maps handling many thousands of objects. The key issue in many cases in fact is that the map is completely overlapped by the markers. We use to recommend filtering the markers in those cases. We have a huge experience in building flash/flex-based maps, so on't hesitate to ask me any question on that.
By the way, I don't think Flash will get out of use soon. Apple's strategy on controlling iPhone/iPad apps (the real reason behind Flash banning) is causing a lot of trouble to web developers, that need to create specific versions of their websites for these devices, it's crazy. But I'm sure Apple will permit Flash, someday... Probably when many other tablets hit the streets supporting Flash. We'll see.
The awesome thing about MVC architecture is as long as you keep your domain logic separate from your business logic and UI, then it's relatively easy to create platform specific apps that access the same data. For example, you could build the same UI to run in the web browser (via html/javascript or flash player), on the desktop (via Air), and on an iPhone/iPad (via iOS) that all connect to the same server-side scripts. It's all a matter of personal choice which platform you choose. If a platform happens to fall out of fashion in the future, then you simply create a new UI on another platform.