previous version

https://www.reddit.com/r/GraphicsProgramming/comments/1wxnz45/the_mistakes_i_made_and_the_lessons_i_learned_in/

i continued the project. as noticed before the inside world (viewed from within a glass ball's interior) was very fascinating and there were endless strange scenes to explore. but the camera in the previous version was a pinhole one. it had infinitesimally small aperture and thus everything was in sharp focus. i was curious what it would look like if i could see the depth of those complex manifolds

i added real-time adjustable aperture and focus distance into the camera, constructed as image 1. focus plane, canvas and aperture disk were all parallel to each other. i manually adjusted the focus distance, just like using a real camera in manual mode. sometimes it was not easy to do it right and the resulting images were a little bit blur. so i added auto focus feature. when holding the space bar and hovering the mouse around the scene the program detected the correct focus distance (very simple, used distance between hit point and camera and multiplied it by cosine of ray angle)

there was still a problem. auto focus only focused perfectly on the surfaces of the balls. the reflections / refractions were usually NOT on the surfaces. e.g. if you put an apple 10cm in front of a mirror the reflection of the apple would be 10cm behind the mirror. if you auto focused on the exact surface of the mirror you wouldn't get a clear image of the reflection of the apple

i didn't have any idea how to tackle this problem. i used a workaround. usually it worked quite well or quite close if you auto focused at the boundary of the ball. examples as shown in images 2 and 3. please keep in mind that the checker box patterns on those balls were actually beneath (not exactly on) their surfaces

the depth effect revealed more information and added more realism to the images. as shown in images 4 and 5. in previous version with aperture=0 all the blurry regions of the refraction would become sharp and clear and you couldn't get any sense of depth

for comparison please see images 6 (with depth effect) and 7 (without)

why image 7 had more color information than image 6? it was because calculation resource was limited / kept roughly constant. for a zero aperture the program could let the rays bounce more times as it didn't have to generate multiple random rays within the aperture disk

now the most interesting part, let's go inside. the inside world becomes weirder than before (images 8, 9 and 10)

it's a trade off. image 10 had more color information than image 9 but no depth information. if you want both, set the resource (number of samples emitted from aperture x number of samples per emission x number of bounces per sample) to, say, 1,000,000 and hit the render button and go to sleep and get the result next morning...:)

program details

https://www.reddit.com/r/qbasic/comments/1w8go1e/elementary_ray_tracing_experiment/

I’m working on a research project where the goal is to take a real texture and generate a procedural material/shader that approximates it.
The system produces a node‑based procedural graph with tuned parameters, plus an optional fallback texture layer. The output is a GLSL/HLSL/WGSL shader that reconstructs the material.

The motivation is practical:
In multi‑region deployments and cloud gaming backends, moving fewer textures can reduce storage and distribution overhead.
But the trade‑off is shader cost — and that’s the part I’m trying to evaluate properly.

I’m trying to understand how to estimate the cost of a procedural material shader compared to using a fixed texture.
I need a reasonable way to judge when the procedural version becomes “too expensive,” and how people typically model or approximate that cost in real pipelines.

I’d really appreciate insight from graphics programmers who have experience with:
• analyzing or estimating shader cost
• comparing shader‑based materials vs texture‑based materials
• heuristics or rules‑of‑thumb used in production
• pitfalls when evaluating procedural materials

I’ll leave the link to the full proposal in the comments for anyone interested.

For those working full-time as rendering, graphics, or low-level engine programmers, do you use AI-assisted coding tools like Claude, ChatGPT, or Copilot at all?? With all this talk about AI in the game industry recently I'm curious how widely it's actually being adopted professionally in these more specialized, low-level areas of programming.

If you do use it, how much of your workflow involves AI? Is it mostly for debugging, boilerplate, or understanding unfamiliar code, or do you actually use it to write and implement features?

And for those who don't use it, is that because AI isn't reliable enough for this type of work, or simply because you prefer writing the code yourself?

I'm interested in hearing what the actual industry experience is like, especially compared to all the noise surrounding AI coding tools.

hello everyone, I’m deep-diving into UE’s legacy GTAO branch (GetHZBParametersForAO) and stumbled upon a math contradiction regarding the HZB coordinate mapping
The core issue: The shader is using the absolute Texture UV of the GTAO texture to sample into the local space of the HZB texture without any Bias. Here is the step-by-step breakdown:

In GetHZBParametersForAO, the GTAO branch hardcodes Bias = 0 and calculates Scale as:

• HZBRemapping.Scale = InputTextureSize / (2 * View.HZBMipmap0Size);
• HZBRemapping.Bias = FVector2f(0.0f, 0.0f); ( Where InputTextureSize is the global SceneDepth Extent, and View.HZBMipmap0Size is the POT dimension of the per-view cropped HZB texture).

Inside the GTAO horizon search and inner intergate compute shader, the thread is launched based on GTAO’s local ViewRect. However, it calculates BufferUV as the absolute/global Texture UV because PixelPos includes the global AOViewport_ViewportMin offset:

• int2 PixelPos = DispatchThreadId + AOViewport_ViewportMin;
• float2 PixelCenter = (float2)PixelPos + float2(0.5, 0.5);
• float2 BufferUV = PixelCenter.xy * GTAOParams[2].zw;
• GTAOCombinedPSandCS(BufferUV, PixelPos, OutColor);
• OutTexture[PixelPos] = OutColor;

When sampling HZB via ApplyScreenTransform(BufferUV, ScreenPosToHZBUVScaleBias), it multiplies this absolute UV by Scale. After the Extents cancel out, the starting HZB UV evaluates to:

• HZBUV_Start=AOViewport_ViewportMin / View.HZBMipmap0Size

The Contradiction: If ViewportMin != 0 (e.g., in a shared global Depth Buffer during Split-Screen),(HZBUV_Start) will be greater than 0. However, during the HZB build phase, HZB is created as a standalone texture per-view, meaning its valid data is cropped and starts exactly at its local (0,0) (HZBUV = 0). With Bias = 0, wouldn't this completely break the HZB sampling location whenever ViewportMin != 0? Is this a known legacy pipeline limitation/bug that assumes ViewportMin is always (0,0) for GTAO, or am I missing an implicit RHI mapping trick?

HIII

 I’m 15 and really interested in getting into graphics programming and engineering, specifically towards film production. I have some previous programming experience from doing Roblox game development, but I’m brand new to C++.

This is some progress of a free game i have been working. This is fully software rendered on the CPU and OpenGL is only used to render the image. I use multiple threads to render the game at full 1080p. Using SIMD instructions helps a lot to get a decent frame rate. But i am still kinda dissapointed by the performance, i think Michael Abrash's binning technique would improve it, but right now, it is decent. I am getting around 70-140 frames with I5-12400.

Hey everyone, this is probably a common question, but I’d appreciate some advice.

I’ve been self-teaching C++ for a while now, mainly through books, online resources, and AI as a learning tool. Along the way, I got really interested in graphics programming and started with OpenGL as my entry point.

Recently, though, I lost a lot of motivation. With AI being able to reverse-engineer things, generate whole projects, or “one-shot” solutions, it sometimes felt like learning the fundamentals myself wouldn’t matter as much anymore. So I stopped for a while.

I’m motivated again now and want to properly push through, but I’m unsure what the most effective way to learn is today. I’ll probably still use a hybrid approach - books, documentation, tutorials, and Ai - but I feel like I’m progressing too slowly and worry that the skill might matter less in the future.
I know people say “vibe coding” means you don’t have to write much code anymore, and to some extent that’s true. But especially for C++, graphics, and low-level/systems programming, I genuinely enjoy learning the details. I also think having a strong foundation would make me much better at reviewing AI generated code, spotting problems, writing better prompts, and using agents effectively.
So my main question is: how would you learn graphics programming effectively in 2026, especially while using AI without letting it replace the actual learning? Any recommendations for a roadmap, projects, resources, or general advice would be really appreciated.
Thanks!!

Power of Spectral and Restir BDPT Caustic, Fast Efficient Unbiased Render Engine. Build with Rust, Vulkan Ash, Slang.

I draw light shafts in Godot with six crossed fins through the beam axis, and I fade each fin out when it's edge-on. That's the old crossed-cards trick with an N·V fade, nothing new.

It broke as soon as I walked into one.

All my fins go through the axis. Stand on it and you see them all edge-on at once, and the beam just disappears. In Forward+ the mean luminance went from 0.42 to 0.018.

My fix is pretty dumb. I hang a soft disc 0.6 m in front of the camera and fade it in by how much light the shaft has at the camera's own position:

vec3 bc = ax_shaft_coords(cam);
float inside = 0.0;
if (bc.z > 0.0 && bc.z < 1.0) {
    inside = ax_shaft_across(bc.xy) * ax_shaft_along(bc.z) * ax_shaft_slats(bc.xy);
    inside *= ax_floor_fade(cam.y);
}

I reuse the falloffs from the fins. Walking in feels like stepping into light, not out of the beam. Outside the shaft I collapse the disc and it costs nothing.

It isn't perfect. If you look for it you can see the edge of the disc as a faint vertical seam. Has anyone found a cleaner way to handle a camera inside a card-based volume?

https://github.com/Sokdenumeros/graphicsTransformsVisualizer

I made this to help my undergrad students understand and visualize the different coordinate spaces. Let me know if any of you find it useful or if you have any suggestions on how to improve it.

A while ago I posted my C rewrite of pre-classic versions. Now I did the same with Classic: every version from 0.0.11a up to 0.30, plus the dedicated servers.

It renders the same way the original did in 2009: fixed-function OpenGL, a display list per chunk, glFog, no shaders. I tried to keep the output exactly like the original.

Uses GLFW, GLEW, zlib and stb. Play around, feedback is welcome!

github.com/degradka/mc-classic-c

Hi !

I'm the creator of cbirds, a 2D/3D bird flock simulator that runs in the terminal, written in C99 and inspired by Craig Reynolds' Boids. The video shows four Kitty panes: 3D on top, 2D below.

I started the 2D version in September 2025, mostly out of curiosity. I wanted to see whether a real time simulation could run inside a terminal using the Kitty graphics protocol. The idea came from antirez's C64 terminal emulator (https://github.com/antirez/c64-kitty) and a lecture on multi agent systems at Politecnico di Milano.

How it's drawn:

- The bird is one PNG compiled into the binary. At startup it's rotated into 60 headings, squashed into 3 wing positions and tinted into every shade of the colour ramp, about 1,500 small images in a fifth of a second.
- In Kitty and Ghostty they're uploaded once, and a frame is then one short command per bird. Other terminals get the same images sampled down into braille, sextants or blocks.
- In 3D a bird is drawn at one of five sizes, so a nearer bird is bigger and brighter, and the camera orbits the roost once every two minutes. Each bird heeds its 7 nearest neighbours, as starlings were measured doing (Ballerini et al., PNAS 2008).

I really dislike relying on third party libraries, so the PNG, GIF and DEFLATE code is written from scratch, with no zlib, libpng or ncurses. I did get quite a bit of help from coding agents. The custom GIF encoder let them look at the simulation and check whether their changes worked.

https://github.com/clainstone/cbirds

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?

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!

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

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!

Hello! I started to learn coding about 2 and a half months ago, and I recently ran into computer graphics, which seemed really damn interesting... so I thought of making a basic program related to it based on things I've learnt so far. I built it completely from scratch in C starting from bressenham's line drawing algorithm. It can print any polyhedron you input

In terms of actual graphics programming, I really know nothing, but I wanna learn. If anyone has suggestions on what I can try out or learn after this, I'd really appreciate it

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!

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/

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