1
\$\begingroup\$

Maybe I'm still confused about my own understanding,

  • Forward Render: render the lighting of an object according to the light source in the scene. (e.g Phong)
  • Deferred Render : render the scene to get geometric information, store it in a buffer, and then apply lighting. (e.g ?)
  • PBR : treats lights in the scene the way it behaves in the real world. (e.g Ray tracing, Photon Mapping)

I don't see how Forward and Deferred render are going to give much difference to the scene. Why do we need to store the geometrical value in Deferred Render before applying lighting ? Why don't we just compute lighting right away like Forward Render ?

Also for Physically Based Rendering, computing each light takes a lot of time, and almost impossible to be done in real time. But why this technique is always considered the best ?

\$\endgroup\$
  • \$\begingroup\$ It's not about the looks and lighting, think about the performance. forward rebdering calculates lighting for every draw pixel, while deferred limits it to the screen pixels \$\endgroup\$ – Bálint Jun 24 '18 at 16:32
  • \$\begingroup\$ Also, PBR isn't raytracing \$\endgroup\$ – Bálint Jun 24 '18 at 16:35
  • \$\begingroup\$ @Bálint Doesn't PBR treat light as of how nature treats lights ? Follows the laws of Physics on how light interacts with material ? And in raytracing, light is a ray. Do I get this wrong ? \$\endgroup\$ – raisa_ Jun 24 '18 at 17:15
  • \$\begingroup\$ PBR is a simulation. It's still rasterization that only simulates how the light rays bounce off or go under the surface of certain materials (e.g. light doesn't bounce off of leather as much as from shiny object, but it certainly goes under the surface more often). Raytracing and many other rendering techniques actually take a ray and follow it. \$\endgroup\$ – Bálint Jun 25 '18 at 0:06
2
\$\begingroup\$

First, I wouldn't consider PBR to be separate from forward or deferred rendering. You can use PBR in either forward or deferred rendering, as I understand it. Physically-based rendering just means trying to simulate the actual physics of light. This gives more realistic results than other techniques, but like all techniques, it involves trade-offs between speed and accuracy.

I think your understanding of forward deferred rendering is correct. One issue you can run into with forward rendering is that there is a limit to the amount of data you can send to a single shader. If you have 100s of lights, you need to send the position, direction, type, color, etc. for each one to the shader. You can hit the limits of number of allowed uniforms in scenes with lots of lights. It's also possible to hit the limit of how much work can be done in a given draw call. I've had the OS kill drawing when a single shader took too long. (This was not with a game, though.) With deferred rendering, you simply make multiple passes sending a subset of the number of lights to each pass. Note, though, that every pass you add adds a lot of overhead to the rendering, making it slower.

I don't see how Forward and Deferred render are going to give much difference to the scene.

The results of forward and deferred rendering may in fact be the same if you're sending the same numbers of lights and rendering them the same.

Why do we need to store the geometrical value in Deferred Render before applying lighting? Why don't we just compute lighting right away like Forward Render?

If you computed it right away, it wouldn't be deferred anymore. That's the difference between the 2. Deferred rendering renders the geometry without taking into account lighting, then in subsequent passes calculates the lighting. Forward rendering does it all at once. (There may still be multiple passes for other reasons, like depth-peeling, etc.)

Also for Physically Based Rendering, computing each light takes a lot of time, and almost impossible to be done in real time. But why this technique is always considered the best?

Computing each light takes more time than for something simple like Phong, but I wouldn't say it's "almost impossible to be done in real time," as there are plenty of games out there using it now. "Best" depends on your goals. If your goal is to run on low-powered hardware, PBR might not be best. Currently it gives realistic results, so it's easy for artists to understand (in that it matches the world they live in) and looks "right" to players. But it has limits, like any technique. It's been popular recently because it's been new and effective, when used appropriately.

\$\endgroup\$
  • \$\begingroup\$ Thanks for explanation! So, in deferred rendering by sending a subset of light instead of computing every pixel, it should be faster than forward rendering ? But forward rendering will give more complex lightning information since it calculates in every pixel, am I right ? Also from the comment in my question, related to I write raytracing as a PBR sample. PBR follows the laws of physics on how light interacts with material and raytracing uses ray, ray is a light. So, raytracing, photon mapping, any techniques related to light is part of PBR ? Do I get this wrong ? \$\endgroup\$ – raisa_ Jun 24 '18 at 17:34
  • \$\begingroup\$ No, forward rendering will not intrinsically give more complex lighting behaviour. The actual math performed and output produced by forward and deferred rendering of opaque objects are generally the same. The difference is the order of computation - forward says, "for each object, for each pixel it occupies, for each light affecting the object..." while deferred says, "for each light, for each pixel it affects..." (objects now out of the equation since the previous pass handled rasterizing them into the G-buffer, so we can just work on pixels) \$\endgroup\$ – DMGregory Jun 24 '18 at 18:10
  • \$\begingroup\$ Also see this link for images that give it a bit more context : gamedevelopment.tutsplus.com/articles/… \$\endgroup\$ – Sidar Jun 25 '18 at 0:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.