Now that we have a super cool PBR system in 3.2 of course I will be switching my models to use it. I have a performance question on light probes for environmental reflections though…
Assumptions are always dangerous but here goes …
I assume that if I want accurate reflections I will need a light probe for each model and I will mode it with the model through the scene. If so, what’s the performance hit with say … 1000 models and probes in the scene? If my assumption of needing a light probe for each model is inaccurate please feel free to let me know that I am an idiot and explain how I should use light probes so that all my space ship hulls can have proper reflections.
Screenspace reflections are shnazzy performance-wise, but they do have some pretty severe limitations (can’t reflect something that’s not in the camera frustum and are prone to artifacts in edge cases). Cube mapped reflections overcome this, but they require re-rendering the scene from the PoV of the reflecting object (nasty with lots of reflective objects).
I think you would have just a few probes, and the closest would be used for reflection (unless there is some blending technique I havn’t used any PBR stuff). Inaccuracy isn’t really noticable since you usually don’t need crystal clear reflections (like a mirror).
If you have 1000 objects you are already doing something wrong imo, let alone 1000 probes.
Of course I don’t have 1000 objects visible and un-culled in the viewport. It’s an opened universe space game so there can be thousands of objects in the scene when you zoom out but at that point you can only see planets and asteroids and such as opposed to ships. The reason I asked the question is more for me to understand how the light probes work. Yes I could look at the light probes code but I have not. I imagine that a light probe looks at the env map and passes a snapshot of a 2D texture to the model’s frag shader at the post processing render pass correct? Or is it just a scene post prossesor live say SSAO for example?
EDIT: Never mind on the post processing statement. Light probes are not post processors … so no I have no idea how they work at this point
I’m also poorly versed in this subject, BUT our hero nehon posted 3 really good articles on it, part 3 might tell you what you want, it covers the details of their working, but not how to use them in code so much: https://jmonkeyengine.github.io/wiki/jme3/advanced/pbr_part3.html
My dumbed-down understanding of light probes:
A light probe is sort of a way of collecting a lighting “skybox”, if you will, for a particular area. So you plant your probe, and it will render the scene around you in such a way that it has a cube map of the lighting.
For space, I think you would just process the ‘sky’ you are already using along with maybe the local sun or whatever… but that could also just be your direct light.
Light probes are not for accurate reflections. They are to give a good sense of the ambient light in an area. (For example, in a forest the bottoms of things should be less lit than the tops but not true in a room with a white floor.) For space, there isn’t really any ambient light at all.
What @JESTERRRRRR and @pspeed said.
Light probes in general can be used for precises reflections though. But ours would need more work to do so.
For now they just have a parallax correction (the reflection ange changes when you get closer to the border of the light probe influence area.
But the influence area is a sphere, so in a square room for example, reflection will look off. We’d need an oriented bbox as the influence to fix this and correct the reflection. Also for now your model will pick the closest light prob it can find and use it for lighting. so basically when you switch from a light probe to another you can have a sudden change in lighting. I need to work on a way to smooth the transition.
So to sum it up.
You need a light probe by “area”. There is no systematic way to determine what an area is, but basically it’s a place where the environment presents some lighting singularities (in your case, a whole solar system with a sun, or near a planet when you are at close up etc…)
Note that performance wise PBR might be more greedy than regular lighting. I didn’t make any accurate benches, but it just does more operations in the shader.
It may be of interest that im currently doing a PBR in shader nodes right now. It isn’t quite the same as other implementations however and i’m a few weeks away from showcasing. Also wasn’t really going to release it till closer to our game release date. But i could be persuaded otherwise.
Visually it is erring to the new blender EEVEE to Unreal for performance. The whole pipeline is very unreal like. AABB probes and sherecial ones. Also a decoupling of the SPH and the EnvMap makes lighting the scene much easier.
Share dude. The larger we make the shader node library the more people will adopt it. The JME shader node approach to shaders in my opinion, is the future of JME shaders and PBR is DEFINATELY the way to go instead of phong
The current pbr puts diffuse lighting into a precomputed cube map and is part of the probe that is also used for the specular component. That is, as far as i can tell its hard to completely different sets of SPH lights around the scene with only a few full environment maps which are somewhat more expensive. At least at the precomputation phase.
While Unreal uses a grid (can be a 2d/3d texture) of SPH lights that are independent of the specular environment maps.
I’ll start a new thread and use that as a place to watch and update. However its still going to be some weeks before its close to first public release.
Not anymore btw, I switch to 9 SH coefficients stored in vec3. But they are still part of light probe and tightly correlated to the specular prefiltered map. I’m eager to see how the system you describe work.