Environmental Maps. How do they work?

[Dlesang]

I love that phrase.

 

I'm curious how to make environmental maps function in Oblivion. Due to some tinkering, I've discovered that my custom eyes, while they do not animate, are very shiny indeed. I have done nothing to make them shiny this way. I don't mean the same dull shininess found on armor or such, but rather a sharper glossiness found on eyes and glass objects like potion bottles.

 

I'm assuming Oblivion has some special procession for eyes to make them shiny this way.

 

However, all my attempts to make a custom object glossy have failed. I'm stuck with the same dull shininess of armor/weapons/etc.

 

Does anybody know how to make environmental maps work in Oblivion?

[KenJackson]

There are many things (some which most of us would never imagine) that can affect how an object looks. There're the base texture, glow textures, gloss textures, dark textures, detail textures, normals maps, vertex painting, materials properties and who know what else. I even made one set of armor that exposed the arms, but if the arms' object name didn't begin with the word "Foot:" for some strange reason the armors' skin tone would darken and the arms would no longer match the hands. One skirt mesh I wanted to retexture was so shiny it looked ridiculous. The effect was done entirely with vertex painting.

The problem with vertex painting is that it's inherent to the mesh and no amount of retexturing can change it.

I've had pretty good luck using the materials properties to make armor and weapons shiny, myself. But I tend to set it in Blender. Years ago, I tried adjusting some for Morrowind with an old version of NIFSkope, but that didn't seem to work. but the newest version of NIFSkope works a lot better than my old one, so it might work, now.

[KenJackson]

Duh,,, How about I actually address you question? Glow textures, dark textures, detail textures and gloss textures can be attached to a .nif in the exact same manner that Base textures are. If you're using NIFSkope, look in the block details window for the texture properties and you'll see flags for each of these. Just turn one on and add the appropriate texture. These all use the same UV maps as the base texture so you can actually use your base textures as a template.

 

The glow maps and dark maps that I've seen have usually been grey scale, but colored textures can add interesting effects. Glow maps make things glow the color of the texture, white is brightest, colors add a shimmer, and black is no glow at all. A dark map adds a shadow effect. While a glow texture might seem like it could add a metallic sheen, it is the object itself that glows. External lighting has little effect on the glow. On the other hand, by sucking up the light, dark maps are really good for giving an object a luxurious satiny appearance.

 

I've honestly never seen anything use either a detail or a gloss texture, I couldn't tell you how they really work. but judging by its name I would assume that a detail map might work like a normals map to make the object look like it has a more detailed mesh than it really does. Also again judging by the name, a gloss texture may be just the ticket for making shiny objects,

 

I may be wrong here, but normals maps seem to be integrated into the mesh at creation. I know that you can create a normals map and apply it as a texture in Blender, but rather than getting a texture property that points to the normls map, your data element for the object will have its normals flag set and a list of "vectors'. Judging by this, it appears that all those normals maps (the 'texurename' with the '_n.dds' tacked on the end) may not actually be getting used during run time.

 

Vector painting must be done directly to the mesh during creation. Unfortunately, none of the tutorials I've seen show how to create the glossy effects that I've seen this method produce.

 

For material properties, Diffuse and Specular colors are the ones that give a glossy effect, these are the ones that dictate how much light an object reflects.

Edited March 26, 2013 by KenJackson

[neomonkeus]

Oblivion has a convoluted system where it checks the name. So given a base diffuse texture texture.dds it would assume there is a file texture_n.dds as a normal map is a requirement. It will then search for any additional suffux'd textures i.e _g, etc. assuming that they have been enabled in the NiTexturingproperty.

 

On the Blender side of things, when a file is exported the only requirement is that the diffuse texture path is added to the list. This also makes it harder to detect on import any files which have not added any additional texture paths directly.

Edited March 26, 2013 by neomonkeus

[KenJackson]

@Neomonkeus

Good to know, but I've downloaded several mods that will use the multiple copies of a single mesh that have retextured for different variations, (primarily offering color options). Most of the time the texture files will be something like: Option1.dds, Option2.dds, Option3.dds, Option4.dds, Option_n.dds, the name of the normals map usually being similar to, but not the same as, the base texture files. How would that work? Or does it?

 

Also, as you seem to be better informed on this than I, do you have any idea why a body part's object name would need to start with the word 'Foot" to be rendered correctly in-game?

[DrakeTheDragon]

@Neomonkeus

Good to know, but I've downloaded several mods that will use the multiple copies of a single mesh that have retextured for different variations, (primarily offering color options). Most of the time the texture files will be something like: Option1.dds, Option2.dds, Option3.dds, Option4.dds, Option_n.dds, the name of the normals map usually being similar to, but not the same as, the base texture files. How would that work? Or does it?

 

Also, as you seem to be better informed on this than I, do you have any idea why a body part's object name would need to start with the word 'Foot" to be rendered correctly in-game?

 

That's actually quite simple. Oblivion ignores any and all additional textures inside the NiTexturing property and only knows normalmaps "..._n.dds" and glowmaps "..._g.dds". This convoluted system will also go as far as mistaking "mytexture_glowsnicely.dds" for a glowmap! It stops 'thinking' after the "_g" point. The situation you're describing actually are textures named "Option_1.dds", "Option_2.dds" and so on, and the normalmap used for 'all' of them is "Option_n.dds", as the game engine doesn't read further than the first "_". That's why it's bad practice and just asking for trouble when you're using '_' in your texture filenames. Causing the engine to mix your name up with a reserved one is just too likely in this case.

 

I'm using this for saving files in regards to simple recolors in my mods as well. My textures are named "footmale.dds", "footmale_redgold.dds", "footmale_black.dds" and they all use the one and only "footmale_n.dds" and don't need to have their own each, simply because of this little trick.

 

As for how the actual bodypart declaration works within NIFs...

To make a mesh a real bodypart, so it will use the skin texture of the race, adapt in skin tint and color to the settings done in CharGen, and ignore all texture and material settings done in the NIF, two things need to be done.

 

- The NiMaterial property has to be "skin" or "Skin", case doesn't matter, but this is a hardcoded material name. All properties will be undone by the engine at runtime. Emissive lighting for example will disappear, no glowmaps on bodyparts.

 

- The 'name' of the NiTriShape/Strips has to include a certain game engine keyword to tell which texture slot of the race to use. The ones I deciphered so far are "Upperbody"/"Arms", "Lowerbody", "Hand", "Foot", there's also "Tail" but its use wasn't really reliable in my tests so far. Which respective slots they target should be self-explanatory, given the 4 texture slots of a race record.

The upperbody/arms thing has something todo with 1st person rendering, like arms render in 1st person while upperbody does not, but I'm not too savvy with this weirdness to tell any specifics, and it's not 'that' simple either.

Again case doesn't matter, so "Foot" and "foot" are both fine. There's also a special character ":", which serves as a sort of remark, preventing the engine from interpreting everything coming behind it. So names like "Foot:Upperbody" are totally fine, will tell the engine to use the "foot" texture, but tell the 'onlooker' it's meant to be an upperbody. Those are pretty common in body mods' body meshes found these days.

 

I said the game engine will control the texture used on it ingame, but there's one thing you need to be aware of to prevent issues later. The NiTexture you assing to the mesh in NifSkope may be ignored ingame, but if it's pointing to a non-existant file or a file missing its normalmap counterpart, you 'will' get a 'missing normalmap' error indicator (pitch-black or invisible mesh) ingame, no matter if the actual skin texture used has one or not.

 

And no, a normalmap is not integrated into a mesh at creation. That'd be against its purpose. A normalmap is for adding details into structure 'between' the vertices. The normalvectors of the vertices can make the edges of the object sharp or smooth, but a polygon will always be flat on the surface. A normalmap now adds structure to the surface of the polygones, too, making the whole mesh 'appear' more detailed than its geometry actually is.

 

I can create a simple plane, 4 vertices, 2 polygones, normalvectors pointing upwards perpendicularly. It'll bee totally smooth and plain.

Now I add a normalmap to it, created from a grey-scale height-map of a letter "H", and ingame my flat plane all of a sudden will render light and shadow trails of the "H" all over it, and only if you look at it from the side you will see there is no 'elevation' at all anywhere. That's what a normalmap does, adding pseudo-3d detail to a flat surface.

 

As normalmaps are 'mip-map'-ed the same as texture (=diffuse) maps are, they also save a lot of performance ingame. When you look at a surface from far away, a different, smaller-resolution patch of the texture will be used, and likewise will a smaller-resolution patch of the normalmap. Maximum detail will only be used when up-close, thus maximum performance loss will only happen when up-close, too. Whereas a similarly-high-detailed structure of vertices and polygones will 'always' be the same amount and have the same impact on performance, no matter how far away or up-close you are.

[KenJackson]

@DrakeTheDragon

I've seen some of your postings in similar threads. You seemed well informed and I was hoping you'd chime in.

 

Thanks, you've cleared up a few of my questions and (hopefully :biggrin: ) set me straight on a few misconceptions I had.

 

But, while uncertain about Oblivion, I'm rather certain I've seen dark textures used successfully in Morrowind. Are you sure they're not used in Oblivion, too?

[DrakeTheDragon]

Not entirely, no. I've never seen them used in Oblivion so far, and I won't be able to guess their suffix.

Maybe if I tried to name a texture file of mine "footmale_dragon.dds", and if it works and isn't mistaken for a dark-map, then "d" certainly isn't the suffix.

 

But I do know the additional NiTexture entries in NifSkope, created through export from say Blender or the like, are not used by the game. There is only 1 NiTexture entry used by Oblivion, the diffuse map. The other maps are connected via filename suffix ("_n", "_g") only. Somebody correct me, if I'm wrong.

 

I think I remember reading something about dark-maps myself also a while back. As Oblivion loves to use alpha channel of one map for a completely different map (alpha channel of normalmap is used as specular map for instance), it could be the alpha channel of the glowmap is a another map of its own again, maybe even a dark-map... but I can't say I've ever seen it documented anywhere so far.

[Nephenee13]

I've never heard of Darkmaps being used for Oblivion at all, in anything I've ever read about Oblivion Texturing.

 

Drake's pretty much covered all of it though, so thats all I can add. Most of my original knowledge on this stuff came from him anyway.

[KenJackson]

If what you're saying is true, then this is "new" as of Oblivion. I can produce literally hundreds of examples where there are standard and also "Glow" versions if otherwise identical meshes for Morrowind. The only difference being that the Glow versions specifie a glow texture in their .NIFs where the standard ones do not. And these textures were always in the same directory.

 

I have verified that eye textures work the way you describe, and as all other body parts, except tails, have their textures assigned via the game engine, I'd assume that they might work this way as well. BTW, in spite of the tail having a "texture" setting in the CS, that setting has no effect. You have to change the texture in the .NIF file. This I know because I moved some tail texture for a custom race into a different folder, and I ended up having to change the texture specifications in the .NIFs to get them to work.

 

But what you say is intriguing. I'll have to play with this a bit.