WebGL Water (2011)(madebyevan.com)
madebyevan.com
WebGL Water (2011)
http://madebyevan.com/webgl-water/
32 comments
Are there any more modern real-time water effects out there/being researched? This basic effect has been around for a while now.
As far as I aware best available for real-time is NVIDIA FleX:
https://www.youtube.com/watch?v=pfonMfP__Ks
In open source field there is Mantaflow that available in Blender, but it's of course not solution for real-time.
https://www.youtube.com/watch?v=pfonMfP__Ks
In open source field there is Mantaflow that available in Blender, but it's of course not solution for real-time.
Not much newer, but I like the in-depth slides that cover how it was done:
The effect: https://29a.ch/sandbox/2012/terrain/
The slides that explain: https://29a.ch/slides/2012/webglwater/
The effect: https://29a.ch/sandbox/2012/terrain/
The slides that explain: https://29a.ch/slides/2012/webglwater/
yes, this is pretty cool.
https://www.youtube.com/watch?v=55rsJI11FOA
http://physicsforests.com/
https://www.youtube.com/watch?v=55rsJI11FOA
http://physicsforests.com/
Look at david.li webgl demos
Cool tech demos like this one can have unforeseen uses:
On an episode of the podcast Reply All [1], a "trip sitter" would use this site to help calm people down who were on bad trips, and it was pretty effective.
[1] https://gimletmedia.com/episode/44-shine-on-you-crazy-goldma...
[1] https://gimletmedia.com/episode/44-shine-on-you-crazy-goldma...
His webgl pathtracer is very cool also!
http://madebyevan.com/webgl-path-tracing/
Wow that's really close to "perfect" real time performance.
hmm, the pathtracer doesn't work in Firefox Nightly on Windows (only wireframe select boxes are visible, the traced image is all black). However it does work in Servo!
And the water works very well in all browsers except Servo.
And the water works very well in all browsers except Servo.
First time I saw this it was awesome - still is - real-time water effects in the browser.
Didn't know Evan is co-founder of figma.com - maybe that's why the app feels quite snappy in the browser.
Didn't know Evan is co-founder of figma.com - maybe that's why the app feels quite snappy in the browser.
Yep, Evan is my cofounder! We started talking about building collaborative creative tools using WebGL shortly after he built this demo in an afternoon during summer 2011.
Shameless plug: if anyone is interested in working with us on Figma, we're hiring. https://www.figma.com/careers#jobs
Shameless plug: if anyone is interested in working with us on Figma, we're hiring. https://www.figma.com/careers#jobs
This was amazing when I first saw it. More so because I was working on an SPH implementation:
http://jsexperiments.herokuapp.com/sph/
source: https://github.com/asadm/SPHjs
http://jsexperiments.herokuapp.com/sph/
source: https://github.com/asadm/SPHjs
Why aren't there floating-point textures on mobile GPUs? (To me) it seems a pretty straightforward addition, and many more GPGPU tasks become easier.
Sure, you can en/decode yourself, but faster in silicon.
Sure, there's openCL, but it's more fiddly, gives worse performance, and no-one uses it.
Sure, you can en/decode yourself, but faster in silicon.
Sure, there's openCL, but it's more fiddly, gives worse performance, and no-one uses it.
ES3 requires floating-point texture support, so any mobile GPU which supports that will support floating-point textures. The extension may not be exposed in ES2 of course.
Note that:
- 32-bit float texture filtering is not required to be supported, as it may cost significant area.
- Floating-point framebuffer support is not required, due to patent issues... :S
Note that:
- 32-bit float texture filtering is not required to be supported, as it may cost significant area.
- Floating-point framebuffer support is not required, due to patent issues... :S
Do you have more info on the patent issue?
See https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_c... and http://www.google.co.uk/patents/US6650327
Not to turn this into a debate on patents, but even the patent itself seems to admit it's an obvious and anticipated improvement made possible by cheaper silicon:
> In an effort to gain the advantages conferred by operating on a floating point basis, some prior art systems have attempted to perform floating point through software emulation
> But as advances in semiconductor and computer technology enable greater processing power and faster speeds; as prices drop;...it has been _discovered_ by the present inventors that it is now practical to implement some portions or even the entire rasterization process by hardware in a floating point format. [emphasis added]
> Hence, due to the improvements in processor speed and other improvements that make it practical to operate on large amounts of data, it is now possible and cost beneficial to utilize the valuable information that can be provided by the frame buffer.
It's a good idea, but obvious - everyone was waiting for this inevitable improvement. Their idea of floating-point-all-the-things is also good, but just a matter of engineering. They don't disclose their exact engineering, anyway; but just patent the general idea.
> Thus, there is a need for a graphical display system which predominately uses floating point throughout the entire geometry, rasterization, and frame buffering processes. The present invention provides one such display system.
I'm surprised it was granted, and I don't think it would upheld in court - but it doesn't need to, it's just another plank in the patent portfolio.
> In an effort to gain the advantages conferred by operating on a floating point basis, some prior art systems have attempted to perform floating point through software emulation
> But as advances in semiconductor and computer technology enable greater processing power and faster speeds; as prices drop;...it has been _discovered_ by the present inventors that it is now practical to implement some portions or even the entire rasterization process by hardware in a floating point format. [emphasis added]
> Hence, due to the improvements in processor speed and other improvements that make it practical to operate on large amounts of data, it is now possible and cost beneficial to utilize the valuable information that can be provided by the frame buffer.
It's a good idea, but obvious - everyone was waiting for this inevitable improvement. Their idea of floating-point-all-the-things is also good, but just a matter of engineering. They don't disclose their exact engineering, anyway; but just patent the general idea.
> Thus, there is a need for a graphical display system which predominately uses floating point throughout the entire geometry, rasterization, and frame buffering processes. The present invention provides one such display system.
I'm surprised it was granted, and I don't think it would upheld in court - but it doesn't need to, it's just another plank in the patent portfolio.
Thank you. It seems I didn't stumble upon the issue because in WebGL I didn't even have to enable the extension to have float color framebuffers in most platforms. Instead I tried to create a framebuffer to check if it's supported.
So patents are what prevents render to float texture on mobile?
They are what prevented it being a required part of ES3 I believe. See the "IP Status" section here https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_c...
Individual vendors can of course expose that extension, provided they have a license.
Edit: it looks like ES3.2 requires support for floating-point framebuffers, so presumably the patent issue has been resolved somehow.
Individual vendors can of course expose that extension, provided they have a license.
Edit: it looks like ES3.2 requires support for floating-point framebuffers, so presumably the patent issue has been resolved somehow.
> (To me) it seems a pretty straightforward addition
Maybe it has some significant cost in power consumption. Perhaps adding it to the silicon reduces power efficiency even when it isn't being used.
Maybe it has some significant cost in power consumption. Perhaps adding it to the silicon reduces power efficiency even when it isn't being used.
Judging by how it runs on the desktop(4 year old gpu) and YT clip it was developed on anemic laptop and never speed tested, reminds me of Wing Commander or Test Drive 3. Learn from the past and dont link main loop speed to framefate.
I think for a demo that is perfectly fine since you get an immediate performance indicator.
I remember that the initial fbdev-on-linux folks showcased their drivers with well known animations[1] at 4-digit frame rates and never had to answer performance questions again.
[1] IIRC something like glxgears and some 3d-tubes screensaver - might have that wrong though, that was about 17 years ago.
I remember that the initial fbdev-on-linux folks showcased their drivers with well known animations[1] at 4-digit frame rates and never had to answer performance questions again.
[1] IIRC something like glxgears and some 3d-tubes screensaver - might have that wrong though, that was about 17 years ago.
Indeed, and with surprising results. I remember running this on a laptop (HD4000 or something) some years ago on which it ran like crap, and it took a dedicated Radeon card (6870 IIRC) to have it smooth. Today it runs what appears to be a solid vsync'd 60fps on my iPhone 6s.
hint: you can click on the water
SPH is better and i've seen some webgl ones out there.
Just wanted to point out not working on Chromebook
Uncaught Error: This demo requires the OES_texture_float extension
I've seen this before though on Reddit, pretty cool how well it works on Mobile.
Also I realize OP may not be related to the post/created it and I should file a bug or whatever, I'm just posting it here.
Uncaught Error: This demo requires the OES_texture_float extension
I've seen this before though on Reddit, pretty cool how well it works on Mobile.
Also I realize OP may not be related to the post/created it and I should file a bug or whatever, I'm just posting it here.
http://codeflow.org/webgl/craftscape/