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 :)
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.
- 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.
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).
"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.
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.
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.
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.
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.
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.
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.)
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
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. :)
Please keep this reddit-tier lack of contribution to the discussion on, well, reddit. It's bad enough that discussion over there is flooded with puns, song lyrics and people calling everything wholesome, do we really need to drag every discussion forum on the internet down to that level?
All internet "forums" have a human sitting at the other end, why do you feel the need to mention there's a human sitting on the other end? GP wasn't really "spewing negativity", just discouraging a certain culture of discussion that is genuinely bad (and uncommon) for HN.
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'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.
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).
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).
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."
- 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.
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:
- 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:
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.
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.
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.
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 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.
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.
"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.
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?
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.
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.
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
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)?
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
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)
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