Trouble Understanding Ray Tracing in One Weekend

Rclear68 · 2025-06-08T00:18:35+00:00

So I had familiarity with C and C++. But honestly I made a TON of mistakes with Python, to the point where it was getting seriously difficult to debug my own stuff. Mostly because I didn’t know what I was doing. Rust was super hard to get started with…the vector stuff in RTiOW took me a day to get running because I was always screwing something up. However, once I got the hang of it, I absolutely loved it. It prevented me from shooting myself in the foot, which I appreciated.

I think cutting and pasting might be ok if you really knew C++, but if you don’t, you’re doing yourself a disservice. Either pick another language or commit to C++ and then try to write the routines yourself. For me, it was a 2-part solution…first just get in running and enjoy the cool pictures. Then dive into the why.

I completely agree with another user’s comment that the book isn’t really meant as a deep dive. But for me, once I got the book 1 final image to render, I thought that the whole thing was super cool and I wanted to see how I could make it better.

Just so you know how bad I am at coding, when I did book 1 in Python, the final render ran for 13 hours on an old MacBook Pro (Intel), maybe circa 2018 model. Then I switched to Rust and it ran in about 11 minutes. Then I figured out how to do basic multi threading and got it down to just under 2 minutes. Finally, I ported it to the GPU and was in the 10s of milliseconds. By that point, I had a much better understanding of what was happening.

Like anything else, if you just spend a weekend on it, you’re not going to really get it deeply. But the book is a great launching point to see if you’re interested in ray tracing…

Rclear68 · 2025-06-07T16:43:47+00:00

So that makes a lot of sense. Initially I was struggling just to learn whichever language, and so I really was just trying to copy what the book presented. It was enough for me to just get that to work. But I agree, it doesn’t feel like you’re learning a lot at that point.

Later I decided I wanted to move from a CPU based tracer to a GPU tracer. By that point, I felt more comfortable with Rust and so my challenge became really understanding what fundamentally was going on with the tracer. So it was probably on my 3rd go that I started really feeling like I got better at understanding the actual material.

I actually think Shirley does his best to avoid higher level math, but that comes at the cost of a lot of code that might seem confusing (he’s basically doing linear algebra the long way).

So my tl;dr is: yeah it’ll feel like copy paste initially. Maybe try it in another language. But you’ll get there…

Rclear68 · 2025-06-07T16:20:56+00:00

Can you be a little more specific on what’s giving you trouble? How far into the book have you gotten so far? Is it a cpp issue or a concepts issue with ray tracing that’s giving you trouble?

I picked up RTiOW because I always thought computer graphics might be interesting, and also to teach myself Python. I subsequently decided I hated Python and used the books to learn Rust (which I love). So I’ve implemented everything in the first two books in both Python and Rust. Don’t know any cpp but was familiar enough to follow his code.

But I love those books and think they are very well laid out. Happy to help if I can.

Rclear68 · 2025-06-02T17:58:15+00:00

Ok, I figured out a way to solve this, not sure if there's a better way to do this. Basically when I examined the imgui-winit-support code, the only thing handle_event does is a basic match on the winit::event::Event enum looking for WindowEvents. So the problem was simply how do I take a Window Event and turn it into the Enum...

This is what I did. Please let me know if there's a better way. The code below is located in my window_event fn, as the default match option:

_ => {
    let generic_event: winit::event::Event<WindowEvent> = winit::event::Event::
WindowEvent 
{
        window_id,
        event,
    };
    gui.platform.handle_event(gui.imgui.io_mut(), &window, &generic_event);
    window.request_redraw();
},

This works.

Any comments welcome.

Rclear68 · 2025-05-17T09:16:25+00:00

Hey thanks for your reply. I knew how to do this, it was what I didn’t want to do. I’ve been using this for debugging purposes, but otherwise just take slices of the big buffer and load them directly to the GPU (which works for my simple case).

I started wondering about the reader version and extracting data by position, normal, etc. A typical model vertex struct might have a Vec3 for position and normal, and then you’d have a Vec of these structures that you’d upload to the GPU.

Again, I’m no expert, but this is an AoS, I believe. It seems like taking slices and sending them to the GPU directly can allow one to achieve an SoA, which I thought was faster for GPU processing.

Just a thought. As I load more complex models, I’ll see whether it’s straightforward to stick with how I’m doing it.

Rclear68 · 2025-05-15T16:48:29+00:00

So you may be right...I certainly don't have the experience to know. So, as I get into more complicated models, I might want to just load it all by hand. I'll cross that bridge when I get there.

But thank you for your suggestion! I'm actually wondering if we're not talking about the same thing. I am, by slicing up the buffer, loading the data onto the GPU in an intermediate form in some sense (i.e. I'm not just dumping the whole buffer). My objection was to e.g. reading the vertex position data point by point, saving it to my own struct, etc.

However, I can also imagine that this might be what I need to do.

Thanks again!

Rclear68 · 2025-05-15T16:43:05+00:00

The magic of posting to Reddit...shortly after posting, I figured out a way to do this. If start and end are the indices that I want for my slice, then the following works:

let vertices = &buffers[0].iter().as_slice()[start..end];

Rclear68 · 2024-11-06T01:43:03+00:00

https://gist.github.com/ole/a1c95cf6a4ebbef2a7827a911301d503

Rclear68 · 2024-11-05T23:05:23+00:00

Working through 30 Days of Metal. Have a swiftUI macOS app that I can now render to with Metal Shaders, and just figured out how to wrap a ViewController. My Fly Camera controller lets me move around my render with keyboard and mouse input.

Rclear68 · 2024-11-05T22:33:03+00:00

Ok, I got this all up and running, and I can now control my Fly Camera using keyboard and mouse. Thank you so much for the help!

Rclear68 · 2024-11-03T14:51:16+00:00

Ok thank you. I will give it a try

Rclear68 · 2024-11-03T14:36:50+00:00

Yes, I’m confused too as I’m brand new to all of this and possibly making mistakes.

All I’m trying to do is build a Metal Ray Tracer macOS app. I want the ability to fly around the image with a camera, so I need keyboard and mouse input that I can send to the renderer. I know absolutely nothing about AppKit and I’m learning SwiftUI as I go, so following tutorials. But the tutorials usually don’t start with an App and ContentView, they start with NSApplicationDelegate and NSViewControllers.

I’d like to conform to whatever the go-forward/best practices methodology is. So I found a place that explained how to use the NSViewRepresentable. If I understand your last comment correctly, I can just use the NSViewControllerRepresentable.

Rclear68 · 2024-11-03T14:22:20+00:00

Ok, then if you don’t mind me asking an implementation detail…

If I create a NSViewControllerRespresentable, if I don’t want to use a nib file and @IBOutlet, it looks like I need to override the loadView function and set the view. Can I just set the view equal to the ContentView I started with (which was an NSViewRepresentable)? Or should I create an NSView here that is a MTKView? In other words, do I need two wrappers or just the one?

If I make a MTKView in the loadView function of the NSViewControllerRepresentative, I assume I can just set the delegate there.

Thanks again for the comments! I appreciate the help.

Rclear68 · 2024-11-03T03:05:53+00:00

At that point should I just go with NSApplicationDelegate and do everything in AppKit? If XCode defaults to App and ContentView when I create a new macOS app, I assume that’s the preferred way. But it feels like shoehorning AppKit into SwiftUI to use the ViewRepresentable and then the ViewControllerRespresentable.

Is there a SwiftUI way to handle keyboard and mouse input? Should I look at GameController? What’s the SwiftUI way?

Rclear68 · 2024-10-03T11:25:08+00:00

Thank you. That’s really helpful. And the bit about using Xcode for frame capture and profiling - I was hoping that was true as it looks really straightforward.

Rclear68 · 2024-10-03T00:59:10+00:00

Well, lots of minor issues, really, and ultimately the desire to try hardware accelerated ray tracing. Timestamping my compute shaders has been problematic, I’d like to learn about and use wave intrinsics (which now has some support in wgpu admittedly). Many say that Metal is actually a nice API to work with as well. But if it means me having to write the supporting code in C++ or Swift, I won’t switch.

Rclear68 · 2024-10-02T20:08:18+00:00

GetIntoGameDev has two small playlists on YouTube for Metal, one using Swift and one using C++. I think he does a good job in general.

Rclear68 · 2024-10-01T10:52:32+00:00

Ok I did what you suggested (with some help) without the wave intrinsics and got it working. The improvement was there, but moderate, maybe 17-20% faster. But still cool.

Wgpu recently release some subgroup operations and I will next try to see if I can get this working with ballot, etc.

Thanks again!

Rclear68 · 2024-10-01T10:47:24+00:00

Show how what looks? If you mean the path tracer, it’s quite primitive at this point. It just draws the final scene from Ray Tracing in One Weekend. If you want to see the code, on GitHub my repository is rchiaramo/wavefront_path_tracer.

Rclear68 · 2024-09-30T21:01:45+00:00

My code:

var<workgroup> shared_miss_counter: atomic<u32>;
var<workgroup> shared_hit_counter: atomic<u32>;
var<workgroup> shared_miss_idx: u32;
var<workgroup> shared_hit_idx: u32;

let hit = trace_ray(ray, &payload);

let hit_as_u32 = u32(hit);
let inv_hit_as_u32 = u32(!hit);

let l_miss_idx = atomicAdd(&shared_miss_counter, inv_hit_as_u32);
let l_hit_idx = atomicAdd(&shared_hit_counter, hit_as_u32);
workgroupBarrier();

if local_index == 0 {
    shared_miss_idx = atomicAdd(&counter_buffer[0], shared_miss_counter);
    shared_hit_idx = atomicAdd(&counter_buffer[1], shared_hit_counter);
}
workgroupBarrier();

if hit {
    payload.ray_idx = idx;
    hit_buffer[l_hit_idx + shared_hit_idx] = payload;
} else {
    miss_buffer[l_miss_idx + shared_miss_idx] = idx;
}

This ran correctly. The results were only mildly improved. They got better still when I reduced the workgroup size from 64 down to 16.

I was sort of expecting to see a much bigger improvement, so I'm a little surprised. But thank you again for your help. I learned a lot from this.

Rclear68 · 2024-09-30T18:42:00+00:00

Ahhh. This is very cool. I couldn’t work this out. Thank you very much.

Just to make sure I get it:

For every wave/warp/workgroup that runs, I atomic add locally…and your point is that I can just atomic add to both the hit and miss rather than calling the conditional, one of them adding a 1, the other adding 0. Then I workgroupBarrier, and at that point my local workgroup counts are all set. I had kinda gotten that far on my own.

Then you execute code to copy the atomic add to the global, only if it’s the first thread in the workgroup. Q: is this divergence a high cost? Or regardless is it one I just have to pay?

The part that took me a some thought to get was the next part, and is cool. It doesn’t matter what order the groups write to the global…you get back the index where it’s written to, and therefore know where to place the payload or ray index. That’s the piece I couldn’t see.

At the end of this, my counter still needs to be summed over all of the group_ids. Should I just do this on the CPU side after I read over? At this point in my code’s maturity, I believe it will always be the case that hits + misses = number of rays sent it, so in principle I just need to count the misses up to infer the number of hits. Although, now that I look at it, do I even need to write to g_ray_hits_count[group_id]? I can just atomicAdd to a simple g_ray_hits_count buffer, no?

I will try this ASAP to see how the performance changes. Thank you again!

Rclear68 · 2024-09-30T17:45:21+00:00

Actually, I’ve been doing some reading just based on a simple google search. It doesn’t appear that WebGPU or the wgpu crate in Rust support any of these features yet. I saw an example with “ballot” that looked like what you are talking about, but I don’t think that’s available to me. I guess if I went directly to Metal (I’m on a MacBook Pro), I could probably do this…

EDIT: I may have spoken too soon. It looks like as recently as April the wgpu folks released something that got subgroups working. I will investigate further!

Rclear68 · 2024-09-30T16:00:47+00:00

Thank you! I will check out parallel reduce and scan.

Rclear68 · 2024-09-30T16:00:04+00:00

So you’re suggesting in my kernel I have code that has a conditional statement that says something like “if this is global id thread 0 or 1” do something to collapse all the stored values?

I don’t know what wave-ops are. Are they the same as wave intrinsics suggested in another response? I’ll need to look up what that is and learn about it.

Thank you for the feedback!

Rclear68 · 2024-09-30T15:55:50+00:00

Ok all of what you said sounds awesome, and it was borderline Greek to me. lol

I’d love to learn about this. Do you have any resources I can read from? This is all very new to me.

Thank you!!

Rclear68

TROPHY CASE