I’ve been holding back for calling this a bug for at least one week. I’ve examine this issue for many days and as of now I am quite confident this is cause by something malfunctioning in the Engine. Before I state the reason I’d like to say this is an extension to a previous thread ( https://answers.unrealengine.com/questions/20653/different-indirect-lighting-from-piesimulate.html ) . Bear with me as this will be quite long.
The reason I’m starting a new thread is because I am now approaching this from a different angle. I realized this have very little to do with PIE/Simulate/Editor view(topic of previous thread) but the issue is in the fact that indirect lighting gets randomly disabled for certain mesh. I am aware that I am unable to reliably reproduce this issue, but I can confidently make it happen in my map with my asset.
For this particular issue I am going to focus on these dark window that have their indirect lighting completely disabled.
My objective is to get someone to help me isolate this issue to a reproducible stage by highlighting areas I might be missing out.
Level Setup:
-Buildings are blueprint with windows/roof procedurally generated.
-Windows and roof are of dynamic mobility. Window have shadow casting disabled.
Here is what I discovered:
-
This issue is confirmed to have nothing to do with lack of indirect lighting. Custom( and stock assets) have shown to have more lighting in a completely enclosed areas than these dark window. Lightmass Important Volume has been placed and light sample volume also verifies this. It is also to be confirmed that is had nothing to do with them being shadowed.
-
The problem ‘causer’ is tied to procedurally generated meshes. It has to be. I deleted all the buildings and the indirect lighting is Restored.
The problem however do not exist when one or two buildings are placed, and only exist when a significant amount is placed.
-
Although I believe the cause of the indirect lighting are blueprint-generated mesh. The indirect lighting failure can happen to any mesh as long as they are movable. Custom and Stock assets have shown to be the receiving end of it.
-
It is not caused by faulty meshes ( Windows/Roof ). I have proven this by replacing all blueprint-generated mesh to be the stock Cube mesh. The same thing still happened.
-
In all instances, this ‘bug’ has caused an inconsistent visualization in Editor vs Simulate.
-
In More than several instances, the ‘bug’ randomly jumps from one mesh to another when blueprints are compiled, lighting are built or when certain buildings are deleted.
-
When the failure occurs, setting the affected mesh to NOT cast shadow and to cast shadow yields different result on the mesh itself. Switching between a pitch black mesh or a dynamically lit but without indirect lighting mesh.
If an epic staff is interested to vigorously test this. I’m more than willing to upload a sample map with these broken lighting to be examined. However, I understand this is a free support and this isn’t something I will demand. To re-iterate myself, my objective of this post is to get help from someone who can help me pinpoint the bug so Epic can fix them. I believe I am facing this issue due to the fact that I am using a relatively large quantity of blueprint-generated mesh.
Note : Because I’m unable to add several images, I am going to add several more pictures as comments.
This picture demonstrate point number 6 and an extremely strange behavior of this bug.
The top picture(middle right building ) has a whole network of generated meshes with disable lighting. The 8 working meshes are manually placed. After deleting the building at the back, the lighting restored ( as shown in 2nd pic ) . However, after re-building the light, the error came back but this time the bottom 2 row’s lighting is restored.
Hi ,
If you do have assets you would not mind letting us use for testing please do upload them, we will be able to have a closer look at what is going on. Thank you!
This is to demonstrate point number 7 . Meshes below are manually placed stock assets with cast shadow being toggled.
Hi @,
Unfortunately after looking at this, we were unable to reproduce the effects you were describing. I know it isn’t pleasant, however it may be best to move everything to a new project if it isn’t occurring. The shadows on our machines with your level seem to be working as expected. Note: you are generating your buildings as movable, if you change this to static it may help with some of the lighting issues you are experiencing. Thank you and have a great day!
I sincerely appreciate the time you spent trying this out.
Moving the content to a new folder did not worked. As I’m typing, It’s already on a second new project, and it’s still the same. It worked for the already placed mesh. but new meshes had the same result. My buildings are static but generated windows aren’t. When the bug kicked in , everything I place would randomly lose indirect lighting. Making everything static isn’t a solution.
Regardless, I won’t be insisting on more support for this unless I discovered new findings with duplicating the result. If you have any solution in debugging this, I would highly appreciate it being shared.
Thank you .
Nevermind the map. I have isolated this issue to a much tighter corner and manage to reproduced it in my friend’s PC as well.
Heres how you can do it:
- make a blueprint that spawns 100 movable object each one on top of each other in an array fashion. ( see screenshot )
- set the base to a static mobility.
Duplicate about 20 of them. Build lighting.
If you can’t reproduce this. I give up. I have included the
to the blueprint so you don’t have to construct them. It only need the Shapes content folder.
FYI there’s nothing else in the map . It’s a Default Map when you create new level. I just added environment lighting in the world settings’ lightmass. and lightmass important volume. And then I throw in all these blueprint.
[link text][2]
Hello,
I am helping look into this issue. Here is what the level provided looks like on our systems:
Though the windows get darker, I am not experiencing the harsh black shadows you are reporting. Please let me know if you notice something I did not.
I am sorry this is occurring on more than one machine. Have you posted both of your DXdiags? I would really like to compare hardware so that we could build a machine in house for testing this.
Thank you for your patience as we investigate this issue.
Okay.
I have been able to reliably duplicate this issue. This is the shortest manner. I have restarted new maps more than 10 times and I got this perfectly accurate result.
- Follow the blueprint attached.( similar to the one I zipped on previous post ) . Blueprint is set to make 10x10 movable cube
- Make new level with default lighting ( not empty) . Resize the ground by 5x . Set Lightmass Volume. Build lighting
- Duplicated 16 of the BP.
At the 16th blueprint exactly. You will get error up to EXACTLY three rows. Which means 1570 cubes will be fine. 30 will not. Subsequently created blueprint-generated cube will be pitch black.
Things I am able to confirm:
- If I modify the creation loop of the BP, the magic number will no longer be 1570. e.g Using 11x11 I get 1584 working cubes.
- After Error kick in. You can delete the BP and recreate, but the error number will be exactly the same.
- Recompiling the Blueprint will change the position of the ERROR-ed cubes, but it will still be excactly 30 damaged cubes and 1570 working cubes. They will not always be clustered ( sometimes split ) . I’m pretty sure they are affected by which object is generated first.
My DXDiag and my friend’s
link text
link text
After a few attempts with the provided asset, I was able to reproduce this issue. It is a bit inconsistent and difficult to give exact steps, but it will be enough for our developers to look into it further. Thank you again for your help during this investigation. Please let us know if you discover any additional information.
I’m not sure if you’re referring to the above post.
Check the post below…it’s a new post posted on Saturday.
I believe that method should guarantee a reproduction of this issue.
Here are some important discoveries I got over the weekend.
- This bug kills the indirect lighting but direct lighting remains IF the movable mesh is set to not cast shadow.
- The bug kills both direct/indirect lighting if the Movable mesh is set to cast shadow. <— The Harsh Shadows
- The screenshot you posted to me regarding the level. I just re-looked into it. Most likely, the last 2 row of the small cube are actually affected by this bug. But the reason why you are not seeing the harsh shadow is because the small cubes are set to cast no Shadows ( this is set in the parent blueprint ; it’s a bit hard to dig out ). Thus you see 2 rows of small cube WITHOUT indirect lighting but is affectd by direct lighting. I am pretty confident the lighting isn’t meant to be that dark on the bottom 2 row. The differences are too big.
- Manually placed object ( non blueprint spawned ) does not cause this issue. I have tried placed over 3000 cubes.
- Order of placement matters, manually placed movable mesh only had bug IF, they are place after the limit ( which can only be caused by the blueprint ). Manually placing everything will NOT bug the system out. Sometimes the bug is inconsistent because after recompiling blueprint, it seems that the placement order will change, hence some manually-placed movable mesh will be cured ( as they are no longer considered to be placed AFTER the blueprint )… This is why a lot of inconsistencies is observed. However, if you place a bulk of the blueprint spawned mesh, it is guaranteed to appear.
Hi .
I’d like to know if issue has been fixed in 4.1 ?I’ve stopped working on procedural building because of this.
If there any follow-up on this I’d like to know thanks.
Hi ,
Thank you for your inquiry. Unfortunately this fix did not make it into the 4.1 patch, please look for it in a future update.
