[HN Gopher] WebGL2 Fundamentals
___________________________________________________________________
WebGL2 Fundamentals
Author : lnyan
Score : 173 points
Date : 2023-02-26 09:12 UTC (13 hours ago)
(HTM) web link (webgl2fundamentals.org)
(TXT) w3m dump (webgl2fundamentals.org)
| chrisweekly wrote:
| > "NOT out-of-date... entirely new..."
|
| (FTA, which contains no date.)
|
| Please, authors, always, just put a date on your posts.
| 0xDEF wrote:
| 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.
| JoeyJoJoJr wrote:
| 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.
| trollied wrote:
| > Why has this not triggered a revolution in browser games?
|
| Monetization.
| whitehexagon wrote:
| 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.
| thejohnconway wrote:
| 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.
| bruce343434 wrote:
| <iframe>? Other than that, nothing is stopping you from
| writing css and scripts and html in one file.
| [deleted]
| viddi wrote:
| 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.
| throwaway12245 wrote:
| 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.
| [deleted]
| viddi wrote:
| 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.
| Joel_Mckay wrote:
| 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... =)
| brainzap wrote:
| Visit https://itch.io to check out some browser games.
| d13 wrote:
| 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.
| mkimball wrote:
| 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.
| T-A wrote:
| 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?
| olivermuty wrote:
| 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
| 323 wrote:
| 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.
| troymc wrote:
| What about https://playcanvas.com/ ?
| samwillis wrote:
| 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.
| dakom wrote:
| 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.
| TazeTSchnitzel wrote:
| 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.
| shove wrote:
| That's not entirely true. They were dragging their feet,
| but there were efforts both within and outside Adobe.
| moth-fuzz wrote:
| 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.
| pjmlp wrote:
| 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.
| moth-fuzz wrote:
| 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.
| pjmlp wrote:
| Which is what one needs for debugging as well, after all
| these years the only debugging tool for Web is spectorjs.
| xdennis wrote:
| 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.
| dakom wrote:
| 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.
| [deleted]
| meheleventyone wrote:
| 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.
| mkl wrote:
| To remove the distracting background and make the page readable,
| run
| document.querySelector('.background').remove()
|
| in the browser console (or use Reader Mode).
| 0xDEF wrote:
| Luckily it's only the landing page that has that annoying
| animated background. But what the hell was the author thinking?
| Yizahi wrote:
| 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).
| threatofrain wrote:
| Also consider readability mode which is available by default in
| Firefox and Safari.
| mkl wrote:
| Yes, I suggested that. I was in Chrome, whose reader mode is
| incomprehensibly hidden and unsupported.
| nycdotnet wrote:
| ads
| benob wrote:
| I hate those websites that mess-up with browser history...
| dang wrote:
| Related:
|
| _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)
| naillo wrote:
| 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
| tppiotrowski wrote:
| 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.
| app4soft wrote:
| > _WebGL2 Fundamentals_ (https://webgl2fundamentals.org/)
|
| A simple showcase of how to warm up CPU/GPU and speed up cooling
| fans.
| yazzku wrote:
| And how to break the browser's back button.
| gtrevorjay wrote:
| 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 LOVE,
| 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
___________________________________________________________________
(page generated 2023-02-26 23:01 UTC)