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.
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.
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.
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