PLUGIN: Render to Texture: Light Maps, Normal Maps, AO

[lordfly]

Originally Posted by lisa

The UV map is the problem. What the render to texture tool does is write the lighting information to the texture map. If more than one face is sharing the same area of the texture, the lighting will get overwritten.

You need a "unique atlas"... all that means is that each part of the map is used by one and only one face. You can create one yourself with the TCE built into AC3D, or there are some tools that will make one for you. There's a texture tool called Ultimate Unwrap 3D that will make one automatically. There's also a freebie command-line tool from Microsoft called UVAtlas that will do it. It used to come with the DirectX SDK, dunno if you can download it separately.

Hmm; I suppose that's where I'm having the issue. Correct me if I'm wrong, but doesn't "proper texturing" include having the same textures going over multiple surfaces? For instance, say I have a tree made with multiple branches; they are all made of the same material (in this case, bark). Rather than having each surface have a unique texture (and thus eat gobs of memory), aren't you supposed to share pixels between surfaces to cut down on texture memory? Obviously this doesn't apply if you're doing static renders, but I'm pretty sure you have to do that for game rendering.

Thus, if this plugin requires unique UV coordinates for every surface it to do it's thing, it's kind of pointless for games, isn't it? Or am I missing something here? I'm sure I am.

[luuckyy]

Originally Posted by lordfly

Hmm; I suppose that's where I'm having the issue. Correct me if I'm wrong, but doesn't "proper texturing" include having the same textures going over multiple surfaces? For instance, say I have a tree made with multiple branches; they are all made of the same material (in this case, bark). Rather than having each surface have a unique texture (and thus eat gobs of memory), aren't you supposed to share pixels between surfaces to cut down on texture memory? Obviously this doesn't apply if you're doing static renders, but I'm pretty sure you have to do that for game rendering.

Thus, if this plugin requires unique UV coordinates for every surface it to do it's thing, it's kind of pointless for games, isn't it? Or am I missing something here? I'm sure I am.

Yes the plugin requires unique UV coordinates for every surface. That doesn't mean it requires a unique texture for every surface in the model.
Put simply, each UV must not overlap with another one on your UV map.

Take a cube, it has 6 faces. If you put all these 6 faces in a unique place on the UV map (and all these UV are not overlapping each other) then it's ok.
But if you put for some reasons, let's say the top and bottom faces at the same place on the UV map (or both are overlapping somewhere) then it's wrong (for a proper use of Lisa's plugin).

[lordfly]

Originally Posted by luuckyy

Yes the plugin requires unique UV coordinates for every surface. That doesn't mean it requires a unique texture for every surface in the model.
Put simply, each UV must not overlap with another one on your UV map.

Take a cube, it has 6 faces. If you put all these 6 faces in a unique place on the UV map (and all these UV are not overlapping each other) then it's ok.
But if you put for some reasons, let's say the top and bottom faces at the same place on the UV map (or both are overlapping somewhere) then it's wrong (for a proper use of Lisa's plugin).

Hum; that's what I thought. Kind of unfortunate; I can't properly conceive of an efficient texture/UV map that would accomodate more than a few faces (complex organic shapes would be impossible, such as tree branches). Maybe I'm just visualizing it wrong.

[lisa]

Originally Posted by lordfly

Hmm; I suppose that's where I'm having the issue. Correct me if I'm wrong, but doesn't "proper texturing" include having the same textures going over multiple surfaces? For instance, say I have a tree made with multiple branches; they are all made of the same material (in this case, bark). Rather than having each surface have a unique texture (and thus eat gobs of memory), aren't you supposed to share pixels between surfaces to cut down on texture memory? Obviously this doesn't apply if you're doing static renders, but I'm pretty sure you have to do that for game rendering.

Not so. Most games that use lightmaps use two sets of UV coordinates, one for the diffuse map and one for the lightmap. These are combined at runtime using either a multitexturing shader or multipass if all you have is a fixed function renderer. e.g. GL_ARB_multitexture if you're writing something using OpenGL or SetTextureStageState if you're using DirectX. The render-to-texture plugin will allow you to bake both together in case your engine doesn't support multi-texturing, but that's not the normal way it's done. These are normally different maps.

The first set of texture coordinates is for the diffuse map, and is as you describe: overlapping as much as possible to use texture space as efficiently as possible.

The second set of texture coordinates is specific to the lightmap. It's a unique atlas, and the lightmaps are *extremely* low-resolution. It's not uncommon to pack an entire scene onto a single 1024 lightmap, or small 32x32 or 64x64 textures for individual objects. Shadows are normally a little blurry anyway, so the maps can be pretty tiny and still look great. This keeps this method pretty efficient even though it uses more UV space.

AC3D only supports a single set of texture coordinates for a model so if you're building models for a game, you'll want to create two versions of the model file and combine them in your export utility. [Multi-coordinates is definitely on my wish list :-) ] If you're fixed function, keep them as separate models and arrange it as a second pass. e.g. Render the first model as usual, then render the second model with alpha blending and a tiny z-buffer offset to blend the shadows in.

[lordfly]

Originally Posted by lisa

Not so. Most games that use lightmaps use two sets of UV coordinates, one for the diffuse map and one for the lightmap. These are combined at runtime using either a multitexturing shader or multipass if all you have is a fixed function renderer. e.g. GL_ARB_multitexture if you're writing something using OpenGL or SetTextureStageState if you're using DirectX. The render-to-texture plugin will allow you to bake both together in case your engine doesn't support multi-texturing, but that's not the normal way it's done. These are normally different maps.

The first set of texture coordinates is for the diffuse map, and is as you describe: overlapping as much as possible to use texture space as efficiently as possible.

The second set of texture coordinates is specific to the lightmap. It's a unique atlas, and the lightmaps are *extremely* low-resolution. It's not uncommon to pack an entire scene onto a single 1024 lightmap, or small 32x32 or 64x64 textures for individual objects. Shadows are normally a little blurry anyway, so the maps can be pretty tiny and still look great. This keeps this method pretty efficient even though it uses more UV space.

AC3D only supports a single set of texture coordinates for a model so if you're building models for a game, you'll want to create two versions of the model file and combine them in your export utility. [Multi-coordinates is definitely on my wish list :-) ] If you're fixed function, keep them as separate models and arrange it as a second pass. e.g. Render the first model as usual, then render the second model with alpha blending and a tiny z-buffer offset to blend the shadows in.

Ah, that makes sense, yes. You'll have to forgive me, my modeling knowledge is sadly limited to "things Second Life can do". In my mind, a texture is a texture is a texture, shadows baked on or not. SL can only have a single texture applied to a surface (not even a material, just a jpg or tga); that's why I was hoping for an easy way to plop a light up in the sky and have it "bake" the shadows into the texture map. Alas, modeling is never that easy.

[lisa]

Originally Posted by lordfly

Ah, that makes sense, yes. You'll have to forgive me, my modeling knowledge is sadly limited to "things Second Life can do". In my mind, a texture is a texture is a texture, shadows baked on or not. SL can only have a single texture applied to a surface (not even a material, just a jpg or tga); that's why I was hoping for an easy way to plop a light up in the sky and have it "bake" the shadows into the texture map. Alas, modeling is never that easy.

Ah, yeah, I understand that. SL is the reason I have the combiner feature in there. For all the nifty things it does, its graphics are pretty primitive in a lot of ways.

The good news is that sculpties already meet the texturing requirements. Anything that is a sculpty can have a lightmap rendered without needing to change the UV map.

Incidentally, if you really need the texture resolution you can fake multipass in SL with two prims as long as your prim does not use alpha mapping. (otherwise you will get z-sort errors.) Create your prim, then create a second ever-so-slightly larger version. I recommend using the displacement mapper to make the slightly bigger one. Place both in the same spot, and put the lightmap on the larger prim. Make sure to convert your lightmap to an alpha map first by creating an all-black texture in your paint program, then importing the lightmap into the alpha channel. Set the repeat on the lightmapped prim to 1, and set the repeat on your "detail" prim to whatever you like. I know it's cheesy, but it works better than you'd think. A lot of the furniture artists do this for ground shadows. If you go to the Avnet museum, there are shadows all over the place in there that are done this way.

Otherwise, the simple answer is to use a larger texture. I know, not ideal, but it gets the job done until we get real UV mapping and poly models in SL which will let people build objects a lot more memory efficiently.

[lordfly]

Originally Posted by lisa

Otherwise, the simple answer is to use a larger texture. I know, not ideal, but it gets the job done until we get real UV mapping and poly models in SL which will let people build objects a lot more memory efficiently.

That is exactly what I'm testing... I'm giving sculpties a complete skip and trying to learn real UV mapping and whatnot.

[epatel]

This is great! Any possibility to see it ported/compiled for Mac?

[Dark_Horizon]

Thank you for such a great plugin!

However, I am experiencing a few problems... Basically I have a model, it is textured and unwrapped, and I want to bake it with the Ambient Occlusion. My settings are like this:

Texture Width: 1024
Texture Height: 1024
Super Sampling: 3
Multiple Textures: Checked
Baking: Not Checked
Input Normal Maps: Tangent Space
Render: Ambient Occlusion (mask)

However when I press render, the program stops responding and closes. What could I be doing wrong?

P.S. I am rather new to the program, beforehand I had used mainly Blender and Sketchup.