first hit optimization accuracy
Author
I currently coding OpenGL to render my scene, with "textures" that are triangle ID's for raytracing effects in my engine. My question is how accurate per pixel is this method? For example, say I render one triangle on the screen and trace a ray for a pixel that lies on the edge of that triangle. Is it likely that the ray will not even intersect the triangle? Has anyone experienced this problem or similar? Is there a better first hit optimization? Any help will be appreciated.
I don't understand what the problem is.
Just store the accurate world position/normal pair in the pixel for each pixel that you render. Then readback and do the raytracing part.
(Of course, I don't know how you're going to implement writing position/normal pair reading, that's up to you :)
Well. There might be slight differences in rasterized/raytraced view (they are different kinds of approximations to the same problem, anyway, although raytracing can handle much general problems and not just rendering "perspective views"), but I don't see why that would break up your algorithm. It won't.
-- Mikko
Just store the accurate world position/normal pair in the pixel for each pixel that you render. Then readback and do the raytracing part.
(Of course, I don't know how you're going to implement writing position/normal pair reading, that's up to you :)
Well. There might be slight differences in rasterized/raytraced view (they are different kinds of approximations to the same problem, anyway, although raytracing can handle much general problems and not just rendering "perspective views"), but I don't see why that would break up your algorithm. It won't.
-- Mikko
Author
I couldn't find the right words to say what I meant, but you hit the nail on the head - the difference between the rasterized and raytraced view. After rasterization, I would create the appropriate ray for a pixel, and assume that it intersects the triangle that was rasterized onto that pixel. Say, for example, that pixel lies onto the border of that triangle and that the intersection test fails. That pixel will then be set to "atmospheric color" (ex. sky, background image, default color, etc) causing visible artifacts. The workaround will be to test all triangles until the correct one is found, which defeats the purpose of rasterizing in the first place.
Well, I am starting to ramble on and on so I will just stop here. I will go ahead and finish coding the algorithm and see if it is really a big issue. Thanks for the reply.
Well, I am starting to ramble on and on so I will just stop here. I will go ahead and finish coding the algorithm and see if it is really a big issue. Thanks for the reply.
I had huge problems with this using it in my lightmapper. The main problem was aliasing. Small triangles sometimes don't hit a pixel center and aren't rasterized at all. Even very large skinny triangles don't always hit a pixel center.
So, I'd say it depends on your input triangles. Most of the problems I had came from a couple of free models. Custom-made models can avoid some of these things.
So, I'd say it depends on your input triangles. Most of the problems I had came from a couple of free models. Custom-made models can avoid some of these things.
Author
I just got an idea but am not sure if it is possible. I will researh it after I write this post. But since this problem is based on alialsing, why not rasterize to higher resolution buffer, shoot the rays through the "normal" buffer and get the triangle ID's from the high-res buffer? Or is this a slower way of sub-sampling? Damn, so many questions in my head now, lol. Im gonna research this and post my findings in a little bit.
I think OpenGL deems that a triangle hits a pixel if the top-left corner of the pixel is inside the triangle, I'm not sure, you should check the spec to be sure. If you set things up so that this matches your ray tracing (you probably use pixel centers for rays) the only difference is precision and I honestly think rasterisation will have better precision, so all should be good, unless you actually REQUIRE exact reaults. But I don't know how many bits of subpixel preciosn that OpenGL requires, so if you're running on bad hard ware, you might be screwed anyway. Overall, my guess is you won't have problems with good source art.
>>After rasterization, I would create the appropriate ray
>>for a pixel, and assume that it intersects the triangle
>>that was rasterized onto that pixel.
Oh, you use that kind of method. First storing the triangle index, then reading it back and getting the world position from raytracing to that triangle.
Well, the difference between raytracing and rasterization shouldn't be *that* big (furthermore, the difference goes to zero as the resolution increases), so I suggest that you just interesect the triangle with the ray, and if the raytracer finds that the intersection point is a little bit outside the triangle, just clamp it to the triangle's domain in some manner (because you *know* from the rasterization part that it should lie on the triangle... of course it's a little approximated but anyway).
Here's another trick: you can figure out the *exact* world positions of the pixels by also reading the depth buffer back. Then the position can be deduced from the image space position and the depth buffer (although I can't come up with the formula right here. It should be standard and easy, though. Someone might tell it here too :) ).
-- Mikko
>>for a pixel, and assume that it intersects the triangle
>>that was rasterized onto that pixel.
Oh, you use that kind of method. First storing the triangle index, then reading it back and getting the world position from raytracing to that triangle.
Well, the difference between raytracing and rasterization shouldn't be *that* big (furthermore, the difference goes to zero as the resolution increases), so I suggest that you just interesect the triangle with the ray, and if the raytracer finds that the intersection point is a little bit outside the triangle, just clamp it to the triangle's domain in some manner (because you *know* from the rasterization part that it should lie on the triangle... of course it's a little approximated but anyway).
Here's another trick: you can figure out the *exact* world positions of the pixels by also reading the depth buffer back. Then the position can be deduced from the image space position and the depth buffer (although I can't come up with the formula right here. It should be standard and easy, though. Someone might tell it here too :) ).
-- Mikko
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
