Game Development Stack Exchange is a question and answer site for professional and independent game developers. It only takes a minute to sign up.
Sign up to join this community
I know raytracing is a technique based on the route calculation done by the light, following the rays through the interaction with the surfaces, and that Pbr is a collection of render techniques that are more or less based on the theory which matches that of the physical world, aiming to mimic light in a physically plausible way.
Is it possible to implement both into a Rendering engine? What's the difference?
Yes, you can... sort of.
DirectX announced a support for hardware based ray-tracing a couple of weeks ago and Epic Games (creators of Unreal Engine) have already made a demo with the models from the new Star Wars movies (check it out here).
This can make reflections much easier to create and should eliminate cube map based rendering almost completely.
There is a catch though, it is very slow. They had to run it on a 1280p screen with a Titan X to get 60FPS, which is a big problem considering how many people have 4k screens.
So yes, it's possible, but we'll still have to stick to cheating our way through different rendering techniques for a while and it's unlikely it will replace rasterizing very soon.
There are two different aspects of a renderer in play here:
How do we determine which bits of surface are visible on each screen pixel (including direct visibility or reflection), and what lighting those surfaces receive? Here we have two families of techniques:
Raytracing & Path Tracing renderers do this by modelling the way rays travel through the scene, including rays through each screen pixel and rays from each light source, seeing where they strike scene geometry first, and where they bounce to.
Rasterizing renderers do this by breaking surfaces into small pieces like triangles, and projecting them onto the screen, using a depth buffer to handle layering. For determining whether a point is lit or in shadow, we do the same thing from the light's point of view, saving the result to a "shadow map" texture we can sample when rendering the camera view.
Now that we know what surface we're drawing and what lighting it receives, how do we colour it so that its material appears to respond to light in the right way?
Older renderers, both raytracing and rasterizing style, relied on simple/idealized models of how materials bounce light, like perfect cosine Lambertian reflectance. That's why when you look at older 3D renderings, even raytraced output tends to have a slightly surreal, plastic-y appearance. The rays are hitting the right spots, but there's something just a bit off about how the material interacts with that light. Real world materials are more complicated.
In physically based renderers, the materials' response to light is grounded in more sophisticated models and often direct measurements of real materials, including things like microfacets, surface anisotropy, fresnel effects, energy conservation, etc. See this earlier answer for some examples of how this affects the appearance of rendered objects and how artists work with them. This work started in offline/ray- & path-traced rendering for films, and more recently made its way into games' rasterizing renderers. The use of these more sophisticated models helps the shading of objects look more natural and accurate over a range of lighting conditions.
So yes, you can combine physically based shading with a raytracing renderer, as they relate to different parts of the problem of rendering a scene.
Raytracing works in some fashion that light does as it travels trough the world, by casting rays, bouncing off surfaces/passing trough them. Only that rays are cast from the eye/camera and tries to find the intersection between a surface and a light source and returns the result of the path. It's actually closer to a physical simulation than PBR techniques for games has it in its name. And to get a good quality image you need to cast a good amount of rays. Which is computational heavy. Raytracing by itself does not mean PBR though. Next to CPU you also need a lot of Ram for this.
PBR for games as is, is similar to any other traditional rendering technique. Where triangles are clipped and rasterized first and the data between vertices interpolated in each shader stage. After just rasterizing the triangles we already have the fragments to work with. The output pixel is calculated by using some PBR principles by combining Albedo, Metallic, roughness values with additional light settings( which can be precomputed/baked for static objects).The name Physical Based Rendering simply implies that it is using some principles of actual physics model. However it does not mean it actually is, as in it just borrows a few ideas but not the exact model. Many things in game render techniques come down to faking it.
Actually simulating lights bouncing off surfaces is very computationally expensive. And these new raytracting apis for gpus are just one step closer to achieving realistic visuals.
wiki article for ray tracing concept
This one is not directly on game graphics, it's still relevant
