WebGPU GLTF viewer

Showcase
, ,
1

card
Here the Link.

Been working on this for a few days on and off. It’s running on top of Shade.

The GI is off, the indirect lighting is:
IBL + SSR + GTAO, with occlusion terms adjusted via bent normals.

There’s HDR display support.

Controls are mouse and keyboard (ASWD)

Knowns issues:

  • no animation support
  • no extensions, just plain GLTF 2.0, so no basis or draco
  • directional lights in GLTF will confuse the tool, point lights and spot lights are fine though.

Would be very curious to see what people use it for, so if you screenshots are very welcome.
Any comments/questions/feedback is welcome too.

4 Likes
2

Tested it with a model. It looks too bright, but this might be just an issue with the default light setting. There is some sort of halo around the model and when the camera is rotated the halo becomes banded. More troubling is the FPS, which is only 105:

The banded halo:

image
image1380×620 70.8 KB

The FPS:

image
image1920×1080 531 KB

Here is the same model + 2 other models (totally 50 instances), animated and the FPS is 144, this is the maximal rendering FPS of my laptop.

Live: https://boytchev.github.io/disfigure/examples/test.html

image
image1920×1080 412 KB

The models are here, if you want to test with them.

1 Like
3

Heya, thanks for the feedback!

The halo is just the bloom.

As for the brightness, I’m not sure exactly, but it might be correct, the character is probably pure white, as on the background of the grass and soil it will look like it’s glowing. Though I should probably tone down the source light intensity.

As for the contrast overall - it’s controlled by the automatic exposure, so some kind of exposure setting is going to be picked and we’re going to adapt to it.

Lastly the banding - under motion that’s probably TAA, judging by the jagged edge which indicates disocclusion

Lastly the FPS. The engine has a certain fixed overhead, so the idea is that FPS will be lower on simple cases, but on complex cases it will overtake.

That, and there’s a whole bunch of post-processing going on, the rendering is true HDR under the hood too, that is - it draws using rgba16float targets, which will always lose to SDR targets, due to doubled memory overhead.

As an example, here’s a similar, very basic model scene, but with 10,000 instances and each instance using a unique material

image
image1917×1077 207 KB

In Shade it runs poorly, at around 60 FPS, but three.js only manages 18 FPS.

Sounds quite defensive, but I do agree with your general critique, that it needs to run faster and that this white model looks over-exposed.

Thanks for the detailed feedback!

1 Like
4

Yes, it was obvious that the GLTF Viewer does additional processing, some sort of beautification.

Having an overhead that does not scale up with the scene complexity is excellent. It is like comparing O(N+100) against O(N^2+10). For small N<10 the first O(...) is worse, but as N increases it gets progressively better than the second O(...).

1 Like