On: Ray Tracing Denoising

[criddell]

At one time, writing a ray tracer was a right of passage when getting into computer graphics. I never did it, but this week I was trying to figure out how to find the intersection point of a ray and an oblique cone and all of the resources I found were related to ray tracers.

I'm thinking that maybe I should actually write a ray tracer. Is that still a worthwhile thing to do, or has the world moved on?

FWIW, I never solved the ray-oblique cone problem...

[dahart → criddell]

Still worthwhile in my opinion! But full disclosure, I happen to be working on ray tracing problems.

Writing them is still really fun, it’s no less useful today for learning things than it was 20 years ago. You can get amazing pictures with not very much code, and the algorithms are really satisfying to understand & implement.

There are also still tons of low hanging fruit. You’d think the easy problems would be mined out by now, but they’re not. New developments are actively happening with intersection primitives, color handling, sampling, direct lighting, shadowing, the list goes on. If you want to do research, you don’t have to dive that deep to find something unsolved that is solveable.

For an oblique cone intersection, I don’t know the right answer, but the oblique cone is a skew transform of a regular cone, right? You might be able to use a regular cone intersector, but pre-transform the ray by the inverse skew transform?

This resource is fantastic for finding intersection building blocks and code examples: http://www.realtimerendering.com/intersections.html

[m12k → criddell]

I've heard good things about 'Ray Tracing in One Weekend' https://raytracing.github.io/

[joefourier → criddell]

For a more modern twist on it I’d suggest writing a path tracer (bonus points if done on on the GPU). It’s not really any more difficult than an old-fashioned ray tracer but the results are much more graphically impressive.

[elihu → criddell]

Here's my solution for a regular cone intersection test (see rayint_cone):

https://github.com/jimsnow/glome/blob/master/GlomeTrace/Data...

One trick is simplify the problem to just doing a ray-intersection test with an axis-aligned cone, and to handle the general case not by complicating the ray-intersection test but rather applying the inverse transform on the ray itself. You can use the same trick to support oblique cones: just figure out what skew transform you want to apply to the cone, and apply the reverse transform on the ray.

[pfortuny → criddell]

It cannot be that difficult, mail me the question and I should be able to help you. See my profile.