7 ms·

An anecdotal observation: there seem to be many ray tracing-related articles and ShowHNs that make the front page. For someone who isn't in the computer graphi

by ramzyo 8y ago

An anecdotal observation: there seem to be many ray tracing-related articles and ShowHNs that make the front page. For someone who isn't in the computer graphics space, what's the importance of improving existing ray tracers or the novelty in writing one's own? Is writing one a particularly challenging thing to do? Is improving existing ray tracers the equivalent of chip manufacturers increasing CPU performance in the chip world? Just trying to understand this a bit better.

speps 8y ago
The big news is a standardized API to do realtime raytracing. Both of those are a big deal because as you said everyone until now wrote their own and had to overcome the challenges associated with that. If that's taken care of (for the most part), the only things left to write as a developer are how you want to use this feature. In TFA, it's using it to do realtime raytraced reflections where previous techniques to do that in realtime are too much of an approximation and have big drawbacks.
electricslpnsld 8y ago
> what's the importance of improving existing ray tracers 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.
chasingthewind 8y ago
>Is writing one a particularly challenging thing to do? 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 :)
- repsilat 8y ago
  Funny, I bet more people know how to raytrace a sphere in software than know how to rasterise a polygon these days. Neither is terribly hard (or terribly useful, to the average dev.)
  - fyi1183 8y ago
    To be fair, raytracing a sphere is easier than raytracing triangles. 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.
- grkvlt 8y ago
  Exactly. And, similarly to fractal rendering, it's also the fun of using what is essentially pure mathematics (3-D geometry, algebra, matrices, etc.) to generate pretty images.
SomeRando111 8y ago
I think they're just cool. 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.
zamalek 8y ago
> Is writing one a particularly challenging thing to do? 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.
keerthiko 8y ago
Simply put, raytracing is one of the most computationally expensive operations in real time graphics (games). Improving raytracing allows moving game graphics more from prebaked artistry towards physical simulations that still result in beautiful visuals.
pzone 8y ago
You can write a ray tracer in a weekend. http://in1weekend.blogspot.com/2016/01/ray-tracing-in-one-weekend.html?m=1 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 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.
JepZ 8y ago
The quality of ray traced scenes is much better and much closer to the real world than rasterized scenes. Yet ray tracing is very expensive in terms of computation (often too expensive for real time ray tracing). 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.
dragontamer 8y ago
To fully understand the obsession with Ray Tracing, simply download Blender and run the Gooseberry Benchmark. Gooseberry is Blender's hardest benchmark. It represents a typical scene in the upcoming Gooseberry open-source movie project. So its a "real" scene, representative of what movie studios have to deal with. 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.
alkonaut 8y ago
Writing one is fun because it’s trivial to start, but you can be sure that there are features that are simply beyond your capability almost no matter how good you are. And it gets hard fast. It’s also very cross disciplinary if you like math, physics and system level programming. Those of use who wrote ray tracers are probably the same that code toy synthesizers. We like numbers. Once you made one it’s also an excellent way of learning a new language to make a new one. 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!
- uryga 8y ago
  > your render will never finish with physically correct subsurface scattering did you mean "will take a very long time", or "won't actually terminate"? if the latter, why? that sounds really interesting!
  - BTeam 8y ago
    Path tracing in general do not technically terminate since it's trying to approach an integral (the rendering equation) with sums. It's up to the user to determine the sample per pixel threshold with which he is satisfied. The goal is often to not have too much noise for the time spent. It's not easy because noise reduction over time tends to be logarithmic.
    - alkonaut 8y ago
      This. Doing “physical” SSS means shooting rays stochastically into the medium (skin, milk, marble) and having them bounce around inside, emerging at a random location, but more likely close to where it entered. That type of tracing will simply not produce a reasonable result in a reasonable time. You have to cheat.
KaiserPro 8y ago
Depends which market you are in. 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 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

by ramzyo 8y ago

speps 8y ago

The big news is a standardized API to do realtime raytracing. Both of those are a big deal because as you said everyone until now wrote their own and had to overcome the challenges associated with that. If that's taken care of (for the most part), the only things left to write as a developer are how you want to use this feature. In TFA, it's using it to do realtime raytraced reflections where previous techniques to do that in realtime are too much of an approximation and have big drawbacks.

electricslpnsld 8y ago

> what's the importance of improving existing ray tracers 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.

chasingthewind 8y ago

>Is writing one a particularly challenging thing to do? 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 :)

repsilat 8y ago
Funny, I bet more people know how to raytrace a sphere in software than know how to rasterise a polygon these days. Neither is terribly hard (or terribly useful, to the average dev.)
- fyi1183 8y ago
  To be fair, raytracing a sphere is easier than raytracing triangles. 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.
grkvlt 8y ago
Exactly. And, similarly to fractal rendering, it's also the fun of using what is essentially pure mathematics (3-D geometry, algebra, matrices, etc.) to generate pretty images.

SomeRando111 8y ago

I think they're just cool. 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.

zamalek 8y ago

> Is writing one a particularly challenging thing to do? 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.

keerthiko 8y ago

Simply put, raytracing is one of the most computationally expensive operations in real time graphics (games). Improving raytracing allows moving game graphics more from prebaked artistry towards physical simulations that still result in beautiful visuals.

pzone 8y ago

You can write a ray tracer in a weekend. http://in1weekend.blogspot.com/2016/01/ray-tracing-in-one-weekend.html?m=1 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 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.

JepZ 8y ago

The quality of ray traced scenes is much better and much closer to the real world than rasterized scenes. Yet ray tracing is very expensive in terms of computation (often too expensive for real time ray tracing). 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.

dragontamer 8y ago

To fully understand the obsession with Ray Tracing, simply download Blender and run the Gooseberry Benchmark. Gooseberry is Blender's hardest benchmark. It represents a typical scene in the upcoming Gooseberry open-source movie project. So its a "real" scene, representative of what movie studios have to deal with. 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.

alkonaut 8y ago

Writing one is fun because it’s trivial to start, but you can be sure that there are features that are simply beyond your capability almost no matter how good you are. And it gets hard fast. It’s also very cross disciplinary if you like math, physics and system level programming. Those of use who wrote ray tracers are probably the same that code toy synthesizers. We like numbers. Once you made one it’s also an excellent way of learning a new language to make a new one. 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!

uryga 8y ago
> your render will never finish with physically correct subsurface scattering did you mean "will take a very long time", or "won't actually terminate"? if the latter, why? that sounds really interesting!
- BTeam 8y ago
  Path tracing in general do not technically terminate since it's trying to approach an integral (the rendering equation) with sums. It's up to the user to determine the sample per pixel threshold with which he is satisfied. The goal is often to not have too much noise for the time spent. It's not easy because noise reduction over time tends to be logarithmic.
  - alkonaut 8y ago
    This. Doing “physical” SSS means shooting rays stochastically into the medium (skin, milk, marble) and having them bounce around inside, emerging at a random location, but more likely close to where it entered. That type of tracing will simply not produce a reasonable result in a reasonable time. You have to cheat.

KaiserPro 8y ago

Depends which market you are in. 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 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