Lighting not built message shows after hitting play

I had a project in 4.76, and after I converted it to 4.9 this error started popping up. It also happened when moving from 4.7 to 4.8, which is why I didn’t make that switch first. It doesn’t happen in all of my scenes, just the majority of them, especially the larger ones.

Essentially, I load into a scene and everything seems fine until I play the level, then the unbuilt lighting message pops up. If I stop playing, it goes away. If I rebuild lighting, everything works right, no message either during play or otherwise, until I save and reload the level, then it acts as before, showing the error message if I hit play.

I found several similar questions, but none of the solutions helped here. No terrain/foliage is in use, and while my levels use construction scripts, I tested removing all blueprint functions from the levels and it still occurs. I deleted basically every temp file associated with Unreal and no change. My UE4 installation is verified and proper. Migrating the scenes into a new project migrates the error with it. Using DumpUnbuiltLightingInteractions just gives a list of assets flagged, removing them doesn’t actually fix the issue, and is also really difficult/painful in a large scene.

I did a test, and it appears that some of the models in my scenes are broken in some invisible way. Rebuilding the affected scenes with exactly the same layout and with exactly the same assets does appear to fix the issue, but I have like 30 scenes all built with modular assets (i.e. each scene is made up of like half a thousand parts). This would basically be building everything again.

I managed to build a stripped down test scene where I can show the error with just a basic scene containing nothing but a few static meshes and a blueprint that I use as a pseudo-light source, that is just a few static point lights and a mesh. I would really appreciate if any solution, work around, or at least some way to identify the affected actors so I can replace just them, rather than the whole level.

Here’s a link to the example project if needed: Dropbox

It is just a project containing two example scenes, the one with the bug that was originally upgraded from 4.7 then migrated to this project, and a copy of that level I rebuilt from scratch that doesn’t seem to have the bug.

In puzzle_3, you should have the error, and if you rebuild lighting, it goes away, but then if you save and reload it comes back. Rebuilt is just the same thing, but was never upgraded from a previous version, made the level in 4.9 and that’s it, and doesn’t appear to have any issue, just to show that the assets themselves are fine.

I did wait for this to be fixed. I completely skipped version 4.8 because it was happening there too. Now we’re a full version past and it still happens. It seems to be a problem that emerges when upgrading projects between versions.

EDIT: To clarify, I’m not referring to the lighting being rebuilt, I mean the level was re-assembled using the project assets in 4.9 and no “lighting needs to be rebuilt” error presents itself. The levels that were assembled in 4.76 then converted to 4.9 have that message pop up during play that re-occurs every time to load the level, regardless of how many times you rebuild the lighting.

This is why many developers stay on a version thats working for them. Wait until 4.9.1 or later till something like this is fixed since its obviously a bug since you say re-building it from scratch entirely fixes it. Submit it as a bug so that the staff can look at it.

Looking at your project I see no errors after building lighting at preview quality in puzzle3.umap and puzzle3rebuilt.umap works right out of the box so its either a bug, your project, or your hardware. Try verifying the engine and trying, otherwise try reinstalling it and trying.

Don’t forget to accept an answer that best clears your question up or answers it so when the community finds your question in the future via search/google they know exactly what you did to fix it/get it going as well as keeping AnswerHub clean so that it gets removed from the “unanswered questions” category.

Hi Daelus,

I’m able to see the issue you’ve described in your project. At the moment I’m going to have to see if I can recreate this in a fresh project from 4.7/4.8 and convert.

Something clearly isn’t being saved correctly though in the converted project since it lists ~1500 meshes that aren’t being built, but there is only 161 static meshes in the scene.

I’ll update you once I know more and get a ticket in. If I have any further questions, I’ll post here.

Thank you!

Tim

Thanks for looking into it Tim.

I spent the better part of 6 hours yesterday trying to find solutions. I did find that in the test scene modifying the light tile blueprint to use 1 light and have it offset from the surface 150 units instead of 50 will appear to work, but that only seemed to work in the test scene, not any of my larger levels. I suspect that’s just pure luck, but maybe it’s helpful. I don’t know.

Just to give you an update.

At the moment I’m not able to reproduce this in a blank project that was made in 4.7/4.8 and then convert it to 4.9. It may be something that was corrupted in the map that may be harder to reproduce.

Rebuilding the map as you suggested is one way to get around this. So that you do not have to go through the extreme of rebuilding your map you can also use the File > Export > and save as a .t3d file. This file type will save the position of where objects in your content browser should be placed in the world. So long as the referenced asset is in your Content Browser it should be placed back in your level.

I know this doesn’t resolve the issue that initially error, but it may be one of those fringe cases that’s harder to track down. If I find anything else I’ll update this post here.

Unfortunately, this doesn’t seem to fix the error. Whatever is causing it stays with the export. I opened the affected level (puzzle_3), went to file>export all>XXX.t3d (also tried directly selecting and using export selected). Then opened a new level, imported the file and it acts… strangely.

It immediately tries to save as puzzle_3, rather than as a new map if I just ctrl+S. If I ‘Save As’, giving it a new name, the map saves, but the viewport appears to go completely blank, with nothing but black rendering in the scene, but still a full world outliner. Reloading it fixes this, but either way it still exhibits the lighting rebuild required bug.

I also tried exporting as a .t3d from the 4.76 project, and importing that in 4.9, but there was no difference with that.

Not sure if it helps at all, but here’s a link to a 4.76 version that you can convert yourself. I tested converting it and the bug is there. LINK

It looks like there is something very specific with this setup that I’ve not been able to recreate. I’ve narrowed down that it has to do with the light being too close to the tile with the light radius, but creating a new tile with your plane asset has not been able to reproduce this on my end. Unfortunately, without adequate repro steps to do so in a new project it’s likely the bug would not go anywhere or be marked as minor/won’t fix due to higher priorities.

Using your test project I can see the warning when converting to 4.9.

I’ll continue to look into this when I can, but it may be quicker to rebuild the level at this point.

If I make any head-way I’ll update you here with what I find.

Not to necro something that’s a little old, but I found a work around that seems to function so far. I think the problem lies with blueprints that have lights as child components, rather than the root component. What I’ve done is create a blueprint that is just the light with all the settings I want, then use a blutility to find all ‘light tiles’ that would have previously had these lights as components, and add them for each as separate actors in the scene. Now I have 4 actors in my scene instead of one, but everything works as you’d want it to.

Not solving the issue, but maybe a good work around if anyone else encounters it, and maybe it points towards where the actual problem is.

I’m glad you have a workaround for the time being. I re-tested this trying to use the light as the root and child components and a few other variations, but did not get the same results with the warning. Hopefully if anyone else runs across this your workaround will work for them in the interim.