Why do AO and LightMap need a second set of UVs?

I’m reading the docs, and MeshStandardMaterial.aoMap and .lightMap both say they require a second set of UVs. Why do these have to be mapped to a second set? Why can’t the light mapping just use the original UVs?

Why can’t the light mapping just use the original UVs?

Shortest answer:

mrdoob (mugen, west langley, looeee etc) want it so.

Any question why three.js _____? can essentially be answered with this generic answer. There are design decisions to be made, and they make them. There are probably a million ways to do something, they have to pick one.

However, your assumption is wrong, light mapping can use the original UVs, unoriginal UVs, channels, transforms, anything you can think of in GLSL basically.

More elaborate answer, rather, question?

How would you use AO and lightmaps in the “original UVs”?

if you imagine a complex interior, but with all the walls made out of brick. Brick repeats… light and AO do not.

So in order to make the most generic solution that would work for most people, you expose the generic “uv” channel for mapping, and map textures with those uvs.

Let’s call this UV0. When you need to use an AO map, 99% chance that you need a different texture space. Three gives you the option to use the “second set” (call this UV1).

If you want to use a 3rd set you’re screwed, or if for some reason you want to swap these two, it’s possible but it’s work. Another design could be to allow you to specify which channel and which transformation for example, you want to apply to which texture.

Most people don’t need this though, and the existing functionality is enough to make it work.

1 Like

@marquizzo Please read the following two threads in order to better understand the current situation in three.js.

1 Like


Could you maybe digest a bit of it here in an easier to read format? It mostly seems that people are asking for more flexibility, but that’s about it. Doesn’t really give any insight into why it’s currently like this. Also the dates on these comments make one wonder if this is something that has just been abandoned.

I’ve written my guesses about this in my first post, but that’s all that they are. Much like the OP i too am interested in this topic. Thank you.

Thanks, @pailhead. I appreciate your help, but why do you have to take jabs at the contributors? Of course it was their choice, I wasn’t questioning their decision-making abilities. It feels like your replies come charged with antipathy, why is that?

1 Like

We’re back to that. :cry:

Could you please help me learn what i’m doing wrong by pointing out where i take jabs and what is charged by antipathy? Or maybe help me by understanding what kind of an answer were you expecting?

They do not have to, no reason other than a design decision. No technical limitation even, you can actually do it. The first link in this article has an example.

It can, original, unoriginal, first, second, eighth etc. Again it’s a design decision, to hardcode attributes etc.

My answer has one sentence referring to this. The rest has much more and it took me some time to write it. I consider myself somewhat knowledgable on these 3d topics.

I get it, people don’t like me, but sure don’t seem to object when i share my knowledge. I took the time to write a response here, have a discourse (discourse.threejs.org). I could have just left a link to some novel, called it done and i wouldn’t get scolded. Never a thank you.

1 Like

To summarize this a bit and explain why it applies to AO/lightmaps specifically —

  1. three.js does not (yet) provide a proper API for changing which UV set is used by a particular texture. Various proposals and workarounds have been made, but it’s still essentially a missing feature.
  2. UVs are designed by artists in order to maximize the amount of texture detail in specific areas of the mesh. For most textures, bigger areas need more detail. For AO and lightmaps that’s often not the case — you need more detail only where there are detailed shadow/light changes. Hence, AO and lightmaps are the two textures where you’re most likely to want separate UVs.
  3. because of the limitations of (1) and the need for (2), it was determined that having AO/lightmap rely on a second UV set was a reasonable workaround for artist workflows. It can be slightly confusing, but (for now) it works well enough.

EDIT: Related links from Unreal and Unity.


Yes, often there are better ways to say what i mean :slight_smile: It’s the people skills I lack, and i’m only improving my 3d. Thanks @donmccurdy. Having contributed myself to three.js and knowing many contributors i don’t think ever took a jab at contributors.

1 Like

To be honest, as a 3d artist I have never seen anybody use UV1 for AO in today’s standard PBR workflows. AO is baked on a per-object base and packed together with the other object textures (as supported by GLTF)

True for objects, not true for many static environment things, or where baked AO is an optimization because SSAO is too computationally expensive / low quality. For lightmaps, Unity defaults to UV2 and creates these, but also assumes the artist might want UV1 for a detail map since that is common these days. For most of us in the web, optimizing for one UV set + lightmaps is plenty.
I just with glTF natively supported light maps out :frowning: