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.
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.
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.
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.
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'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
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.
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
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.
https://news.ycombinator.com/item?id=8325700