I think you answered your own question. I know that you know that noise in ray tracing is very inconsistent. It's easy to get people excited about "real time ray tracing" because people expect it to "happen" soon when most people have no idea about the nuance of what affects speed and noise in ray tracing.

If you gonna cheat just give up on RT - this is what precomputed shadow maps, light maps, speculate maps etc are for together with various cheats to clip shadows when they overlap or already at max "darkness" same thing with lights when you have multiple lights sources you usually approximate by stacking the combine illumination values for light sources of the same direction.

I really don't understand why are they chasing RT.

Also would be nice to know how well they can actually compute shaders, do tessellation and many other things because this is one heck of a fluff piece and I can remember at least 1 of these past 20 years that proclaimed that real time RT in hardware is here.

> I really don't understand why are they chasing RT.

1. The highly-parallelizable nature of RT is ideal for many-core architecture we're heading toward. Note that the PowerVR hardware used in the demo has 4 cores, needs no fans, and uses 10x less power than a traditional rasterization-optimized GPU.

2. The simplicity of implementing physically-based effects leads to a much easier time for artists.

I would argue that physically-based raytracers actually make things more difficult for artists, because they tend to be less flexible. Being physically correct is great if what you get out of the renderer is exactly what you want, but as soon as you need to cheat anything to achieve a particular look, it's much easier to not be bound by physical correctness.

The Disney BSDF [1, 2] is extremely flexible and offers a lot of artistic freedom. The only real limitation is that the BSDF is required to be energy conserving, but that's hardly a limitation. A physically-based renderer is still able to produce non-photorealistic results.

[1] http://blog.selfshadow.com/publications/s2012-shading-course...

[2] http://blog.selfshadow.com/publications/s2015-shading-course...

Maybe, depends on whether you're doing CG animation (Pixar, Dreamworks style) or more realistic stuff - VFX, photoreal stuff.

If the former, then maybe a bit.

But the beauty of physically-based is that in many cases, you can take a model that's been textured and lookdeved and it will work nicely in many different lighting setups. Before Physically-based, you practically had to re-do stuff completely when you changed the lighting to get the look you wanted.

However, Physically-based still isn't a complete win - you can't looked something close up and expect it to look good in the distance - it just won't. You need to be aware of the LODs and create different asset variations appropriately for different distances.

It would be really nice to be able to do things like this in RT:

http://www.zeitguised.com/geistxyz#geistxyz01 https://vimeo.com/150824660

You've described a struggle that's very real in production with the off-the-shelf renderers today. People seldom realise that.

Pixar switched to a path tracer for Monsters University, and it made it easier for the artists (once they unlearned the tricks and hacks they would have needed for less sophisticated renderers).

PathTracing (Though not regular Ray tracing) is actually pretty tricky to parallelize. I'd be interested in hearing what their hardware actually does? I'm guessing some hardware implementation of ray intersections with a BVH or kd-Tree?

The problem that occurs when trying to do path tracing on current hardware is that secondary (reflected) rays are incoherent so the gpu will stall one ray while waiting for another that hit something, leading to poor utilization of the gpu. It's still normally faster than on a cpu, but compared to "simpler" problems like some linear algebra (Machine Learning or similar) the perf of gpu vs cpu is low.

I thought GPU techniques do something like accumulate the secondary rays and use really fast GPU sorting algorithms on them before continuing, to bring back coherence.

Rasterization also is of highly-parallelizable nature and this parallelism has been exploited to great effect in the last decade(s). Given that Ray Tracing's only advantage over Rasterization is specular reflection it seems unlikely it is really superior in terms of efficiency. Especially since specular reflections and many other effects can be achieved via cheating in Rasterization.

For real GI, Path Tracing, Photon Mapping and so on are the methods of choice and not Ray Tracing.

Global Illumination, Path Tracing, Photon Mapping and Ray Tracing all belong to a category of algorithms that are better suited for multi-core general processors -- not the SIMD hardware of today's GPUs.

GPU's haven't stuck to SIMD parallelism for quite a few years now. NVIDIA is not there yet SMT/DPT isn't true parallelism but it's good enough even for path tracing. AMD GPU's are pretty much truly parallel with every execution unit capable of executing any instruction asynchronously.

Ray tracing has other advantages besides shiny reflections: it can handle refraction, shadows, non-triangle-based geometric primitives (including CSG), and has less sensitivity to the total amount of geometry in a scene.

Global illumination is where we want to go to surpass the realism of current games, but path tracing and photon mapping are both fundamentally based on ray-tracing. Any hardware that makes ray-tracing go faster (especially for incoherent rays) should also help to speed up global illumination.

Their hardware actually combines hardware rasterization and raytracing.

Depending on the implementation, raytracing can have many benefits over rasterization, such as: - ability to produce pixel-perfect shadows - sub-linear complexity on the amount of primitives (vs. linear for rasterization) - rays need not be coherent, i.e one can render non-linear projections or lots of small views

Path Tracing also is just another form of Raytracing. They demonstrated that their hardware can be used for it (just read the link).

> Also would be nice to know how well they can actually compute shaders, do tessellation and many other things because this is one heck of a fluff piece and I can remember at least 1 of these past 20 years that proclaimed that real time RT in hardware is here.

The chip iterates on "standard" GPU designs made to performed rasterization, therefore it has everything in place to launch compute jobs or do tessellation. In addition, they have some additional hardware for raytracing. From one of the previous GDC presentations it was more or less clear that you could programmatically activate raytracing with a configurable number of rays and those rays will deliver additional lighting contributions to the objects of the scene.

RT is a rasterization method it doesn't not save you from actually having to build the scene as in textures, materials, and transform it to the players viewport, for this you need many other things than RT which is why info about it would be appreciated rather than saying we can do RT at 1/10th of the power consumption NVIDIA does.

As I was saying, the GPU pipeline we are all used to is still there. I have posted in another comment some presentations from the GDC 2014 which you might find interesting.

... your carrying a flashlight/torch/wand-with-light-point-source on you as you walk through a room ...

As you get closer to that in real time you get to the point where VR will give you out of body experiences.

RT is by far the least efficient method of doing that. One of the issues with RT is that it actually creates "unrealistic" lighting at least as far as computer entertainment goes the global illumination tends to be way too uniform and washed out. It looks great on the big screen when your eyes can adjust to the brightness of the screen which is the most luminous object in the room but it looks really washed out on a monitor in a well lit room.

Agreed, but the "grail" is you invent some technology where the GPU can RT a scene in real time with all of the illumination identified just prior to the frame it is used in, and now you save a ton on artists and modellers who are spending their time making lightmaps etc. Just point the magic gizmo at your geometry and "poof" perfectly lit scene.

No you don't have tons of artists and modelers making light maps etc, they are in 99% of the cases made automatically depending on the engine and modeling software you use you can render objects using what ever method you want in non-real time including raytracing and the software can generate things like specular and shadow maps.

>Just point the magic gizmo at your geometry and "poof" perfectly lit scene.

There are plenty of global illumination models that do not require doing full path tracing e.g. Radiosity https://en.wikipedia.org/wiki/Radiosity_(computer_graphics) which are much more efficient than ray tracing (even on dedicated RT hardware fyi) while resulting in pretty much an identical image, path tracing also works pretty damn well. One of the main reasons that these aren't use isn't because the current hardware isn't fast enough but because the resulting image just doesn't look right because of various factors and has to be then highly adjusted to increase it's dynamic range. Global illumination creates brilliant results when your eye perceive it as "real" illumination like for example when sitting in a dark cinema when the only light source is the light bouncing from the screen which means your eyes only adjust to the brightness level of various areas in the screen which allows it to maintain relatively high dynamic range even tho it's pretty much uniformally lit.

With computer monitors this simply doesn't work the monitor is most cases isn't the brightest object in the room as you have both day light and indoor lighting. The monitor in most cases doesn't take as nearly as much of your view as a movie screen does and modern cinema projection solutions can actually provide high dynamic range by having different luminosity levels for different parts of the screen while your monitor is lit by a single diffused light source.

This pretty much means when you use global illumination you get much much lower contrast between lit and shadowed areas as well as overall darker lights and lighter shadows. Sure the scene is universally lit but it just doesn't look like what people expect partially because they are used to direct illumination as it has been mostly used (with a few exceptions mostly due to the issues brought up here) for the past 20 years of real time 3D graphics.

So when you do use global illumination models (doesn't matter if they are precomputed like Valve's implementation of Radiosity, DICE's real time RS, or Nvidia's Gameworks Path Tracing) you either get a really washed out look or you have to tweak the hell out of it during post processing to give it a more stylized look.

And again Ray Tracing doesn't save you from shaders you still need to write the same material shaders as you do today some of them might be slightly simplified if you are doing various things like fetching different specular/reflection maps based on the viewport or scene composition etc. But overall you will still have the same shaders that make one door look like glass while the other like wood because it's silly to have to make 2 doors when you can just adjust a flag in a shader.

> Global illumination creates brilliant results when your eye perceive it as "real" illumination so VR with Occulus should work wonder, correct ?

Primary rays cache, secondary rays trash. That's why. If anyone comes up with a powerful enough system to do truly useful and fast raytracing in realtime, they will show it.

I wonder if the Sorted Deferred Shading algorithm from Disney's Hyperion renderer could be adapted to realtime rendering? Optimizing a renderer that does one frame every 10 minutes to produce one every 16ms is difficult, but a scaled-down version with a lot of fakery might be possible.

http://www.disneyanimation.com/technology/innovations/hyperi...

It won't - at least for general ray intersection itself, the deferred sorting doesn't buy you that much - the main benefit it gives you is much more coherent texture accesses, which Disney needs because they use PTex which needs coherent access for the filtering.

Almost everyone else is still doing pretty much shade-on-hit one-at-a-time and getting pretty good performance out of it.

PRMan RIS is batching shading points up, but after the first bounce the batches get much smaller, so the win you get from it is much less.

Disney do a lot of work sorting the batches, and that takes time.

Also their render times for full frames are generally 12 hours wall clock or more (like most of the rest of the VFX industry). And Disney are heavily de-noising their images afterwards anyway.

where are you getting 10 minutes from?

most animation or vfx rendering takes hours per frame.

I probably misread the numbers in the paper.

The graphs in Figure 10 imply that the interior scene can be done in 10 minutes, but Figure 4 says the scene takes 68 minutes to render.

You're talking about an algorithmic problem (of a path tracer), this hardware just traces rays. It supposedly does so at 10x the efficiency of a high-end GPU (which isn't designed to do raytracing in the first place). That's the "groundbreaking" part.

For realtime use, this hardware will likely do no more than a single directional light's shadow plus and single bounce of sharp reflections. This is then combined with a rasterized view of the scene. Keep in mind that this is a "mobile" GPU that hasn't been "scaled up" for the Desktop yet.

For offline use, this hardware will at least be more efficient than a GPU.

Why is 'sometimes occluded' important? For each surface your ray hits you need to look at all lights, and if more of them are occluded that's better as you have less computation to do to add that light in don't you?

Because in path tracing, when you have many lights, you don't want to be sampling each light each bounce - that just doesn't scale due to the explosion in number of rays you have to send to test occlusion. The whole point of path tracing (generally anyway, and especially for games I would have thought) is each progression gives fast updates, but with not necessarily great results quality (which you make up for by averaging loads of progressions). If you sample each light each ray bounce/progression you'll get much better results, but it will be much slower.

So you randomly sample/pick one, or a few (maybe vary it based on the current ray importance or throughput) to test.

So given that you can't sample all lights (efficiently anyway), you have to try and efficiently cull/find lights which are visible to the surface being shaded/lit. Because otherwise you might be sending test occlusion rays to lights that wouldn't even contribute anything even if they weren't occluded.

It's close to impossible to do this perfectly (in an unbiased way, anyway), and even if you do a pretty good job, it's extra computation, and the fact that certain lights are sometimes occluded significantly adds noise to the lighting.

These problems can be overcome (somewhat) by using more clever path tracing such as bidirectional path tracing, and mutating "successful" paths instead of creating new ones, such as in Metropolis Light Transport.

Determining which lights are occluded is non-trivial and can't be done on at a low level (too many checks) thus you need to precompute it on some level, but if different parts of the scene have different sets of lights visible you need to somehow abstract that to keep your parallel computations going.

All very doable but are the hard problems with the tech that should be solved before we say that ray tracing is solved.