Jump to content
  • Advertisement
Sign in to follow this  
Deebo

OpenGL first hit optimization accuracy

This topic is 5408 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
Advertisement
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
>>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

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!