Spectral Ray Tracing

There's also Indigo Renderer and the open source LuxRender:

https://indigorenderer.com

https://luxcorerender.org

If you want to look under the hood and find the big production ones like too complex, I can recommend peeking at this one. It's a great example example of just the minimum of a spectral path tracer https://github.com/TomCrypto/Lambda

The closer rendering comes closer to underlying physical principles, the more game engines will become world simulation engines. Various engine parts commonly seen today will converge towards a common point, where, for example, we'll observe less distinction between physics and rendering layers. I wonder if this trend can be traced to some degree even today. Several orders of compute growth later, we'll look upon current abstractions in the same manner as on the 30 years old state of the art, shaped by technical limitations of the yesteryear, obvious in hindsight. Love the perspective this puts the things into.

Reality has surprising amount of detail.

Another one that few implement, and which can have a quite noticeable effect in certain scenes, is polarization of light[1].

[1]: https://www.giangrandi.ch/optics/polarizer/polarizer.shtml

It's like a fractal; the closer you look, the more details you notice affecting what you see. It's like we're creeping to 100% physically accurate rendering, but we'll probably never get to 100%, instead we'll just keep adding fractions.

It's possible to implement this efficiently using light tracing - the final value in the image is the (possibly transformed) contribution from each light source, and since you have the spectrum of the light source you can have the spectrum of the pixel.

Until you encounter significant dispersion or thin film effects, that is, then you need to sample wavelengths for each path, so it becomes (even more of) an approximation.

I would also recommend Ray Tracing in One Weekend [1] if you want a very quick introduction, and Physically Based Rendering [2] if you want to then go really in depth.

[1] https://raytracing.github.io/

[2] https://pbrt.org/

I can't take time to fiddle with raytracing (however much I'd want to!) but I skimmed the first half of that book and alias sampling is a very elegant and nice technique. Wish I had known about it earlier! It is useful in a far broader context than graphics.

What are the applications you have in mind?

I'm no RF guy, but I imagine you quickly will have to care about areas where the wavelike properties of EM radiation dominates, in which case ray tracing is not the right tool for the job.

It's the same thing! What are you trying to do with it?

One thing you'll run into is that there isn't a clear frequency response curve for non-visible, so you need to invent your own frequency to RGB function (false color).

Another thing is that radio waves have much longer wavelengths than visible, so diffractive effects tend to be a lot more important, and ray tracing (spectral or otherwise) doesn't do this well. Modeling diffraction is typically done using something like FDTD.

https://en.wikipedia.org/wiki/Finite-difference_time-domain_...

I think the term “distribution ray tracing” was a bit of a mid-point on the timeline of evolution from Whitted ray tracing to today’s path tracing? IIRC distribution ray tracing came from one of Rob Cook’s Siggraph papers. It’s probably worth moving toward path tracing as a more general and unified concept, and also because when googling & researching, it’ll be easier to find tips & tricks.

Yes when combining spectral rendering with refraction, you’ll need to pick a frequency by sampling the distribution. This can get tricky in general, good to build it in incremental steps. True of reflections as well, but up to you whether you want to have frequency-dependent materials in both cases. There are still reasons to use spectral even if you choose to use simplified materials.

when i wrote my very first ray tracer it didn't take me an entire weekend; it's about four pages of c that i wrote in one night

http://canonical.org/~kragen/sw/aspmisc/my-very-first-raytra...

since then i've written raytracers in clojure and lua and a raymarcher in js; they can be very small and simple

last night i was looking at Spongy by mentor/TBC https://www.pouet.net/prod.php?which=53871 which is a fractal animation raytracer with fog in 65 machine instructions. the ms-dos executable is 128 bytes

i think it's easy to get overwhelmed by how stunning raytraced images look and decide that the algorithms and data structures to generate them must be very difficult, but actually they're very simple, at least if you already know about three-dimensional vectors. i feel like sdf raymarching is even simpler than the traditional whitted-style raytracer, because it replaces most of the hairy math needed to solve for precise intersections with scene geometry with very simple successive approximation algorithms

the very smallest raytracers like spongy and Oscar Toledo G.'s bootsector raytracer https://github.com/nanochess/RayTracer are often a bit harder to understand than slightly bigger ones, because you have to use a lot of tricks to get that small, and the tricks are harder to understand than a dumber piece of code would be

Real-time is unfortunately a sort of vague term.

If you mean raster rendering pipelines then I don’t believe it’s possible because the nature of the GPU pipelines precludes it. You’d likely need to make use of compute shaders to create it at which point you’ve just written a patthtracer anyway.

If you mean a pathtracer , then real-time becomes wholly dependent on what your parameters are. With a small enough resolution, Mitsuba with Dr.JIT could theoretically start rendering frames after the first one in a reasonable time to be considered realtime.

However the reality is just that even in film, with offline rendering, very few studios find the gains of spectral rendering to be worth the effort. Outside of Wētā with Manuka , nobody else really uses spectral rendering. Animal Logic did for LEGO movie but solely for lens flares.

The workflow change to make things work with a spectral renderer and the very subtle differences are just not worth the high increase in render time

There’s more than one way to implement spectral rendering, and thus multiple different trade offs you can make. Spectral in general is a trade for higher color & material accuracy at the cost of compute time.

All else being equal, if you carry a fixed-size power spectrum along with each ray that is more than 3 elements, instead of an rgb triple, then you really might have up to an n/3 perf. For example using 6 wavelength channels can be up to twice as slow as an rgb renderer. Whether you actually experience n/3 slowdown depends on how much time you spend shading, versus the time to trace the ray, i.e., traverse the BVH. Shading will be slowed down by spectral, but scene traversal won’t, so check Amdahl’s Law.

Problem is, all else is never equal. Spectral math comes with spectral materials that are more compute intensive, and fancier color sampling and integration utilities. Plus often additional color conversions for input and output.

Another way to implement spectral rendering is to carry only a single wavelength per ray path, like a photon does, and ensure the lights’ wavelengths are sampled adequately. This makes a single ray faster than an rgb ray, but it adds a new dimension to your integral, which means new/extra noise, and so takes longer to converge, probably more than 3x longer.