HTML5 Fluid Simulation in WebGL | Hacker News Reader

HTML5 Fluid Simulation in WebGL

haxiomic.github.io

172 pointsjunto49 comments

Previous discussion from 37 days ago:

https://news.ycombinator.com/item?id=8325700

Beautiful.

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.

In the latest version they enable WebGL by default, also in Safari iOS.

Well not in my safari. It crashes as soon as I try to click on the particles.

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.

I'm not getting these, what's the browser?

Chrome V38.0.2125.104 on 64-bit Ubuntu 14.04

I'm on the exact same Chrome version, but on Windows 7 - no issues here.

The difference is the OpenGL implementation.

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.

What GPU/driver are you using?

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 see.

   product: 2nd Generation Core Processor Family Integrated Graphics Controller
   vendor: Intel Corporation
   driver=i915

Unfortunately, that generation of Intel GPUs is known to be quite bad in performance and having very buggy OpenGL 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.

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.

Is this fake physics or real? How deep is the fluid, what methods are used etc...

Looks really neat.

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.

This has been a common request, so I'm definitely going to be adding these features in

As a complete physics noob, can I mod this to work in 3D? I.e. model a concave rigid body shape, and have the fluid flow around it?

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

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

Great stuff! Kudos to George Corney (haxiomic), the creator!

Chromium 38.0.2071.0 (279972) works fine in whatever setting on a medium sized machine.

It doesn't seem to do anything for me with Firefox Nightly/Yosemite on my recent rMBP. Nothing in the console, either.

Did you click and drag?

No, doh.

Still, maybe a little hint could work to improve usability in this sense?

I agree, took a while to figure out what was going on. Especially because the grid lines are so tiny with such low contrast.

Can't see on my Z2. No touch event listeners.

Here's a version with touch listeners

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

Works great, smooth. Thank you!

These things make me genuinely happy.

Me too. Especially as it's Haxe (Actionscript 3) rendering out to JS / HTML

I'm hoping this goes more mainstream

Tells me "WebGL is not supported" on MBP Yosemite - Latest chrome version.

Strange! I'll look into this, what about safari?

For me, it works even smoother on Safari 8.0/Yosemite on 13" rMBP 2013.

I'm on a retina MBP, Yosemite, latest chrome, and it works amazingly for me.

Make sure "Use hardware acceleration when available" is enabled in Chrome.

Chromium: "WebGL is not supported"

Firefox: 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.

Runs perfectly well on an AMD FX 8350 with 32GB RAM and a top-line nVidia graphics card!

Awesome, I wish I had a system like that! Doesn't seem to run on my chromebook though. :-(

Works pretty good with the latest Chrome here.

Works fine in latest FF. Retina MBP.

That odd - it works fluidly (!) on High setting on my mid 2010 Mac Mini running 10.10 and using Firefox 33, and pretty well on Ultra High setting.

I get about 2-3 FPS on Firefox 33 for Linux. Could be the Nouveau driver. The Nvidia driver slows down Firefox so I can't switch back.

How would a kernel driver slow down a browser? And nvidia runs incredibly smooth on Linux, even on older hardware.

Beats me. I've filed issues with both Firefox[1] and Gnome[2].

1. https://bugzilla.mozilla.org/show_bug.cgi?id=1065236

2. https://bugzilla.gnome.org/show_bug.cgi?id=736669

Works fine on my Chromium, 34.0.1847.116

I'm on 38.0.2125.104 64-bit Linux. The alert now says "WebGL is not supported on this device :(" so maybe it's a Linux thing.

Works fine with Firefox on GNU/Linux with just an AMD Kaveri APU (and the free drivers).

This is really trippy/amazing looking. I love it.

Reply on news.ycombinator.com