I've wanted to get behind WebGL for so long but if it can't work as well as the OpenGL ES running on my phone then I will just have to wait and see if it gets any better.
Though it looks awesome, It's spamming my console with WebGL errors:
[.WebGLRenderingContext]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : glDrawArrays: framebuffer incomplete (clear)
[.WebGLRenderingContext]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : glDrawArrays: framebuffer incomplete (check)
WebGL: too many errors, no more errors will be reported to the console for this context.
On Windows, Chrome uses the ANGLE middleware to implement WebGL. It's a layer that implements the OpenGL ES 2 API on top of Direct3D 9. That solves quite a lot of driver quality issues (at the cost of some overhead).
So the question is, which GPU/driver was being used on Linux.
It is the same driver as the later Intel models. It is one of the very few drivers that are not blacklisted by Chrome on Linux, owing to its unbugginess.
I know, but that doesn't mean that there aren't bugs or missing features specific to that GPU model (hardware or software). But I can't be sure whether this particular issue is a driver bug or just an unsupported combination of pixel formats (FRAMEBUFFER_INCOMPLETE hints at that).
WebGL spec requires certain of pixel formats to be supported but either the test case is using some combination that isn't guaranteed to be supported or the driver+hw combination doesn't actually support everything required by the spec.
Intel has made huge improvements since the days of the i9xx series of GPUs. They were miserably bad from a programmer's standpoint.
Works very well on my mid-2012 MBP in OSX 10.10 with a puny Intel HD4000 GPU!
The framebuffer completeness check error is a result of some early confusion around the OES_texture_float WebGL/OpenGLES extension. Most browsers interpreted this as being able to both read from a floating point texture, as well as render to a floating point frame buffer. But some (mobile) GPUs can sample fp textures but not render to them. So later another extension was introduced to clean this up (WEBGL_color_buffer_float and others) which specifically handles rendering to fp render targets, while OES_texture_float is restricted to sampling textures. But this is not widely supported yet, and most desktop browsers still support rendering to fp render targets even they only expose the OES_texture_float extension in order to not break backwards compatibility. Because of this, some WebGL code which runs on desktop browsers breaks on some mobile devices even though the code 'properly' checks for extensions.
I also find this a good test of Apple's bold claims about the speed increase in the latest version of Safari - and, true to what they say, it does seem smoother in Safari, at ultra-high, than in Chrome.
This is amazing, thank-you.
I would love to see the addition/option of adding static geometric shapes.
In other words this would make for an awesome wind-tunnel simulator.
It's solving the incompressible form of the Navier-Stokes equations, it's very barebones however - I've left out diffusion for example. It's possible to reduce the grid size and increase the solver iterations to have a more physically accurate simulation, but to go down that route I think there are a lot of algorithmic improvements that should be made
The mathematics generalizes to 3D quite easily, but the way the webgl pipeline is used in this case doesn't. It'd be easier I think to start from scratch. I recommend reading through the GPU Gem's article on the topic with code samples
51 comments
[ 3.7 ms ] story [ 52.6 ms ] threadFirefox: laggy on UtlraLow settings
I've wanted to get behind WebGL for so long but if it can't work as well as the OpenGL ES running on my phone then I will just have to wait and see if it gets any better.
1. https://bugzilla.mozilla.org/show_bug.cgi?id=1065236
2. https://bugzilla.gnome.org/show_bug.cgi?id=736669
Chromium 38.0.2071.0 (279972) works fine in whatever setting on a medium sized machine.
https://news.ycombinator.com/item?id=8325700
I'm hoping this goes more mainstream
On Windows, Chrome uses the ANGLE middleware to implement WebGL. It's a layer that implements the OpenGL ES 2 API on top of Direct3D 9. That solves quite a lot of driver quality issues (at the cost of some overhead).
So the question is, which GPU/driver was being used on Linux.
This looks like either a driver bug or some unsupported combination of pixel formats.
Unfortunately, WebGL doesn't solve these compatibility issues that are inherent to OpenGL and running on a wide variety of hardware and drivers.
I don't know if that's the cause of the issue you're seeing but don't expect to run any fancy 3D on Linux with that GPU.
WebGL spec requires certain of pixel formats to be supported but either the test case is using some combination that isn't guaranteed to be supported or the driver+hw combination doesn't actually support everything required by the spec.
Intel has made huge improvements since the days of the i9xx series of GPUs. They were miserably bad from a programmer's standpoint.
The framebuffer completeness check error is a result of some early confusion around the OES_texture_float WebGL/OpenGLES extension. Most browsers interpreted this as being able to both read from a floating point texture, as well as render to a floating point frame buffer. But some (mobile) GPUs can sample fp textures but not render to them. So later another extension was introduced to clean this up (WEBGL_color_buffer_float and others) which specifically handles rendering to fp render targets, while OES_texture_float is restricted to sampling textures. But this is not widely supported yet, and most desktop browsers still support rendering to fp render targets even they only expose the OES_texture_float extension in order to not break backwards compatibility. Because of this, some WebGL code which runs on desktop browsers breaks on some mobile devices even though the code 'properly' checks for extensions.
Still, maybe a little hint could work to improve usability in this sense?
http://awestronomer.com/lab/binA
I'm sure sure how well they work until I can get my hands on a device to test them on however
I also find this a good test of Apple's bold claims about the speed increase in the latest version of Safari - and, true to what they say, it does seem smoother in Safari, at ultra-high, than in Chrome.
Looks really neat.
http://http.developer.nvidia.com/GPUGems3/gpugems3_ch30.html
although the physics is discussed, you don't need to follow it deeply to implement it