Download

How to prevent character and movable objects from being highlighted through walls?

This is what I mean:

Skylight highlights the character and/or movable objects through walls.
And I don’t have flat walls either, they are “solid blocks” 20 cm (units) wide to prevent baked light bleeding.

I checked volumetric lightmaps, and it seems like they don’t go close enough to the wall, so the ones outside take effect instead.

I already decreased volumetric lightmap cell size, but it didn’t solve the issue. Decreasing it further could affect performance.

I tried to put Volumetric Lightmap Density Volume and set it to 0,0 as it says in the tooltip, but regardless of how I set it up, all it does is completely removes the “spheres” from the area and makes things worse.

So, how can I fix this?

They need to be a lot thicker than that to prevent bleed from the volumetric lightmap. By default the probe spacing is 2 meters apart and they don’t store any sort of occlusion so they’ll just interpolate straight through walls.

The distance between probes can be reduced by lowering the “Volumetric Lightmap Detail Cell Size” (it’s in centimeters, so a value of 200 = 2 meters). Just keep in mind that the memory cost of the volumetric lightmap scales cubicly…

In my opinion the best option is to simply design your environments under the assumption that areas with strong lighting differences will need to be spaced far apart. But if that isn’t an option you could try falling back to the legacy method by setting Volume Lighting Method to “Sparse Lighting Samples” and see if that produces a better result.

My usual workaround for this is to make “light blockers” - simple cubic meshes with unlit black material. I place them behind walls to prevent light bleeds and volumetric lightmap issues.
However, it’s not a great solution when there are windows, for example. Or if there is an environment outside of the interior - it looks silly when a house has 2 meters thick walls.

I thought maybe there’s something better that I can do…

Also, what’s up with Volumetric Lightmap Density Volume? I never could make it work. It just completely removes volumetric lightmaps from the area, no matter how I tweak it.

What about re-positioning the light so that the volumetric blip behind the wall is correctly lit? The light doesn’t need to actually sit where the torch is - at least, not necessarily…
You could also have to move the whole wall/lights to get that to work. Depends.

Basically this

In another sauce.

The tileset I’m working on is 3x3 meters. So I thought, if I place the tileset on the grid correctly and set volumetric lightmap detail cell size to 150 then they should match perfectly!

Unfortunately, the engine has different plans. And it always places volumetric lightmap samples off-grid no matter how I’m trying to line-up the entire level. They are still exactly 150 cm apart, but never line up with the grid or with the level - on one side of the level they are close to the walls inside, on the other - they are close to the walls outside.

I just find it weird that there’s no way (not that I’m aware of, at least) to locally increase samples density in areas that have problems. As I mentioned before, Volumetric Lightmap Density Volume doesn’t work.

That’s like a guarantee 99% of the time.
At least it’s not just my studio :stuck_out_tongue:

You know, this could be an issue with the build derived from bad math.
Are you mathematically 100% sure that this is the case?
IF it was, then at 0,0,0 you’d see different distances between the visualizers - a large gap.
It would really be evident, as you’d have a space of 3m in between the way you describe it.

The volumetric samples are lining up to be 1,5 meters apart as I set in the settings, yes. I can line them up perfectly with my tileset, that is 3x3 meters, as I mentioned.

But after I rebuild the light, the samples move to the positions like on the screenshot in my previous message. Still 1,5 m apart, but not in the positions I want them to be.
The engine doesn’t seem to like the samples to be inside geometry, so it tries to move it in a way to have as little samples as possible clipping into something. In this case, that means that it moves all of them (the grid they are lined up to) 20 cm to the side to avoid colliding with my tileset.

I think you are sort of misunderstanding.
Not really your fault as much as how UE4 works.

If you place the wall at a 1.5m intersection, you will cause the grid to shift.
If you were to place the wall at .75 of that (so exactly in the middle) then it might still get the grid to adjust, but it should have the samples split correctly left and right (provided the wall isn’t 1.5 meters wide)

@Arkiras Correct me if I’m wrong.

I tried moving the level around. The samples move and assume the same positions relative to the level every time I rebuild the light.

If you move the whole thing, that does make sense.
What about just the individual wall though? Does moving that to a value that falls at half the value of the volumetric lightmap cause it to shift - or does it render properly?
It works for me, but I have the value set to 1m…

Well that would defeat the whole point of tileable geometry, wouldn’t it? :smiley:
It’s easier to just use “light blockers” as I’ve mentioned before… I was just curious if there’s a better way of handling it than fiddling around with geometry and rebuilding light until a miracle happens.

… If you need to build lights, or use LPV, not really.
Most of us use full dynamic.

Some use the Loushang lightmass.

The engine also added a derivation of this on which apparently Loushang has been hired to work on. IDK. read the thread.
IF you need to bake, that’s probably your best bet…

  1. With regard to probe placement, as far as I know the VLM positions itself with your lightmass importance volume (for GPU lightmass I assume it just uses the level bounds maybe?) so if you move the lightmass importance volume, the probe positions will change. But if you are just moving walls around the grid should stay fixed (again… AFAIK)

  2. I have found that ideally you should be placing walls directly between probes in order to minimize the light leakage. It’s not perfect though


  3. Did you try switching the volumetric lighting method to sparse volume samples as I posted above? I find it handles occlusion better in some cases.

Honestly, light leaking is a plague on gamedev. Most games have to deal with it in some form or another and historically the solutions have been to design around it, using things like thicker walls, quarantining the player from leaky areas, placing darkly lit areas far away from lit areas, etc… Some games even make their dimly lit interiors completely separate levels from their exteriors and hit the player with a loading screen.

If you manage to come up with something better I would love to hear it, I’ve sunk a lot of time into dealing with this problem but I wasn’t able to come up with anything better than the time tested “make it thick” strategy.

Newer games have come up with some interesting solutions for handling various kinds of leaks but usually they require artist intervention, such as manually placing additional probes and occluders. Epic in general doesn’t seem to be big on solutions that create more work for artists/designers.

@MostHost_LA mentioned this solution, and when I tried it didn’t work. I must’ve messed something up. Because I tried moving the whole level again to better line up with probes, and this time it went fine.
I must’ve accidentally moved the lightmass importance volume with the level the last time.
Still not perfect, but waaay better than it was before.

This solution doesn’t work for me, unfortunately. Because I’m making a modular tileable geometry aligned to 3x3 meters grid. So everything “snaps” together perfectly on the grid. So having to move walls around to match the probes defeats the whole purpose of modular tileset :slight_smile: However, as I’ve said, setting VL detail cell size to 150 and moving around the whole level helped a bit.

Yeah I remember fiddling around with that in other projects. Never satisfied with results.

In any case, thanks everyone for suggestions! :slight_smile: Now I, at least, got a bit better results.

Ok so, here’s some news…

I was working on my scene, added a bit more space. After building the light to test lightmaps on new objects, I’ve noticed that volumetric lightmap samples are off again!
God dammit!
It’s so inconsistent, unreliable and annoying!!!


Now I have huge gaps of missing samples under some parts of the floor.

So, I thought… Since the ■■■■ thing doesn’t want to work properly, maybe I can trick it? I decided to place some cubes in the areas with missing volumetric lightmap samples.
And it actually worked!

Of course I would gladly have some better solution, like the one @Arkiras linked from the developers of Ghost of Tsuhima. But I’m not a tech wizard and have absolutely no idea how to make something like that.
So, this little work-around will have to do.

Hey man.
Did you see the Nvidia rtx real time thing they shared today?
Just saying… if it works (doubtful) … then maybe there’s no need for any of this :stuck_out_tongue_winking_eye:

I have a “red” one in my PC :upside_down_face:

… if you are in the US I suggest Newegg shuffles.
Though I have to he honest, the darn bundles and the MSRP on stuff still feels like armed robbery >:p
The best option is still waiting in line at EVGA directly, if they ever open up some extra production and allow selecting some more peoducts… ever…

Meanwhile you aren’t missing much - we spent the past month having to re-install Nvidia drivers every morning at the studio just to be able to work.
They introduced some sort of bug where multi display plus HDRI/4k screens would randomly cycle on and off.
So idk man.

If you can’t trust them with their own darn drivers, can you trust them with engine code? :man_shrugging:

Unfortunately, my entire rig is outdated by now. If I’m to get a new video card by some miracle, I’d have to swap the motherboard.
I’ve checked how much it would cost to get a new PC, and it’s beyond $3k. So… yeah. I can only dream.
My RX 5700 XT choking so hard when I’m working in Mixer with 4k textures. And my old i7 can barely keep up with ZBrush.

The problem right now is DDR5…

I9 12th gen is $610.
An Rog similar mobo is $400.
A 1000w psu is $75(to $110).

A water cooler for the cpu is $120.
A regular one is $50 (and probably cools better but not when you have to use zbrush. Go with water).

Up to here, $1240

128GB of ddr 4 can’t possibly be all that much - $600?

But it’s still a wasted expense because ddr5 is better - I can vouch for that. Even just 32GB is better than 64GB ddr4 on the (probably being recalled) ROG maximus 690 hero. And the cas timing of the ddr4 is supposedly a lot better.

The bottleneck is the $2k plus on the GPU.

Otherwise you can buy used. Thing is, all used stuff is already dated. For example, I have an i5 kaby lake with an rog formula 7 and grx 1060 put aside for testing, which is basically made up of scrounged leftovers.
It can do pretty much everything the new one can - you just have to wait longer for it to do it.
When sculpting details in zbrush on 16b poli… that’s really not what anyone wants.

Any way, we should probably get back to your actual problem :stuck_out_tongue:

Ps: I forgot the hard drive.
Samsung Evo 980pro - 2TB $300. Cheapest/best speed I have seen.
That does put the ram-less base at $1.5k

And technically, you may need a case.
Buy a good one. Corsair obsidian or similar - read rating. Get a Full or bigger. I haven’t changed cases in 10 years or longer. Even at $400 each they made up for the expense 1000 times over…