Yes. That needs clarification. I was talking about all these 3 extensions. I will put that in my fix TODO list. Already mentioned by somebody else in Twitter too.

Too many social media platforms... too little time.

Usually people put NonUniformResourceIndex in the same line as the texture sampling call (or just above it). But you are correct, the semantics should be well defined if it's passed as an argument or stored in a struct.

We already have that API. It is called CUDA :)

I ended up writing an API in the end of the blog post titled "No Graphics API". At least my API has only 150 lines of code. In comparison WebGPU is 2700 lines and Vulkan is over 20,000. But "5% API" isn't as catchy title as "No API" :)

This game doesn't have any textures. This is true for most of the games on the platform currently.

Texture support is a recent addition, and we are going to add lots of new texturing features in January / February.

This is why we have virtual texturing in HypeHype. Our games are tiny (10MB), so we don't need to stream anything. However, we still implemented virtual texturing to improve our CPU and GPU performance. It also solves material variety and tiling issues (fast material blending and decaling).

Rendering, culling, collisions, physics, etc. engine features need well-optimized data-oriented code. That code is long-lasting, so you can afford to write complex parallel algorithms and micro-optimize them. Game code on the other hand is prototyping heavy and with lots of organic dependencies.

In Claybook, we had a game world in GPU and lots of game code running in compute shaders. Iteration times sucked. We couldn't make a good game. It ended up shipping as tech proto. For game code, prototyping speed is often more important than runtime performance.

Yeah, ECS examples tend to be trivial: Mover component moves entities along their velocity vectors. No complex dependencies. Real game code has many dependencies that are hard to express with ECS. Game programmers then waste time writing complex CS stuff like graph colorization algorithms.

Even without math knowledge, dividing by determinant is unnecessary if you normalize the vectors. Because that's just multiply (inverse multiply) by a scalar, which is lost in normalize anyway.

But people just take math formulas and put them one after the other without thinking.

I inherited HypeHype rendering code ownership, and we had stupid bugs like quaternions being left handed in some places and right handed in others, and OpenGL and DirectX matrix layouts mixed (row vs column major). Now we have been cleaning up the math. This is one extra thing to do.

Yeah. But it's hard for people to unlearn things. If the old solution works, they stick with it. AFAIK Unreal, Unity, and Godot all still use the traditional inverse transpose. Most game devs don't read math books. They just use Unity.

Inverse transpose is still the de-facto standard solution, even though it's not the best. Most engineers working on game engines haven't read your books or articles.

I have your book, and I am halfway through it. It's excellent. Thanks for educating people.

Not right now, but that's a plan.

Nice!

VT makes it possible to fit all textures in one atlas (3x atlases, actually, since there are three textures per PBR material). 4096x4096 atlas is fine for 720p resolution (low end phones) and 8192x8192 for 4K.

This demo doesn't yet have a virtual texture decaling system. It will make it possible to add lots of texture variety with minimal storage cost. But it's possible to make pretty good-looking results even with just a couple of traditional tiling textures.

Thanks for the info! We are implementing local lights for HypeHype and investigating similar techniques. UGC is usually kit-bashed content, and users don't consider technical limitations. They want to add more objects. This is why we are also interested in "unlimited" light count technologies.