WebGL Water | Hacker News Reader

WebGL Water

madebyevan.com

369 pointsag8111 comments

So the cool thing about this demo was that I remember when it was first submitted many years ago and thought it a cool demo that demonstrated the viability of WebGL which I expected to take off a lot quicker than it has.

But I also recently came across madebyevan.com again by accident after researching the backing of different npm projects to assess which ones had good momentum or commercial backing behind them to assess their long-term viability, and noticed a lot of npm projects (~2M weekly) relying on esbuild [1] as a fundamental part of their build system due to its amazing performance [1].

All good except that the foundational part of many npm projects feature is mostly being maintained by a single developer [2], a @evanw who was also prolific in responding to esbuild's issue catering for different peoples issues & feature requests. I didn't think this level of investment in a popular OSS project was sustainable and hoped they had good sponsorship behind them, but was surprised that @evanw [3] didn't have sponsorships enabled which I thought strange as most authors of popular npm projects have good sponsorship, but upon further research it's because Evan Wallace's day job is as the CTO and cofounder of Figma - a popular company with ~10B valuation.

Which is great in that esbuild isn't at risk of being sporadically abandoned from its lead developer joining a new/demanding startup, on the other hand a foundational project in npm's ecosystem is being developed in the spare time of a Co-founder & CTO of a ~10B Co - who also creates great demos :)

[1] https://github.com/evanw/esbuild

[2] https://github.com/evanw/esbuild/graphs/contributors

[3] https://github.com/evanw

Obligatory XKCD: https://xkcd.com/2347/

I'm not super familiar with this area, but from my vantage point, it seems like WebGL didn't really take off because of the awkward timing. Right around the time it was being developed, the industry started working on a replacement for OpenGL. Hopefully WebGPU fares better, because I think 3D web experiences are full of untapped potential.

WebGPU is irrelevant :

- iOS still doesn't support webgl 2.0 and webgl 1.0 is ancient

- browsers suck for 3D content in other ways too (slow load times, impossible to controll cache/asset loading/storage, etc.)

- the above sucks even more when you are on limited connectivity/offline

- wasm load times also suck

- browser input is terrible for 3D

A lot of these could be fixed by providing some APIs but it's not in Apple interest to give you the tools to bypass their appstore tax. And web standards take forever to develop. I lost enthusiasm about webgl back in 2016 when it was already ancient and showing no signs of fast cross browser adoption.

iOS supports WebGL 2.0 now.

"browser input is terrible for 3D" doesn't make sense. The web version of game streaming services like Stadia use browser input and they work fine.

Offline storage of gigabytes of assets is tough, that's a valid criticism. But that is not a deal breaker for many applications. Hopefully we'll see more movement on this.

A lot of the load time issues with web games are just bad software architecture and can be solved by the same techniques web developers use: breaking assets and code into modules loaded on demand instead of giant monolithic wasm binaries or asset packs.

Apple enabled WebGL 2.0 by default as of iOS 15.0, and Apple was the company who proposed WebGPU to the W3C (which was its own news story because Apple started the debate over shader language)

That's interesting, I had no idea they were the ones that proposed it. Everything I've read paints them as the odd one out, since they're going their own way with Metal and not Vulkan.

What they initially proposed was essentially WebMetal. Their likely reasons for doing so were to force a change in venue to W3C instead of Khronos, and preempt any attempt at a WebGL 3 or WebVulkan, due to their ongoing legal dispute with Khronos (also the reason they deprecated OpenGL).

I didn't know that, nice it only took them 4 years.

WebGPU is like I said irrelevant since the platform is not enabling for these kinds of apps.

> - iOS still doesn't support webgl 2.0 and webgl 1.0 is ancient

Right, it supports Metal and all the WebGPU implementations right now are using Metal. Apple was in fact the driving force behind WebGPU.

I see where they are coming from, opengl (including webgl) is such a clusterfuck.

Agree, unfortunately Vulkan seems to repeat all the mistakes regarding tooling, extensions and expecting the community to come up with SDK like solutions, only at lower level, so a newbie suffers much less with OpenGL, despite its warts.

Exactly this. I've been trying to get a handle on Vulkan and it's just _dense_. The way it's written I feel like you basically have to understand GPUs inside and out to use it. There's no such thing as a 'reasonable default' to it. WebGPU is a bit better, but still quite dense. We absolutely need a standardized higher level interface to the hardware, but like you said, that's not what Vulkan is.

I just went through comments from all the times this has been reposted in the past 10 years, and this is (so far) the first time there aren't any complaints about not working in their browser! I'm counting just the submissions that got >10 comments.

The previous time, from 2017[1], was already quite good - there was only a single complaint, and that was about someone missing a WebGL extension this needs for floating point textures.

[1] https://news.ycombinator.com/item?id=14432809

Let me be the first then: Doesn't work on my Galaxy S8 - "This demo requires the OES_texture_float extension", so I guess it's the same issue.

Truth be told the phone is relatively old, but then again I haven't switched because it... still works and I assume many other owners made the same choice regarding their devices.

I replied almost at the same time as yours and my phone is galaxy a32 and getting the same error message as yours.

It works in Firefox on my a32

Yes. By seeing your comment, I just installed firefox and tested.It works fine.

It works fine on my Samsung A8 using Firefox Nightly, but not on FireFox 68.

S8 was released in 2017, for anyone else curious.

Is it the Mali (Exynos) or the Adreno (Snapdragon) variant?

I doubt either would actually lack float texture support though. The WebGL implementation perhaps has weird requirements for when to allow this extension.

Exynos.

I checked and indeed it's not listed when looking at chrome://gpu

Works on Firefox though.

You may want to try temporarily disabling GPU blacklisting in chrome://flags or about: config (both Chrome and Firefox have this "feature"). There are a bunch of very specific hardware, OS version, driver version, and feature extension combinations that are disallowed in the browser.

Unfortunately, this feature is very obscure, not really explained anywhere, and no complete list of blocked configurations exists anywhere. I've heard that it's supposedly to protect from buggy implementations that might allow a sandbox escape exploit. But again, that's just hearsay, there's really no official, up to date documentation on any of this

I happen to know it, because for years there was an issue with hardware acceleration in Chrome on Mali cards (something something EXT_robustness), so I just chalked it up as the same sort of fuckery.

Thanks for reminding though.

It works on my Galaxy S8 when I view the page from HN reader Materialistic :)

That's because it runs fine in Firefox Focus. The error message shows up in Samsumg Internet Browser and Chrome though.

(S8 is a great device. I don't want to "upgrade" - hate the notch on newer versions, the S8 still performs very well, and I don't know of any feature only in newer phones that I have a use worth paying for.)

It does not work on my galaxy a32 phone. I tried with both samsung internet and chrome.

Looked up the release date for this phone: January 2021.

I get:

400 Bad Request, You have attempted to access this site via TLS (HTTPS), but it is not configured for TLS access.

Probably because I have "dom.security.https_only_mode" enabled in Firefox

It's terribly slow on my Monterey OSX Safari, yet flawless on Chrome.

Flawless on iOS 15 Safari

Works great on my Big Sur Safari...

It is flawless on my 4 years old $200 phone...

Might be worth checking if your Mac is in low-power mode? On my M1 Max, on low power it's a bit laggy but on normal mode it's snappy (Monterey, Safari 15.1). Safari appears to resource-limit WebGL in Low Power mode, whereas Firefox/Chrome don't

Ineresting!

The first line: "This demo requires a decent graphics card and up-to-date drivers." made me chuckle at the humbleness since I'm running this in Firefox on a 10 year old laptop. Buttery smooth (I'd say 60fps) at what seems full native resolution.

I guess it's the "up-to-date" drivers part (or rather, browsers playing along with existing drivers) that makes the difference.

Apparently even graphics cards that are terrible at actual graphics can run this (GT 710) at full FPS.

Getting:

"Uncaught Error: This demo requires the OES_texture_float extension"

That's a Mozilla browser on Android though.

I think it's your phone, not software. Got it working on Mozilla @ Xiaomi Mi 8, quite dated model.

(2011)

Previous threads:

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

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

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

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

This works on my iPhone in chrome. I really like that. I am aware of the fact that it’s old. The fact that it still works in chrome on my phone makes it more awesome. I’m sure it’s probably elegant and awesome under the hood to make that work.

Going to take this positive feeling, eat and ice cream bar, rub my tummy, watch some Babylon 5 and go to sleep with all of these happy feels. :)

It doesn’t matter that you are using chrome. All browsers on iOS use safari under the hood.

Yikes.

It's really no big deal to provide that detail even if it transpires to be irrelevant.

The first time I saw this I was in awe of how far we’ve come, realizing the first 3d rendering I ever did took several seconds and was accomplished within DOS. Now we have things like this in the browser running in real time.

Since then I’ve had my mind blown several more times, but this demo has a special place in my mind. I was so excited at the prospect of WebGL.

Are you talking raytracing or real-time? I loved POVRay in the early 90s for raytracing. It blew my mind. As a little kid in the 80s, John Lasseter was my hero; I had a picture of Luxo Jr I used to eye regularly.

By '92 I had built a whole software 3D renderer in x86 and had the T-Rex from Jurassic Park stomping around in real-time on my 286.

That suddenly brought back a memory of the first 3d rendering code I did - it was written in Basic on an 8086 machine running DOS 2.1. Not only did it take several seconds to render, it was only an unshaded wireframe line drawing. To be fair, there were techniques available at the time to make it quite a bit faster that I didn’t know. But it still blows my mind a little bit every time I think about how far things have come since I was a kid.

I remember looking at this a decade ago with an old Sony Xperia phone and just being amazed at the possibilities of the web.

10 years later it still looks as good as I remember

10 years later it is still the same API, in spite of the hardware progress, which is kind of sad.

Reading this on a sony Xperia mini. Still my daily driver. Can't belive how many weird looks and "what is that thing???"s I get.

I'm disappointed "toggling gravity" doesn't actually toggle gravity, just changes the density of the ball.

Edit: Looks like I'm wrong about the density. When you load the page the "gravity" of the ball is actually off (but it's at the bottom, so it looks like it's on and dense), and pressing G lets it float up.

It's not turning off gravity though. If there was no gravity, the water wouldn't pool at the bottom, so I was hoping to see blobs of water floating around.

mmmh first thing I tried was putting the ball outside the water and it levitated there. Technically speaking yeah, it could still just be density even in that case, but it would also make sense as gravity (indeed the ball felt into the water as soon as I activated gravity).

Huh? When I toggle G, the ball is locked in place. Not exactly what I'd call "toggling gravity" (except for very large masses), but it's sufficiently useful (I can toggle G and then drag the ball our, wait for the water to settle and then drop it with G).

"This demo requires a decent graphics"

Even being from 2011, the fact that works right on a 2017 low end phone with low battery, is totally mind blowing

It's interesting to think of the reasons we don't have browser-based 3D renderers. Sure, WebGL exists. But it seems like the promise fizzled out, and I'm not quite sure why.

Maybe it's as simple as "Steam is the money pipeline, and everyone makes native games on Steam."

Easy, so many reasons beyond just blaming Apple,

- WebGL is a subset of ES 3.0, when the hardware can do GL ES 3.2

- WebGPU, when it arrives sometime during 2022, it will be a 1.0 MVP of the features from Metal, Vulkan and DX 12, with yet another shading language that looks like a mix of C++/HLSL/Rust, WGSL.

- If you just want compute, now WebGPU is the only option, although GL ES 3.2 has it. After two failed attempts from Intel, Chrome folks managed to force everyone to use WebGPU instead, so that is ready when WebGPU is ready.

- Lack of tooling, to debug WebGL you have basically to debug the browser process and try to track down your 3D calls from the browser own ones (there is a SpectorJS, which is quite simple when compared against something like Pix or REnderDoc)

- Browsers black list consumer's hardware/software, so content producers have no idea how well it actually runs.

- Indie game development moved from Flash into mobile, where tooling is much better.

Finally, I leave you the Flash demo for Unity 3 using CrossBridge[0] and Stage 3D [1], back in 2011.

https://www.youtube.com/watch?v=UQiUP2Hd60Y

[0] - https://adobe-flash.github.io/crossbridge/

[1] - https://help.adobe.com/en_US/FlashPlatform/reference/actions...

I tried to do mobile web gamedev and found it impossible: both Apple and Google break mobile web games in different ways, I presume because it could threaten the 30% cut their mobile stores get. For example, the HTML5 Minecraft I've never seen run properly in a mobile web browser:

https://classic.minecraft.net/

Mobile Safari:

- Forever lacked >WebGL 1.0

- WebGL very slow compared to native

- Won't let you use accelerometer, motion control, etc., because "Privacy" (but privacy loving Apple was totally going to scan our iPhone photos until we all raised hell...)

- Web Audio stack breaks games in interesting ways desktop doesn't. "Oh, we don't let you load .mp3 audio samples by default like desktop browsers can...."

Android Chromium:

- Has 200-300ms audio latency on many devices. Here's a demo where touching/clicking the squares should have instant response (try it on desktop) but many Androids have the lag:

https://webaudiodemos.appspot.com/TouchPad/index.html

> the HTML5 Minecraft I've never seen run properly in a mobile web browser:

> https://classic.minecraft.net/

I think that site just doesn't grok touch. Tech-wise, I believe it would run okay on modern phones if the controls were sorted out.

Chrome and Safari both have WebGL debuggers that let you see all the API calls made IIRC. It's not RenderDoc but it's not that bad?

Chrome certainly doesn't have such thing unless you mean SpectorJS, yes it is bad, it is pre-historic compared with something like RenderDoc and Pix, which can on Pix's case, I can even single step and set breakpoints on shader code.

"Steam is the money pipeline, and everyone makes native games on Steam." This is 100% it, everyone thinks browser games are a thing of the past and that's it, end of story. Well, they couldn't be more wrong and I'm happy to explain why. The tooling for developers traditionally just hasn't been there. Developers coming from the native game engine world typically don't have a firm grasp of web technologies, so the ones that do target it get massive file sizes which turns off anyone who would actually try it out, but ends up getting frustrated and closes the tab.

Shameless plug, but my team and I are on a mission to solve this for Unreal Engine developers looking to export their projects to HTML5. The potential for the gaming and metaverse opportunity in the browser is enormous, so to this end we're bringing the full power of UE4/UE5 to WASM, in combination with WebGPU + WebXR to deliver experiences that rival anything on Steam or other storefronts or app stores.

In addition to our hosting platform for deploying, maintaining, and monetizing, we offer a suite of tools for optimization that include compression for drastically reduces file sizes, and on the fly asset fetching to keep load times as short as possible. The goal is near native performance, with faster deployment and accessibility than Steam.

For developers and creators, there's no unnecessary 30% cut of your virtual worlds and real-time 3D applications to walled gardens. Add in that you only have one codebase to main that when deployed, it just works everywhere with a browser.

For users, play is a single click away, no local installs or dedicated clients required on computers or mobile.

Link to our website: https://www.theimmersiveweb.com/

Link to our Discord: https://discord.gg/zUSZ3T8

How are those Unreal developers supposed to debug WebGL, GLSL shaders, and browser profiling of their WebAssembly code?

I understood the major challenge isn't about displaying a 3d model, but content caching and distribution. Are you going to download 4gb of textures and keep that in local storage?

The browser is not an appropriate medium for games that need non trivial access to local storage and system input. Browser compatibility, and being subordinate to multiple third parties isn't great, either. Rather than fighting with browser limitations, it's easier to package, deliver, and maintain a stand-alone application.

Steam isn't a major consideration once you've gone into the weeds of implementing software that colors outside the usual browser lines.

This is changing. Browser has 0 friction distribution and security advantage other mediums don't have

That security advantage is the reason it's inappropriate for certain things. One of those things is i/o intercept. You don't want browsers to be able to do certain things that games or first class apps can.

Unity's WebGL player is alive and well:

https://docs.unity3d.com/2021.2/Documentation/Manual/webgl-g...

It is alive, regarding well it depends, given how little it is actually used, and Project Tiny seems to have been dropped.

https://play.unity.com/

https://simmer.io

there are several other unity only web game sites and lots of others with not just unity

https://itch.io/games/free/unity

There’s Shadertoy and Three.js although the main reason we don’t see many 3D web games is both Steam being where the money is, portability to consoles and asset size. The latter in particular makes the web unattractive to game developers used to delivering gigabytes. It’s a different mode of production and people won’t make that switch en masse until someone proves it out.

Now Blender is really good we’re seeing a lot more indie games exploring low-poly 3D aesthetics. Further the increasing viability of using more compact formats like SDF hopefully means we see even more people realising they can actually build something on the web.

The Xbox actually has a working browser:

https://www.youtube.com/watch?v=vw_4kiYvEmE

Yeah we shipped by accident on it thanks to that: https://twitter.com/bobbydigitales/status/144144607851193959...

You can even plug a keyboard and mouse in and use all our game editors.

Well old titles that are on Steam have been ported to WebAssembly... and keep in mind these are just straight ports with little to no compression or asset fetching to reduce the file size and load times.

Curse of Monkey Island: https://personal-1094.web.app/scummvm.html (press esc key right away upon load to skip straight to playing)

Baldur's Gate 2 demo: https://personal-1094.web.app/gemrb.html

Diablo demo: https://d07riv.github.io/diabloweb/

Humongous Arts games:

Spy Fox in Dry Cereal demo: https://thatgamedev01.itch.io/spyfoxindrycereal

Pajama Sam demo: https://thatgamedev01.itch.io/pajama-sam-3

All titles released around the time GL ES 3.0 was modern.

Sadly no sounds on my Mac for Baldur's Gate & Diablo in Safari (haven't tried other browsers). Not sure if other platforms, browsers have sound.

We do. Follow some of the Three.js people in Twitter to see some interesting things people are making, eg https://twitter.com/mrdoob

For example this IFC-in-browser thing looks amazingly useful: https://twitter.com/ifc_js/status/1462880392915083269

As a gamer, Steam is about way more than mere distribution. It's a community: discussions, chat, friends, voice chat, screen share, remote play over the internet, cloud saves, sales, filters, betas, tags, mods, library management, matchmaking, etc. It's way better at those things than Epic Store, GOG, Microsoft or Apple or Google stores. Valve has been evolving it as a platform for decades and its competitors just aren't very good at all.

Even if you can get the game's renderer and UI to reach parity, it's hard to overcome the UX and network effects of Steam. And that sort of ecosystem fragmentation (alternative platforms often don't offer crossplay) is bad for gamers, not to mention having to implement different multiplayer pipelines makes lives harder for devs.

Gaming on the web might be nice for trashy flash like games, but for anything more, why would anyone waste time on that when there's much better curated experiences on Steam, or barring that, mobile app stores and Switch? There are already enough excellent indie games to last several lifetimes. Not gonna waste time exploring the dark corners of the web to try some amateur's experiment with webgl. If they're not on an established game platform by now, I could only assume the devs care about their philosophies more than end user experience, and it would be a subpar experience even if I got the graphics to load (big if).

Even something like GeForce Now (cloud rendered streaming games) use Steam and Steamworks APIs for the community and multiplayer APIs. It's therefore much better than competitors like Google Stadia (which is pretty much dead and has no community). GOG has a niche but only for single player games. For multiplayer it's either Steam or dead matchmaking.

Maybe a more interesting comparison is something like boardgamearena or boardtopia, which offer not just simple games but also the marketplace and matchmaking features of their own. They have established their own communities finding a niche (digital low fi board games) that Steam has neglected.

And streaming technologies have a big advantage, they can take full advantage of modern hardware without any sort of driver issues on the client side blacklisting the page.

Yeah, now just waiting for the last mile connections to catch ip Maybe another decade or so...

WiFi is also still not up to par just quite yet. Maybe wifi 6?

We do have browser-based 3D renderers, but it's always several years behind the state-of-the-art in terms of what you're allowed to do with the hardware, so I think it tends to only appeal to indie developers like me…

At first I thought it was just doing bump mapping on the water surface (with some hack for the caustics)... then I dragged the sphere. Pretty impressive.

This is very cool and very old.

I know it's not meant to be 100% perfect simulation of water, but the lack of air bubbles, or the waves not growing in amplitude when I smash the sphere in the water makes it feel really dense and off.

Kinda funny that if I move the ball out of the water slowly, it generates a lot of waves, but if I shoot it in the water or out, it's just a small wave. A few times I was able to yank the ball in or out with no trace at all—though that can perhaps be chalked up to the cursor moving too fast to register the intermediate positions.

This can be solved by doing the following:

instead of checking "currentPosition" and "futurePosition" for a collision per frame, instead compute a sphere using those two values as bounds, and check if there are any collisions within that sphere

By converting the whole ball movement into an object, you end up with a "pill".

The parent is talking about Continuous Collision Detection. A pill would be similar to the end result, but only at speed.

Very impressive, even more so at its time. I still don't know how it was done.

So a lot of these are powered by the performance of GPU, is there any water implementation that's suitable to run on a CPU (doesn't have to realistic as long as it conveys the message)?

This demo is more recent, and FAR more impressive in my humble opinion:

https://doom-portal-in-webgl.vercel.app/

The fact that this runs like a dream in my browser on my $300 Acer laptop, on my second monitor, is actually unbelievable.

Yeah pretty amazing. You should respost it to HN!

Yeah, those guys are gonna love it!

What’s more impressive about it? Two static lights and some normals maps, compared to caustics, wave simulation and physics. One of these is much harder than the other, in realtime no less

Did you put your glasses on..?

Clearly I’m talking about the technical aspects of the demos. Not a lot to discuss if you think one is prettier than the other

This lags a lot on my computer

This is only possible in WebGL 2. There's a texture fetch in the vertex shader for the particles. The water demo is so impressive because it runs in WebGL 1 (Though it needs partial derivatives)

This does not have any water simulation ! how is it comparable?

I only get a black screen.

Fun trick: pause it with spacebar, then click/wiggle over an area until there's a sky-high wave

Then unpause, watch the ripples

> This demo requires a decent graphics card and up-to-date drivers.

This maybe old. Runs perfectly on my 2013 dell laptop.

Doesn't work in Brave on Android (S10):

Uncaught Error: This demo requires the OES_texture_float extension

This is still my go-to demo for making sure my WebGL is working properly.

That’s awesome!

I’m running it on an older iPad Mini (Safari, on the latest OS), and it works fine.

this was my college 3rd year project in C back in 2004

This was impressive a decade ago

friggen beautiful !

Mate, this is beautifal !

Idk why this got so much attention.

Because beauty is in the eye of the beholder.

Reply on news.ycombinator.com