Lightmaps UV alignment and Resolution

[herb64]

Currently dealing a lot with lightmapping, there are 2 questions I would like to discuss

1. UV alignment raster in modeling package

Almost all infos on the web refer to calculate grid size for UVs using Grid size = 1 / Lightmap Resolution.

Reading the [Docs from Epic][1] shows this formula: Grid size = 1 / (Lightmap Resolution - 2)

1 / 62 = 0.0161290323

Here’s a quick picture with Resolution set to 8 pixels and 2 variants of chosing the grid raster in Blender. There’s just a quad unwrapped and aligned to the raster. Left: using 6x6 as to above formula, right using 8x8. And extra 1 pixel padding added by UE4 outside.

When padding is added by Unreal Engine at bake time, most UV values will be misaligned in the resulting texture, if using a raster of 8x8.

There are some discussions on that, but even the gurus describe the way of using 1 / LMAP_res approach, which makes me uncertain. I tend to do it the way as shown on the left side of my image and I’m almost sure, that this is the way to go, because of Epics documentation mentioned above - well, almost, so anyone having the definite answer?

2. Power of 2 for Lightmap Resolution of static mesh - really?

Sources on the web all mention to use power of 2 values for lightmap resolution, just an example [here][3].

I found that entered random values for Overridden Light Map Res on a mesh get rounded to the next multiple of 4 value in the entry field automatically - there must be some reason for that.
I did a test with resolutions 96 and 32 and found, that these get perfectly aligned into a 128x shadowmap texture.

This actually makes sense to me, because in the end, the final baked lightmap/shadowmap textures need power of 2 (streaming?) but not the parts of which these get assembled by lightmass.

Not being forced to power of 2 jumps for some gain in quality brings quite some potential memory savings in my opinion. Any thoughts on this?

Thanks for some discussion about these points.

[Deathrey (DeathreyCG)]

1. Docs are correct. When using lightmap resolution of 4, your object will occupy 2x2 texels area in lightmap, and therefore, your grid spacing in content creation package would be 1/(4-2)=0.5, and offset of -0.5/(4-2)=-0.25

2. While there is no explicit requirement for individual light map sizes to be power of two, it is the only way to guarantee, that borders of whatever your unwrap contains always land on texel center.

On practice, quite often both are skippable in favor of authoring speed, where it does not bring sufficient issues in.

[herb64]

Hi Deathrey, thank you for clarifying this.

I just did not get that offset, could you explain further, what you mean?

I did a small test with a quick and dirty lightmap UV layout for Resolution 16 - authoring with raster of 14x14 - works perfect.

Even when authoring UVs for correct alignment in Blender, if later using Overwrite in mesh editor to a higher resolution does break the alignment then as well. But as you say, this is often skippable, so it looks like testing and choosing the correct approach. And with higher resolution, it should be less noticable as well.

Thanks again

[Deathrey (DeathreyCG)]

I just did not get that offset
You are supposed to snap UVs to texel centers.

[herb64]

Hmm, that would mean my example is wrong, because I used “snap to corner”? Going for “center snap” now:

Thanks a lot for that hint.

[presto423]

It’s an inherent issue with the power of 2 methodology. Do architects use it in blueprints and outlines? Not so. It’s because extrapolating resolution to a mesh that is non-conforming to the power of 2 multiples doesn’t often fit correctly. When scaling, it’s not simply doubling the texel coverage, which would imply it to mathematically fit. It’s similar to the difference between adding 16 to 16, and adding a 1 to the exponent of 2^4…after having applied the 2d texture. There’s actual algebra or even calculus involved, not all simple arithmetic.