Comment by 2renderman | Hacker News Reader

Comment by 2renderman | Hacker News Reader

Parent Full thread

"getting all the physically-correct-rending details right"

So, the short answer to your real question is 'tone mapping' which...is kind of dumb, imho. Clamping is probably fine.

The important thing to remember is that, while ray tracing is cool and fun to code, it has no basis in physical reality. It's no more or less of a hack than scanline polygon rendering (which is to say, you could possibly look at them as approximate solutions to the 'rendering equation' with important things variably ignored? but that's like saying y=x is a cheap approximation of y=x^2...)

One cool hack to take a description of a scene graph as a set of polygons and end up with an image of the scene is to be like "ok what polygon is under this pixel in the target view? Which way is it facing? Which way are the lights facing relative to it? What color is this material? Ok multiply that crap together, make the pixel that color". That's good old fashioned scanline 'computer graphics'. Another cool hack is "well, what if we followed a 'ray' out from each pixel, did angle-of-incidence-equals-angle-of-reflection, did some csg for intersecting the rays with surfaces, see if we end up with a light at the end and then multiply through the light and the material colors blah blah blah" but its also just a hack.

I mean, it takes some loose inspiration from the real world I guess, but it's not physically correct at all.

I mention this because I totally get where you are coming from. You might want to check out some techniques that are physically-based though, because they also have interesting implementations (mlt, photon mapping, radiosity)....you might even find it useful to drive your physically-based renderer's sampling bias from intermediate output of your ray tracer!

Plain Whitted-style ray tracing has a lot of shortcomings and in general doesn't look great compared with what people expect from modern graphics, but I don't think it's fair to say that ray tracing is "just a hack". Global illumination methods such as path tracing, Metropolis light transport, and photon mapping are much more accurate and are all fundamentally based on ray tracing. (Radiosity is not, but then radiosity is tremendously slow and doesn't handle non-diffuse surfaces.)

My goal is real-time rendering. I've met with some success; it's definitely nowhere close to the fastest ray tracers around, but I can manage to pull off around 30 fps on a well-behaved static scene with maybe a few tens of thousands of triangles at 720x480 on a dual-socket broadwell Xeon setup with 24 cores. This means that it's fast enough to make simple interactive simulations and/or games, which is what I mostly care about.

Ray tracing has a lot of advantages when it comes to building applications. I can define by own geometric primitives that are represented by compact data structures. I can do CSG. I can create "portals" that teleport any ray that hits them to another part of the scene and use that to build scenes that violate conventional geometry. I can trace rays to do visibility calculations, collision detection, and to tell me what I just clicked on. I can even click on the reflection of a thing and still be able to identify the object. There may be ways to do some of these things in scanline renderers, but I find it satisfying to be able to do them purely in software with a relatively simple codebase.

I don't have the CPU resources or the skill at optimization to attempt global illumination in real time, but there are other projects that are working on that sort of thing. I have done non-real-time photon mapping before in an earlier incarnation of my ray-tracer; maybe I'll port that forward some day.

(In case anyone is curious, my ray-tracer minus a lot of changes I've made in the last month or so and haven't bothered to push yet can be found here: https://github.com/jimsnow/glome)

I'd say scanline rendering is "more of a hack" than ray tracing, but both can produce useful looking results, of course. They are both crude approximations of reality, but ray tracing is a closer model and it makes non-local phenomena easier to model (especially if you do things in a physically-correct way, respecting the law of conservation of energy etc.) Arguably, you would end up writing a "Universe simulator" if you wanted to accurately model absolutely everything that's happening in the real world :)

By the way, I've written about this exact same topic in my initial ray tracing post:

http://blog.johnnovak.net/2016/04/28/the-nim-raytracer-proje...

Reply on news.ycombinator.com