Weird dark squares / z-fighting with nothing (and "The question is waiting approval by a moderator.")

(Posted a question on the AnswerHub, and I guess editing it too quickly to add more details caused to get stuck in limbo for several days - link)

Been getting very odd dark square shadows on moveable object in a persistent level, with lighting (stationary directional + skylight) from a sub-level.

The shadows are 3d cubes - if you align a mesh right, it can z-fight with it (as seen on the right 3 meshes).

Only happens with the lighting from the sub-level that envelopes the persistent meshes (other sub-levels with similar lighting setups are fine) - I’m assuming this is cubemaps or some other 3d lighting infromation, but I just don’t know enough to figure out what it is and why it would look so wrong…

I’m using 4.24, and tried upgrading to 4.27 didn’t help.

Any help at all is appreciated.

Is the surface receiving the shadows parallel with the direction the light is facing? That can be an artifact due to shadow maps

The surfaces are pretty much perpendicular to the light source (as I rotate the cube meshes, I can see the dark squares fade in on faces as they turn away from the light).

I’ve also found that the map streaming order has an affect:
There’s a persistent map (dynamic meshes w/ artifacts),
a sub-level with the lighting (common between several other sub-levels),
and a sub-level with the level geometry, etc.

Seems like the artifacts are from the lighting sub-level? If I unload and reload the geometry sub-level it seems alright.

Might play around with that for a work-around, but does this track? Is it possible I have overlapping shadow maps or something like that, and the recently loaded is being used?

Did you uv unwrap and assign the lightmap channel correctly?

Are you not getting errors when building?

Lightmaps are fine, afaict (it also happens with a simple plane, can’t imagine how to unwrap uv / lightmap that improperly).

No errors when building, but mind you, the meshes aren’t in the level whose light is being built (they are all moveable).

The squares appear on any model I place there, as long as it’s in the persistent level, and only when the specific sub-level with the lighting is loaded…

It’s obviously a rendering issue.

But why use a static (stationary) light at all?
If the objects are movable it’ll be handled as a movable light.

If you aren’t using baked at all, change everything to movable and even toggle “force no precomputed lighting” in world settings.

That’ll probably solve the issue.

If you are using precomputed, then something is wrong with something.
Maybe DFAO?

Also a video would help to actually understand the precise issue / perhaps a way to replicate it.

The precomputed lights are used on a different sub-level, with has the geometry (hidden in the screenshot above) - sorry about any confusion. Lots of different elements, might record a video later.

Somehow I missed an important part - there was a static light in the level geometry sub-level (that has lighting built w/ the lighting sub-level).

The squares only occurred on meshes within that light’s radius, despite it having shadows disabled. Maybe that’s the issue? Conflicting shadow information from different levels for the same area?

Anyhow, making it dynamic and rebuilding the lighting seems to have made things better.

Without a proper object level view of the levels/geometry its kind of impossible to say.

Normally, bakes override if you bake again with everything loaded.

If you have different levels and you bake them separate, they would stay separate.

A lightmap is nothing but a texture that gets automatically applied by the engine.

You could pre-compute the same out of the engine and filter it in manually (which given how bad the engine is baking now a days is a really good idea? I wish they’d just let us edit the bake with a brush or something… maybe I should tell them that via feedback hu?)

Use the Lighting Only and Detail Lighting view modes to see if the baked lighting causes any issues. If the squares disappear in any of the view modes then you have a good start to find the cause.