I've been playing with a minecraft style voxel renderer. Current demo has about 11 different techniques to render large worlds as fast as possible.

Demo also has TAA, distance and height fog, shadow maps for directional and ambient cube with per voxel baked AO for ambient, tonemapping and sharpening.

Data is the kings landing model duplicated 100X to make the world bigger. I would ideally like a much larger mesh but memory usage is already quite high so it'll need to be optimize and potentially streamed in on demand. Screenshot is at about 7ms @ 1440p on a 5070 Laptop. Being in the corner so all 100 worlds can be scene is about 15ms. Still a huge amount of various optimizations to be done.

• The anamorphic bloom based on tent kernel filters was shared before.
• Now added support for color fringing, anamorphic streaks, tinting, etc.
• Its a shader written for ReShadeFX.

https://github.com/umar-afzaal/LumeniteFX
https://discord.gg/deXJrW2dx6

There is a self shadow artifact, the black rectangle on the side of the wall. Weirdly this is also dependent on zoom level.

What do you think is causing this issue?

The implementation follows from the 2024 paper “Visual simulation of opal using bond percolation through the weighted Voronoi diagram and the Ewald construction” by Soma Yokota and Issei Fujishiro.

I open-sourced it here: https://github.com/a-sumo/opal-pathtracer

I also wrote an article on opals an more broadly photonic crystals: https://armandsumo.com/posts/opals/

The Problem / Questions:

Orbiting the camera translates cameraPos and zooms change the frustum splits, shifting the stable bounding spheres and triggering texel-snapping updates. However, the resulting edge shimmering is severe.

1. Reconstruction Precision: Reconstructing worldPos in the fragment shader via u_InvViewProj * ndc is highly sensitive to single-precision float accuracy under view-matrix updates. Should we reconstruct view-space position first via u_InvProj and then analytically reconstruct world-space position?
2. Texel Snapping Math: Does offsetting the projection matrix (proj.columns[3].x += ...) introduce floating-point drift/mismatch when used with Metal's coordinate system (Z∈[0,1])?
3. Cascade Fluttering: Cascade selection uses viewDepth = abs((u_View * vec4(worldPos, 1.0)).z). Since worldPos is reconstructed, does this float round-trip cause cascade indices to flutter back and forth at boundaries?

1. CPU-Side: Bounding Spheres & Texel Snapping

To make cascade sizes rotation-invariant, bounding spheres are centered at the camera position:

cpp// Center is camera position, radius is constant based on split distances
const Vec3 center = cameraPos;
float radius = farDist * fovAspectFactor + 2.0f; // 2.0f PCF padding
StableCascadeData cascadeData = MakeStableCascadeViewProj(*shadowLight, center, radius, CASCADE_MAP_SIZE);

Grid snapping shifts projection boundaries to world-space texel alignment using std::floor:

cpp// Project world origin (0, 0, 0) into light space
Mat4x4 viewProj = proj * view;
Vec4 shadowOrigin = viewProj * Vec4(0.0f, 0.0f, 0.0f, 1.0f);
shadowOrigin.x /= shadowOrigin.w;
shadowOrigin.y /= shadowOrigin.w;
const f32 halfMapSize = (f32)mapSize * 0.5f;
const f32 originX = shadowOrigin.x * halfMapSize;
const f32 originY = shadowOrigin.y * halfMapSize;
// Offset the projection translation column
proj.columns[3].x += (std::floor(originX) - originX) / halfMapSize;
proj.columns[3].y += (std::floor(originY) - originY) / halfMapSize;

2. GPU-Side: Reconstruction & Sampling

We use nearest filtering for reading G-Buffer depth to prevent edge interpolation jitter, reconstructing world position via u_InvViewProj:

glslvec3 ReconstructWorldPos(vec2 uv, float depth) {
    vec2 screenUV = vec2(uv.x, 1.0 - uv.y); // Metal UV flip
    vec4 ndc = vec4(screenUV * 2.0 - 1.0, depth * 2.0 - 1.0, 1.0);
    vec4 world = u_InvViewProj * ndc;
    return world.xyz / world.w;
}

In the sampling step, we apply world-space normal bias scaled by texel size, and evaluate shadows using a 9-tap bilateral PCF gather (5x5 footprint):

glslfloat SampleCascade(sampler2D shadowMap, mat4 cascadeVP, int cascadeIndex, vec3 worldPos, vec3 N, float NdotL) {
    float texelSize = max(u_CascadeTexelSize[cascadeIndex], 1e-5);
    float depthRange = max(u_CascadeDepthRange[cascadeIndex], 1e-3);
    // Apply normal bias in world units
    vec3 shadowPos = worldPos + N * (u_ShadowParams.y * 30.0 * texelSize);
    vec4 lightClip = cascadeVP * vec4(shadowPos, 1.0);
    vec3 projected = lightClip.xyz / lightClip.w;
    vec2 shadowUV  = vec2(projected.x * 0.5 + 0.5, 1.0 - (projected.y * 0.5 + 0.5));
    float currentDepth = projected.z * 0.5 + 0.5;
    // Slope-scaled depth bias
    float slopeScale = sqrt(max(1.0 - NdotL * NdotL, 0.0)) / max(NdotL, 0.05);
    float bias = u_ShadowParams.z * (texelSize / depthRange) * (1.0 + 1.75 * clamp(slopeScale, 0.0, 4.0));
    // PCF grid sampling using textureGather...
    return EvaluatePCF(shadowMap, shadowUV, currentDepth, bias); 
}

Hello everyone, I've made a zero player game cellular automata simulation with C++ - Conweys game of Life.

The rule of the game is very simple:

The world is an infinite grid and A cell would be alive if it had 2-3 neighbours alive.

It can die by under and overpopulation.

That's it.

But to render and simulate I've made the world as a 100x100 grid with a torus wrap. This is a very fun way to learn and spend time.

To use this all you have to do is just open the file and run the code. By default it has an Acorn Pattern and a ready to use other two patterns.

So yeah take a look at my GitHub and give my repo a star.

GitHub: https://github.com/Radhees-Engg

I’m currently working through chapter 1 of GPU Gems 3 (link: https://developer.nvidia.com/gpugems/gpugems3/part-i-geometry/chapter-1-generating-complex-procedural-terrains-using-gpu) as a way to strengthen my understanding of the Metal API and implement some interesting stuff. For context, I’m relatively novice though not unfamiliar with the api.

The issue I’m having is that after reading the chapter, I now understand the concepts and the rough idea of how they implemented it, but I had no clue as to how to even start. I used Claude to help me translate the problem into actual metal concepts, and that helped me get started.

My question is, how do you guys generally deconstruct a problem/paper/idea into the design of a solution and eventually into implementation? Is there a framework you have built up which has helped you to speed up this process? Further, is it possible I’m biting off more than I can chew and should seek something a little more within my metal abilities? Let me know what you think.

TLDR: Would love to get some ideas on how I can improve translating ideas to code.

Added better materials to my path tracer and added multiple importance sampling.

1. Glass (varying roughness)
2. Glossy (varying roughness)
3. Diffuse (varying roughness)
4. mix(diffuse, glossy, 0.1) (glossy of varying roughness) Roughness vary from left to right (0.0, 0.5, 1.0). Glass and Glossy material uses single-scattering GGX and Diffuse uses Energy-preserving Oren-Nayar model.

Edit: 3D model is from here: https://sketchfab.com/3d-models/laughing-buddha-646f46ae29084d8696afc4efa5c81c39

Built with help from Claude. I mainly used Three.js to create a randomized 3D polygon mesh using random divisions on a square grid. Slapped a basic slope based lighting on top for better view. Source code on GitHub: https://github.com/Hegho/Terrain-Creator

Hey everyone,

I've been building Pixel Shader Academy

a browser-based, interactive GLSL learning site aimed at people who are completely new to shaders. It's free and live here: https://shader.dolstep.com

The full source is on itch.io https://bobddadoo.itch.io/pixel-shader-academy-full-source

What it actually is

A sequence of bite-sized stages where each lesson hands you a real fragment shader running in a WebGL canvas next to a code editor. You edit GLSL → it recompiles live → the result is the puzzle target. Stages walk through the usual fundamentals: UV coordinates, step/smoothstep, mix, SDFs for circles/rectangles, polar coordinates, time-based animation, simple noise, and a few small post-effects toward the end.

Implementation notes

• Frontend: Vite + vanilla JS, no framework. Each stage is a small data file (starter code, target image, hint text, success predicate).
• Rendering: a single full-screen triangle with a per-stage fragment shader. Shader compile errors are surfaced inline in the editor with the GLSL line number mapped back.
• Validation: I render the user's shader and a reference shader to offscreen framebuffers at the same resolution, then do a per-pixel diff with a tolerance threshold. Below the threshold = stage passes. It's dumb but it works surprisingly well for "did you reproduce this image" puzzles.
• Asset pipeline: all reference images are baked from the reference shaders themselves at build time, so I never have to hand-author solution PNGs.
• Mobile: the biggest pain. Float precision differences (highp vs mediump) on some Android GPUs broke a few SDF stages — I ended up forcing highp and adding small epsilons in the diff.
• I built it almost entirely by pairing with Claude (Anthropic). I designed the curriculum and made the pedagogical calls; Claude wrote most of the boilerplate and helped iterate on shader puzzles.

What I'd love feedback on

1. The per-pixel-diff validator feels naive. Anyone done something smarter for "did the student reproduce this image" without being brittle to anti-aliasing differences across GPUs?
2. Curriculum ordering — is there a fundamental I'm missing before noise/post-fx, or one I'm teaching too early?
3. Any classic GLSL "aha" exercises you'd add?
4. Anything else I should add?

Happy to answer anything about the architecture, the validator, or the Claude-assisted workflow. Roasts welcome.

Hi folks,

A few weeks ago I wrote about one of my current projects on volume rendering here.

Since then the renderer got some traction in the bioimaging community. Since then I worked on things like better support for the OME-Zarr format, local filesystem streaming (Chrome/Edge) and a few other improvements regarding performance and usability.

And today the project was accepted to the OME-NGFF tools list and is now listed on their community portal as a suggested viewer for people who work with Zarr datasets.

https://ngff.openmicroscopy.org/resources/tools/index.html#zarr-viewers

Still early days with support for v0.5, single-channel 8/16-bit unsigned int, but features such as v0.4 support, multi-channel rendering and more are already planned.

Wanted to share this here, since the renderer evolved into something that is now part of the ecosystem. Which feels great!

A big thanks to everyone who commented and provided feedback — it really helped shape this into something that is actually useful.

For reference:

Live demo: https://mpanknin.github.io/kiln-render

GitHub: https://github.com/MPanknin/kiln-render

Here is a tutorial on a Fractal Tunnel Shader Tutorial

#float speed 0.5 0.1 2.0
#float zoom  2.0 0.5 5.0
#float twist 3.0 0.0 10.0
#color color1 #ff3366
#color color2 #3366ff
#color color3 #33ff66

void main() {
    vec2 uv = v_uv * 2.0 - 1.0;
    uv.x *= u_resolution.x / u_resolution.y;

    float t = u_time * speed;
    float r = length(uv);
    float a = atan(uv.y, uv.x);

    float tunnel = 1.0 / (r + 0.1);
    float angle  = a + tunnel * twist + t;

    float pattern = 0.0;
    for (int i = 0; i < 4; i++) {
        float fi = float(i);
        float scale = zoom * (1.0 + fi * 0.5);
        float wave  = sin(tunnel * scale - t * (1.0 + fi * 0.2));
        wave       += sin(angle * (3.0 + fi) + t);
        pattern    += wave / (2.0 + fi);
    }
    pattern = pattern * 0.5 + 0.5;

    vec3 color = mix(color1, color2, sin(pattern * PI) * 0.5 + 0.5);
    color = mix(color, color3, sin(pattern * 6.28318 + t) * 0.5 + 0.5);
    color *= 1.0 - r * 0.5;

    fragColor = vec4(color, u_opacity);
}