I have a very very frustrating issue: in any indoor scenario, even just inside a walled cube, I get light bleeding through the walls both from the directional light (sun) and any lights in the scene that bake lighting.
I decided to tackle the baked lighting bleed issue first to try to not confuse myself. I read up a bit on how UVs work and to me it seems to be a lightmap issue, but I don’t know how to solve it. In my simplest test I made a model in Blender, 4 walls, each is a cube, no spaces between them (used vertex snapping). Did the Smart UV project (0.1 islands) and exported to UE4. On import I leave the checkbox checked that allows UE4 to auto generate lightmaps and on the mesh the UV for channel 1 (second channel) looks nice and clean. I think there is something I might need to change in the mesh properties to tell UE4 to actually use its own generated lightmap, but I’m not sure… any help would be greatly appreciated.
As far as I read, if the destination lightmap channel is set to 1 and the previous LM channel is 0, then building lighting stores the light bake in channel 1. There’s one more setting for destination channel in the mesh editor, and it is under the advanced expansion (with the down arrow that has a line over it) for one of the sections of the details panel. There’s a few other things that are said to be common causes of light bleeding / leaking. Check these:
Volumetric Lightmap and its settings
Light Propagation Volume (if there is one, its settings are in the Post Process Volume)
Skylight settings
Lightmass in World Settings
Is the scene using a scene captured cubemap, or a custom specified cubemap in the skylight (if there is one)?
Are the meshes involved set to static, stationary, or movable?
To make things simpler I have recreated the cubic room out of one solid in Blender by extruding and combining faces. I’m sure there are no double vertices.
In the mesh editor there is “source lightmap index” and " destination lightmap index, set to 0 and 1 respectively. I assume this is correct. Further down in the panel under general settings (under the drop down arrow) there is “lightmap coordinate index”. I assume this is the setting you mentioned. Setting this to 1 does indeed make a difference in that now it looks like it is actually using the UE4 generated lightmap instead of my Blender UV map. Bleeding still as bad as ever unfortunately.
No lightmass importance volume for this testing scene. I did find a setting in world settings under lightmaps where I can “Force no precomputed lighting” and that solves everything, although I have this feeling all light are now handled as dynamic (correct me if I’m wrong) which is not good for my actual project performance.
This definitely seems to be something with the lightmaps as it only happens with baked lighting…
Pics to showcase the horror! Outside cube, inside cube on side with light and then inside cube on side with no lights. The cube is split in two on the inside to test the light bleed. No skylight or any other lights accept the point light set to stationary inside the cube on the one side.
“Force no precomputed lighting” does change it to dynamic lighting. Although, it could be retaining some aspects of baked lighting in the settings, yet not using lightmaps that were generated before the “Force” dynamic action. I think it comes down to testing some settings with respect to the volumetric lightmap, global illumination, and the skylight. There’s shadow and light bias settings, also for directional light, that are specifically referenced in the docs as used to remove light leaking / bleeding. I would go into more detail about what I read, but it probably wouldn’t be comprehensible to you currently. Uncheck “Force no precomputed lighting” to bring it back to baked lighting, and rebuild the lighting. But before rebuilding light, do a few things to start testing:
Rebuild all reflection capture probes
Click recapture in the skylight, far down its details
Reduce the number of bounces for the scene’s indirect lighting to 3 or 4 (to start)
Reduce the skylight’s number of bounces to 1 or 2
Then rebuild. See if there’s any reduction in the light bleed / leak after that.
Another question: is there any color bleeding from one or more areas to other area(s)? This really needs to be a procedure for trying / testing, which makes it easier to track what works and what doesn’t. You could change the lightmaps numerous times, and it could still be another parameter or feature that is combining with it to produce the artifacts.
IMO very confusing and unhelful replies/comments so far! :S …maybe people who have no clue about static lighting shouldn’t comment… :S You guys just direct people to a wrong direction and confusing them!! :S …sad…
Your lightmap resolution is too low!! Your lightmap compression is still turned on?
…if you could show the lightmap uv…
…also your lightmass settings and what quality are you trying to build…
If you want detailed lighting result you’ll nedd to use the importance volume…
How would lightmap resolution and lightmap compression on cause light bleeding? I’m going based on the docs to check VLM, LPV (not lightmass importance volume), and global illumination, all of which have excerpts about how to avoid or reduce/remove light leaking and bleeding. Global illumination picks up static, baked lighting in lightmaps and spreads it. How else would it work in static lighting? Please don’t slam my attempt at helping to try and justify your own repetitive suggestions. It’s more than likely the OP is going to listen to it all anyway.
I’m sure you have a big experience in archviz lighting… no I’m not… Reading the documentation WITHOUT experimenting helps nothing!! I’m sorry but you bring people into the woods and confuse them with your answers… you’re also confused what is static and stationary lights…
BUT as I’ve said: this is only my opinion!!
So as I’m sure you already know this: “lightbleeds” are usually not light passing through BUT lightmap getting wrong information!! And usually what’s causing it is wrong lightmaps!
As you can see on the screenshots the uv’s are wrong, shadows are pulled over to lit parts…
Also the blockiness is caused by the low res lightmap + compression AS USUAL!
Those screenshots are of a test cube he did in Blender, quickly, and exported to UE using a point light inside at the corner (where it may be overlapping the exterior and causing the shadowing being pulled to the other side, or the blockiness). I experiment, and I read the docs, and no I don’t have a bunch of experience in archviz lighting. But I don’t start with the same suggestion that lighting artifacts are caused by lightmap compression being on and low res lightmaps, or even bad UVs in every post I write to try and help. There’s a number of factors involved in lighting, and in the documentation it is obvious that a number of settings can produce artifacts depending on the lights in the scene and what their settings are.
Check this Eden, in the Lightmass Global Illumination page, it states that two settings control for the shadow penumbra size (which is how the shadow edges transition from sharp to blurry / soft). The shadows in your screenshots are blurry on the one heavy-shadow side, at their edges. Here’s the excerpt from the page:
“In the first image is a Static Directional Light with only static lighting, the penumbra size is the same everywhere. In the second image, Lightmass calculated area shadows whose sharpness is controlled by both the light source size and occluder distance. Notice how the shadow of the pillar is much sharper close to where the pillar meets the ground.”
It’s not required to have high lightmap resolution with all static / stationary geometry. That is the point of LODs (level of detail) and of having global illumination and ambient occlusion settings. The indirect lighting is stored in the lightmaps, and shadow maps are generated which are used in the various shadow features (distance field shadowing, cascaded shadow maps, ambient occlusion, and volumetric lightmaps). Light Source Size and Occluder Distance are settings in a light (such as directional, which is often used for the skylight or in conjunction with it), and control for the shadow transitions at their edges. It’s used to get soft area shadows, or sharper shadowing that is not predicated entirely on UV lightmap resolution. Not everything in the engine is geared toward ArchViz, and is actually a newer development for Unreal since it started as a game engine decades ago.
It is evident that your scene is experiencing technical problems with the lighting somehow, and simply turning off lightmap compression and increasing lightmap resolution, I highly question, that it’s going to solve the problem. Those are two definite answers to certain kinds of artifacts, and I have used both to solve problems. But I’ve also encountered where using both of those didn’t solve anything, and shadows looked awful while lighting was having issues too. The thing I keep seeing with UV lightmaps is the layout generated has to maintain spaces between all polygons of the UV lightmap. Another is if it’s enabled, having lightmap errors color coded shows colors in the lightmap after building lighting. But that by itself isn’t going to determine the exact cause just by staring at it unless you’re an expert.
Thank you so much for the help people! Although the two of you do seem to have had a bit of a misunderstanding, your two very different ways of approaching the problem coupled with your interaction is in my opinion very helpful!
I am no expert in lighting and have only recently started using Blender (since 2.8). I have a tiny bit of experience in 3D software, but completely new to UV and lightmap aspects of it. I have learned how to do the texture UV at least. In a simple setup like this it just seems impossible to me for this issue to be present, especially at this scale. Requiring tweaking for this is very frustrating… Ok I ranted, now back to it.
Preston: I set light bounces to 1. Removed skylight, directional light and skybox to simplify everything. The point light inside the box is not overlapping the mesh. I adjusted penumbra size both ways. Results are still the same with tiny differences.
MakiGirl: Added importance volume, lightmap compression turned off, problem still there. Raised the lightmap resolution from 64 to 256 as well.
I can’t help but get the feeling something is wrong with my model! Would I be allowed/able to attach my raw blender model file in this forum for someone to download and see if I missed something very basic?!
I reverted all settings except for the lightmap resolution as I do understand the worry about it being too low. Screenshot of the scene attached. My actual project uses small single floor building for the game level and there I have the exact same type of problem.
Thanks again for all your help, I really really want to get past this!
Just for your information when you set the lightmap resolution it’s in pixels… as any other maps, just like texture maps!
So this is your current resolution (256) on your lightmap to let you show how low res it is still… IMO!!!
…and this is your main wall’s lightmap in pixels (!!) again! …just imagine how it would look as a texture map on your mesh…
The same stands for the lightMAP too!
Also areas that have smaller than 1 pixel information will not get information. The way you keep the uv islands for your wall pieces together (1 inner and 1 outter face) with low res lightmap will generate “random” looks…
You can keep only the visible parts on your lightmap to get a better resolution /those part will be never visible anyway/!
…also I’m not sure if you’re using lightmap compression…
Yes, you can attach the raw Blender model file in the forum. Use the Attach tool. Is it an FBX? Sometimes settings from Blender do not carry over to UE, or ones that are not correct for UE carry over to it…such as the normals. Blender and UE use different XYZ axis references. In Blender I think it is X and Z are the horizontal planes, while Y is vertical. In UE, X and Y are horizontal, and Z is vertical. During export, you’re able to select which direction each axis translates to in the file exporting. Not changing it probably means that model is exported into UE with the wrong orientation / reference planes, and that would damage / mess up a set of texture UVs. I’m not sure if it would screw with lightmap UVs.
Actually, generating lightmap UVs in Blender, and then exporting to UE, then generating lightmap UVs in UE could become a problem. How, I do not know exactly. You should read up on it or even look for a youtube video. I’ve seen that videos are in youtube search results for it. But a simple set of instructions would be easier, IMO!!!
Thank you for the tip on the unnecessary planes that will not render so do not need lightmap UV.
I have rendered the scene with a lightmap resolution of 2048. The edges are smoother, but the problem is still there. I do not have a few pixels light bleed. I have half of the plane bleed, like 1 meter segment.
Upload it to a cloud sharing site such as dropbox or another free one, and then post the link here. I have Blender 2.8, so a .blend or .fbx would work. I don’t have 7zip though, and have had trouble lately with unzipping zip files…so it’s quicker to use the .blend or .fbx versions.
Something is definitely wrong here! New project, imported with default import options. Horrible! My light is unchanged (stationary). I did lighting build on preview quality.
