Nice challenges include:
add parallellism. Traversing a tree hierarchy efficiently with SIMD or GPU code isn’t trivial. (I tend to dodge this part of the problem by using intels simd lib Embree)
Or make it spectral (trace with wavelengths instead of simple colored light, to get effects such as rainbows in refractions). This is actually reasonably simple - but then you realize it ruins your hope of parallelizing efficiently as the rays diverge when they refract!
Or implement realistic subsurface scattering. Doing it physically right means your render will never finish, so it’s back to inventing the most clever hacks - just like rasterizing!
did you mean "will take a very long time", or "won't actually terminate"? if the latter, why? that sounds really interesting!
That type of tracing will simply not produce a reasonable result in a reasonable time. You have to cheat.
Cheats like Dipole/Dwivedi are still used when they can be, but they often have artefacts and aren't completely correct, so they're starting to be avoided now.
- implement a bidirectional path tracer to increase convergence speed
- implement multiple importance sampling. It's a simple concept that I found astonishingly hard to implement in practice.
- implement an acceleration structure (like a BVH) that builds and caches efficiently. Can you make it fast enough to have animation?
- implement shader based unit tests to ensure correctness. Thus is also surprisingly hard.
In the offline space (film, visualization), cost. Movies get cheaper to make.
In the realtime space (games), lots of visually important effects are difficult to do with rasterization, leading to complicated/large/expensive-to-maintain rendering solutions. With a physically based path tracer, a lot of these effects come out of the box. Path tracing has traditionally been too expensive to do in realtime, however, and has been 'just around the corner' for the past 20 years. If I'm not mistaken, recent advances in image de-noising, which seems to be the crux of the new NVIDIA technology, have made real time path-tracing on the GPU much more practical.
> Is writing one a particularly challenging thing to do?
Depends how deep you dive. You can write a basic tracer to render a sphere and fit it on a business card -- this is a typical assignment in introductory graphics courses. Rendering complicated materials is a never ending rat hole of complexity, lots of rendering research looks effectively like material's science, these days.
So we have some technology which delivers superb results but is some sort of 'future technology' as we can't afford it yet. I think that is whats makes so many interested in ray tracing here. We know that some day that technology will revolutionize the rendering industry and every time some progress is presented we are curious how that progress is being made.
I wrote a simple ray tracer for a college project in the 90s so I would tend to say that part of the novelty is that it's actually quite easy to write a very basic ray tracer and get cool looking images :)
Even a single triangle is harder than a sphere, but with a triangle mesh you can't avoid thinking about acceleration structures and having a watertight intersection test, which includes worrying about floating point precision issues.
So what you're saying may be less about raytracing vs. rasterization and more about spheres vs. triangles.
Depending on the speed at which you want frames to appear (vs. noise), it can be. Writing a raytracer that can render a few shiny spheres in a few seconds on modern hardware is trivial - not more than a weekend project if you know nothing about the subject. Writing one that can render a Stars Wars scene 25 times per second is a vastly different beast.
First of all, "ray tracing" means at least two completely different things in the world of computer graphics:
MEANING ONE: GRAPHICS HACK
The old meaning of "ray tracing" is a hack: you take your screen, you figure out the projection into the world that represents the "camera", you trace out from each final pixel in the image to see what geometry it hits first, reflect, and allow for a certain amount of bounces before you decide on a color for the pixel based on the surface material properties you interacted with and where you got to a light.
The driving intuition here is that this bouncing this "ray" off geometry has some surface similarity to how light actually works in the real world (Except backwards: we don't shoot photons out of our eyes of course). However, it's not really any more "physically-based" or physics-accurate than traditional rasterization, which is just loads of hacks: i'm a triangle, i'm angled like so towards a light, i should be this color, except i'm bumpy, so lets simulate that by pretending im actually angled a bit off that angle here...
This particular hack does one or two things really well that normal rasterization does not: mirrored surfaces and translucent materials with a high index of refraction. This is why 99% of ray tracer demos include a bunch of mirrored spheres floating over a fountain on a marble floor. Ray tracing, the hack, _does not_ solve many other problems that ignoring the physics of lighting leaves out: caustics (those effects you see on say a the table under a glass of water when it catches the light), soft shadows, ambient occlusion (the tendency for things that are hidden by other things to not receive as much illumination, the way the joint where the wall meets the ceiling is a little darker than the wall.)
Writing this type of ray tracer is actually really simple and easy, which is part of the reason lots of people are interested in ray tracers, I'd wager. It's an intro computer graphics project. It also provides ample opportunity to hack on the performance because it's embarassingly parallelizeable and there are all sorts of intuitive algorithmic enhancements available (octree subdivision, etc.)
A lot of posts get on to HN about this type of ray tracer because the two things these are good at are cool, and given the parallelization opportunities fit with modern hardware development, this is hoving into range of "shiftable from offline to real time" which is cool. The second big reason there's always random ray tracer stuff on HN is because a ray tracer has one of the highest code-volume-to-cool-effect ratios so it shows up in intros and demos all the time. It's a great little project where you get something super neat super fast, but you have loads of runway to make things better with satisfying increments.
MEANING TWO: ACTUAL GRAPHICS SOLUTION
The "real way" to determine the appropriate illumination for every pixel on a rendered image is to start with all the lights, characterize the photons they emit, emit a zillion, trace them around the room bouncing off of objects, and see which ones ultimately hit the camera plane and write those colors. This will produce a photorealistic (or heat-camera realistic) rendering of a scene. You are simulating the actual physics of illumination here.
Of course, this is computationally insane, so there are approaches to dramatically reduce the computation at the expense of accuracy. The family that concerns us here are "path tracing" algorithms (e.g. "Metropolis Light Transport" is a monte carlo approach to integrating the "rendering equation", the equation that determines how things should look under lighting conditions). There are other ways to start with the rendering equation and reduce the computational complexity (e.g. radiosity) but this is the one that is sometimes called "ray-tracing".
These methods handle all the things I mentioned hack ray tracing not handling: soft shadows, ambient occlusion, caustics, etc.
I think this kind of stuff gets to the top of HN because it's awesome? My more serious answer might be that a lot of real-time rendering code is layered with hack upon hack to handle adding bits of detail to a rendered scene to make it more photorealistic. There's nothing particularly physical about bump maps, environment maps, or a zillion other real time shader tricks. They're all cool but they're hacks. The idea of being able to make a path-tracing-type renderer that runs at realtime speeds would mean that we wouldn't have to spend so much time hacking in things like prebaked shadow volumes or what have you in any realtime renderer (e.g. a game engine) and consequently our engines might be much more generic, instead of carefully tuned shader-by-shader to the specific types of effects we want to create. I'm kind of doubtful of this (I don't work in the games or computer graphics industries though so I'm extremely not an expert) because the "look" now is so much a look: people like bloom and lens flare. Film doesn't look "real" but when you make a movie tha looks more accurate people complain it looks "fake": you need to flicker.
There are other hacks too - the typical start-at-the-eye technique doesn't bounce the paths around the scene until they hit a light, it just does a couple of bounces, and at each surface it takes an estimate of how lit it is by looking at the lights that are visible from the intersection. I guess you could simulate the rays bouncing until they hit a light source, but at that point, why not just do the simulation from the light source like in the physical world.
What you really want to do at a surface intersection when you're going from the eye is an integration over all the possible paths light could take to hit that point and reflect along the path you took from the eye. For specular highlights and perfect reflections, this is reasonable, but in other cases there are an infeasibly large number of possible incident paths that could come out along the path you took.
On my 16-core / 32-thread 1950x Threadripper, it takes about 35 minutes to complete the benchmark.
That's 35-minutes to calculate ONE FRAME of the movie. It'd take about 300-days to have my computer calculate the entirety of the 10-minute long movie.
There are huge clusters of computers out there in Disney or any other animation studio, whose sole purpose is to calculate the light paths and properly shade these movies. After all, computers are cheaper than animators.
------------
Performing these calculations faster is a MAJOR hurdle in the movie industry. Gamers hope to eventually get these graphics into video games, but the math is just too computationally expensive to run right now.
---------------
Overall, the algorithms behind raytracing are relatively simple. If light is pointing at an object, it should be brighter. If light isn't pointing at an object, it should be darker.
There's a bit of details in the matter. Specular shading vs Diffuse Shading vs Subsurface Scattering vs Ambient Occlusion. But that's the artist's job. The artist simply tells the computer which algorithm (or combination of algorithms) best emulates the material.
The computer programmer's job is to simply emulate the light as it bounces off of the objects. That's all it is, very simple algorithm (ray-tracing) applied to a lot of points in 3d space, in a way that has been documented for decades.
The math has all been documented. It just requires a supercomputer to handle all of these calculations. So its a task that requires highly-optimized coding and really, really big computers (or clusters of $10,000 GPGPUs). You know, the kinds of stuff that gets ycombinator readers really excited.
-----------
Diffuse Shading -- when light hits a "rough" object and it doesn't bounce very cleanly. This provides the majority of the light in most cases. When held directly against light, the object is brighter.
Specular Shading -- when light bounces off cleanly the surface of the object. Leather and Metals are often a high degree of Specular.
Subsurface Scattering -- when light is absorbed by the object and bounces out elsewhere. This is very common in human skin: red light is often absorbed by the skin, and the light path will be diverted elsewhere.
Mirror -- Mirrors are incredibly handled well in raytracing, and are handled poorly by standard techniques. Expect lots of reflections as devs unleash mirrors upon us! (Kinda like how Wizard of Oz had overly bright color design because film-makers were flipping out about color movies).
Lots of other algorithms -- Smoke, Clouds, Fog, etc. etc. Its the Artist's job to know all of these algorithms. The Programmer / Raytracer just does whatever the artist requests.
Water is a great example that uses a combination of these. Imagine an ocean for instance.
Water is partially reflective (Mirror). Subsurface Scattering of the blue-wavelength occurs, so you let blue-light enter deeper into the water, but reflect off red/green. The top-layer of water is incredibly shiny (specular). Finally, ocean waves creates "foam", which is well represented by diffuse shaders and textures.
Gooseberry has been released -- https://www.youtube.com/watch?v=Y-rmzh0PI3c ... they have done multiple movies since then including agent 327 https://www.youtube.com/watch?v=mN0zPOpADL4 and Hero -- https://www.youtube.com/watch?v=pKmSdY56VtY
GPU acceleration really helps cycles (Blender's open source raytracing engine)... however, the gooseberry benchmark uses up too much ram to make this render purely off the GPU.
First for a ray tracer to be effective it must model billions of photons, so optimising how and where you fire them is key to making a _fast_ ray tracer. A non optimised, (therefore multi hour per single image render time) ray tracer is fairly easy to write (can be done in less than 5k lines of code)
As for what the point is, there are a number of things: Raytracing means that you are effectively simulating the physical properties of something. This means that light interactions between objects come for free (well, kinda) When you put a lamp shade on a light bulb, it will cast shadows. Windows are transparent, etc, etc. In raster land, thats not a given.
This means that architects who are designing building in cad, and have been very specific with their material choices can get accurate representations of how the light will interact inside the building. Maxwell render bills it's self as a physically accurate renderer, but it is _slow_, very pretty, but slow. (yes, there are trade-offs, a real-time renderer is not going to be physically accurate, but it is way more accurate than a rasterer) So making small incremental changes might mean waiting for a number of hours for the render to finish.
In VFX, renders can take > 24 hours per layer, per frame (Each finished frame might have > 1000 assets, each with > 100 versions, each with a number of layers.) So any time saving there can save thousands.
Also, getting real time feedback makes production much more fluid and intuitive. At the moment, when acting with CGI characters or backgrounds, you have to use a standin: https://imgur.com/gallery/OVk4DYp
This means that the cameras have to be much more scripted, a lot of working out has to be done to make sure that CGI elements blend in properly. In the film gravity, they used realtime motion capture heavily, as most of the elements (in some case only the eyes of the actors are real) are CGI. The director is a visual person and wanted to look through a camera and see the space station. He would have sacrificed his left testicle to get the demo's level of realism in his view piece
http://in1weekend.blogspot.com/2016/01/ray-tracing-in-one-we...
Improvements to commercial render engines today are often these days about adding new features and improving end user workflows. Here's last year's SIGGRAPH talk from Renderman. https://youtu.be/iDUV4ISCklA
Commercial end users include digital art studios and other advanced users. In-house teams of specialists will use low-level APIs to achieve desired results. Render engines often more like a software development platform than a video game engine. The CG industry is constantly changing, these days a lot of effort seems to be aiming toward standardization and interchangeably as pipelines become more complex and software becomes increasingly specialized. (Zbrush, Maya, Mari, Houdini, Katana, Nuke.) A render engine will have to support several of these DCC packages and ensure artists get consistent results.
Render engine speed improvements still play an important role in development, but it's most noticeable in areas that are outside of the traditional "path tracing" parts. This is things like subsurface scattering (the red glow of a flashlight behind your fingers), volumetrics (smoke and steam), and caustics (shimmering light on the table when a water bottle sits in the sun). The "ray tracer in a weekend" parts are very thoroughly optimized, but you do see innovation now and again with developments in importance sampling methods. What you say is true in this sense: modern render engines are still just as CPU intensive as ever and you still need massive server farms to create final frames.
A more modern development is GPU-based render engines such as Redshift, Octane and Blender's Cycles. These engines are subject to the limitations of GPU memory - unlike a server where you could pop in a TB of RAM if necessary, GPU render engines are not currently able to handle extremely complex scenes like hero assets with tens of GB of textures, entire cities worth of geometry and so on.
This Unreal Engine feature is a slightly different world. This isn't a raytracer in the sense of what I've been describing above, what it's doing is adding a layer of reflective effects, computed with raytracing, on top of ordinary "game engine", where in theory you could add controls to manipulate the camera with your mouse and keyboard and look around.
To hit 30fps, the trick is adding just a little bit of reflection to improve the look, and setting up assets do that the approximated effect looks appealing and convincing. The machine they ran this on would cost nearly $100k, though the cost of creating professional assets specifically tuned for this specialized environment would rival that. However for an architecture studio trying to make a pitch showing a stunning interactive demo of their design, the economics are nearly there. And on a wider scale, this same technology could add extra pop to glass, metals, and liquids in next gen video games on a more modest gaming rig.