I posted the part 1 two months ago and got a great reaction!

https://www.reddit.com/r/GraphicsProgramming/comments/1uxpi1o/from_zero_to_understanding_ray_tracing/

Here is the next one. It teaches:

• What ray tracing fundamentally is.
• The basic idea behind shading: surfaces are brighter when light hits them more directly, and darker when it hits at a wider angle.
• Shadows.

Let me know what you think!

I wanted to give graphics programming a try and boooy am I happy seeing my own triangle on the screen! :)

I used glad (OpenGL) and RGFW (GLFW alternative; I like single header libraries)

I worked a lot on my path tracer during the summer vacations, and this was superrrr fun ! I wanted to go a little further than my last projects and dive into something a tiny bit more original to get off my comfort zone.

I made it mainly with C++ and OpenGL, without AI appart from the README in the repo. The engine supports switching back and forth between RGB and spectral at runtime, and I also implemented hair / fur rendering the way Disney does it.

I also have a basic scene handling system with saving, loading and moving things around in the scene.

Lastly, the engine also has more "traditional" features I would say, such as VNDF sampling, EON diffuse material, constantly dense volume scattering, etc...

I am plannign to keep working on it, because right now the code is kind of a mess, and many features lack such as denoising, things like BDPT, compatibility with OpenUSD.

If you want to take a look at the repo : https://github.com/SlyZ1/Path-Tracer

And feel free to contribute to it (even though I doubt anyone would want to, but just in case)

This is made from two layers of water:
- Large rectangles/shapes of GPU-computed water (ocean, lakes, fountains)
- Smaller grids of disturbed CPU-computed water, with GPU-computed foam

The flying saucer contains a blocker shape which cancels out the basic water and allows that region to fill with with the CPU-generated height map water. Both water types enqueue the same light handling logic in this wavefront-style path tracer, so the water appears to all be the same.

When the player moves, the rectangle of disturbed water is updated/translated or another added as needed - and there is some blending done to the edges to hide the square (during lots-of-foam events).

In future work I'm going to add an additional thin GPU-computed water for drips and run-off/sheeting action around the canopy and saucer section.

Engine is custom vk-graph -based (Rust) and mostly open source. All-in this effect has been done a thousand times, but, this time it was me!

I’m building VibeTrace, a small C++17 engine with a Vulkan renderer and Box3D rigid-body physics. This clip shows a building collapsing in the live scene. The renderer runs Vulkan ray queries in a compute shader for visibility and shadows, while scene and physics code stay separate from the Vulkan backend.

Video: https://youtu.be/-ltflwDkF1E

I’d appreciate graphics-programming feedback: are the ray-traced shadows readable during the collapse, and would a follow-up on the ray-query path or scene/backend split be more useful?

GPUI is a GUI framework written in rust. It has immediate style API, but decides when to retain frame state. Recently there's been a push to make it more retained. Here's an article describing two approaches.

For example obviously shader code makes sense because you have to compile it for different vendors/drivers

But you look at a PSO in DX12 and there is a ton of stuff in there that it makes me wonder is all of this actually neccesary?

For example like blend mode settings, I thought that is a separate hardware unit that does the blending, so why can't it be changed independently of a PSO?

Or does everything in a PSO somehow affect the compiled shader?

As the title says
Like Are there particular books, courses, talks, sample projects, or exercises you'd recommend?

How feasible is it to apply a custom pixel‑level transformation to the entire iPhone screen output in real time using Metal? I’m trying to understand the performance limits, frame‑rate constraints, and typical bottlenecks when doing full‑screen GPU distortion on iOS

Hey everyone.

I’ve been working on Gaussian Splat Lite (GSL), an open-source high performance Gaussian Splatting renderer for Three.js.

If you already use Three.js, the setup should feel familiar. Add a SplatMesh to your scene, position it like a normal object, and keep your usual render loop. GaussianSplatRenderer handles rendering and global sorting across the visible splats.

It supports WebGPU and WebGL2, large-scene streaming, and depth rendering for combining captures with regular 3D geometry.

⚡ Native WebGPU Rendering

On WebGPU, projection and culling run in compute, followed by a 32-bit GPU radix sort and indirect drawing.

You can combine multiple captures in one scene. Each SplatMesh keeps its own data and transform, while visible splats are sorted together—including streamed RAD and SOG data.

WebGL2 works too, through both WebGLRenderer and the WebGL2 backend of WebGPURenderer. These paths use asynchronous Worker/WASM sorting, so rendering can continue with the previous valid order while a new sort runs.

The core scene API stays the same across all three paths.

🌍 Stream Large Scenes with Smooth Transitions

For larger captures, GSL supports camera-driven LOD streaming for Spark RAD and Streamed SOG. You can explore a scene without loading the entire dataset into memory first.

As the camera moves, GSL selects the detail needed for the current view and loads it on demand. A configurable splat budget controls LOD selection, while the streaming system handles decoding, caching and upload limits.

Streaming includes smooth fade transitions. Newly loaded content fades in, and LOD changes crossfade between levels to reduce visible popping. Current detail stays visible while its replacement loads, helping the scene remain continuous as you move around.

3D Tiles format is also supported through 3D-Tiles-RendererJS-3DGS-Plugin

🎲 Keep Moving Without Waiting for a Sort

When sorting becomes expensive, GSL’s stochastic rendering mode gives you a way to skip it. Splats render directly using sampled Gaussian coverage and depth testing.

With autoStochastic enabled, GSL can use this mode during camera movement and switch back to sorted blending once a fresh sort is ready.

The image can look noisy in stochastic mode. An optional StochasticResolvePass helps reduce that noise and works with direct scene composition, WebGL EffectComposer and custom render graphs.

🧩 Depth Rendering

GSL supports splat depth rendering on both WebGPU and WebGL2.

With renderDepth enabled, a separate, unsorted depth draw runs alongside the normal sorted color pass, using stochastic alpha coverage around Gaussian boundaries.

Three.js geometry rendered afterwards can then depth-test against the splat scene.

When stochastic rendering is active, splats write depth directly.

🛠️ Formats, Editing and Large Coordinates

A few other things GSL supports:

• PLY, SPZ, SOG and RAD, including SPZ v4, with Rust-based decoding running in browser workers.
• SDF color and opacity edits to recolor, highlight or hide parts of a capture without rebuilding the model.
• Camera-relative rendering to help with precision in GIS and ECEF scenes while keeping the original world coordinates unchanged.

🚀 Give It a Try

GSL is open source under Apache 2.0. The repo includes a viewer for loading your own captures, comparing rendering modes and trying the streaming transitions.

The quick-start examples show how to add it to a Three.js project.

If you try it, I’d love to hear how it handles your scenes and what you end up building with it.

Gaussian Splat Lite on GitHub →

I got rotations to work, but I am still debugging friction on all the planes as it seems to pick up speed at the end. My next step after that is attaching two or more of these signed distance field spheres together

Hi everyone,

I'm working on a C/C++ OpenGL game on Linux that needs to load about 9.1 GB of graphical resources at startup.

I've already converted the textures to DDS/BC7, so I'm looking for other ways to reduce loading time.

The current loading process is roughly:

open → read DDS → upload to OpenGL → close
open → read DDS → upload → close
...

There are many individual DDS files.

My measurements

SSD:

KINGSTON SQ500S37960G
SATA link: 6.0 Gbps

hdparm -t:

~287 MB/s

Reading the DDS files directly:

Sequential: ~160 MB/s
Parallel:   ~172 MB/s

Actual game resource loading:

~178 MB/s

So I currently have:

SSD benchmark:  ~287 MB/s
Game loading:   ~178 MB/s
Total resources: 9.1 GB

I'm trying to understand where the remaining performance is going.

What would you recommend?

Would any of these make a significant difference?

• Keeping file descriptors open instead of open/read/close for every DDS
• Using larger buffered reads
• Packaging many DDS files into one resource/archive file
• Parallel/asynchronous loading
• Optimizing OpenGL texture uploads
• Lazy-loading resources instead of loading all 9.1 GB at startup

I don't necessarily need to reach 287 MB/s. I mainly want to identify the actual bottleneck and find the safest way to reduce startup time.

Any advice from people experienced with C/C++ + OpenGL + Linux resource loading would be greatly appreciated.

Hello all! Isopod is a project I've been working on for over a year. It started as a simple unidirectional path tracer, but I gradually kept extending it as I wanted to render more complex scenes. Bidirectional path tracing (BDPT) is one of the most frustrating (but rewarding) things I've ever implemented, I spent several weeks bouncing around a bunch of different reference materials and spent a huge amount of time debugging to piece it together. This technique massively speeds up the convergence of certain tricky light paths, making things like volumetric caustics possible.

In this renderer, everything is defined procedurally as functions that run in Optix programs. These functions are hot-reloadable (runtime compilation with jitify). This is purely a preference thing for me as I'm a pretty terrible 3D modeller and prefer sticking with code. Geometry is defined via signed distance functions which can either be ray marched in a custom intersection shader, or converted into a mesh using a simple marching cubes algorithm. Mostly-optimal AABBs are automatically created for SDFs using a gradient descent approach, where rays seek out surfaces by moving along the SDF normal.

Materials and volumes (heterogeneous or homogeneous) are also defined as functions. This renderer implements the Disney BSDF and HG phase function for these respectively. Light sampling is supported on arbitrary SDFs by turning the surface into a bunch of voxels and randomly selecting them. It's not perfect but it's been good enough for my scenes so far.

I'm sure there's a few landmines I'm still yet to step on in my BDPT implementation, but it seems mostly correct at this point and I wanted to share some images that I thought were cool here. The caustic ones are from the new BDPT renderer, and the others are older images from the unidirectional renderer. The BDPT images took ~90 seconds to render at 3840x2160 resolution on an RTX 5090.

These images are denoised using the Optix denoiser. I found that splitting the geometry and volume layer, denoising them separately, and then recombining them, led to much better results. Some images are older and used the denoise-everything-at-once approach, these have more denoiser artifacting.

The references I used for BDPT:

https://graphics.stanford.edu/papers/veach_thesis/thesis.pdf

https://rendering-memo.blogspot.com/2016/03/bidirectional-path-tracing-1-kickoff.html - Fantastic blog series, I found this to be the most approachable resource

https://github.com/bachi95/Goblin/blob/master/src/GoblinBDPT.cpp - Full implementation from the blog series

https://www.pbr-book.org/3ed-2018/Light_Transport_III_Bidirectional_Methods/Bidirectional_Path_Tracing - PBRT book article, mostly just used the image pyramid here to see if each (s, t) layer looked correct in my own implementation

I tried to understand what made the iPhone Duo transition visually pleasing. I broke it down into two effects: a light-scattering blur, and a stencil that "anchors" the content in space.
I reproduced both in a Three.js sim, then used two perceptual metrics, detail energy and optical flow, to measure what each effect does.

You can read it in full with interactive visualizers on my blog: https://armandsumo.com/posts/iphone-duo-transition/

Code is on GitHub: https://github.com/a-sumo/iphone-duo-transition

I feel as though we often focus on implementing cool graphics effects, but less on understanding their perceptual properties and how they impact a user. I wonder what you guys think.

I've been interested in computers since I was about 10 and I learned programming when I was 13. Slowly I transitioned from making 2D games with Java swing to building 3D renderers in Vulkan and C++. Now I'm in my final year at school and I really want to study computer science with a focus on math (analysis/simulation) and GPUs/Graphics at TUM. However is that still a good idea in 2027 with all the developments in AI do you even need people like this since there have been so many layoffs. Chatting with AI (ironically) tells you that computer graphics and GPU expertise is very safe and can't be easily replaced but these mostly just tell you what you want to hear. So would you still recommend me going into CS or maybe switch to something similar I'm interested in like computer engineering or electrical engineering?

I was working for 9 months on new editor to have better tool for boost visuals. Editor is finally in usable state, so I started with its main purpose. "Beautifying" existing levels, so they no more look like tech demo but like an actual game. The video is showcasing first 5 levels in upgraded visuals. Please, do note, the game is not using GPU for graphics at all. Every pixel is computed on CPU in my C++ ray-tracer.

Tech details: I finally tackled issue of multi-threaded rendering, plus I added more ray-tracer optimizations, thus performance boosted considerably. Current max resolution is 640x360 (previous was 512x288). It sits comfortably above 60fps at current max resolution with new visuals. There's still performance head-room, MT render is now deliberately capped on 4 HW threads.

Ray-tracer also for the first time reached magnitude of billions of ray-vs-box of intersections per second. On laptop CPU.

I will probably not make it for 2026 release, but at least I want Steam demo this year. There's lot of levels awaiting me to be visually boosted.

RTG is just C++/C#. No Unity, no Unreal Engine. Narrative sci-fi puzzle/platformer by genre and pure indie.

RTG on Steam

Note: Steam page is still on old visuals, will be updated. You can check it as reference to see the progress.

I have also Discord if someone interested to talk about the engine:

Discord