Volumetric Lightmaps without baking shadows?

Development Rendering
1

Hello,

is there a way to only use the Volumetric Lightmaps but not the baked shadows? (Building VLM with a dynamic light).

I would like to use the VLM, but i have no interest to fiddle with baked lighting/shadows at all. (Its simply an awful workflow, and i dont have the time to deal with it. (it takes eternities, even on my Ryzen 1700X with 8 cores at 100%))

Technically, I see no reason why it should not work with a Dynamic light that is casting shadows. (of course the VLM would not update when the light moves, but i have no intent to do so.)

Thanks.

PS: I practically managed to achieve this, but I still had to build shadowmaps to make it work, but then i could use another light source without loosing the VLM/ILC.

2

No, it’s entirely based on precalculated lighting.

3

he still wants the precalculated lighting.
he wants to dismiss the shadowmaps and just make use of the volumetric lightmaps (I guess to have some sort of statically-baked indirect lighting information to use alongside the dynamic lighting)
the effect would be such as if you would bake your lighting and then hide all the static geometry and replace it with movable versions of all of it, then turn off the static light and turn on a dynamic light.
I guess the result could be weird if your lighting is ever going to suffer any changes but if you never intend to change it (and just want to do this to avoid having to do lightmap UVs in your meshes) I don’t see why it wouldn’t work

4

He also said he doesn’t want to spend the time to setup objects for baked lighting or spend the time baking it, which isn’t an option, the objects would need to be set up for lightmaps for any results to come out well and you wouldn’t be able to get volumetric lightmaps without doing a proper baking.

5

ah yeah he’d still need to bake the lighting of course
but if objects aren’t set up for lightmaps (i.e. lightmap UVs) does that invalidate the photon emission/bouncing over the VLM?

6

The results in the lightmaps of an object can affect the lighting of another, for example if you have low resolution lightmaps and pixels of sunlight are bleeding onto the inside of a building that will add illumination to the surrounding areas as the light from those pixels bounces to the other surfaces. So if you don’t do the UV’s and the lightmaps end up black or something then that would affect how the volumetric lightmaps would look.

7

@Chosker is right, i want to use the VLM for cheap GI.

I could have written my request better, sorry for that.

I only want to bake the VLM but not the shadowmaps, since the shadowmaps are very time consuming.
It is not planned to change the lighting in my levels on runtime, therefore it would be no problem to have static GI from the VLM and dynamic shadows.

I practically achieved what i want already, but i still have to build shadowmaps on top of the VLM. (just to disable the shadows from the light after baking.)
It is possible to build the VLM without the shadows from the Directional Light, but then everything is too bright, this is why I asked if there is a way to disable the building of shadowmaps. (Since the VLM is calculated via Raytracing it should not be a problem to calculate it based on a non moving dynamic light.)

VLM currently is the best option we have for GI in UE4 (if you dont change your sunlight too much), LPV is bad, SSRTGI is not in the engine, VXGI is nvidia-based and therefore no option (ue4 already runs worse on AMD than nvidia, dont need to make it even worse with vxgi. (I hope this changes with vulkan…))

For me, VLM with a dynamic light would greatly enhance the visual quality of my stuff while lowering system requirements. (And I also would not need to rebuilt lightmaps when i move something around while patching a bug etc.)

Building Lightmaps is so time-consuming (even on an 8core cpu) that I simply cant make use of it in a way that wont break my workflow. (i also get a lot of artifacts with shadowmaps on actors that were merged to reduce drawcalls etc., and I simply dont have enough time to find the issues and fix them.)

EDIT: Pictures of my experiments with VLM and ILC (tried both, both in theory work without static shadows, but picture is ILC)
Technically, VLM seems to work somewhat like the LPV, but it only calculates the one “frame” while building and stores the information in its grid. (i see no reason why it should not be possible to calculate this information based on dynamic lighting, the shadows are still there and can be accessed to calculate the correct information.)

8

Since it ultimately would still require building lighting like normal, the best you could hope for is some way to render lighting at a much lower quality than normal (since the VLM doesn’t need that much accuracy) and then some way to then still use that while disabling the static lightmaps. There might be some way to make lightmass render only save results to the volumetric lightmaps rather than saving the static lightmaps and using them as part of the calculation. Ultimately what you want to do would require changing some things in the engine source.

9

Hmm, did not expect it to be such a “big deal” that it would require changes to the source. (I could even live with the build-times when the engine would allow me to discard the shadowmaps, because the VLM doesnt need to be rebuilt when i move something by 20cm, therefore calculating it once would be enough.)
Thanks for explanation.

I came up with the idea because of the “SSRTGI”-Discussion a few days ago (somewhere here in the forums), and i thought this might be some kind of solution until epic decides to give us proper GI.

EDIT: Currently I use a grid of stationary point-lights to achieve the same, but it obviously is only an approximation by me, not the perfect calculation of light-values. (and it is only usable on somewhat decent GPUs, 1060 3gb or better.)
I still have performance that is far better than the LPV, especially since I dont fill the whole space with lights, but it feels like a “dirty hack”. (but unlike the VLM/ILC i can change light colors, which allows me to have partly-dynamic-fake-gi.)

10

Realistically it could be done, it just isn’t something that can be done simply by changing some settings in the UI of the editor. If they really wanted to, they could make it work really well where the precaculation would be quick, and it could be done for large maps since the amount of data for volumetric lightmaps is way lower than the static lightmaps

11

It could even be partly dynamic.

For a Day/Night-Cycle one could simply bake for every X hours of the day and interpolate between the values (like uncharted 4 did it), even stuff like Cloudy Days would be possible because we simply could interpolate between “normal” baked values and “cloudy” values. (Probably baking of “current world state” would be the best option, so we could bake stuff like streetlamps etc. at night. Alternatively lights could directly affect the stored values around them, but not every frame, only when there is a change to the light.)

Since Epic already has VLMs in the engine, it probably is a low hanging fruit to add this - *if epic gets knowledge about this topic here. (Hmm, i should put “Global Illumination” into the topics title, that will make everyone notice :P)

There definitely is potential in that idea when i think about what it could look like. (especially since i already have a very simplified version of this based on pointlights.)

12

I’m thinking it could be a little bit slower than something like VXGI. It wouldn’t have to be fast enough to run every frame, maybe could give much better results since you could increase some of the calculations without adding too much to the processing, could even do some intelligent level analysis to get the volumetric lightmap samples located in the most important areas and to avoid some bleeding. Maybe some lights could be fully dynamic if it restricts calculation updates for the light to a certain radius.

13

I dont know how fast VXGI is, but you are right, I also thought about “not letting it run every frame”.

There is no need to calculate GI every frame, unless you are removing a light instantly from the scene, but then you only need to calculate the affected area. (actually, unless the sun changes there is no need to calculate most of the samples, do it once, store the values and thats it. When the sun moves it would be a good idea to not calculate all samples in one frame, it would be enough to calculate them every X frames and interpolate between the values - so that you never calculate all samples in one frame -> overall gpu load goes down because the task is spread over time. (just spreading the work over 2 frames, will halve the gpu-load, spreading it over 4 frames will save 75% of the total cost you normally have (per frame))

I personally would not update anything that is not affected by stuff that moves around.

On top of that we could limit the “grid” to the LigtmassImportanceVolume or so, and exclude areas with another volume. (there is no need to fill spaces that are empty anyway with information if the space is never used by gameplay. / what is not there does not need to be calculated. (obviously culling invisible “light points” could yield a few fps too, there is no need to mess with things the player cant see because they are below him. - this would also fix bleeding to some extent.))

I think the biggest problem with most GI-Solutions is that they calculate GI for every frame and for a large area.

14

I’d be keen for this also - there’s already the option to use only volumetric lightmaps per actor/staticmesh, and it works for me, so that’s all I really want to bake. Does anyone actually know for sure that the traditional lightmap result informs the generation of volumetric lightmaps?