Archived

This topic is now archived and is closed to further replies.

The real Raytracing for GI thread continued

This topic is 5132 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

This image shows soft shadow and indirect illumination. I stopped the other thread because I figured it was quite purposeless to argue about something without actually doing any verifications. So here I come, with an early version of my improved raytracer, implementing the algorithm I proposed. Of course, several things are not optimized at all and could actually be much faster. The image was made to render fast. Its a sphere sitting on a plane with a very large light source on top. The main flaw in my system is that I need to find a better way to generate random lighting vectors quickly. Vectors that will be within reasonable boundaries of the real vectors, because if they are out of the light cone, they are not worth much. I was also wondering what you people think about this simple one: When weighting the contribution of all light rays, do you average by dividing by the amount of rays emitted, or by sum of the weights of all light rays (yes, this is a serious question). Next steps for me: - Update scene file loading (this scene is hardcoded) - Command line options - Add in polygon support - Optimize random vectors

Looking for a serious game project?
www.xgameproject.com [edited by - Max_Payne on November 30, 2003 11:35:25 AM]

Share this post


Link to post
Share on other sites
I''ve said it before, I''ll say it again: importance sampling based on the BRDF. There are dozens of papers available for free on the Internet. Do yourself a favor and hunt them down.

To answer your second question, it depends on how you send out your rays. If you are sending out rays randomly, then test the BRDF using the surface normal and your random ray - that will give you your weighting factor for the ray. Add all of the rays up and divide by the number of rays. If you are importance sampling, just add up each ray with a weight of 1 (i.e. no weight) and divide by the number of rays.

Share this post


Link to post
Share on other sites

My own version of the Cornell box

A bit of improvement. There is now support for polygons and those are loaded from a scene file. The camera parameters are also set from the scene file. I still have to improve my light sampling because the technique I used to obtain quick results isn't too efficient.



Looking for a serious game project?
www.xgameproject.com

[edited by - Max_Payne on November 30, 2003 11:41:27 AM]

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
I think there''s way too much noise.

If you add a bunch of weighted rays, you should divide by the sum of the ray weights, not the number of rays.

Share this post


Link to post
Share on other sites
quote:
Original post by Anonymous Poster
I think there''s way too much noise.

If you add a bunch of weighted rays, you should divide by the sum of the ray weights, not the number of rays.




You''re right, my mistake. These things happen when I''m working at 3 AM



From what I can tell it looks like your noise is coming from unimportant samples getting too much weight (i.e. a ray firing off into the darkness is contributing more to the color of the pixel than it should). You''ll definitely see an improvement with a better sampling scheme. The color bleeding looks pretty good, though.

Share this post


Link to post
Share on other sites
Right now the rays are weighted according to the cos of the angle between their direction and the normal vector of the surface (concentrating on diffuse reflections right now). The light value is also divided by the square of the distance between the light source and the surface (quadratic attenuation). Rays are randomly generated by being assigned random values (between -RAND_MAX/2 and RAND_MAX/2) for each component and then being normalized. If a ray has a negative weight, it is multiplied by -1 and so is his weight (to avoid recalculating another ray).

I suppose a good way to get random rays could be to pre-generate a uniform spherical distribution of rays, but that seems like a slow process (choosing from a bank of rays, especially when the light cone gets smaller, when it gets more specular).



Looking for a serious game project?
www.xgameproject.com

Share this post


Link to post
Share on other sites
You can use importance sampling of the diffuse BRDF. This basically means generating rays with a cosine distribution:

OCaml

let cos_hemispherical r1 r2 =
let theta = acos (sqrt r2) in
let phi = r1 *. (2.0 *. pi) in
Vector3.of_spherical_unit phi theta


Basically use two random numbers in the [0,1] interval.

Generate two angles theta and phi:

theta = acos( sqrt(r2) )

phi = r1 * (2 * pi)

And then generate the vector:


let of_spherical_unit phi theta =
let sin_t = sin theta in
let cos_t = cos theta in
let sin_p = sin phi in
let cos_p = cos phi in
{ x = cos_p *. sin_t; y = sin_p *. sin_t; z = cos_t }


(should be obvious)

This then needs to be aligned to the normal at the surface point.

In general uniform distributions are not at all useful.

[edited by - JuNC on November 30, 2003 3:05:38 PM]

Share this post


Link to post
Share on other sites