|
|
|
|
|
by omolobo
539 days ago
|
|
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 direction of the normal. This line basically adds the normal (with a sign) to the origin (intersection point), which seems odd. Poor's man way to find where the negatives come from is to max(0,...) stuff until you find it. |
|
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 more or less rays to certain pixels based on their estimated variance so far.