Hey @benjaminsuch , interesting musings on HBAO. I know the base theory behind HBAO, and read in the references leading up to GTAO that it’s the same basic Horizon-based idea.
Never actually read the source or saw any design diagrams as HBAO was under NDA and closed source.
As for the questions
To me it’s 100% worth it, because without it you can’t build a GPU-driven drawer as easily. It makes culling performance much more predictable as well, because meshlets have excellent spatial distribution.
Consider a large terrain for example, with nothing else but just meshlet shading and occlusion culling - you’re going to be submitting a tiny fraction of the overall geometry to the GPU, instead of the entire mesh.
I actually tried without and without meshlets, with meshlets it was a lot harder initially. But as long as you’re comfortable writing sorting compute shaders - you can generally overcome that. Or if doing CPU-driven draw is fine for you - you don’t even have an issue in the first place.
Right now I don’t do LoDs explicitly. Users are free to swap geometries on the fly, from the CPU-side though, so anything that exists in Unity or here in thee.js is double and is arguably easier because Shade has full set of dynamic spatial acceleration structures, so you can quickly figure out what’s visible and how far away from the camera. I plan to build virtual geometry tech in the future. I have experience with it already, and the processing code, which is the hardest part - already exists.
Yes, it’s a fully streaming engine.
DDGI is actually built into the engine. It’s just off by default because RTX load is quite significant, especially on the lower-end devices. Oh yeah, Shade has a full software (compute sahders) ray-tracer implementation.
Both yes and no. The engine is almost entirely GPU-driven, so any expensive work happens on the GPU. The draw is issued by the GPU, culling is done by the GPU, sorting is done on the GPU etc. For complex scenes with a lot of materials Shade might have about ~4ms overhead on the CPU. For typical scenes it’s closer to 1ms, doesn’t matter if you have 1 mesh or 1,000,000 meshes.
JavaScript is an explicitly single-threaded language, and I wanted the engine to be as close to being a pure javascript library as possible, so I write code to either be so fast on the CPU that it’s not an issue, or I move it to the GPU so that the user has the main thread almost entirely to themselves to do other work on, such as programming gameplay
Worth qualifying perhaps, I write performance-critical code in C-style, which makes it about 2-4 times slower than C on average, but put it differently - it’s a couple of orders of magnitude faster than idiomatic (how you would normally write it) JavaScript.