I agree you should add a version that's closer to the vanilla fence color...I really like the textures and design, but I find the mossy look a bit out of place in some locations (especially the Bruma area). Otherwise I'd love to use this, since NO texture pack I use covers fences
Your point in the description about NMM not being designed for modding Oblivion is a moot one, as NMM follows Oblivion's folder and files structure. As long as a mod has this file structure NMM will install plugins and textures and meshes in the exact right spot. As a consequence of you having used the correct folder structure for the mod to fit the game, NMM installs it correctly.
Another thing: does anyone know of a mod that makes the fence poles and the bars smaller? They look really big everywhere in game, almost a bit silly. But to just resize them would make missing pieces in the fences. Someone would have to put more fencepoles and fence bars to make it work. Is there such a mod? (i'm talking about the vanilla size of the fences)
Would probably be a huge enterprice :O Or maybe possible by script? I checked out using [fencePartName].SetScale 0.5 ingame and they look good. Using a script that gets the position and the angle of the fence parts, calculates the middle position of one fence pole and the next and then use [fencePartName].placeatme 0, newposx, newposy, newposz and thats it....(if someone who likes scripting reads this hehe)
I had taken a screenshot that featured fences quite prominently, and I realised they didn't look great, so I went on a search. Your replacer was amongst the first I saw, so it was an instant download. Cheers for all your amazing work!
piekne, naprawde piekne, mam ten materiał, na teksturę , tylko Normalmap nie moze być zbyt mocna, bo robi ''cienie'' i psuje teksturę , dobra robota , tytaj są meshes jak w Skyrim ? , moze bym coś tutaj zrobił......
Dzięki Rafał. Dopiero teraz zobaczyłem Twój komentarz. Nie znam zbyt dobrze modeli w Skyrim, ale o ile się orientuję, w ogólnym sensie są dość podobne. Z jakiegoś powodu są zorganizowane jako shapes, a nie strips (łatwo da się to zmienić w Nifskopie), poza tym w Skyrim są bardziej zaawansowane - obsługują w inny sposób heightmaps itp. Oblivion tego nie ma i trzeba iść okrężnymi drogami. Dużo o konwersji wie Tamira (przekonwertowała mnóstwo modeli Strotiego do Skyrim).
w Skyrim Meshes nie uzywam ''strips'' to jest niepotrzebne i mozna to zmienic w ''exporcie'' w Max , prawidłowo działa, w NIF Nitrishape , tak, Tamira, lubie jej prace , oglądałem jej Nif i sa naprawde dobre, widac ze umie robić lowpoli , nie do przesady oczywiscie , Stroti tez
I wonder if these textures aren't too green for some users (although it's a 1:1 conversion from real life image)? I might add an optional, less mossy/less rotten wood version. What do you reckon?
Well, to my taste, what I saw is exactly as it shoud be Mossy, rotten wood. Like in real life after some time. I'm pretty sure I saw some similar fence in real life somewhere.
EDIT: and out of curiosity, how's the UV maps changes make performance better?
Okay, I'm sorry for not replying yesterday - family life, you know.
So the thing about these UV maps is this: I remember reading a long time ago that when you unwrap a mesh you should keep in mind a few factors:
1) Avoid ugly stretches. You need to think about it when you're still in modelling program. Projecting UV map from view is generally a lazy method, leaving stretched the parts that can't be seen from the point of view, and orphaned individual faces. Only the surfaces perpendicular to POV look nice. You'll have a lot of extra work adjusting faces to make up for every foreshortening. It's much better to mark seams on the model in Blender - or similar program you use - and then unwrap along these seams. You can do it in Blender - which I did for my new project I'm working on.
2) Contain your UV maps in a small area to preserve GPU resources. Let's say your texture is a 1024x1024 pixels seamless square, and UV nodes extend beyond the borders of the image box (the base texture) in Blender or Nifskope. GPU loads as many full squares, as are covered by the model. Take this example of a piece of fort ruin:
Here the map covers 8 1024x1024 squares (A, B, C, D, E, F, G, I), so to apply texture to this element of the fort ruin GPU must load not one, but 8 identical texture files. (maybe even all 9 - depending on how it measures the distance to G and I)
Of course sometimes for better details you can blow up an "island" of connected triangles so that it ends up covering more than one "texture square" (in other words, it extends beyond the borders of the image box). Islands 1, 2, and 3 would be blurry and ugly if you scaled them down to one 1024x1024 square. It's okay to leave them as they are (play with the scale - sometimes they may take up even more squares before they look good. But be aware of noticeable repetition). Number 10 potentially could be scaled down, but I let it be, because due to 1, 2, and 3 it's going to be a two-box texture anyway. But what you should do is move every island so that they cover as few squares (boxes) as possible.
Here I moved them to the center:
Now the whole model uses only two instances of the texture (two 1024x1024 boxes), so the GPU loads only these two instead of eight (or nine). Position of individual islands relative to its borders is exactly the same, but it's like if I moved the whole box. Nothing's changed visually, but amount of pixels that must be loaded by GPU is just a fraction of what it was in vanilla.
With vanilla textures it wasn't a huge problem because they were quite small (though GPUs back in 2006 were less powerful, and TES4 was infamous for being resource hungry, so people would have benefitted from it, too). But when you retexture things with 2k or 4k textures it's a serious matter to consider. Especially when, like me, you're on a mobile 512 MB integrated graphics.
Add to it that in vanilla UV maps sometimes you have a single orphaned triangle thrown 3-4 boxes away from the center. The engine loads all boxes up to that third or fourth box. You can imagine how much unnecessary strain that is for your GPU. I've noticed that Quarl seems to have modified some UV maps to a certain extent, but the vast majority of them are still left untouched.
Whew! That was a long explanation, but hopefully it answers your question, and possibly helps other potential retex artists on nexusmods. If only what I wrote is clear enough. Also, if someone knows for sure that what I say here is rubbish, I'd be happy to learn otherwise.
Thank you for the detailed explanation, more that I expected. Since I hardly done more than simple recolors, and only observed meshes in blender to fix texture paths and what not, I don't think I understand everything, but if I'm ever to do such things it will be very helpful.
Now, you should probably make that post an Article on the Nexus, far more people will see and benefit. A post on the forums would help too. Maybe more people would do such optimisations to their new textures or to existing ones. And thanks for taking time to write and draw that!
One suggestion for it might be to include an image with the texture on the mesh (before, and after optimisation), with highlighted interested points.
Oh, and did you see whether such optimisations were made in QTP 3 Redimized?
Well, it may be me not being able to put it in clear, simple terms, since English is not my native language (Polish is, like yours, I see ;P). But I think it's a good idea to flesh it out (thanks for suggestions) and post it as an article - if only I knew how... Maybe you could help me? Point me in the right direction?
Oh, aha, and no, it seems Quarl only adjusted UV maps when it suited him, but left the majority untouched and flawed.
Well, I only published one Article, from the modpage on the MOBSification of Mods, here: http://www.nexusmods.com/oblivion/articles/44198/? <--- this is the direct link, but I wrote it from the mod's subpage here: http://www.nexusmods.com/oblivion/mods/45522/?tab=10&navtag=http%3A%2F%2Fwww.nexusmods.com%2Foblivion%2Fajax%2Fmodarticles%2F%3Fid%3D45522&pUp=1 But I see that articles are also accessible from the main Nexus Oblivion page (the tab is called File News): http://www.nexusmods.com/oblivion/?tb=art&pUp=1 <---- you would notice it if you scroll a bit down, but anyway, articles are there, about many mods.
So to sum it up: you probably need to publish it from any of your mods' pages, but it will be visible on the main page too. +Do give a post on the official forums too, so that people would notice.
Oh, and the post itself is quite clear, it's just my lack of experience with the Blender
Thanks Carlos, you're very helpful. Now I only need to find confirmation that all this is actually true. As of now it's only based on my vague memory of reading about it sometime in the past. ;P
- I am not sure about this whole "better performance through UV mapping" thing... unless you scale the entire UV map up so big that the texture gets tiled across the mesh a lot of times, I can hardly think of a way it could have any noticeable or even measurable impact on performance. And even then it will use the mipmaps of the texture so there will not actually be more texels rendered. There may be a tiny impact for UV coordinates that are far away from the origin, but if you stay mostly inside the 3x3 grid Nifskope gives you, there should be absolutely no way that this can have an impact on performance. Even a lot further away should not actually matter for gameplay, especially if it is only on a few not very complex meshes like these. And as far as I know, UV coordinates are totally independent from texture resolution, so it doesn't matter if a vertex is mapped onto a 256x256 pixels texture or a 4k one. UV coordinates are relative to the complete texture area, so the origin (0,0) is the upper left corner of the texture and the entire texture is 1x1 "units" (in Nifskope it is 2x2 for some reason, but all the same). No matter how big the texture is, a uv coordinate of 0.5,0.5 will always be in the middle of the texture. Any performance impact related to larger textures would just come from the texture itself, not from the uv mapping.
- But speaking of performance... I noticed that for some reason your meshes are just a bit larger than the vanilla ones, and I was wondering why, because larger file size implies more complex mesh, implies greater performance impact... you get the picture. Again, as these meshes are pretty simple, anyway, any impact they could ever have on performance would most likely not be noticeable and barely measurable, if at all. But I see that you converted them to NiTriStrips instead of NiTriShapes, and while I don't really know the difference, I read that NiTriStrips are better, performance-wise. So if anything you did to the meshes actually affects performance, it would probably be that. I doubt that there is any real difference, though.
"Here the map covers 8 1024x1024 squares (A, B, C, D, E, F, G, I), so to apply texture to this element of the fort ruin GPU must load not one, but 8 identical texture files. (maybe even all 9 - depending on how it measures the distance to G and I)" No. The texture is only loaded once, it doesn't really matter how often it is tiled. Just think of the landscape, the textures are tiled all over it. I mean, that's what texture tiling is for - having to load a texture that is displayed multiple times only once. UV coordinates are just numbers, and they relate to a specific point in the texture space. It doesn't matter where it is, though, unless the numbers are VERY large. Unless you give me a reliable source about it, I highly doubt the accuracy of this statement.
It is not easy to find information about it, but I dare say that this might indicate that it really doesn't matter. Here is a thread where I believe this question is discussed, and the result appears to be that it has no impact: https://www.garagegames.com/community/forums/viewthread/92075
What I found, though, is that uv seams can in fact have an impact on performance, because every vertex in the 3d mesh that borders two uv "islands" has to be calculated as two vertices in the uv map. the same goes for "sharp" edges in the 3D mesh (like when you open a mesh in NifSkope, smooth the normals and remove duplicate vertices). So instead of keeping the "islands" close to the origin, the best thing is not to make too many islands at all. (https://docs.unity3d.com/355/Documentation/Manual/OptimizingGraphicsPerformance.html)
By the way, many of Skyrim's meshes appear to have a TON of unnecessary duplicate vertices, which means in places where no sharp edges are intended, but I guess with today's hardware it barely matters any more.
As I see it, the bottom line is: Not the triangles or vertices (3d mesh or uv map) per object are the most important thing, but the amount of "batches" or draw calls the engine receives, which means a single complex object is better than many simple ones. The actual geometry of a single object is the least important performance factor in games today (or in old games running on modern hardware, see some of the so-called "better meshes" mods for Morrowind - they often have insane amounts of polygons but don't affect performance at all for most people). Coming back to the fences from this mod: They are really simple meshes, compared to many others in Oblivion, and I doubt there would be any difference if you either removed them completely or replaced them with ten times as complex ones.
I am not exactly sure how draw calls relate to polygons, but when it comes to single objects, there is basically no difference if they have 100, 1,000, or maybe even 10,000 polygons - as long as they are still in one batch.
This is most likely what makes "visible when distant" mods so performance-heavy in Oblivion: even though the individual LOD meshes are simple and use small textures, every mesh and every texture generates additional draw calls which slow down the game - especially as draw calls are handled by the CPU, not the GPU. This is why the LOD in Skyrim uses one single atlas texture for all objects: one 2k texture is better than 64 256x256 ones.
More about draw calls: https://docs.unity3d.com/Manual/DrawCallBatching.html
Pherim, I'm teribly sorry I hadn't replied earlier. What you say is my most favourite kind of comments (sure, praise is pleasant, troubleshooting is necessary, but posts that actually teach you something are the best). I've read everything you linked here, and went on beyond that, and indeed it seems I was wrong. Everything you said in both comments now becomes my official texturing religion - which is actually terrific, because I can concentrate on smoothing out the stretches and on the best placement of maps/joint points in relation to the model, without worrying about stacking up elements within a small area.
I've noticed the issue with unnecessary multiple draw calls in farmhouses (eg. the roof "fringe" mesh is divided into many parts while it could easily be one), but to mend it I'd have to rebuild the model, and I'm afraid it might cause issues elsewhere, so I'd rather let them be, since impact on GPU is tolerable.
You are welcome! Glad to be of help and to free your mind for more important things than uv optimization.
Anyway, you are talking about the farmhouse03.nif I suppose (don't see anything wrong with the other ones)? Hm, fixing this should not be a big issue. But since all these parts are using the same texture and material, it may well be that the engine automatically batches these parts together, anyway.
Speaking of which, I just noticed that your fences are using a different material for every part, even though they are identical, whereas the vanilla ones only use one material for the entire mesh. I'm sure in this case it really won't make any difference, but in general it is a good idea to combine materials (and other identical properties attached to a number of different nodes), which can be done in NifSkope with Spells->Optimize->Combine Properties. It will tell you that it has removed a number of properties, but if you expand the NiTriShapes or NiTriStrips you will see that they now all use the same material with the same number in front of them.
Wow! Mate, you're a real fountain of knowledge! Yes, I meant farmhouse03.nif indeed. If you say it won't matter, I won't try to fix it. Hmm, it's an odd thing you say about fence meshes and materials. I used models unpacked from vanilla BSA (a long time ago, so I admit I may have overwritten them later with something else). So, in your opinion, would it noticeably improve performance if I used straight vanilla nifs, and paste new UV maps over them (by copypasting NiTriStripsData)?
Most certainly not, I thought I made that clear . And the result would be the same if you just used the "Combine Properties" spell from NifSkope. As I have said before, there is probably nothing you could do to these meshes that would have any impact on performance. In fact, if the textures work with the vanilla uv maps, why even include the meshes? I think It really only makes sense if there is a visual improvement from the uv edits.
What I said about combining materials was more of a general suggestion. I really have no idea how the engine handles the materials in a mesh, but from what I've gathered it may well be that they also count towards the draw calls, so it would make sense to combine them, if possible. I am not talking about textures, obviously, but about the NiMaterialProperty in every NiTrishape/NiTriStrips.
But one more thing concerning the farmhouse I just found out: You can do this very easily in NifSkope, if you want. Just right-click on the root NiNode and go to "Optimize-->Combine Shapes", and it will put all the loose roof parts into a single NiTriShape (to be precise, all NiTriShapes with the same material and texture will be combined). Apparently you don't even have to remove duplicate vertices afterwards. But once again, there will probably be no noticeable effect in the game.
You made it clear enough, it's just I needed confirmation that it was clear to an amateur like me These are very interesting suggestions. But one argument against combining shapes is that when I do it, smoke emitters (borrowed from AWLS) stop working...
Aha, since you mentioned it, I'd read about NiTriStrips vs. NiTriShapes. That article favours strips and explains why. That's why I stripify the meshes.
Oh, and yes, my primary reason for playing with maps is aesthetic. Presumed economy was just a secondary thought.
Anyway, great to learn all that. I hope to hear more often from you
Hm, no Problems with AWLS smoke emitters for me it seems... and if you already borrowed them from there, why not re-borrow them after combining? Anyway as I said, this will also make no difference in the game.
Thanks for the link about NiTriStrips. Some of this I had found before, but not this exact page, I believe. I still can't imagine what exactly this means for the mesh, but I guess it's enough to know, they perform better. Well, in Oblivion at least. They are not used any more in Skyrim, apparently, and I read they don't even work any more in the SE. Maybe the engine renders NiTriShapes more efficiently again, or it just doesn't matter any more as well.
51 comments
Or maybe possible by script? I checked out using [fencePartName].SetScale 0.5 ingame and they look good. Using a script that gets the position and the angle of the fence parts, calculates the middle position of one fence pole and the next and then use [fencePartName].placeatme 0, newposx, newposy, newposz and thats it....(if someone who likes scripting reads this hehe)
I had taken a screenshot that featured fences quite prominently, and I realised they didn't look great, so I went on a search. Your replacer was amongst the first I saw, so it was an instant download.
Cheers for all your amazing work!
I wonder if these textures aren't too green for some users (although it's a 1:1 conversion from real life image)? I might add an optional, less mossy/less rotten wood version. What do you reckon?
EDIT: and out of curiosity, how's the UV maps changes make performance better?
So the thing about these UV maps is this: I remember reading a long time ago that when you unwrap a mesh you should keep in mind a few factors:
1) Avoid ugly stretches. You need to think about it when you're still in modelling program. Projecting UV map from view is generally a lazy method, leaving stretched the parts that can't be seen from the point of view, and orphaned individual faces. Only the surfaces perpendicular to POV look nice. You'll have a lot of extra work adjusting faces to make up for every foreshortening. It's much better to mark seams on the model in Blender - or similar program you use - and then unwrap along these seams. You can do it in Blender - which I did for my new project I'm working on.
2) Contain your UV maps in a small area to preserve GPU resources. Let's say your texture is a 1024x1024 pixels seamless square, and UV nodes extend beyond the borders of the image box (the base texture) in Blender or Nifskope. GPU loads as many full squares, as are covered by the model. Take this example of a piece of fort ruin:
Here the map covers 8 1024x1024 squares (A, B, C, D, E, F, G, I), so to apply texture to this element of the fort ruin GPU must load not one, but 8 identical texture files. (maybe even all 9 - depending on how it measures the distance to G and I)
Of course sometimes for better details you can blow up an "island" of connected triangles so that it ends up covering more than one "texture square" (in other words, it extends beyond the borders of the image box). Islands 1, 2, and 3 would be blurry and ugly if you scaled them down to one 1024x1024 square. It's okay to leave them as they are (play with the scale - sometimes they may take up even more squares before they look good. But be aware of noticeable repetition). Number 10 potentially could be scaled down, but I let it be, because due to 1, 2, and 3 it's going to be a two-box texture anyway. But what you should do is move every island so that they cover as few squares (boxes) as possible.
Here I moved them to the center:
Now the whole model uses only two instances of the texture (two 1024x1024 boxes), so the GPU loads only these two instead of eight (or nine). Position of individual islands relative to its borders is exactly the same, but it's like if I moved the whole box. Nothing's changed visually, but amount of pixels that must be loaded by GPU is just a fraction of what it was in vanilla.
With vanilla textures it wasn't a huge problem because they were quite small (though GPUs back in 2006 were less powerful, and TES4 was infamous for being resource hungry, so people would have benefitted from it, too). But when you retexture things with 2k or 4k textures it's a serious matter to consider. Especially when, like me, you're on a mobile 512 MB integrated graphics.
Add to it that in vanilla UV maps sometimes you have a single orphaned triangle thrown 3-4 boxes away from the center. The engine loads all boxes up to that third or fourth box. You can imagine how much unnecessary strain that is for your GPU. I've noticed that Quarl seems to have modified some UV maps to a certain extent, but the vast majority of them are still left untouched.
Whew! That was a long explanation, but hopefully it answers your question, and possibly helps other potential retex artists on nexusmods. If only what I wrote is clear enough.
Also, if someone knows for sure that what I say here is rubbish, I'd be happy to learn otherwise.
Now, you should probably make that post an Article on the Nexus, far more people will see and benefit. A post on the forums would help too. Maybe more people would do such optimisations to their new textures or to existing ones. And thanks for taking time to write and draw that!
One suggestion for it might be to include an image with the texture on the mesh (before, and after optimisation), with highlighted interested points.
Oh, and did you see whether such optimisations were made in QTP 3 Redimized?
Oh, aha, and no, it seems Quarl only adjusted UV maps when it suited him, but left the majority untouched and flawed.
http://www.nexusmods.com/oblivion/articles/44198/? <--- this is the direct link, but I wrote it from the mod's subpage here:
http://www.nexusmods.com/oblivion/mods/45522/?tab=10&navtag=http%3A%2F%2Fwww.nexusmods.com%2Foblivion%2Fajax%2Fmodarticles%2F%3Fid%3D45522&pUp=1
But I see that articles are also accessible from the main Nexus Oblivion page (the tab is called File News): http://www.nexusmods.com/oblivion/?tb=art&pUp=1 <---- you would notice it if you scroll a bit down, but anyway, articles are there, about many mods.
So to sum it up: you probably need to publish it from any of your mods' pages, but it will be visible on the main page too. +Do give a post on the official forums too, so that people would notice.
Oh, and the post itself is quite clear, it's just my lack of experience with the Blender
looks like a good mod, well done!
However, I do have a few things to add:
- I am not sure about this whole "better performance through UV mapping" thing... unless you scale the entire UV map up so big that the texture gets tiled across the mesh a lot of times, I can hardly think of a way it could have any noticeable or even measurable impact on performance. And even then it will use the mipmaps of the texture so there will not actually be more texels rendered. There may be a tiny impact for UV coordinates that are far away from the origin, but if you stay mostly inside the 3x3 grid Nifskope gives you, there should be absolutely no way that this can have an impact on performance. Even a lot further away should not actually matter for gameplay, especially if it is only on a few not very complex meshes like these.
And as far as I know, UV coordinates are totally independent from texture resolution, so it doesn't matter if a vertex is mapped onto a 256x256 pixels texture or a 4k one. UV coordinates are relative to the complete texture area, so the origin (0,0) is the upper left corner of the texture and the entire texture is 1x1 "units" (in Nifskope it is 2x2 for some reason, but all the same). No matter how big the texture is, a uv coordinate of 0.5,0.5 will always be in the middle of the texture. Any performance impact related to larger textures would just come from the texture itself, not from the uv mapping.
- But speaking of performance... I noticed that for some reason your meshes are just a bit larger than the vanilla ones, and I was wondering why, because larger file size implies more complex mesh, implies greater performance impact... you get the picture. Again, as these meshes are pretty simple, anyway, any impact they could ever have on performance would most likely not be noticeable and barely measurable, if at all. But I see that you converted them to NiTriStrips instead of NiTriShapes, and while I don't really know the difference, I read that NiTriStrips are better, performance-wise. So if anything you did to the meshes actually affects performance, it would probably be that. I doubt that there is any real difference, though.
"Here the map covers 8 1024x1024 squares (A, B, C, D, E, F, G, I), so to apply texture to this element of the fort ruin GPU must load not one, but 8 identical texture files. (maybe even all 9 - depending on how it measures the distance to G and I)"
No. The texture is only loaded once, it doesn't really matter how often it is tiled. Just think of the landscape, the textures are tiled all over it. I mean, that's what texture tiling is for - having to load a texture that is displayed multiple times only once. UV coordinates are just numbers, and they relate to a specific point in the texture space. It doesn't matter where it is, though, unless the numbers are VERY large. Unless you give me a reliable source about it, I highly doubt the accuracy of this statement.
It is not easy to find information about it, but I dare say that this might indicate that it really doesn't matter. Here is a thread where I believe this question is discussed, and the result appears to be that it has no impact: https://www.garagegames.com/community/forums/viewthread/92075
What I found, though, is that uv seams can in fact have an impact on performance, because every vertex in the 3d mesh that borders two uv "islands" has to be calculated as two vertices in the uv map. the same goes for "sharp" edges in the 3D mesh (like when you open a mesh in NifSkope, smooth the normals and remove duplicate vertices). So instead of keeping the "islands" close to the origin, the best thing is not to make too many islands at all. (https://docs.unity3d.com/355/Documentation/Manual/OptimizingGraphicsPerformance.html)
By the way, many of Skyrim's meshes appear to have a TON of unnecessary duplicate vertices, which means in places where no sharp edges are intended, but I guess with today's hardware it barely matters any more.
Here is an interesting thread which somewhat touches these issues:
http://polycount.com/discussion/50588/technical-talk-faq-game-art-optimisation-do-polygon-counts-really-matter
As I see it, the bottom line is: Not the triangles or vertices (3d mesh or uv map) per object are the most important thing, but the amount of "batches" or draw calls the engine receives, which means a single complex object is better than many simple ones. The actual geometry of a single object is the least important performance factor in games today (or in old games running on modern hardware, see some of the so-called "better meshes" mods for Morrowind - they often have insane amounts of polygons but don't affect performance at all for most people). Coming back to the fences from this mod: They are really simple meshes, compared to many others in Oblivion, and I doubt there would be any difference if you either removed them completely or replaced them with ten times as complex ones.
I am not exactly sure how draw calls relate to polygons, but when it comes to single objects, there is basically no difference if they have 100, 1,000, or maybe even 10,000 polygons - as long as they are still in one batch.
This is most likely what makes "visible when distant" mods so performance-heavy in Oblivion: even though the individual LOD meshes are simple and use small textures, every mesh and every texture generates additional draw calls which slow down the game - especially as draw calls are handled by the CPU, not the GPU. This is why the LOD in Skyrim uses one single atlas texture for all objects: one 2k texture is better than 64 256x256 ones.
More about draw calls: https://docs.unity3d.com/Manual/DrawCallBatching.html
I've noticed the issue with unnecessary multiple draw calls in farmhouses (eg. the roof "fringe" mesh is divided into many parts while it could easily be one), but to mend it I'd have to rebuild the model, and I'm afraid it might cause issues elsewhere, so I'd rather let them be, since impact on GPU is tolerable.
Thank you again for valuable lesson
Anyway, you are talking about the farmhouse03.nif I suppose (don't see anything wrong with the other ones)? Hm, fixing this should not be a big issue. But since all these parts are using the same texture and material, it may well be that the engine automatically batches these parts together, anyway.
Speaking of which, I just noticed that your fences are using a different material for every part, even though they are identical, whereas the vanilla ones only use one material for the entire mesh. I'm sure in this case it really won't make any difference, but in general it is a good idea to combine materials (and other identical properties attached to a number of different nodes), which can be done in NifSkope with Spells->Optimize->Combine Properties. It will tell you that it has removed a number of properties, but if you expand the NiTriShapes or NiTriStrips you will see that they now all use the same material with the same number in front of them.
Hmm, it's an odd thing you say about fence meshes and materials. I used models unpacked from vanilla BSA (a long time ago, so I admit I may have overwritten them later with something else). So, in your opinion, would it noticeably improve performance if I used straight vanilla nifs, and paste new UV maps over them (by copypasting NiTriStripsData)?
What I said about combining materials was more of a general suggestion. I really have no idea how the engine handles the materials in a mesh, but from what I've gathered it may well be that they also count towards the draw calls, so it would make sense to combine them, if possible. I am not talking about textures, obviously, but about the NiMaterialProperty in every NiTrishape/NiTriStrips.
But one more thing concerning the farmhouse I just found out: You can do this very easily in NifSkope, if you want. Just right-click on the root NiNode and go to "Optimize-->Combine Shapes", and it will put all the loose roof parts into a single NiTriShape (to be precise, all NiTriShapes with the same material and texture will be combined). Apparently you don't even have to remove duplicate vertices afterwards. But once again, there will probably be no noticeable effect in the game.
These are very interesting suggestions. But one argument against combining shapes is that when I do it, smoke emitters (borrowed from AWLS) stop working...
Aha, since you mentioned it, I'd read about NiTriStrips vs. NiTriShapes. That article favours strips and explains why. That's why I stripify the meshes.
Oh, and yes, my primary reason for playing with maps is aesthetic. Presumed economy was just a secondary thought.
Anyway, great to learn all that. I hope to hear more often from you
Thanks for the link about NiTriStrips. Some of this I had found before, but not this exact page, I believe. I still can't imagine what exactly this means for the mesh, but I guess it's enough to know, they perform better. Well, in Oblivion at least. They are not used any more in Skyrim, apparently, and I read they don't even work any more in the SE. Maybe the engine renders NiTriShapes more efficiently again, or it just doesn't matter any more as well.