Jump to content
  • Advertisement
Sign in to follow this  
serious_learner07

OpenGL Ray Tracing doubts

This topic is 3681 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 have just started learning Ray tracing.I have few doubts in Ray Tracing. 1. How many rays from the camera position? 2. In one of the books, it is mentioned that for ray tracing we need to determine incoming direct light at the point of intersection by casting rays to the light sources. 3. Can I implement Ray tracing using OpenGL/Direction.If so, how can i implement 4. Finally Is Ray tracing a recursive algorithm? Thanks in advance.

Share this post


Link to post
Share on other sites
Advertisement
1. At least one ray per pixel of the image you wish to render. Additional rays are typically used to implement anti-aliasing or effects such as depth of field or motion blur.
2. That's right: For each primary hit point P you cast shadow rays to the light sources and use them to determine whether light reaches P or not. Only if the light source is not occluded you calculate its contribution to the color of P.
3. Ray tracing has been implemented on the GPU in pixel shaders. That requires you to encode primitives and the acceleration structure in textures. Google should give you plenty of results.
4. If you compute reflections/refractions/etc. through secondary rays, ray tracing is indeed recursive. For reflections you trace a ray starting at the point you're currently shading along the reflected direction vector and weigh in the color of the hit object.

Share this post


Link to post
Share on other sites
Quote:
Original post by serious_learner07
1. How many rays from the camera position?

At least one ray is fired for each pixel in the rendered image. If more than 1 ray is used, then a technique called "oversampling" is applied, but I would suggest you to shift oversampling into the future until the basics are clear. For the pixel resolution, construct the rays emanating at the camera's position and going through those positions of the camera's viewing plane that correspond to the pixels of the output image.

Quote:
Original post by serious_learner07
2. In one of the books, it is mentioned that for ray tracing we need to determine incoming direct light at the point of intersection by casting rays to the light sources.

Physically light is emitted from the light sources, hitting surfaces of objects and gets reflected, transmitted, absorbed there. The portion of light that finally arrives at the camera (or the eye if you want) defines what is seen. However, implementing a ray tracer that way would be an enormous waste of computation, so ray tracing goes the other way around: It starts at the camera; if a hit with a surface is detected, then look how that point is illuminated. One part of the illumination is directly incoming light. To determine the belonging amount of light, check whether the hit point is directly visible by any light source. That can be done by firing a ray from the point to each light source, and checking whether or not the ray intersects any surface on its way.

Quote:
Original post by serious_learner07
3. Can I implement Ray tracing using OpenGL/Direction.If so, how can i implement

OpenGL and D3D by itself are scanline rasterizers. They don't work like a ray tracer. "Misusing" the GPU as a kind of co-processor is possible but not directly related to OpenGL/D3D.

Quote:
Original post by serious_learner07
4. Finally Is Ray tracing a recursive algorithm?

Not necessarily, but usually. You can ray-trace a scene and determine its corresponding pixel in the output image by just the result of its first hit. The very first ray tracers were made that way. But then you can take only ambient illumination into account. Okay, ways exist to fake some direct illumination; also indirect illumination can be faked, but that veils IMHO the fact that those illumination was already computed earlier. Also transparency (at least including refraction) is done with recursive rays. You can determine from my "no ... yes ... but ..." that there are several exceptions. But ray tracers with branching rays are recursive by nature, and hence well suited for a recursive implementation.

Share this post


Link to post
Share on other sites

Thanks for the post. I am really grateful to you people. To further sharpen my knowledge, I have the following questions.

Quote:
Original post by Stereo

2. That's right: For each primary hit point P you cast shadow rays to the light sources and use them to determine whether light reaches P or not. Only if the light source is not occluded you calculate its contribution to the color of P.
.

What is a shadow ray. How do we generate the shadow of the object illuminated by the light source.

Again Should our ray tracing application know about the no of lights in the scene in advance. How should be do this.

Quote:
Original post by Stereo
4. If you compute reflections/refractions/etc. through secondary rays, ray tracing is indeed recursive. For reflections you trace a ray starting at the point you're currently shading along the reflected direction vector and weigh in the color of the hit object.


In this case, how will we terminate from recursive calls.

Share this post


Link to post
Share on other sites
Quote:
What is a shadow ray. How do we generate the shadow of the object illuminated by the light source.


Shadow ray is ray, its origin is at hitpoint of primary (or reflected/refracted) ray and its directions is toward one of the lights (you go through all of them in loop). If our shadow ray hits something before light, this pixel is in shadow, if not - this pixel is illuminated by the light.

Quote:
Again Should our ray tracing application know about the no of lights in the scene in advance. How should be do this.


Ye, our application has to know about number of lights in scene, How should we do this - we just increment integer with our light number when we're creating one light.
Then if we collide with some primitive, we just loop through the lights and do some calculations.

Quote:
In this case, how will we terminate from recursive calls.


If we reach some value, which we define (I personally use maximum of 5, even smaller is acceptable) - Imagine this - your first reflection bounce will be F.e. on 1/4 of total screen pixels, the second bounce will be lets say just 1/4 pixels on reflecting objects will do another reflections -> 1/16 of total screen pixels - and if we go further 3. bounce -> lets say 1/64 - and even this is sooo little number of pixels.

Share this post


Link to post
Share on other sites
Quote:


In this case, how will we terminate from recursive calls.


Usually you set a max depth value (a number between 4 and 8 is enough most of the times) and when you reach that depth you stop. For example, a sequence can be the following:

Depth = 5

-You shot the first ray from the camera.
-First hit. Surface features specular reflection. You shot a second generation ray.
-Second hit. Ray bounced on a transparent surface. Trace the transmission ray.
-Third Hit on the backside of the transmissive object. Light exits the material and continues its trip with a fourth generation ray.
-Fourth hit on another mirror. Trace the fifth ray
-Yet another mirror. But now the depth is 5 and you cannot go further. You set the contribute of the last ray to black.

As you can see, usually a typical scene wont have all those mirrors/glasses, so 5 is more than enought,.

In addition. unless your material are 100% reflective or transmissive, at each iteration the ne ray contribute will be scaled. So that if the first mirror had 50% reflectivity and the two transmissive surfaces had 50 transparency each, just the 17% of the fourth ray would have been taken into account. You may use this value to set a threshold.

This should work most of the times. Anyway, if the fourth ray hits a powerful light (or a surface lit by a powerful light) then it may contribute substantially to the final pixel color, and using that threshold trick may lead to quality loss.

Share this post


Link to post
Share on other sites
Quote:
Original post by serious_learner07
4. Finally Is Ray tracing a recursive algorithm?


You can do it in iterative form just for the sake of it. I have an example of such an iterative form in my online tutorial :

Raytracer in c++, iterative.

Of course it's not really optimized as I stated many times in the article, you can probably do better performing (without necessarily resorting to recursive function calls).

If you had to implement a raytracer in a language/platform that does not accept recursive function calls you would for example have to manage a pseudo-stack by hand (not necessarily first in first out by the way).

LeGreg

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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!