Live data from Hacker News

Show HN: I've made a Monte-Carlo raytracer for glTF scenes in WebGPU

github.com

41–43 of 43 posts

Re: Show HN: I've made a Monte-Carlo raytracer for glTF scenes in WebGPU

#41

Earlier quoted context omitted.

This is an interesting idea but please no more AI graphics generation in video games please. Games dont get optimized anymore because devs rely on AI upscaling and frame generation to get playable framerates and it makes the games look bad and play bad.

No its because hardware is not fast enough. Performance optimization is a large part of engine development. It happens at Epic as well.

No, it's because the software they write has higher requirements than computers at the time can provide. They bite off more than the hardware can chew. And they already know exactly just how much the hardware we have can chew... yet they do it anyway. You write stuff for the hardware we have NOW. "The hardware is not fast enough" is never an excuse. The hardware was there first, you write software for it. You don't write software for nonexistent hardware and then complain that the current one isn't fast enough. The hardware is fine (it always is). It's the software that's too heavy. If you don't have enough compute power to render that particular effect... then maybe don't render that particular effect and take technical considerations in your art style.

Re: Show HN: I've made a Monte-Carlo raytracer for glTF scenes in WebGPU

#42

Earlier quoted context omitted.

No its because hardware is not fast enough. Performance optimization is a large part of engine development. It happens at Epic as well.

No, it's because the software they write has higher requirements than computers at the time can provide. They bite off more than the hardware can chew. And they already know exactly just how much the hardware we have can chew... yet they do it anyway. You write stuff for the hardware we have NOW. "The hardware is not fast enough" is never an excuse. The hardware was there first, you write software for it. You don't w…

I agree thats true.

Re: Show HN: I've made a Monte-Carlo raytracer for glTF scenes in WebGPU

#43
post #5

It's a mega-kernel, so you'll get poor occupancy past the first bounce. A better strategy is to shoot, sort, and repeat, which then also allows you to squeeze in an adaptive sampler in the middle. > // No idea where negative values come from :( I don't know, but: > newRay.origin += sign(dot(newRay.direction, geometryNormal)) * geometryNormal * 1e-4; The new origin should be along the reflected ray, not along the dire…

> A better strategy is to shoot, sort, and repeat Do we have good sorting strategy whose costs are amortized yet? Meister 2020 ( https://meistdan.github.io/publications/raysorting/paper.pdf ) shows that the hard part is actually to hide the cost of the sorting. > squeeze in an adaptive sampler in the middle. Can you expand on that? How does that work? I only know of adaptive sampling in screen space where you shoot m…

After reading this paper a bit more it seems that the it focuses on simple scenes and simple materials only, which a bit unfortunate. This is exactly where ray reordering overhead is going to be the most problematic.

They also do talk about the potential of ray reordering for complex scenes and complex materials in the paper (because reordering helps with shading divergence since "all" reordered rays are pretty much going to hit the same material).

So maybe ray reordering isn't dead just yet. Probably would have to try that at some point...

Post reply on HN