0
$\begingroup$

Most of the PBR tutorials out there use HDR maps loaded from disk. But in games these maps need to be generated by taking snapshots of the scene from the objects location which is where problems arise.

Let's say there are just 2 objects with PBR material a sphere and a cube.

Here are 2 problems I come across

1)Each of these 2 objects need an full 360 degree view of the scene around them stored in an cubemap for proper IBL implementation which means for just 2 objects we have to render our scene 12 times!!![6 times to fill the cube map of each object] which is ridiculously expensive and this is just for 2 objects. Is there an alternative to this especially in dynamic scenes where objects move around all the time?

2)If the sphere and the cube are very close to each other then the color of one object will depend on the light reflected from the other and this light can bounce an infinite number of times between the objects. This can be solved using recursive ray tracing where we control the bounces using an depth variable. Is there an similar recursive approach for the raserization pipeline ?[Similar to 2 mirrors facing each other and reflecting each other problem]

Some theory, ideas or maybe some linked articles would be of great help

Improve this question
$\endgroup$
4
  • $\begingroup$ Conceptually raytracing is the same as rasterisation you just do one sample instead of multple. So you can forego doing all the rasterisation setup and caching. Yeah you can do recursive rasterisation. But really this is why we are allmost inexorably moving towards raytracing. So answer to 1) is yes its called raytracing. $\endgroup$
    – joojaa
    Commented Feb 14, 2021 at 12:54
  • $\begingroup$ But how would you cache the previous render? If lets say the sphere gets rendered to the cube's frameBuffer and the cube gets rendered with pbr. Then when the sphere is being rendered it would have to again wait for the cube to complete its pbr calculations but then the cube would have to wait for the sphere to complete it's calculation and then....to infinity??. When the cube is rendered to the screen how would i cache that result so it can be used by the sphere. Sorry for the twisted question but i'm very confused $\endgroup$
    – Sync it
    Commented Feb 14, 2021 at 14:41
  • $\begingroup$ Dont you mean answer to question 2) is ray tracing? But for older computer's like mine what would be the nearest rasterization solution? $\endgroup$
    – Sync it
    Commented Feb 14, 2021 at 14:43
  • $\begingroup$ there is no solution. You would simply avoid this calculation $\endgroup$
    – joojaa
    Commented Feb 14, 2021 at 14:50

1 Answer 1

Reset to default
2
$\begingroup$

There are no easy answers here, if you are serious then it is possible to replace cubemaps with hemispherical maps, which result in just 2 offscreen renders each instead of 6. They are not popular because the math and setup are nontrivial. RTR4 has references to papers. If you get that working do a writeup here please! Look for Dual-paraboloid shadow mapping.

Another solution is to only update your maps every other frame, or every third frame. So if you have say 12 maps, then update 4 of them each frame round robin style. Also frugal culling can greatly reduce the number of faces that have to be rendered but quality is reduced. I see so many implementations that render all the geometry in the scene to every face when much of that geometry is outside the frustum of that face. This alone can increase performance but scene complexity will play a major role in overall performance.

As far as infinite reflections is concerned, think about that for a second, infinite rays is going to take infinity to render no matter what your technique is. If you manage to trap photon's in a perfect reflector in real life then you can't observe it because observing it destroys the perfect reflector. I'm not trying to be sarcastic, I'm just giving a reality check.

But simple techniques can get good reflections in real time. Screen Space reflections are tricky little buggers to get right but when done well can yield very nice results. You don't see many implementations around because there are a lot of corner cases to consider. Again if you get a good implementation of this working, please share it here!

What you are implying in your post sounds like you would, at the very least, have to do reflections against all the cube faces, this too is not realistic, even on the best hardware, your computes are better spent someplace else, like ray tracing...

Improve this answer
$\endgroup$
3
  • $\begingroup$ But how do games implement pbr without using HDR maps loaded from disk. What's their technique? $\endgroup$
    – Sync it
    Commented Feb 15, 2021 at 3:06
  • $\begingroup$ By using all the techniques describe here plus others, some ray tracing can be done in the fragment shader, replace point lights with spot ligths, "one large light is worth many small lights". I recommend looking for post mortem presentations for games on the net they are usually pretty open about the methods they used. gamedesigning.org/learn/postmortem $\endgroup$
    – pmw1234
    Commented Feb 15, 2021 at 12:15
  • $\begingroup$ Another approach is to pre-render "deferred" cubemaps, where you store the albedo/normal/roughness/etc of the surfaces, and load those from disk and only recompute lighting on them while running the game. That is much faster than fully re-rendering the cubemaps but allows changing lighting conditions (especially time of day cycle in open-world games). It does not allow the cubemaps to update with dynamic objects though. Most AAA games simply do not render dynamic objects in cubemaps. They cheat around it with SSR, SSAO, etc. $\endgroup$
    – Nathan Reed
    Commented Mar 17, 2021 at 0:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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