Do you think we could get a material node to access the new volumetric lightmaps (with a “Position” input to specify where to sample it)?
I’ve only been using 4.18 for a week but run into a couple of situations already where it would be really useful. First I was making rain, and thought it’d be great if I didn’t have to use the full-blown expensive surface translucency lighting in order to get some form of lit rain (and not really have much control over it) - with volumetric lightmap access we could fake that kind of thing really cheaply (and exaggerate it too). Similarly, I was also trying out a cheap custom PP fog solution and being able to light it with the existing volumetric data would be great.
But yea… mainly I can imagine using it to fake cheap lighting on a variety of unlit materials, and do exaggerated/stylized lighting too.
As a note though, keep in mind the volumetric lightmap data is a tree so open areas would have very chunky data as it gets away from geometry - if you’d want your rain to get lit up by a spotlight for instance. But agreed, this would be great to have access to.
There are multiple translucent lighting methods. Just try non directional vertex lit. Problem with volumetric lightmaps is that it’s only indirect portion of stationary lights. So sun and spot lights would be missed from rain. For small particles like rain drops that does not cover huge on screen there is not really a need for that kind of optimization.
Materials are supposed to describe material properties like roughness, reflectivity, etc, and should be decoupled from lighting. Exposing light sources to materials would couple the two together, preventing us from integrating other features correctly (shadowing, deferred shading, decals, etc). We do not support custom lighting and keep it that way so that we have full control to optimize lighting as needed.
That said, you can modify the engine code to do whatever your project needs. You can easily add some shader code to access the volumetric lightmap in a material. Have a look at GetVolumetricLightmapSH3 and GetPrecomputedIndirectLightingAndSkyLight.
Ok… I can accept why Epic wouldn’t want to officially support custom lighting (and lighting data isn’t available in deferred etc), but I see this as more of a case like Mesh Distance Fields (just useful static data that we can access) - isn’t the volumetric data essentially 3D texture that gets generated at build time? That would be very useful to access for all sorts of uses… and wouldn’t affect how you integrate other features… or am I underestimating the complexity of the data?
For example (ignoring for a moment the practical possibilities for optimisation or stylization) the volumetric data could be used to have moss grow on materials where it is well lit, or change the appearance of vegetation in different lighting, so it could help workflow or consistency too.
If it’s just the principle of not allowing access because it’s considered lighting data… I dunno… It’s kinda like if you hard-code-prevented users in UE3 from doing “fake lighting” with unlit materials, simply because materials “shouldn’t define lighting”… when in reality it’s just a useful thing to be able to do and probably 100% of projects did that either for optimisation or artistic reasons… you know what I mean?
I get that we could implement it ourselves too, but I love to help this engine be as generically useful as it can be. Personally I only ever suggest a feature if I think it’s useful for more than 50% of projects out there / improves the baseline possibilities in the engine without too much effort. And I just think this is one of them.
I also understand the intention behind decoupling the systems, but +1 that this would be a super handy thing to be able to use in the materials directly. Currently I am using a material parameters collection to pass useful data to the materials, but if there were a more direct way of getting the lighting data that would be great (even if it’s not this particular request). We use this data for stylistic purposes, faking additional rim lighting that takes into account the main local light source.
In my case instantiating, getting a pointer to and keeping the collection current all seem quite a round-about way to get the light color. Is there a better way?
There is no point to expose just random part of lighting process to material editor. Lightmaps are not exposed. Any direct light is not exposed. So why indirect part of diffuse for movable objects should be exposed? Why just that?
99% of the time it’s a good indication of what light exists in an area (you can see that by just looking at the visualization samples in the viewport) - that information is pretty useful, and it costs a lot of MB to store, so personally I think it’s waste to keep it locked away. I’ve discussed this with several other experienced tech artists in chat who also think it’s a great idea and would be useful. But if you don’t understand how it’d be useful, thats ok.
Lightmap UVS are actually a geometry attribute and not lighting. They are used to map the lighting to the surface, but they describe the surface. That is the role of materials - describe the surface, and how it interacts with light. Then the renderer can combine that material with light sources in an efficient way to compute shading.
There are some other exceptions though where they are not fully decoupled: material ambient occlusion, AO Material Mask. These cause a lot of problems due to the coupling. For Material AO, we have to store it in the GBuffer which decreases performance, even though it is rarely used. For AO Material Mask, it’s only available in the Base Pass but not in the depth only or Shadow Depth passes. So for example if you use Material AO in your opacity mask, the passes will not match up and things will go poorly.
Bottom line - materials describe how a surface interacts with light, but should not do the actual lighting. However, you can modify the engine to do whatever stylized behavior your project wants!
Another inconsistency is the precomputed AO mask. It works fine for shader access from regular lightmaps, but not for volumetric lightmaps. Is this intended?
