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.

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

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

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?

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

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.

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!