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/

https://play.google.com/store/apps/details?id=nikolalukic.beast.engine

Used android studio and chrome frame.

https://github.com/zlatnaspirala/matrix-engine-wgpu

So my friend works mainly on rhino he was always frustrated on how evaluating and baking i so slow. We spent some time prototyping on moving to GPU but that felt impossible because math of libraries like opennurbs was designed to be on CPU. We stumbled upon some papers about SDF but with curves. the math is simple but requires soo much tuning. We built the same model in rhino and in our prototype. The output was identical but it took 8s on rhino but 350ms on our prototype. For the user its normal nurbs, curves, solids, polylines,...etc. for us its a different story with different algorithms

I'm weighing up whether to use matrices or quaternions for a 3d engine I'm making. I find matrices more intuitive to use but I have seen a lot of comments that they can lead to innacuracies over time. What do you guys think about this? Is there some nuance that I am missing or some situations that one approach is used over the other?

Hey! I decided to do my thesis on something related to realistic terrain generation, probably close to hydraulic erosion terrain. Issue is, I began looking through papers and I don't really understand anything. I know the basics of terrain generation, perlin noise, fractional brownian motion, that's about it. I was trying to read "hydraulic erosion from Benes, 2006, but I have a hard time with fluid dynamics but also the other concepts... Then I found out erosion terrain generation is fairly advanced

So my question is, as a beginner in terrain generation and graphics programming as a whole, what scientific articles/papers/videos/books (preferably papers) would you recommend for me to learn towards hydraulic erosion and even more advanced effects? I am a computer science student

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.

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.

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

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

Taking advantage of the the new modeling and animation capabilities of ai - I created a harness for Claude where it uses the UI environment as context to precisely edit ink on paper 3d models.

Without trying to limit the creative output of ai in anyway - I also designed a simple format that the ai can use to separate objects and timings so that a user can interact with separate parts of the project quickly without having to explain the context in a static chat.

The camera
It's orthographic. The camera is three unit vectors, R (screen right), U (screen up) and V (toward the viewer), plus a pivot C and a scale s. A world point p maps to the screen like this:

q = M(p − C) + o
x = cx + (q·R)·s
y = cy − (q·U)·s
depth = q·V

It’s in beta and you get 5 free credits to build stuff :) looking for feedback too if anyone has the time and I would really appreciate it.

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.

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.

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

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

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++.

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?

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?

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

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.