ompf2.com

Hi Yurika, Ah, you're right, I misunderstood your post! I understand your method now. However, I think there's still a subtle problem with it. (I ran into this, too!) The problem is that sampling the visible area from the inside of the sphere samples it uniformly, but sampling it from outside of th...

Hi yuriks, Sorry for the late reply, but I think your method doesn't quite work...I ran into the same problem also! The problem is that the point of intersection is in general not tangent to the sphere, so the triangle formed by it, the center of the sphere, and the origin of the ray isn't a right ...

If you re-render the whole image then you have the overhead of creating paths, tracing rays, sampling, calculating cosines, etc. which doesn't really vary by light but that's still being repeated anyway. If you use the light-vector approach then that's only computed once and you save on that computa...

Your understanding still seems somewhat confused (sorry if that's not indeed the case), so here's an alternative way to explain it: Light intensity is additive. That means that rendering a scene with N light sources is the same as rendering the scene with only one light source active at a time. Here...

EDIT: This algorithm is incorrect! See akalin's post below. I've had a similar confusion while reading PBRT. I like to derive all algorithms myself from first principles, so while deriving the sphere sampling one I arrived at an (in my opinion) simpler solution, and couldn't find any drawbacks with...

Hello, first time poster here. It seems like this is the only ray-tracer development community around! :cry: In my spare time, I'm reading PBRT and developing a ray/path/hacktracer of my own. Using the book for a mathematical and technical foundation but then trying to apply my own ideas. Recently I...

My tracer had some funny ideas about how shadows work for a while: