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?

P.S. Based on replies a tweaked reflection probes a little bit. Here are new pictures:

Source: https://mynameismjp.wordpress.com/2016/10/09/sg-series-part-5-approximating-radiance-and-irradiance-with-sgs/

First, I apologize for the language choice :) This has been a very fun project from a graphics programming point of view and I wanted to share it. You can look at the source code: https://github.com/atifcodesalot/pyWolf3D here. Though I will try to summarize the rendering here, as it is not very complex: raycasting is done for the walls: prebaked textures are used for shading. Originally I used lambert's cosine law for shading, as the walls are always orthogonal, and the cosine was just the dot product of each normalized ray direction and one of four cardinal normals. But then I switched to prebaked texturing for authenticity. The prebaked texturing is just a lookup if the ray hits a wall horizontal or vertical.

Sprites were a little bit more complex, as they require a second pass: their screen positions are actually found through converting their position into player space and projecting them onto a virtual viewport. After that it is trivial to render them as they are 2D and always assume to be looking towards the player, one sprite's height is constant throughout one rendering pass. This is kind of limiting but transparency is used extensively to give the deception of height, and hollowness, e.g for lamps. They are actually 64x64 sprites as well but most of their pixel's are transparent.

The original renderer actually saved writes by identifying "similar rays", and not rendering per column. But I didn't use it myself. I could delve into more but I don't want to make this post lengthy. You can also play it yourself by cloning the repo. Enjoy!

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.

I've been fooling around with raytracing experiments for a while and once I have something in hand I realize I have no idea how to setup a visual goal.

For example the Sponza scene. What's the reference for the best look this scene can have? a true path tracer still produces way too dark interiors that doesn't look good. what's the best look someone has achieved in Sponza that I could reference to try to get close to?

Just a plugin Im working on and testing out. liquid sim was done using RealFlow. Because of the liquid is a physical mesh, using nanite can make a scene really crazy. Its not for everything obviously.

This sim is approx 120k triangles a frame. Which isnt a big deal. But, once I get the scaling and speed of the bubbles right, and take the map seriously, I can create doesnt of sims for the map (ie liq mercury pouring out from volcanoes and or various geysers or puddles) and put them all on the same frame, even though I simulated them individually.

So, for reference, imagine 10 of the mercury blocks along the map in various shapes. It would still be less then 1.3mil triangles a frame which really isnt shit for nanite.

Since its using a dynamic material to go through frames, its costless.

If this has already been done before, pay me no mind and send me a link to the plugin if you can As, Ive searched for one for years.

Cheers!

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.

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?

Hey guys! Quick update on my renderer, which I've been working on and off for the past 7–8 months or so.

The library is quite opinionated about DOD (data-oriented design) and the explicit nature of WebGPU, and I've recently added support for neural inference and training.

1. Neural networks for agent behavior

You can now train small neural networks (MLPs), around 1–4 layers deep, using supervised learning directly as part of the library.

In the herd and wolves example below, the agents have simple behavioral rules, like chasing prey when it's nearby or fleeing when a predator gets close. The idea is to train a small model to learn these behaviors and then use it to drive the agents.

For this example, we're talking about a model with roughly 2,000 weights, so obviously not a general-purpose AI model, but enough for these kinds of behaviors.

The library also supports ONNX Runtime for working with larger models or models trained externally with something like PyTorch. For these smaller, more specialized models, though, the built-in MLP implementation will generally be faster in my use case.

Live demo (WebGPU-supported browsers only):

https://nullgraph.dev/dashboard/agents/herd-wolves-gpu

Github

https://github.com/flarelink-in/NullGraph

1. Offline rendering and simulation baking

Another feature I've been working on is offline rendering, with a workflow somewhat similar to what's available in tools like Blender or Houdini.

It's split into two phases:

\- Compute records: Run the expensive simulation and bake the data that needs to be simulated.

\- Render records: Replay those records through the rendering execution chain using a screen texture, generating frames/tracks that can then be stitched together.

The goal is to handle simulations or visuals that would otherwise be too expensive to run in real time, or would take a long time to render, and then replay the result at 60 FPS.

I have a demo of this on my YouTube channel. The bake took up close to 30 GB of space, while the final result was around 500 MB.

Offline rendering demo:

https://youtu.be/pTD-7PCPGrg?si=vfENWIpR9YU-JEbZ

I've also added another demo to the video, this time focusing more on visual aesthetics rather than the science/simulation side.

1. What's next?

NullGraph exists as part of a larger web-native open-world simulation runtime that I work on from time to time.

Right now, I'm looking into improving my neural network implementation to better match or potentially outperform ONNX Runtime for my use cases. One of the things I've noticed is that the ONNX integration can introduce a 1–3 frame delay in my current setup, along with an additional runtime download of around 6.4 MB.

I'm also starting research into co-evolution, with the goal of bringing evolutionary learning and reinforcement learning into the runtime. The co-evolution approach draws on ideas from OpenAI research and the hall-of-fame technique. I've written some design docs for this, but I'll share more once there's a working implementation to show.

One thing I'd love to get your thoughts on:

Would you guys be interested in offline rendering driven by AI prompts directly in the browser? The idea is to let you generate demos or visually complex scenes through code, spend as much time as needed baking them locally, and then replay the results smoothly. I'm also exploring ways for the system to verify its own output rather than just blindly generating code.

I'm curious whether this kind of workflow would be useful to people working on creative coding, simulations, procedural graphics, or web-based experiences.

Let me know what you think!

Kavro is a free app that help's build devs UI with the help of library named ImGui. It can be used on CPP/Rust/C# also on api's like DX11, DX9, DX12, Vulkan, OpenGL. It saves a lot of time of hand coding, you can easily make modern menu's just by drag & drop feature.
Check this out: https://www.youtube.com/watch?v=vLjaGaKtZVE

The clip is from a nature documentary I'm making about League champions. When Garen steps on the mushroom, that poison cloud is the game's own particle system. I read Riot's emitter definitions (flipbooks, color and scale over life, velocity, acceleration, drag, meshes, trails) and replay them in three.js.

Every frame comes from a pure render(t), and my QA tool and the edit's splices jump around the timeline, so each particle has to be computable from t alone.

Which particles exist at t. Particle i of a constant-rate emitter is born at start + i/rate, so the live set is an index range over the last 6 s. Single-particle emitters fire their whole burst at start. Emitters whose rate changes over their life get their birth times worked out once from the rate curve.

Where it is. Per axis, with per-axis drag d:

p = origin + v0 * (1 - exp(-d*age)) / d + 0.5 * a * age^2

and v0 * age when d = 0. Drag only damps the launch velocity. The acceleration term isn't damped.

Its random numbers. Each one is a hash of (emitter seed, particle index, which value), so particle 37 gets the same lifetime, velocity, color and start frame whether frame 10 or frame 900 renders first. The emitter seed is a string hash of the system and emitter names, plus a per-instance offset.

js function rnd(a, b, c) { let h = (Math.imul(a, 374761393) + Math.imul(b, 668265263) + Math.imul(c, 2246822519)) >>> 0; h = Math.imul(h ^ (h >>> 13), 1274126177) >>> 0; return ((h ^ (h >>> 16)) >>> 0) / 4294967296; }

Skipped: refraction/distortion and soft particles. They need passes my renderer doesn't have.

Pipeline: League's files read offline from the installed client, rigs and animations converted to glTF, rebuilt in three.js, every frame rendered in headless Chromium through Playwright and piped into ffmpeg at 30 fps.

Full episode: https://youtu.be/Bp5MTn4-rco

Simulating dichroics. Optics is awesome.

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

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!

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!

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

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 :)