UDK lightmaps
greentooth
Hey girls & guys,
I got some issues and questions with the lightmaps from udk.
First I show you my process:
For a simple and clear exemple I made a simple cube and a simple plane in Maya, then I snap the Uvs of this two objects on a 32x32 grid. The plane use 100% of the UV space.
I import this 2 guys separetly in UDK, put them in an empty map, add 2 lights and bake the lightning with lightmass.
But when I look at the objects with the "lighting only with texel density" enable, I see the checker didn't match with the hard edges of my cube.
And when I look at the plane I count only 30 little squares instead of 32.
I guess that this problem is responsible of many lighting issues in my meshes like this one.
So if somone can explain me what am I doing wrong it would be awesome. I really want to understand why 32=30 in Unreal Editor.
Thx
Adrien
I got some issues and questions with the lightmaps from udk.
First I show you my process:
For a simple and clear exemple I made a simple cube and a simple plane in Maya, then I snap the Uvs of this two objects on a 32x32 grid. The plane use 100% of the UV space.
I import this 2 guys separetly in UDK, put them in an empty map, add 2 lights and bake the lightning with lightmass.
But when I look at the objects with the "lighting only with texel density" enable, I see the checker didn't match with the hard edges of my cube.
And when I look at the plane I count only 30 little squares instead of 32.
I guess that this problem is responsible of many lighting issues in my meshes like this one.
So if somone can explain me what am I doing wrong it would be awesome. I really want to understand why 32=30 in Unreal Editor.
Thx
Adrien
Replies
http://udn.epicgames.com/Three/LightMapUnwrapping.html#Contiguous%20UVs%20and%20Padding
"Padding between UV charts is necessary to prevent bleeding artifacts. Padding around the edges of the lightmap UV layout, however, is not necessary as Lightmass automatically pads by one texel to prevent bleeding artifcats."
So UDK is scaling your UVs down to add this padding. Your 32 pixels now appears as 30 because you have one empty pixel on each side, and your nice alignments are lost. I don't see anything about disabling this through an ini or anything, so other than doing some maths in your 3d package ahead of time to compensate for this, I'm not sure what the best fix is.
Azza: he uses channel 0 for both, it's fine if the unwrap is unique.
To solve seams between modular meshes: Combine meshes in Maya and import into UDK as one larger mesh. Also merge the verts along the seam, and merge the 2nd channel lightmap UVs so that they are one continuous shell, then use a larger lightmap size if needed.
The actual mather is : if I snap on a 30 pixel grid it will be ok with a 32 pixel lightmap, but if I want to enhance to 64 or 128 it wont match, I'll have to redo my UVs. I need to have multiple lightmaps resolution choices (low res for background instancied object and better rez for the forground instances)
If I need to have 4 pixels between each shell, it will be very hard to have something clean with on object wich have 15 UV shells.
If anybody know how to disable the rescale UV it will be awesome !!!
When you say merge the 2nd uv channel, do you mean merge them with the 1st uv channel or merge as in sewing the uv's in the 2nd uv channel?
Looking at the OP's example:
Instead of having 2 instanced meshes side by side you'd want to have one mesh with seamless UVs where the lighting seam the middle is.
So in this case you would want to have 6 UV shells total (assuming there is a bottom) rather than two meshes with 12 shells.
The most important point I'm trying to make here is that if there is a seam in the lightmap channel's UVs then there will likely be a visible seam in the baked lighting.
Taking that one step further. If there are multiple meshes next to each other, then it's highly likely that the lighting will not be smooth and continuous.
There are other things to consider when taking my advice on this issue. I'm giving advice on how to get the best visual result (how to get rid of baked lighting seams) but the tradeoff will be higher memory consumption due to having more unique meshes in a level instead of many instanced meshes. Not to mention the logistical issues of dealing with many unique meshes.
what you could do is build props to cover the seams like pillars. for covering seams between wall modules.
What the fuck?! No. Just no.
You don't solve problems with modular assets by making them NOT MODULAR ASSETS. The "fix" you're suggesting is lazy, inefficient and bad practice. Doing something like that should be a last resort.
What I am suggesting is pretty much the same solution mentioned in the Modular Floor Tiles - Outlined in Shadow thread.
It's not like I'm suggesting merging an entire level into one giant chunk.
Just merge things into chunks that make sense to keep visual seams to a minimum while also using a mixture of other props and decals to hide the remaining seams as passerby said.
It really depends on what's causing issues. Each case will have optimal workarounds. I think there will always be balancing between visual fidelity and performance, that's just the nature of making art for real time rendering.
Obviously it would be awesome if Epic could improve UDK's lightmap tech to automatically take care of these issues. We can hope for the future
I have only seen these demonstrations done with extremely simple geo, its impossible to get your uv's perfectly on the grid when you have a MUCH more complicated mesh, or when you have geo with bevels and extrusions and such, could someone explain
And another thing, is it ever appropriate to stretch your UV's to make certain they are on the uv grid?