It supports Metal. In fact Metal is probably one of the reasons they built an adapter like this in the first place since GL became less of a supported thing on Darwin.
Not trying to shit on anyone, but that screenshot reminds me of 1990s/early 2000's games. I'm sure there has been a ton of work that went into it, but having some better textures or highlighting the usability would go a long way.
Just based on the screenshot, I am not sure that I would even bother to dig too deeply into the library.
The original Vulkan Demos were butt ugly too. Then 2 or 3 years later that super flashy DOOM remake went all-in on it and shut everyone up for a while.
It looks about on brand with the static renders used in a lot of Final Fantasy games of the PS1 era, albeit with higher pixel density of course, so I can see the resemblance. That said, this is definitely doing it in engine, so while I can see how the GP's memory palace built that memory, you're definitely accurate that no game from that era was doing graphics like this in-engine.
Pre-rendered? Sure. In-game? No.
I think the art direction is half of the problem here. You can place lighting much better and the textures are lacking.
I like it. It manages to be on the healthy side of the uncanny valley, so as to feel more like an actual inhabitable world instead of a disconcerting knock-off of the real world.
the screenshot could/should probably be better, but that doesn't mean the library is incapable of producing higher quality renders. I haven't dug in, but I am assuming this is basically Meta's WGPU. if so, these sorts of libraries are low level libraries abstracting different platforms that can be used to build high quality render pipelines on top of that can run anywhere. you could build an N64 quality rendering pipeline with little effort, or something rivaling AAA studios with a lot more knowledge and effort.
I guess, to make a poor analogy, your comment is sort of like looking at a still frame of a poorly shot movie and complaining that the codec is shit.
The problem is, it implies that the library isn't capable of higher quality. I could imagine maybe because it is a lowest common denominator. Or because the Metaverse is not focussing on high end graphics, as their previous releases looked poor. Or maybe this is something like VML. Designed to be fairly barebones and people would use it for museum websites and educational tools but not for graphically intense games.
I always see this idea on HN that a library, website, framework should be marketing itself for mass appeal and adoption.
this is made for people building rendering engines on top of. if you are the software engineer with the knowledge necessary to do that, the screenshot is probably not going to influence you, because you understand what this is for. if you aren't, why should they be marketing to you with eye candy?
The picture looks like they didn't have automatic tonemapping, the rendering equivalent of auto exposure control. So the picture is too dim. I brought it into a photo editor, saw that the top third of the intensity space was empty, used "Levels", and it looked much better.
That's a standard glTF test scene, called "bistro". Here's the same scene, rendered with Rend3/WGPU.[1]
Here's the source code for that example.[2] Rend3 is a level above WGPU; it deals with memory management and synchronization, so you just create objects, materials, transforms, and textures, then let the renderer do its thing. Rust handles the object management via RAII - delete the object, and it drops out of the scene.
Looking at Meta's examples, there are too many platform-specific #ifdef lines. More than you need with WGPU. Probably because WGPU is usually used with something like Winit, which abstracts over different window systems.
We'll have to wait for user reports about performance. Meta didn't show any video.
Here's a test video of mine using Rend3/WGPU on a town scene comparable to the "bistro" demo.[3] This is a speed run, to test dynamic texture loading and unloading while rendering.
The WGPU people are still working through lock conflicts in that area. The idea with Vulkan land is that you should be able to load content while rendering is in progress. For that to be useful, all the layers above Vulkan also have to have their locking problems hammered out. Most open source game engines don't do that yet. Unreal Engine and Unity do, which is why you pay for them for your AAA title.
hi John! you know a lot more about this stuff than I do. is it possible they just haven't implemented a full PBR pipeline for this demo/screenshot, or do you think this (the differences in the two screenshots) is more an indication of what would likely be areas for future development?
They seem to have implemented everything that the "bistro" scene calls for. I don't know if those hanging colored lights emit light, though. Rend3/WGPU doesn't handle large numbers of light sources yet. But you wouldn't see them in daylight anyway, because this is high dynamic range rendering, and, as in real life, those light are dim relative to the sun.
Here's the same scene in Godot.[1] This was modified a bit, and has accurate values for the lamp illumination. So they are totally washed out by the sun.
And here it is in several other renderers, with a video.[2]
The original scene was in .fbx, from Amazon's "Lumberyard" project. [3] That project started as the Crysis engine, was bought by Amazon, spun off as open source, was renamed
Open 3D Engine, and is still getting Github changes, so it's not dead.
There are many open source game engines. Most of them get stuck at "mostly works, not ready for prime time". That's where the problems get hard and fixing them stops being fun.
Why does Meta need an answer to WGPU? How does the existence of WGPU create problems for them, and how does this new thing solve problems that anyone else has with WGPU?
This just feels like sour grapes about the fact that WGPU excluded Khronos when it was developed, so Khronos wants their own, with maybe a bit of promotion-driven development on Meta's part.
"Just based on the screenshot, I am not sure that I would even bother to dig too deeply into the library."
Adding any PBR materials as samples would have been the wrong choice, since those are not hardware or graphics api dependent, and are always for the implementor to implment by themselves.
You don't want a graphics api to look nice at this abstraction level.
You get access to device resources, shader API etc.
Once you get triangles in, it's up to you to make it nice using the shaders you write - materials and GI model of your choice.
> Adding any PBR materials as samples would have been the wrong choice, since those are not hardware or graphics api dependent, and are always for the implementor to implment by themselves.
That "bistro" image is all PBR materials, represented in glTF. It's supposed to look the same for all standards-compliant glTF renderers, and it pretty much does. I posted the same scene in another renderer above. It's a brightly sunlit scene with no environment shaders, so it looks rather blah. glTF and Vulkan can do more than that, but this is all the test example asked for.
I don’t see the API claiming to be a standards compliant GLTF renderer, and I would be very confused if it did claim something like that as it’s feature. That said a ’render GLTF PBR’ sample would not be a bad thing to show the authors intent how to organize things etc.
It's not texture, it's the lighting, it makes it feel very flat, especially when contrasting with RTX'd stuff which we all have in memory to some degree.
You are too kind. Mid to late 90s game. What is up with those shadows. I have written a 3D-engine with better image quality than this like 20 years ago.
A large part of creating a 3D-engine is to try figuring out what capabilities can be used with what performance across different hardware. If this is only an abstraction it won't solve anything.
The textures are ok, but the lighting is super flat. People are used to games making at least some attempt at global illumination, whether it's prebaked light maps, or faking it with SSAO, or anything to not have surfaces be a totally consistent brightness across the whole thing.
Your rendering API is not going to implement GI for you, and having it in a sample app is kind of misleading, that's not really the point. It's probably a mistake to include that as a sample scene as it creates the impression that it's trying to be a game engine. A few material spheres and test meshes would probably be a better example.
For better or worse, these graphics API shots are not the place to show cool shaders. SIGGRAPH papers are usually the same dry, boring test scenes. It's just the culture of it.
Can someone explain the significance of this? I do WebGL development and I believe there is already an intermediate layer called Angle that WebGL compiles to. The Angle layer decouples the hardware from the software and allows hardware vendors to develop drivers that run Angle and shader languages to target Angle without the two needing to know anything about each other. (Not sure if that's right?)
This seems like another intermediate decoupling layer?
ANGLE is a portability layer for Windows which provides the OpenGL API on top of DirectX, since Windows clients aren't guaranteed to have good OpenGL drivers installed. WebGL is itself closely related to OpenGL so it makes sense to build it on top of that.
Angle is ultimately a OpenGL|ES implementation on top of other APIs since webgl is pretty close to GLES, but desktops don't typically implement GLES.
This (IGL) is more a layer sitting on top between your app and the system provides API since pretty much every system has a different blessed API these days: Browser:WebGL/WebGPU, Windows:DirectX/Vulkan, Mac:Metal, Linux/Android:Vulkan, Consoles: Proprietary APIs like NVN/GNM/AGC/DX12 with a lot of extensions.
Just about every major cross platform 3D graphics app/engine has a layer like IGL, this just seems to be an attempt to make Meta's a standard.
Technically there's also a driver layer sitting between the DirectX 'client-side' API and the hardware, so it's even worse ;)
(the whole point of more modern 3D APIs, which move most of the expensive "abstraction-layer translation work" into the initialization phase is to "cut through" all those layers in the frame loop though)
They claim to support WebGL as a compile target, it seems like a pretty big missed opportunity that all of their demos don't link to in-browser WebGL running examples!
HTML clicked for me one day when I mentally decoupled the hypertext from the actual browser rendering. So many of us think HTML and imagine the point is to render a webpage. But HTML describes the semantics, topology, and content of a document. It’s 100% valid to “render” HTML in some other format like a PDF or an mp3.
I'm hoping we see a move to allow the rendering of the webpage to be entirely up to the users. Just provide the data, and let me decide how I want to interact with it. But that would ruin SEO and Ads, so we're gonna get in a buncha legal battles about web scrapers instead.
But reader mode is mostly bunch of heuristics with tons of ad-hoc special cases and hacks instead of relying documents to be well-structured. So in many ways it is the opposite of successful example.
Is it kind of a compromise then to "tag" HTML with classes for CSS?
CSS doing the "rendering," like laying out mobile-responsive versus desktop.
I wonder how we would separate out explicit class names from HTML, unless the tags themselves are <custom-names />. (Micro frontends & web components?)
HTML is the semantics, CSS is the styling, but you need both. Which is why browsers come with default CSS (which you can unset) for everything. You get the element tag to say "what it is", and you get the CSS classes to say "what visual rules to apply".
This is mostly true, but the asterisks cause a little chaos.
> HTML is the semantics ... the element tag to say "what it is"
Maybe this is best framed as a perspective thing.
"Semantic HTML" is about HTML authors using HTML elements in a way that is consistent with the definitions laid out in the specs. These definitions try to specify element semantics because user agents want to be able to do less-dumb things (things that don't work as well if HTML authors are constantly abusing tags for some presentational effect even though the semantics are weird or wrong).
The main consequence of this is that tag semantics (from the UA's perspective) won't always square with what the author assumes it means unless they go study the spec. For example, it's probably not hard to go find cases where the <address> tag is used for the obvious thing from the author's perspective: marking up addresses. The spec, however, explicitly contradicts this surface-level reading: https://html.spec.whatwg.org/multipage/sections.html#the-add... (i.e., it can be "correct" for pages to contain a mix of addresses that do and don't have the address tag.)
We also have a lot of tooling that invites semantic abuse for presentational effect (i.e., using markdown blockquotes as notes, and even the fancy behavior browsers attach to the <details> element).
You joke but I wonder how big of an impact ray tracing in the browser would have, especially when the fidelity is increasing at such a massive rate. Some of the web demos I’ve seen, like the Unreal ones, are mindblowing.
(Also if that comment exposes any ignorance I have, please forgive me and point it out so I can learn something!)
Any game/3D developers here be interested in WebGPU/WebAssembly support for Unreal Engine 5? Along with an asynchronous asset loading system, for dynamic fetching of assets at runtime.
Asset delivery is one of the key aspects, no doubt. Keep in mind that today, browsers support up to 4GB at the moment - but that is a limitation that won't be an issue eventually, and when it's lifted it will allow whatever local storage the user's client hardware has to be leveraged. This would enable AA and AAA desktop/console games on the web.
Similar to https://dawn.googlesource.com/dawn in the sense that both are solving the cross platform problem. But Facebook is solving it at a higher level of abstraction
I hope this is a easy to use high level library that wraps Vulkan apis. That would help solve one big complaint that Vulkan is too low level for normal programmers.
Having to do a lot of your own switching at the implementation level seems annoying, I'm surprised there isn't a more simple API on top of that to give you the correct impl directly.
For an intermediate library, it doesn't actually seem to be very much backend-independent. At least the desktop sample [1] has a disappointing amount of code paths with parallel implementations for OpenGL and Vulkan, switched at compile time using "#if USE_OPENGL_BACKEND".
I guess this means that this sample will use OpenGL rather than Metal on macOS? They claim there's a Metal backend, but how would one enable that for the "Tiny" sample? By manually adding a third parallel implementation with "#elif USE_METAL_BACKEND" everywhere?
Those seem to be mainly platform-specific initialization things, like creating a window and rendering context. That's pretty normal for these types of rendering libraries which don't include a full blown portable windowing API.
If you use something like SDL, you'll probably be able to minimize the platform-specific stuff.
You're right, that's weird. The particular snippet you linked to isn't that egregious, it just creates a dummy 1x1 texture for some reason, and changes a hint. A lot of stuff in that file though is branched on that opengl flag. The `render` function is a huge mess, and it doesn't even seem like that demo supports Metal at all.
But tbf also, I'm just skimming the code base. Maybe they'll publish some better docs later that explain/justify these things.
createRenderPipelines uses the branch to add #version 460 to the beginning of shaders (one would think the platform backend could do that for you, also this won't support GLES2 or GL3), and also makes the programmer build a sampler/uniformblock mapping table.
That's... perhaps needed if you're on GL3 because you don't have access to binding=N in the shading language and you don't want to do any shader parsing in the backend, but also, you're forcing it on GL 4.6, so... huh? Just use explicit binding in the shader and the binding index APIs.
The render function uses USE_OPENGL_BACKEND to adapt for the -1...1 clip space. Sure, again, glClipControl is more modern than your minspec, but you're already forcing GL 4.6, so WTF. Also, it's not hard to write device_->adjustProjectionMatrixForNativeClipSpace(); that does a matrix mul.
It also makes the shadow render target have a color attachment (wtf? depth-only targets are supported just fine in GLES2/GL3 to my knowledge), and it also... doesn't use an index buffer when rendering? (EDIT: This is because it's using a 32-bit index buffer, which GLES2 doesn't support. But it's a much better idea to split it into multiple 16-bit index buffer draws if required than drop the index buffer entirely... also, you know, shaders have 4.6). I give up trying to understand what's going on. Oh, and despite building the uniformblock mapping table from before, you still have to use glPipelineState->getUniformBlockBindingPoint? What on earth?
This looks like what happens when the "All abstractions are leaky" crowd go too far. It's an absence of abstraction to the point that the intermediary layer is not helpful enough, and will simply end up hidden behind another layer of obfuscatory gunk.
Graphics people need to face the fact that writing optimised cross platform renderers is not something that can be solved by divide/conquer into layers in this bottom up way anymore, instead you need to architect the data flow of the renderer and implement platform specific/optimal approaches for each sub part of that, which are so specific that this sort of wrapper would not help. This isn't exactly far removed from the pyramids -> gothic cathedral comparison.
I have been researching, and it is my current understanding that this is the approach that WebGPU takes, specifically wgpu.
Is that right? I have been thinking that wgpu is the best choice available for intermediate cross platform graphics one level below something like Skia and one level above Vulkan, OpenGL, DirectX, and Metal.
Reads to me like the usual collection of utility/glue that people build for their own needs? Those usually don't get open sourced, but it's also not wrong to do that. At least if you can resist the urge to announce it as the graphics API to end all graphics APIs...
I did not intend to imply that they did. Sorry if that hasn't been clear. I was considering adding a few words in that direction but went with brevity.
You can build far better abstractions than what we have here. A lot of games that support more than two platforms have graphics abstractions that leak less than this.
Don’t you think this is already happening for most AAA production tech? Most high performance real-time stuff does go top-down. Mid-core stuff or art tooling might be fine with bgfx (or this I guess).
I disagree. Most of what's platform specific is stuff like shaders, and host window stuff. I definitely do NOT want a graphics layer owning that - I may want to control the type of os window (say, for an audio plugin). I already know gl shaders, and metal is really similar, a new 'common denominator' shading language would just be another language - with less docs, stackoverflow posts, etc.
And on the other hand, you get abstractions for the stuff that really is similar, like command buffers, camera control etc.
I think the API is well designed, and nails flexibility together with performance, at the cost of requiring to have, at least, expert knowledge in one library. After that I would get chatgpt to convert my shaders to metal, Vulkan, etc.
I think the documentation could be a lot clearer about this. I can understand if the goal is for the abstraction to be thin and unopinionated, and that means you have to be an expert in each backend. But they don’t seem to explain this very well.
Same impression here. The triangle example isn't better than a raw Vulkan one. Then I thought maybe it'd have more value in larger applications, but the Bistro demo is just the same kind of leaky abstraction code all over the place. The GUI is also just ImGUI. I don't know what value this library provides.
Just noticed the installation command "python3 deploy_content.py" installs the scene and not the library. Don't run that one if you don't want do download 2G of stuff, just run the deploy_deps one.
It doesn't support vulkan though, but if that's important to you you're probably much better off just using vulkan directly since it's supported on all the major platforms.
...technically, Vulkan on Windows is also only supported via 3rd-parties (the GPU vendors), so the situation isn't actually all that different. The "Vulkan driver" is just bundled with the application on Mac instead of installed separately.
Darn, I opened the link and saw it was using Python. Sadly that seems to just be for the install process, for whatever reason.
Does anyone have any recommendations for an intermediate graphics library that uses Python and supports compiling your code to a WebGL target?
I'm interested in exploring SDF functions in a parametric CAD context, but coming from a Mechanical Engineering background. Not having to learn a new programming language for a side curiosity would be ideal.
Purely because I already know it well enough to be semi-dangerous. My day job is designing physical goods, I don't have the time to learn anything new just to satisfy my curiosity with signed distance fields.
I don't think you realize just how horrendously bad Python would be for this application. The global interpreter lock and marshaling between Python objects and GPU state would absolutely kill any kind of performance.
Pick up Rust and Bevy. It should be pretty easy to mock up what you want, and you can dip into wgpu when you need extra fine control over the GPU.
Filement is full blown renderer (with shadows, advanced materials, effects like transparency, postprocessing) with platform abstractions. IGL has only the platform abstractions and the rest is left as an exercise for the reader.
I'd say even Vulkan alone is sufficient to cover Windows.
The main benefit of DirectX 11 is that it's a lot simpler for the developer. But when you are creating an abstraction layer for multiple APIs, you are not the target audience for a simple to use graphics API.
IIRC Doom Eternal only supports Vulkan (on PC) and that didn't really cause problems. In fact, the game's performance was superb.
I understand why WebGPU defined a new API since it's primarily intended for web browsers, however, in this case why create a new API? Why not implement the OpenGL API? Essentially this could have been an OpenGL wrapper over the lower-level API's, e.g. over Vulkan, Metal, and Direct3D 12.
OpenGL has the advantage of being an open standard. Did Meta need custom behavior? If so, OpenGL already has a well-defined extension mechanism.
OpenGL is not the most straightforward, not the most compact, not the most ergonomic, not the most modern API. It's one of the most widespread though.
Meta produced this library not for the benefit of general public. They produced it to make their own development easier and faster, and internally they are unlikely to benefit from OpenGL's ubiquity or backwards compatibility. Then they released the library for the benefit of general public. This is very nice, thanks! But we are not the main target audience.
I know next to zero about rendering capabilities. But when I saw Meta | Release | Graphics Library. Given Facebook's history with data collection and the proprietary nature of their VR headset. I doubt they have any interest in open standards.
Facebook have released a bunch of good-quality open-source libraries and tools. Not just zstd, rocksdb, folly, flow, hhvm and other niche things, but also PyTorch and React, staples of two industries.
Since they are honestly open source, they have been inspected a lot, and, if they included any data siphoning, that would be long known, and long since deleted.
Their technical achievements are not my domain. But I know behavior patterns, since Facebook's platform was built to harm peoples ability to choose for themselves, I consider it a blight on humanity. I doubt they have any interest in serving the common good. But I hear that you don't share my skepticism, time will tell.
Abstractions over the low level apis (opengl, directx, vulkan, metal) have gotten a bit popular in recent years. I think some driving forces behind it are inconsistent support of some apis on some platforms (i.e. opengl on macos) and maybe also a desire to support some of the newer apis (Vulkan or dx12) without going all in due to their complexity/verbosity.
I've been playing with wgpu-rs, bgfx, and a couple others in the past and they work pretty well for the most part. At this point I think I'd still rather choose just Vulkan for a new project though.
Having worked with OpenGL since around 1998 let me say: it's definitely the worst of all popular 3D APIs, and already has been since around the time D3D7 was released. It's time to let it go the way of the Dodo (just a shame that Vulkan didn't fix the worst OpenGL problem which is the vendor extension zoo).
220 comments
[ 2.0 ms ] story [ 219 ms ] threadhttps://github.com/facebook/igl
“It supports various graphics APIs, such as OpenGL®, OpenGL ES™, WebGL™, and Vulkan®”
Seems strange that’s missing from one and showing in the other.
Just based on the screenshot, I am not sure that I would even bother to dig too deeply into the library.
This screenshot is far from current AAA games, but there is no way to render such a scene in a game made for 2000 hardware.
https://developer.nvidia.com/orca/amazon-lumberyard-bistro
https://www.jmeiners.com/pre-rendered-backgrounds/img/ff7.jp...
and the image in the article about Meta's library:
https://www.khronos.org/assets/uploads/blogs/2023-july-blog-...
If FF7 were rendered at the same resolution, I think it would be comparable. Here's an FF7 AI upscale mod for reference:
https://www.resetera.com/threads/a-full-high-res-ai-upscale-...
https://youtu.be/j-Iykz0gb7Q (video uploaded 2006)
I guess, to make a poor analogy, your comment is sort of like looking at a still frame of a poorly shot movie and complaining that the codec is shit.
this is made for people building rendering engines on top of. if you are the software engineer with the knowledge necessary to do that, the screenshot is probably not going to influence you, because you understand what this is for. if you aren't, why should they be marketing to you with eye candy?
The picture looks like they didn't have automatic tonemapping, the rendering equivalent of auto exposure control. So the picture is too dim. I brought it into a photo editor, saw that the top third of the intensity space was empty, used "Levels", and it looked much better.
That's a standard glTF test scene, called "bistro". Here's the same scene, rendered with Rend3/WGPU.[1] Here's the source code for that example.[2] Rend3 is a level above WGPU; it deals with memory management and synchronization, so you just create objects, materials, transforms, and textures, then let the renderer do its thing. Rust handles the object management via RAII - delete the object, and it drops out of the scene.
Looking at Meta's examples, there are too many platform-specific #ifdef lines. More than you need with WGPU. Probably because WGPU is usually used with something like Winit, which abstracts over different window systems.
We'll have to wait for user reports about performance. Meta didn't show any video. Here's a test video of mine using Rend3/WGPU on a town scene comparable to the "bistro" demo.[3] This is a speed run, to test dynamic texture loading and unloading while rendering. The WGPU people are still working through lock conflicts in that area. The idea with Vulkan land is that you should be able to load content while rendering is in progress. For that to be useful, all the layers above Vulkan also have to have their locking problems hammered out. Most open source game engines don't do that yet. Unreal Engine and Unity do, which is why you pay for them for your AAA title.
[1] https://raw.githubusercontent.com/BVE-Reborn/rend3/trunk/exa...
[2] https://github.com/BVE-Reborn/rend3/blob/trunk/examples/scen...
[3] https://video.hardlimit.com/w/sFPkECUxRUSxbKXRkCmjJK
Here's the same scene in Godot.[1] This was modified a bit, and has accurate values for the lamp illumination. So they are totally washed out by the sun.
And here it is in several other renderers, with a video.[2]
The original scene was in .fbx, from Amazon's "Lumberyard" project. [3] That project started as the Crysis engine, was bought by Amazon, spun off as open source, was renamed Open 3D Engine, and is still getting Github changes, so it's not dead.
There are many open source game engines. Most of them get stuck at "mostly works, not ready for prime time". That's where the problems get hard and fixing them stops being fun.
[1] https://github.com/godotengine/godot/issues/74965
[2] https://www.ronenbekerman.com/orca-amazon-lumberyard-bistro/...
[3] https://developer.nvidia.com/orca/amazon-lumberyard-bistro
[4] https://en.wikipedia.org/wiki/Amazon_Lumberyard
This just feels like sour grapes about the fact that WGPU excluded Khronos when it was developed, so Khronos wants their own, with maybe a bit of promotion-driven development on Meta's part.
Adding any PBR materials as samples would have been the wrong choice, since those are not hardware or graphics api dependent, and are always for the implementor to implment by themselves.
You don't want a graphics api to look nice at this abstraction level.
You get access to device resources, shader API etc.
Once you get triangles in, it's up to you to make it nice using the shaders you write - materials and GI model of your choice.
That "bistro" image is all PBR materials, represented in glTF. It's supposed to look the same for all standards-compliant glTF renderers, and it pretty much does. I posted the same scene in another renderer above. It's a brightly sunlit scene with no environment shaders, so it looks rather blah. glTF and Vulkan can do more than that, but this is all the test example asked for.
Go watch nvidia’s demo of their lighting and scene modification/remastering tool.
At least it is not a teapot.
Well good news, it's not a 3d engine at all! It's a nice common API to cover all the existing graphics APIs.
This seems like another intermediate decoupling layer?
This (IGL) is more a layer sitting on top between your app and the system provides API since pretty much every system has a different blessed API these days: Browser:WebGL/WebGPU, Windows:DirectX/Vulkan, Mac:Metal, Linux/Android:Vulkan, Consoles: Proprietary APIs like NVN/GNM/AGC/DX12 with a lot of extensions.
Just about every major cross platform 3D graphics app/engine has a layer like IGL, this just seems to be an attempt to make Meta's a standard.
Owie
(the whole point of more modern 3D APIs, which move most of the expensive "abstraction-layer translation work" into the initialization phase is to "cut through" all those layers in the frame loop though)
HTML clicked for me one day when I mentally decoupled the hypertext from the actual browser rendering. So many of us think HTML and imagine the point is to render a webpage. But HTML describes the semantics, topology, and content of a document. It’s 100% valid to “render” HTML in some other format like a PDF or an mp3.
https://github.com/mozilla/readability/blob/main/Readability...
CSS doing the "rendering," like laying out mobile-responsive versus desktop.
I wonder how we would separate out explicit class names from HTML, unless the tags themselves are <custom-names />. (Micro frontends & web components?)
Then it sort of works out nicely, I think.
> HTML is the semantics ... the element tag to say "what it is"
Maybe this is best framed as a perspective thing.
"Semantic HTML" is about HTML authors using HTML elements in a way that is consistent with the definitions laid out in the specs. These definitions try to specify element semantics because user agents want to be able to do less-dumb things (things that don't work as well if HTML authors are constantly abusing tags for some presentational effect even though the semantics are weird or wrong).
The main consequence of this is that tag semantics (from the UA's perspective) won't always square with what the author assumes it means unless they go study the spec. For example, it's probably not hard to go find cases where the <address> tag is used for the obvious thing from the author's perspective: marking up addresses. The spec, however, explicitly contradicts this surface-level reading: https://html.spec.whatwg.org/multipage/sections.html#the-add... (i.e., it can be "correct" for pages to contain a mix of addresses that do and don't have the address tag.)
1990s web, with flashing tags and just infant monkeys trying to cobble together a webpage?
Your comment brings so many images to mind.
We can still do flashing tags and cobble together webpages; all we need is a text editor.
That's one allure of programming: we can (re)invent primitives of everything, for better or worse.
¹ With CSS and Javascript
(Also if that comment exposes any ignorance I have, please forgive me and point it out so I can learn something!)
I guess this means that this sample will use OpenGL rather than Metal on macOS? They claim there's a Metal backend, but how would one enable that for the "Tiny" sample? By manually adding a third parallel implementation with "#elif USE_METAL_BACKEND" everywhere?
[1] https://github.com/facebook/igl/blob/main/samples/desktop/Ti...
If you use something like SDL, you'll probably be able to minimize the platform-specific stuff.
But tbf also, I'm just skimming the code base. Maybe they'll publish some better docs later that explain/justify these things.
createRenderPipelines uses the branch to add #version 460 to the beginning of shaders (one would think the platform backend could do that for you, also this won't support GLES2 or GL3), and also makes the programmer build a sampler/uniformblock mapping table.
That's... perhaps needed if you're on GL3 because you don't have access to binding=N in the shading language and you don't want to do any shader parsing in the backend, but also, you're forcing it on GL 4.6, so... huh? Just use explicit binding in the shader and the binding index APIs.
The render function uses USE_OPENGL_BACKEND to adapt for the -1...1 clip space. Sure, again, glClipControl is more modern than your minspec, but you're already forcing GL 4.6, so WTF. Also, it's not hard to write device_->adjustProjectionMatrixForNativeClipSpace(); that does a matrix mul.
It also makes the shadow render target have a color attachment (wtf? depth-only targets are supported just fine in GLES2/GL3 to my knowledge), and it also... doesn't use an index buffer when rendering? (EDIT: This is because it's using a 32-bit index buffer, which GLES2 doesn't support. But it's a much better idea to split it into multiple 16-bit index buffer draws if required than drop the index buffer entirely... also, you know, shaders have 4.6). I give up trying to understand what's going on. Oh, and despite building the uniformblock mapping table from before, you still have to use glPipelineState->getUniformBlockBindingPoint? What on earth?
This does not impress me.
GPU programming is insane and the devs have stockholm syndrome.
I only read the announcement by the time I submitted it, it is quite clunky.
Thr shaders are backend specific but rest is mostly generic?
Graphics people need to face the fact that writing optimised cross platform renderers is not something that can be solved by divide/conquer into layers in this bottom up way anymore, instead you need to architect the data flow of the renderer and implement platform specific/optimal approaches for each sub part of that, which are so specific that this sort of wrapper would not help. This isn't exactly far removed from the pyramids -> gothic cathedral comparison.
Is that right? I have been thinking that wgpu is the best choice available for intermediate cross platform graphics one level below something like Skia and one level above Vulkan, OpenGL, DirectX, and Metal.
Please quote the text that made you believe this. It's a very negative take.
And on the other hand, you get abstractions for the stuff that really is similar, like command buffers, camera control etc.
I think the API is well designed, and nails flexibility together with performance, at the cost of requiring to have, at least, expert knowledge in one library. After that I would get chatgpt to convert my shaders to metal, Vulkan, etc.
https://github.com/floooh/sokol
It doesn't support vulkan though, but if that's important to you you're probably much better off just using vulkan directly since it's supported on all the major platforms.
https://github.com/gfx-rs/wgpu
It is written in Rust
There are other tools you could use out there with IGL, but Sokol's solution streamlines the whole process.
...technically, Vulkan on Windows is also only supported via 3rd-parties (the GPU vendors), so the situation isn't actually all that different. The "Vulkan driver" is just bundled with the application on Mac instead of installed separately.
https://github.com/facebook/igl
Does anyone have any recommendations for an intermediate graphics library that uses Python and supports compiling your code to a WebGL target?
I'm interested in exploring SDF functions in a parametric CAD context, but coming from a Mechanical Engineering background. Not having to learn a new programming language for a side curiosity would be ideal.
Pick up Rust and Bevy. It should be pretty easy to mock up what you want, and you can dip into wgpu when you need extra fine control over the GPU.
https://libfive.com/
[0]: https://github.com/google/filament
The main benefit of DirectX 11 is that it's a lot simpler for the developer. But when you are creating an abstraction layer for multiple APIs, you are not the target audience for a simple to use graphics API.
IIRC Doom Eternal only supports Vulkan (on PC) and that didn't really cause problems. In fact, the game's performance was superb.
OpenGL has the advantage of being an open standard. Did Meta need custom behavior? If so, OpenGL already has a well-defined extension mechanism.
Meta produced this library not for the benefit of general public. They produced it to make their own development easier and faster, and internally they are unlikely to benefit from OpenGL's ubiquity or backwards compatibility. Then they released the library for the benefit of general public. This is very nice, thanks! But we are not the main target audience.
Since they are honestly open source, they have been inspected a lot, and, if they included any data siphoning, that would be long known, and long since deleted.
I don't share your skepticism.
I've been playing with wgpu-rs, bgfx, and a couple others in the past and they work pretty well for the most part. At this point I think I'd still rather choose just Vulkan for a new project though.
It does seem like kind of a mess. Unlike WebGPU, though, it doesn't sound like Meta's thing is much of an improvement.
https://github.com/ocornut/imgui/wiki/Software-using-dear-im...