WebGL2 Fundamentals | Hacker News Reader

WebGL2 Fundamentals

webgl2fundamentals.org

213 pointslnyan44 comments

This site most definitely delivers on the "fundamentals" it promises. Regardless of if you're planning on using a higher level engine like Unity or even something super simple like LÖVE, I would highly recommend at least skimming through. There's just no substitute for the low level understanding it maps out once you need to debug or do something tricky with 3D or shaders. Case in point: it clearly lays out camera matrix construction. Most libraries provide a magic function for this based on camera parameters, which is all well and good until you need to extract or modify the matrix itself.

This site was my bible for creating the 2D engine for Cat-Tastrophe: https://www.newgrounds.com/portal/view/861234

Somehow this tutorial never clicked for me. I finally looked elsewhere and it got way easier for some reason. I think it has to do with him using his own little library in almost example which hides away some important setup (which obviously helps him out efficiently writing the articles but if you're there to learn I think you should see that too without layers hiding it).

These are fantastic though: https://www.youtube.com/@osakaandrew/videos

> "NOT out-of-date... entirely new..."

(FTA, which contains no date.)

Please, authors, always, just put a date on your posts.

It's a living document maintained in a git repo which is prominently linked.

Mainstream browsers have supported WebGL since 2011/2012 (and WebAssembly since 2017).

Why has this not triggered a revolution in browser games? It feels like the best browser games are still the ones from the Flash era.

> Why has this not triggered a revolution in browser games?

Monetization.

and possibly related, the ease of which code and assets can be copied. I am doing some Go/Zig WASM with WebGL2, but no idea how I could sell something based on this tech.

I think about this from time to time, and i think it’s got to do with the pipeline of creation, distribution, and presentation. With Flash, you had an obvious piece of graphical software to create your thing, and when you were done you had one file you could upload anywhere that would accept it. Once it was uploaded somewhere, it could be served up as simply as an image, at the stated size, and it would work.

So it was all obvious and encapsulated.

I would like a generally agreed upon encapsulated html standard. Single-file sites that can be served as simply as media.

Flash games and animations often had a lot of static assets, like sound, bitmap images, or fonts. You could data-uri all that in your html file, too, but with all the base64 overhead it might be a good idea to compress everything afterwards (e.g. SingleFileZ, see my other comment). Of course only if file shipment is an issue for you, otherwise relying on your server's gzip compression might be enough.

Try xz compression and put in a blob and then and put in wasm (C or rust for best performance). You can inline the wasm in single html file along with js and css. At load time, in wasm, you can decompress and instantiate the elements/objects/records from parsing the blob. You can keep in wasm or copy/move to js land. Sounds like a lot but it's pretty easy.

Although there is no agreed upon standard for encapsulated single-file web content, you can try to run your finished product through SingleFileZ or single-filez-cli, and ship that around, or embed it with an Iframe. I'm just not sure if it's suitable for games or application that load static assets upon certain interaction.

Visit https://itch.io to check out some browser games.

One problem I quickly ran into when I played around with WebGL a decade ago was that browser support was both unstable (things would break unpredictably on every update) and conditional. If you had the latest Nvidia GPU and drivers, it would mostly work. If you were on an older Nvidia GPU, AMD, or - heaven help you! - Intel integrated graphics, you would be lucky to see anything beyond a blank canvas.

You needed a recent gaming PC to run WebGL content. Why use it for that, when it could run vastly superior native games?

I dont make games but I am the architect behind and owner of the company that develops V3Geo [0] (and another paywalled version for the oil industry) and it’s been years since we felt we had to worry about compability.

Initially we needed a young priest, an old priest and a lot of luck for the setup to work properly on anything except for specifically pinned versions of Chrome but these days you can just whip up any smartphone and all our models render just fine.

More advanced stuff that requires bleeding edge and to port old games, sure, but to relive the heydays of flash games every chance we had on the library computers?? Seems like we have had that possible for years now.

[0] https://www.v3geo.com

WebGL is very low-level. And there is no good Flash-like editor where you work with shapes and animations and which compiles and outputs to WebGL.

What about https://playcanvas.com/ ?

The key to the success of Flash was the combination of the player with a really good and accessible creation tool. That's what's missing from WebGL development, a flash style tool that scales from basic animation and interaction design up to full game development.

I was maybe 13 when I first used Flash (v3 in about 1999), way before I had much experience with "proper" coding. The fact that I could use it, the same tool professionals were using was what made it so special.

I'm sure it's coming.

That tool could and should have been Flash, but Adobe don't seem to be interested in making ActionScript work on the modern web, which is weird.

That’s not entirely true. They were dragging their feet, but there were efforts both within and outside Adobe.

The carefree fun of youth is kinda the difference though :)

I also built a lot of stuff in Flash/AS back in the day, and even rode the wave into AIR for a while.

The OOP system, event handling with spaghetti code, and high level graphics abstractions just never bothered me. Things worked, and the nature of the beast is I didn't have to worry about maintainability so much.

Nowadays it would be different. I don't think Flash or Actionscript would be quite as fun. For out of the box engines, Unity->WebGL is far more powerful imho.

PIXI.js and any compatible spritesheet animation package gets you more than halfway there, using the same OOP scene graph paradigm, for people who really miss the Flash approach. Not the same level of IDE integration, but, still..

At least least I looked at it, which was years ago, and successfully ported over some old flash apps.

The success of self-publishing indie games on Steam redirected the whole scene because it streamlined monetization and discovery.

In comparison the web of that time lacked tooling, robust support and easy routes to discovery and making comparable money. Web portals paid/pay pretty poorly.

I feel like a new market surely is going to appear in the web games space. The low level pieces (webgl, game pad support) are good enough to make awesome games, but the main engines don’t jell with the web ecosystem. I think it is going to be a game like Celeste - high quality, developed with a mid level rendering library, game pad exclusive — that paves the way for a new batch of indie titles that better leverage the web to its potential.

I see an awesome opportunity for a minamalist immediate mode rendering library in the vein of Kha/XNA/Mono Game to deliver blistering 2D performance on WebGL, that an ecosystem can form around and build upon. Libraries like Phaser and Pixi attempt to give Flash like functionality but don’t offer the Flash like API stability, so as an ecosystem foundation they kinda suck. A library that merely implements a subset of the 2D canvas API, but performant and easily portable, would serve as the best foundation IMO.

You can see a cross-Browser WebGL Game Engine here:

https://github.com/BabylonJS/Babylon.js

In general, the tradeoffs are:

* WebGL is not always available and enabled in all browsers

* Spacial Audio effects and formats are inconsistent across platforms

* mouse/keyboard/game-pad support is tricky (browser security is messy)

* Rigging a mesh for animation gets computationally expensive

* Basic collision detection and snapping to surfaces is always computationally expensive, so to make it performant people use 90's style sphere/cube assumptions

* mutable textures are supported, but basic animated effects still bloat into video memory

* all game assets and runtime code are exposed to end users

Thus, most conclude JS+WebGL are incompatible with most commercial settings, and basic anti-cheat enforcement. Note, WebAssembly+webGL is marginally improved, but again further reduces the number of supported platforms.

People tend to prefer native App binaries, as unity3D/OpenGL can allow better content experiences without the added resource overhead. One could try to fight this trend, but Apple/Google/Microsoft want their cut... and will continually do things that enforce their bottom line.

Have a wonderful day... =)

The app economy took over just as Flash died. The only 2 niche industries still able to make money from web games are education and gambling. Education because schools require a zero installation process for all platforms and gambling because it’s the most friction-free route to impulsive spends.

It’s all dated. All of it. WebGL 1 is an outdated version of OpenGL (which is already an outdated API), WebGL 2 which was only just recently widely supported, brings a sort-of-less-outdated version of OpenGL (which, again, is itself outdated).

So we’re mostly waiting on WebGPU support so we can use a more modern-feeling API. But by the time WebGPU becomes both itself standardized and then widely supported, well, who knows if it will still be relevant…

The web just unfortunately lags behind while still emulating desktop. It would be fine if it did it’s own thing entirely so we wouldn’t have anything to compare to but writing 3D for web just feels like writing 3D for desktop 10 years ago. Plus performance and security… it’s way easier to just drop a .exe on itch.io or whatever.

Except WebGPU is also dated, based on the version 1.0 of Vulkan/Metal/DX 12.

Don't expect mesh shaders, RT or something like nanite in the next 10 years after WebGPU 1.0 gets released later this year.

Exactly. I just didn’t want to sound too pessimistic in the original post… honestly I’m just excited we get bare minimum a modern architecture on the web. That doesn’t mean I wouldn’t still rather just write for desktop in the end anyway if I want to use techniques from this generation.

Which is what one needs for debugging as well, after all these years the only debugging tool for Web is spectorjs.

I'm not convinced that subpar graphics is the reason for the lack of browser games.

I'd suggest that the reason is monetization. People are used to buying phone apps and console games, but expect web pages to be free. And open source is good at software but not games.

I think that's part of it, but the other part is load times.

People are fine waiting the 10-30 minutes for a game to download on Steam or console. But they don't want to wait more than a few seconds for webpages.

Also, techies understand that there's ways of agressively caching,but I don't think average users register that it's just a first-load issue.

I was the primary programmer on this web based 3D dungeon crawler: https://mkimball.itch.io/gift-of-fire

It's slow to load, and you'll get lag when you move around a bit, and this is due to slow shader compilation, which I wasn't able to avoid with stock Godot 3.5. You can't easily multithread your WebGL application (at least not without a bunch of caveats), so the audio glitches as well. Additionally, streaming a lot of content while providing a good user experience is an extra design and technical challenge compared to downloading a native app.

Every shipping game is a miracle - by doing WebGL instead of native, you are adding a bunch of additional challenges. And for what? Players are just as happy to download a native build.

To remove the distracting background and make the page readable, run

  document.querySelector('.background').remove()

in the browser console (or use Reader Mode).

Also consider readability mode which is available by default in Firefox and Safari.

Yes, I suggested that. I was in Chrome, whose reader mode is incomprehensibly hidden and unsupported.

ads

Luckily it's only the landing page that has that annoying animated background. But what the hell was the author thinking?

I think it is actually clever. First of all it not in the foreground or side by side, reducing area for the useful content. And at the same time it immediately promotes the tech with no marketing words - look, you can do this, it runs flawlessly without lag or stuttering. Seems to me it's a nice balance between marketing and useful info (text and links).

On my 2019 MBP it runs horribly slow and makes my browser tab unusable in both Safari and Edge.

Other things run fine, including samples from webglsamples.org.

I hate those websites that mess-up with browser history...

This was my main source of tutorials when learning WebGL. It's hosted on GitHub and you can submit corrections as PRs which is great. There is also webglfundamentals for webgl1 and webgpufundamentals by the same author, I believe.

WebGL2 Fundamentals - https://news.ycombinator.com/item?id=25251916 - Nov 2020 (2 comments)

WebGL2 Fundamentals - https://news.ycombinator.com/item?id=16085360 - Jan 2018 (74 comments)

> WebGL2 Fundamentals (https://webgl2fundamentals.org/)

A simple showcase of how to warm up CPU/GPU and speed up cooling fans.

And how to break the browser's back button.

Reply on news.ycombinator.com