Finally got my hands to try SG. And I'm so happy by the looks of it.

The first screenshot is directional lightmap + shadow mask + 3 reflection probes..

The second screenshot is 5 lobe SG + shadow mask. Reflection probes are also there but those make little to no difference.

I expected it to be much bigger in memory size but to my surprise it turned out to be not that bad in reality.

Lightmap is 3x 2K textures => ~21mb.

SG is 1 2K*5 texture array + RGBA shadow mask => ~24mb.

Yeah it's more texture samples and more math than just sampling 2 lightmap textures. But then you also sample reflection textures with box projection and blending. And after that you still may end up with specular light leaking under shadow.

So... why it's only just one game to use SG?

Since nvidia is pretty much entirely focused on ai now, and graphics are kind of a minor line item for them, do you think they might finally release source for the proprietary linux userspace drivers?

They have delayed any new gpus until who knows when, and even pulled 5090 from shelves.... why should they care about keeping userspace graphics drivers secret?

Maybe this could be a parting gift from them to the graphics community that they built their company on?

Disclaimer: AI was used to help aid the coding, video and textual editing of this project. If that is a problem for you, then please pass by this post without indulging in unnecessary toxicity in the comments.

Ever since I discovered how many incredible point clouds exist for real-world geographic regions, I’ve been working on a Direct3D 12 point-cloud renderer to explore and visualize them.

I started with a traditional discrete Level of Detail renderer.

During loading, the point cloud is divided into an octree. Leaf nodes contain the original points for their region, while internal nodes store up to 4,096 representative points sampled from their descendants.

Every frame, the renderer traverses this tree and estimates the visual error of each node using its spacing, bounds, and distance from the camera. If the representative points are sufficient, it draws that node. If more detail is needed, it replaces the node with its visible children, continuing until it reaches leaf nodes or exhausts the point budget.

This resembles hierarchical LOD selection for meshes, but point clouds make the transition between levels much more visible. Replacing an entire node at once can create patchy density, obvious region boundaries, and large groups of points popping in together.

That led me to the paper “Real-Time Continuous Level of Detail Rendering of Point Clouds” by Markus Schütz, Katharina Krösl, and Michael Wimmer.

Their Continuous LOD approach moves the final detail decision from the CPU and its chunks to individual points on the GPU.

During preprocessing, every source point is assigned to one detail level. A coarse level might target approximately eight metres of spacing between samples, followed by increasingly dense levels targeting four metres, two metres, one metre, and so on. Each point belongs to exactly one level, and combining every level reconstructs the complete source cloud.

The resulting points are stored with their position, colour, and calculated level. At runtime, a compute shader evaluates the points using the current camera position and the desired spacing at each point’s location. Accepted points are compacted into a reduced GPU buffer and rendered.

Because detail changes point by point rather than node by node, density can transition much more gradually across the scene. This reduces the block-shaped transitions and heavy popping produced when complete octree nodes are swapped.

The video compares my LOD Renderer and Continuous LOD Renderer using the same viewpoints and approximately 3.5 million points drawn in each image.

I’m still refining the implementation and plan to share a more complete code walkthrough later.

Paper: Real-Time Continuous Level of Detail Rendering of Point Clouds

Point-cloud data from OpenTopography, with colour imagery from the USGS.

Play (Chrome 150+ on Windows only, why below): https://4k-minecraft.ayfri.com Source: https://github.com/Ayfri/4k-minecraft

Notch's 2009 Java 4K entry drew a 64x64x63 world with a CPU raycaster at about 214x120. I wanted to see how far the same 4096-byte budget goes if everything moves to the GPU.

Pipeline - At load, the compute shader fills a 128 MiB storage buffer with value-noise terrain (biomes, lakes, a snowy massif, caves, trees, ores). WGSL has no u8 storage, so 4 cells are packed per u32. - Each frame, a 1-workgroup dispatch steps the player (gravity, collisions, swimming, break/place; a single invocation edits, so no atomics), then a per-pixel dispatch marches the voxels and writes straight into the canvas as an rgba8unorm storage texture. No render pipeline, no vertex buffers, the CPU never reads the world.

Two bits of the shader

Cell lookup, the mask gives the x/z wrap for free:

fn I(c: vec3i) -> u32 { return dot(vec3u(c) & vec3u(MASK, TOP, MASK), vec3u(1, LAYER, SIZE)); }
fn B(c: vec3i) -> u32 { if c.y > TOP { return 0; } let i = I(c); return (W[i >> 2] >> (i % 4 * 8)) & 255; }

The march is a branchless DDA step:

N = step(e, min(e.yzx, e.zxy));
e += N * r;
C += vec3i(N * s);

Flowers and grass tufts are X sprites: when the ray enters their cell, it intersects the two diagonal planes and tests the alpha of the 16x16 texture.

Shading: procedural 16x16 textures tuned toward vanilla, smooth AO over 8 cells, sun shadows, see-through leaves, glass that only draws its frame, day/night with stars, fog at 200 blocks, underwater tint.

Why Chrome only: uniforms go through the new WebGPU immediates (setImmediates + var<immediate>), which saves a uniform buffer's worth of bytes. Firefox and Safari don't have immediates yet, and Chrome on macOS doesn't support rgba8unorm storage canvases.

The page is 4085 of 4096 bytes. Happy to go deeper on any part.

I was surprised none of the existing VS Code extensions provided the complete LSP experience for WGSL, with all the niceties like rename refactoring, semantic highlighting, navigation, offset/size/align hints for custom structs, etc. Plus I needed it to closely check against the Chrome's Tint compiler, so decided to make one.

Figured someone else might find it useful, so sharing it here:

• VS Code: https://marketplace.visualstudio.com/items?itemName=Elringus.wgsl-linter
• GitHub: https://github.com/elringus/wgsl-linter

Feedback and bug reports are welcome!

This is hilarious. Thought I'd share since it might be of interest to you, especially if you aim your thing to end up in a realtime setting.

There's a library you can use to insert Mario from Super Mario 64 into your renderer at https://github.com/libsm64/libsm64 It comes with full behaviour / movement. I was fiddling with exposure settings in the renderer and, since it took time, little dude went to sleep.

Aside (big) scenes to test against like Bistro, Moana Island, Caldera, etc.. this comes in real handy.

Reflections and transmission of a menger cube made of glass with a dichroic coating. Now I want to make this IRL.

Simulating dichroics. Optics is awesome.

I built lgpu because I wanted a minimal desktop GPU abstraction focused strictly on modern Vulkan without the heavy compile times of larger frameworks.

What it does:

• Fast clean builds (~1.5s): minimal dependencies (ash, bitflags, raw-window-handle, thiserror).
• Dynamic rendering: uses Vulkan 1.3 dynamic rendering directly—no VkRenderPass or VkFramebuffer setup.
• Bindless indexing: global descriptor heaps (update_after_bind) for textures and buffers.
• C99 bindings: includes lgpu.h if you want to use it from C, C++, or Zig.
• Platform support: Linux (Wayland/X11), Windows, and macOS via MoltenVK.

Code & 5 runnable examples: https://github.com/kuntal-devrat/lgpu
Crate: https://crates.io/crates/lgpu

Just released v0.1.1. Would appreciate any feedback on the API or bug reports!

413,532 triangles, with no geometry simplification

960 × 840 resolution

4 logical processors, enforced through process affinity

96 measured frames per renderer, following the same camera path

8 stationary warmup frames each

Pop Data Engine is 1.78× faster in this run.

Just bragging :)

It is in early development (this is actually 3d engine development for my OS) so there is a lot to work on, but it is fast :)

Does anyone else feel like you hit a wall building a toy engine where eventually it’s like I can’t really evaluate how good the engine actually is without building a game with it

Like an engine in isolation doesn’t mean much, it needs real content to actually be comparable to anything

But as a programmer I can’t do that so you can only go so far with it

I don't simulate the brass in my Godot gun effects at all. I just evaluate a casing's position from its age in the vertex shader. That's pretty much the stateless particles from Lutz Latta's "Building a Million Particle System" (GDC 2004). What I added is the bounces.

On a flat floor I can get the hit time straight from the quadratic. The shader loops over the bounces like this:

for (int k = 0; k < MX_BOUNCES; k++) {   // 2
    float h = max(p.y - gy, 0.0);
    float t_hit = (v.y + sqrt(max(v.y * v.y + 2.0 * g * h, 0.0))) / g;
    if (t_hit <= 0.0 || tt < t_hit) break;
    p += v * t_hit;
    p.y = gy;
    v.y = -e * (v.y - g * t_hit);   // restitution
    v.x *= fr;
    v.z *= fr;                       // friction
    tt -= t_hit;
}

After the second bounce it slides with tau * (1 - exp(-t / tau)) and I tip it over onto its side. Ejecting one is a single write into two uniform arrays. Brass from three seconds ago costs what brass from this frame costs.

I also kept a GDScript copy of the formula so the game can ask where a casing is. At 10 sample times they agree within 5.4 mm, about a pixel! In the GIF the dotted line is the GDScript side and the casing is the shader. I made the casing bigger and turned restitution up to 0.5 for it, because at my default of 0.34 the second hop is about 2 px tall.

It only knows one floor height, though. A casing will go straight through a wall. Two bounces looked like enough to me, but I'm not sure a third would even read on screen?

Actually the raycasting logic itself is just a single line, but it's done in propably the most inefficient way possible.

The map is just a single 64 bit integer, so I could fit a small 8x8 level in it, and I can index it with some unorthodox bitshift magic.

Also all the integer constants are huge, because I wanted do to the whole thing without floating point math, which makes everything even more unreadable, but at least it's funny ig.

I'm very proud of this one.

After many days of learning and scratching my head around, I was finally able to render a triangle on a screen. I am using Vulkan 1.4 for this. Although I learned this from a youtube channel called constref, but this is a very valuable lesson for me, even if it is a first step to Vulkan.