Lightmap Coordinate Index on static mesh maxes out at 3 - bug or feature ( 4.27 )?

My static mesh has 6 UVs + 1 lightmap UV. In the Static Mesh Editor I cannot set Lightmap Coordinate Index to be 6 (or anything beyond 3), which messes up my light bakes.

Is that a bug in 4.27 or a standard behavior ? (I didn’t have to use more than 2 UV maps in my previous projects, so I don’t know if has always been the case)

As I recall, the UV maps cannot just be added in engine. Meaning you would only see 6 channels if you were to import a mesh with 6 channels.

Perhaps the UVs aren’t all assigned? Or it was a bad export?

From docs
You can use the Get Num UV Channels node to find out how many UV Channels currently exist in a given Static Mesh Asset.

So the “limit” would be based on whatever type of value that node returns (which is likely Int. So 2147483647. For int32).

There’s some interesting stuff about unwrapping in blueprint.

1 Like

You might be correct, but StaticMesh.h has this code:

and no, nothing is broken in my assets. I see 6 UV maps in the Static Mesh Editor, just as I exported them from Blender.

It’s only deprecated when you try to access it directly.

All that really means is that they made the value private and it therefore it now requires a get and a set method for perforim the same final action… (there’s more to why that’s better, but let’s keep it simple).

The class has to derive it somehow from the model data (Keep digging in that same file, it should be part of it).

SM has to have a constructor too.

And re setting the lightmap index.

If the Uvs are avaliable it let’s you slide. Otherwise it stops at the last avaliable.
So, it could very well be a bug OF the editor (the code for that would be elsewhere).

Do you happen to know if the code I posted is the Editor’s code? I’d like to tweak it and see if it fixes the issue.

I think that’s just the static mesh actor code…

It’s one of those files here that you want to check/edit

Adjust for your branch ofc.

Btw, you have a destination and a source for lightmap.
Make sure you are tweaking the correct one.
I see nothing in the code that would justify it being stuck.
Particularly not when you manually type in a number.

I have that too and those sliders let me set UV index to 6.

Well, index 6 is lightmap 7 so you should be good to go for having the engine generate the lightmap.

Lightmap UV is index 6. If I make UE4 to generate UV, I get another one that becomes Index 7 and … slider still only goes up to 3.

Just to make sure, I made cube with 4 basic UVs and had UE4 generate lightmaps UV - slider still only goes up to 3.

But that’s normal

0 to 3 is 4 maps.

It’s annoying that the “light map UV index” slider goes from 0 to 3, but the “which UV channel is this” UI display for each channel goes from 1 to 4.

Separately, I have to ask: Why are you using 6 UV channels?
Every time I’ve seen this happen before, it’s always been for some reason that doesn’t hold up to game-engine scrutiny.
For example, if you have six separate materials on a mesh, they can and should all use the same UV set. It’s OK for those to overlap, as they will use different actual materials when rendered.
If you use materials with 6 different layers, you can just have all those layers use the same UV set and load different texture objects in the material. If you need de-correlated noise channels or something, scale/offset each texture load by a different uniform value.

In practice, the absolute most I’ve seen motivated, was 4 channels, and even that was pushing it. The channels used in that case were:

  1. “regular” texture/material map (this can overlap to re-use different texture features.)
  2. “detail” texture/material map, that for Reasons™ couldn’t just be a scaled version of 1)
  3. “unique parameterization” of the mesh – every point on the mesh maps to exactly one point in a texture map, where the goal is to minimize distortions and maximize shared edges. No coordinate is outside the 0-1 range, no triangle is flipped, and no no triangle is degenerate. Btw: Once you have this set, any other material function can just use a look-up based on this set – it could replace 1 and 2 in most cases. Many tools are able to generate this one from the others in a baking process, too, which is generally more efficient to run in-engine.
  4. Light map coordinates. These can be different from 3, because you may want bigger gutters between unconnected edges to avoid light bleed, and you’re less sensitive to stretching.

For any real, practical game assets that perform well, you should aim for using use 3), and if you need static pre-computed lighting, 4). This will load faster, render faster, download quicker, use less VRAM, and generally just be a better game-ready asset.

Also note that, the more UV channels you have, the more vertices will be split in the GPU vertex buffers, and thus the heavier the objects will be to render if you are vertex shading bound.

1 Like

It was for an experiment. I need to have 1 mesh with 1 material, but various tiling textures assigned to various parts of the mesh (level design similar to good ol’ Quake 1 )

I gave up on it since I couldn’t really achieve such a thing.

Let’s see.

  1. normal
  2. detail
  3. vertex mapping
  4. unique map
  5. vertex animation tool UV
  6. lightmap

Vertex mapping is just enumerating the mesh vertices to UV coordinates. Similar to the unique map you described but made of degenerates.
You only use it to select a specific vert to offset or mask a specific texture to select specific verticis.

The vertex animation tool UV is whatever the Maya vertex animation tool generates.

You could argue that they are the same. The end goal is similar at least.
In reality they probably aren’t.

The idea of the vertex mapping is literally just to solve how ■■■■■■ unreal is at giving access to a specific vertex (or set thereof) within the material shader.

I am not sure how it’s all done and if Blender can be used to author such vertex mapping :frowning: Are there any docs/tutorials about that?

Not really.
Its also limited to being just for visual stuff, so its kind of pointless.

And while the UV can be sampled up to the limit the engine allows for with increased uv precision, you can’t really use images larger than 8k as maps anyway.

To get the UV layout you have to script a process in python that just looks up the mesh and produces the correct UV map.

A vetex every .1 allows for 10x10 100.
A vert every .01 is 1000
And a vert every .001 being 10,000 is where the sweetspot is.

There’s no in engine support obviously (unlike pivot painter) so you have to then script whatever the material does yourself.

Make a quick script and play around with the 10,10 version so that is nice and easy to understand.
For educational purposes… because if you need to do something specific there’s probably better ways.

1 Like