PCG4m3r

Hey haelfix, I agree, there is definitely a trade-off in terms of some quality loss vs. performance, but if the game isn't stable, then reducing normals may be the best option for those who may have issues with high VRAM usage. If you can run stable without having to reduce any normals, then you may want to revert back to the orginal sizes and see how the game plays for you. Â I did a comparison a few weeks back using AOF mountain textures, showing the difference between 2048K for both *.dds and *_n.dds VS 2048K *.dds + 1024K *_n.dds VS 1024K for both *.dds and *_n.dds. The reduced normal showed an acceptable middle-ground, as long as the *.dds texture remained a higher resolution. See the following post (bottom half): https://forum.step-project.com/showthread.php?tid=1392&pid=22130#pid22130 The mountain images are in the link in that post. I recommend opening each one to full resolution in separate tabs and then jump back and forth to see the results clearly. For me, I didn't really notice degraded quality while in-game. It was more apparent when comparing those images back to back, with a slight blur, which you can see more clearly in the foreground textures.

Thanks Kelmych. That's really odd, I wonder why the repacked BSA is causing a problem for for me? :? Are you using BSAopt v1.6.3 or the 2.0 beta?Â

Curious question. When you guys/gals are resizing all normal maps using constraints, are you first DE-selecting both options under the "Apply" menu in DDSopt? My understanding is that should be done to ensure the normals are simply resized without any possible compression/optimization applied to them. I mentiioned something about this in an older post here in case you find the info useful: https://forum.step-project.com/showthread.php?tid=228&pid=16394#pid16394 NOTE: That post mentioned using the 50% constraint, but lately I've been using 1024x1024. I'm only bringing the "Apply" menu up, because I didn't see this metioned in some recent posts about how others are resizing normals and thought it might be helpful to know about, in case some were not aware. To be honest, I haven't done any thorough comparisons of resized normals with both "Apply" menu settings selected vs. DE-selected, to see if there is any significant difference. I only wanted to mention it in case it does affect the results in a negative way. I did have some bad results with DDSopt-ing some model-space normals (*_msn.dds) when I accidentally forgot to turn off the "Apply" settings. https://forum.step-project.com/showthread.php?tid=228&pid=22196#pid22196 My understanding about the way normals work is that the colors in those files represent how the textures are to be presented in X Y Z of 3D space, so just resizing them without compression doesn't change that color information and the result is only slight blurring due to the normal being stretched more than the texture itself. However, if those normals were optimized/compressed, then it's possible the color information could be skewed/changed, thereby affecting the textures in 3D space and giving generally bad results (some, not all cases). Also, I was curious if anyone experienced any problems where some normals were resized, but others that had the same dimensions were not resized? I did an experiment per the following post using Vurt's Flora Overhaul and found that some of the normal maps didn't get resized, while others did, using the latest DDSopt pre-Update 4: https://forum.step-project.com/showthread.php?tid=228&pid=23115#pid23115

Similar to the issue Dark reported with Dawnguard, I ran into an issue related to Hearthfire today. I was experimenting with the packing/optimizing/repacking using BSAopt/DDSopt after reading the Guides today. I actually did this with Dawnguard, Dragonborn, and Hearthfire, but immediately I noticed an issue with Hearthfire. So I restored the original DLC BSAs back to \Skyrim\Data and the issue went away. Here is what I did and the result: I confirmed it was related to Hearthfires.bsa by copying the optimized back and overwriting the original. As soon as I loaded the game, the letter showed "LOOKUP FAILED!" again and problem cleared when I launched with the original .bsa again. I guess for now I'll stick with using the original/unoptimized DLC .bsa files and will just load optimized textures as loose. I also followed the BSA Guide to convert these 6 BSAs using BSAopt, but I'm worried that there could be problems later on. Is it still recommended to convert these? https://wiki.step-project.com/Guide:BSA_Extraction_and_Optimization#tab=Optimizing_Vanilla_BSAs Skyrim - Animations.bsa Skyrim - Interface.bsa Skyrim - Meshes.bsa Skyrim - Misc.bsa Skyrim - Shaders.bsa Skyrim - VoicesExtra.bsa

Hey z, I just noticed in the DDSopt Guide that you added screenshots for the Behave menu settings. For this particular image (Foliage-map opacity), the value is set to 2.0x. https://wiki.step-project.com/images/5/59/DDSopt_Fig2b.jpg In your old post #430, the value was set to 4.0x. https://forum.step-project.com/showthread.php?tid=228&pid=15687#pid15687 I was wondering if 2.0x is definitely the new value we should be using? I have been using 4.0x all along, so was just curious what the change in value will do to the foliage...make it better, worse, slight difference? Also for @Ethatron, as I was looking at that title I noticed the word foilage was misspelled in DDSopt in a couple places; the I and L are transposed. See here for reference: https://dictionary.reference.com/browse/foliage?s=t

You have my vote for that Kelmych, especially for HRDLC. I'm not sure which textures don't get overwritten by other mods, but I found that even in the Vanilla textures there are some that are 2048x2048 (i.e. \textures\dungeons\caves\cavebasewall05.dds). A tip in case you aren't aware, in Windows 7 if you wanted to find all textures with a dimension, say greater than 512x512, you could input the following in the Windows Explorer Search box (without quotes): "Dimensions: >512x512" Before you search though, you'll want to add "Dimensions" as a new column by right-clicking the column header row and go to "More...". This way you can see the actual texture sizes. There are 732 Vanilla textures greater than 512x512, but the largest dimension for most (665 to be exact) have 1024 on at least one side. It looks like 60 total have a 2048 dimension and even 1 with 4096x1024. While on this topic, I was experimenting with DDSopt Update 4 by resizing normals with the following constraint options for the same files in Vurt's Flora pack (main 1.76b): NOTE: With all three constraint choices, I had both options under the "Apply" menu deselected (not checked). 50%512x5121024x1024I noticed in some cases, DDSopt didn't resize and produced some errors instead: "failed to regenerate DDS" and "Couldn't downscale the DDS". Does anyone know what those mean or why they occurred? Focusing on one file in particular where this occurred, \textures\landscape\trees\treeaspenbarkcomp_N.dds, these same errors occurred regardless of which constraint settings (of the three) I chose above. In contrast, I also ran DDSopt pre5b against the same textures and same constraint options, but it did resize the normal from 512x2048 to  256x1024 using the 50% option. However, the other two constraint options gave a similar error "Couldn't downscale the DDS", but at the same time showed a little more info than update 4. Here are some examples from the logs (with some color to make it easier to see differences): DDSopt pre Update 4 - Constraint = 50% DDSopt pre Update 4 - Constraint = 512x512 DDSopt pre Update 4 - Constraint = 1024x1024 DDSopt pre5b-SSE3 - Constraint = 50% DDSopt pre5b-SSE3 - Constraint = 512x512 DDSopt pre5b-SSE3 - Constraint = 1024x1024

You have my vote for that Kelmych, especially for HRDLC. I'm not sure which textures don't get overwritten by other mods, but I found that even in the Vanilla textures there are some that are 2048x2048 (i.e. \textures\dungeons\caves\cavebasewall05.dds). A tip in case you aren't aware, in Windows 7 if you wanted to find all textures with a dimension, say greater than 512x512, you could input the following in the Windows Explorer Search box (without quotes): "Dimensions: >512x512" Before you search though, you'll want to add "Dimensions" as a new column by right-clicking the column header row and go to "More...". This way you can see the actual texture sizes. There are 732 Vanilla textures greater than 512x512, but the largest dimension for most (665 to be exact) have 1024. It looks like 60 have a 2048 dimension and even 1 with 4096x1024. While on this topic, I was experimenting with DDSopt Update 4 by resizing normals with the following constraint options for the same files in Vurt's Flora pack (main 1.76b): 50%512x5121024x1024I noticed in some cases, DDSopt didn't resize and produced some errors instead: "failed to regenerate DDS" and "Couldn't downscale the DDS". Does anyone know what those mean or why they occurred? Focusing on one file in particular where this occurred, \textures\landscape\trees\treeaspenbarkcomp_N.dds , these same errors occurred regardless of which constraint settings (of the three) I chose above. In contrast, running DDSopt pre5b against the same textures and same constraint options, it did resize the normal from 512x2048 to  256x1024 using the 50% option. However, the other two constraint options gave a similar error "Couldn't downscale the DDS". Here are some examples from the logs: DDSopt pre Update 4 - Constraint = 50% DDSopt pre Update 4 - Constraint = 512x512 DDSopt pre Update 4 - Constraint = 1024x1024 DDSopt pre5b-SSE3 - Constraint = 50% DDSopt pre5b-SSE3 - Constraint = 512x512 DDSopt pre5b-SSE3 - Constraint = 1024x1024

I'll add appropriate Notes annotation to these three; sorry I missed them. If you need to resize them to 1kx1K go ahead, but first read the rest of this reply. DDSopt isn't always able to resize some of the non-square textures. I've noticed this particularly with some of the landscape textures. When it can't it does note this in the log it creates. When this happens there is nothing you can do; it isn't a problem with how you setup the run. Across a large set of mods the total number of textures that can't be optimized is quite small, so it is probably not something to worry about. The hardest question to answer is which textures to select when reducing texture sizes to improve performance. We don't have a table that describes the performance gains and graphic quality loss when reducing the size of textures. I expect that reducing the size of the textures that affect large portions of the screen, such as architecture and landscape textures, provide the most performance gain with reduced size. However, most of the architecture, landscape, dungeon, and interior textures textures in STEP that affect large portions of the screen (vs. clutter textures, for example) are typically high quality textures that have already been optimized by the mod developer. Reducing the size of these can sometimes cause noticeable graphic quality loss. I'm not sure what the performance and quality effects are for reducing texture sizes on weapons, armor, clothing, and textures used for LOD, effects, sky, etc. Perhaps other such as z or Ethatron or some of the mod authors like Cabal and Vurt can comment on this. We have found with recent experimentation that reducing the size of just the normal maps (files ending in *_.dds) provides significant performance improvements without a lot of graphic quality loss. I would suggest trying this first to see if you can get enough performance improvement, especially with mods that have very high quality textures like Book of Silence and Elven Weapons for Silence. Of course, as mentioned above, we don't have any quantitative data on how much performance gain results from reducing armor and weapons textures. @Kelmych, Great info with that "Mod Optimization" table. Thanks for putting that out there! Regarding the comment in yellow above I believe you meant to write *_n.dds, correct? :)Â Just wanted to point that out. I agree with you that probably the biggest performance gain by resizing normals is most noticeable where textures consume a large portion of the screen, especially outdoor/landscape areas. And the results seem to be acceptable (IMO) when resizing normals on anything 512x512 or higher, but below 512x512 it's probably not recommended to resize those normals, because it seems to be a more obvious degradation of quality in-game. I believe someone had suggested not resizing below 1024x1024 as well, so that may be better. In my own testing/comparisons, textures appear very slightly blurred due to the normals being smaller and more stretched across the meshes/models, while the related textures are kept at their default size, but are still optimized with DDSopt. However, this slight blurring is only obvious when comparing images with unmodified normals and those where normals have been resized. And the blurring is even more apparent when reducing both the normal and related texture size than it is when just reducing the normal only. So reducing the size of the normals seems to be a good middle-ground for quality and the performance improvement is worth it. When I'm in-game I really don't notice the blurring at all, at least for the larger textures. I think it should also be mentioned that resizing *_msn.dds could be done as well, as they are just a different type of normal for bodies/faces/hands. It may help improve performance when there are a lot of NPCs on screen, but I don't have any real data to confirm that. I do know that when reducing the size of *_msn.dds (without any compression/optimization) I haven't noticed any obvious issues with character textures in-game. I think it would be helpful to include some information on the DDSopt Guide about reducing normals and how exactly to setup DDSopt to do that. It's easy to do, but some may not know about this or how to set it up. It could be identified as an optional step in the optimization process for those who would like to try it, since it does help with performance. And it may allow some modders who typically choose 1024K textures to go up to 2048K in some cases (not everyone of course). Just a thought.

Wow, thanks for all the info Besidilo! :) I'm looking to get the 512GB, since I currently have a WD Velociraptor 300GB and have been nearing the limit of space on that. A 256GB SSD would be a downgrade in capacity for me, but an upgrade in speed either way (same SATA 2 port). I'll eventually get a 256GB SSD for my boot OS/Applications later on. I found that I can get the 512GB 840 Pro for a little less than the 512GB 830 retail (about $10 cheaper)...so I will definitely be getting the Pro at that price point. At least when I eventually do upgrade the motherboard, I will be able to take advantage of greater performance. Regarding your comment "to avoid excessive writes to the SSD", since I would be using this first drive to install many of my Steam games, and for Skyrim in particular will be constantly updating and trying out new mods, does that count as excessive, or will I be ok there? And how do I know if I'm writing too much to the drive and what will happen if I do? Performance degradation or potential data loss? My understanding is that the drives somewhat regain performance during idle time, so would issues caused by excessive writes eventually be undone or are they permanent? Again, thank you very much for the advice.Â

What budget? I'd go with something around $200, like the Crucial M4 256GB: https://www.newegg.com/Product/Product.aspx?Item=N82E16820148449&nm_mc=OTC-FroogleNEW&cm_mmc=OTC-FroogleNEW-_-Solid+State+Disk-_-Crucial-_-20148449 Or if you can find a Samsung 830 256GB for $10 more, get one, because it's overall a faster and even more reliable SSD. Bear in mind that 840 is not a direct replacement for the 830 and is actually a slower drive. @Besidilo, Since you mentioned the 840, what is your opinion on the 840 Pro? I hear good things about that over the basic 840 model and was considering picking up a Pro very soon. Here are a few of several articles I found. Most seem to say very good things about it. Â https://www.anandtech.com/show/6328/samsung-ssd-840-pro-256gb-review https://www.techpowerup.com/reviews/Samsung/840_Pro_SSD_256_GB/ https://www.hardocp.com/article/2012/12/10/samsung_840_pro_ssd_review/1 Btw...this will be my first SSD. I know the performance is better than a mechanical HDD, but I've been hesitant to buy one, because I read some things in the past about potential data loss, garbage collection issues (something like that), or that they may not last as long as regular HDDs. It seemed SSDs weren't mature enough yet for reliable, daily use by most users. I'm sure much has changed with newer controllers now that it's a couple more generations ahead, but it will be new territory for me. I know SSDs can't be defragged (bad for the drives?), but beyond that, any concerns I should be aware of or are they pretty simple to setup and use, without any regular maintenance? And this first drive I get I will not be using as my main boot drive, but my next one will. I want to get comfortable with using an SSD first before I take that leap -- this one will be pretty much for improving loading of games like fully-modded Skyrim and other big ones. EDIT: Oh and my motherboard (ASUS Rampage III Formula) has SATA 3 (6gb), but it uses a Marvell 9123 controller, which I read Marvell actually produces slower performance than Intel and doesn't have TRIM (don't know what that is), so I'll be hooking up to a SATA 2 port (Intel). When I eventually upgrade my motherboard again, I'll be sure the next one has a better controller, so I can take advantage of the extra speed.

@Neovalen: Here's a small mod suggestion that makes some of the rings look MUCH better! I can't stand the ugly shape of the vanilla (basic) ring meshes. This mod has actually been around for a while, but it's the only one I know that made the ring meshes better. And it includes a few other mesh improvements, but those can be overwritten of course...totally worth it for the rings (IMO). Higher-Poly Skyrim https://skyrim.nexusmods.com/mods/2054 CONFLICTS (with SMIM): apple01.nifbread01a.nifCONFLICTS (with Radiant/Unique Potions): winebottle01a.nifHere are a couple before/after screenshots: https://imgur.com/a/KCaBa#0 I will also ask Brumbek if he could fix those for a future SMIM update.

Thanks you! It was driving me crazy how long BOSS was taking and when it didn't recognize Dawnguard.esm, Hearthfires.esm, etc. I was like WHAT???? Â

Very good info Kemlych. I still have a lot to learn with regard to CK and TES5Edit, but things like this help me get more comfortable with those tools. You're right, it's not a simple process, but I certainly appreciate any knowledge and I'm sure it will be useful for me I can reciprocate a little. I know how to identify what texture file a mesh uses, but only using NifSkope. An in-game solution would be ideal, but alas I doubt that will ever be possible. Based on your \landscape\rocks\rockM01.nif example, if you open that file in NifSkope, you can click on the mesh in the viewport and the relevant "NiTriShape" will be highlighted in the Block List. Or you can just select the "NiTriShape" if you know what it is (in this case it's the only one). From there, you can expand down to the "BSShaderTextureSet" under "BSLightingShaderProperty". Then at the bottom, under Block Details, you can expand "Textures" and in this case you will see it's associated with \textures\lanscape\mountains\MountainSlab02.dds and \textures\lanscape\mountains\MountainSlab02_N.dds.

This may be slightly off-topic here, but maybe not. Hoping someone can give me advice or can answer the questions below. If this is the wrong thread for this, I apologize. It seems like it could be applicable to this thread. Since comparison screenshots are very useful to determine in-game how textures look between vanilla and modded textures or after optimization, I want to go through and try to capture as much as I can for each distinct texture in-game. However, doing this, as you might suspect, is very cumbersome. Here's my current method, taking Whiterun area as an example: Anyway, besides the implied question "is there a better/faster way to go about doing all that?" I have some questions about mods that may exist or not, which could help. Since those mods probably don't exist, I'd welcome any suggestions on quicker ways to improve my "method" above. It's beginning to feel like work and isn't fun waiting for the load menu or repeating steps over and over and over. My aspirations may be set too high on this one.

What you are seeing with these normals is that they have been converted but not re-normalized, thus, this is 'de'-normalized and looks strange. You will need to use an application that can normalize the image to see the result that will appear in game (Gimp or Photoshop have NM plugin viewers).I actually notice a problem in-game though. I first noticed the problem on the body, what I can only describe as some kind of color banding with apparent, hard transitions on the skin. After replacing with the unoptimized file, the body texture looked much smoother and normal. I looked at the good/bad msn files using the NVidia NormalMapFilter plugin in Photoshop. When I use the 3D Preview in the plugin the good file looks smooth, while the bad file is not smooth at all. I also use SageThumbs to initially view thumbnails in Windows Explorer and Windows Texture Viewer as the default viewer for all .dds files; with those tools, I see the same good/bad results. I haven't checked with Compressionator yet, because I don't have it installed.

@Ethatron: First wanted to say thanks for DDSopt. This is a excellent/powerful tool and your efforts are truly appreciated. :) I wanted to ask about optimization of model-space normal maps, based on a problem I observed. I had unintentionally ran optimization on all *_msn.dds files for every mod I have installed, which includes several body/face mods. I meant to reduce the msn files by 50% with no compression/optimization, but it was an oversight. I noticed that DDSopt handled some msn files ok, depending on the mod, but others looked noticeably bad. I posted my initial findings (some specific mods mentioned) here: https://forum.step-project.com/showthread.php?tid=1392&pid=22105#pid22105 And here are two example images "NO DDSopt" and "WITH DDSopt": https://imgur.com/a/PMZE3#1 Those images were from the UNP Blessed Body mod ver 2.4. I had used the recommended settings per the STEP DDSopt Guide. Questions: Do we need to configure DDSopt settings differently for these types of files?Or should we exclude them from any optimization...period?Or is DDSopt simply not coded to handle these properly yet, but may in a future update, thus we still should exclude for now?

I saw them but I've been using fixed maximum sizes for each dimension (e.g., 1024x1024) when I wanted to reduce normal map resolution. If there happened to be a small normal map in a set of textures I wan't sure I wanted to reduce the size of the existing one as it wouldn't save very much processing and might cause problems with the graphic quality.I believe I can confirm that reducing the size of already small normals does impact the texture quality more noticeably in game than reducing larger normals. I just posted some images at the following URL (see soulgem images "NODDSopt" vs. "HalfSizeNM"). https://imgur.com/a/OKapQ#4 The "HalfSizeNM" were reduced 50% normals (i.e. 512 to 256 (common / grand) ...and... 128 to 64 (soulgems01_n.dds)). Also in that same album are some comparisons of mountain textures with reduced textures and/or normals, which I wrote about the results here (cyan text at bottom): https://forum.step-project.com/showthread.php?tid=1392&pid=22130#pid22130 I have been using Neovalen's "Skyrim Revisited" guide (all his mods installed). After I had them all setup, I ran DDSopt 8 upd 3 on every mod that had textures; first pass on all *.dds files except *_n.dds; second pass on all *_n.dds to constrain by 50% with NO compression/optimization. I did this regardless of the mod or original texture size. This was so that I can go through the game to see what was impacted texture-wise for these other, non-vanilla/HRDLC mods, but also to see if the reduced normals improved anything. I posted my initial "gameplay" impression here (performance noticeably improved): https://forum.step-project.com/showthread.php?tid=1392&pid=22105#pid22105 I will post other findings here and in Neo's thread in case this is helpful to anyone.

Thanks Kelmych. I was definitely going to post something over there, hoping Ethatron can either fix or tell us why the msn files look bad in some cases, as you mentioned.

I haven't actually TRIED the new one in game yet... but I know for sure that doesn't happen with the old version and SR. To all: I've updated everything EXCEPT the USKP now. Will see how far I get but I should get done before the evening is out. Updating for the new USKP slowly in increments, please be patient. Mod patches updated so far (will update as finished): Clanking Armor Guard Dialogue Overhaul (Weapons and Armor section changes only) Better Skill and Quest Book Names (simply update) More Interactive Items Skyrim Coin Replacer SkyTEST Distant Detail Hearthfire Edition Consistent Older People Pelagius Wing - Unlit Candles Ars Metallica (No changes - waiting for Arthmoor to fix - requires script merge. Not a show stopper though.) Non-Essential Killable Children Bring Out Your Dead UPDATES COMPLETED. Hey Neovalen, Just wondering exactly what this entails? Does this mean after updating the USKP, that I should delete and reinstall these mods with instructions that have been updated in the Wiki? It's hard for me to tell if any changes have occurred there. Thanks for all your work and for bringing me back to Skyrim! I should have my GTX 680 w/ 4Gb VRAM incoming soon, so I'm going to blow out these hi-rez textures. Basically for any updated mod simply open in TES5Edit and basically recheck/add changes at least for this go round. The safest thing is to reinstall said mod and re-edit but really not required this time. USKP changes are obviously the most difficult due to the mass number of changes each go round. @MorningLightMountain: In case this helps you or anyone else, here is what I have been doing to find the exact changes Neovalen has been making. Obviously he can't put everything in the changelog, so this is a good method to find the specific changes and has worked pretty well (I'm pretty anal -- or it's just OCD)! :) 1. Get Notepad++ if you don't have it (highly recommended/versatile text editor):    https://notepad-plus-plus.org/ 2. After installing, open Notepad++ and go to:        - Plugin            |_ Plugin Manager                    |_ Show Plugin Manager 3. Find the "Compare" plugin and install it 4. I also recommend installing the TextFX Tools plugin while you're at it (named something like that) 5. Then in Neo's Guide page select all the text -- CTRL A works but also selects Wiki menu stuff (don't need that) -- this is what I do:         - Start by clicking/dragging a selection before the "S" in "Skyrim Revisited" title and drag down a line or so         - Let go of mouse button         - Scroll to the very bottom - DON'T CLICK ANY TEXT YET         - Then hold SHIFT and click at the very end of the last line "....versions and confirmed in game." 6. Copy the text (CTRL C) 7. Open Notepad++ and paste all the text 8. Save as a new file somewhere and KEEP IT! 9. Next time Neo makes changes, repeat steps 5-8 but be sure to save as a different file and don't overwrite the previous one 10. Then open both text files in Notepad++ at the same time 11. Run the compare (it's very fast!) by using the shortcut ALT D 12. Now you can scroll down and see each every change in the new text file compared to the old one TIPS: You can see what the highlighted colors represent and even change them to personal taste by going to >>Plugin >>Compare >>Option settingsAlso you can undo the Compare quickly by pressing CTRL ALT DHope that helps someone! :) Â

Cool. I will definitely do that. It will probably be a slow process due to the amount of textures modified and trying to find them all in game...and being a single dad with a few kids (don't have a lot of time to mod/play). I will report as I find them though. I've been surprised to find that most actually turned out pretty good, aside from those I already mentioned and the known problems with \effects \sky textures (vanilla). Unrelated question: I'm curious if you know how in-game to identify a mesh (rock) that appears to be missing a side/texture? It's a vanilla problem and drives me crazy when I see it. See screenshots via URL below. https://imgur.com/a/08nGD#0 I know I can open the console and click on screen to get some sort of cell value, but I'm not sure how to tell if I'm clicking in the right area. And once I have the value, how can I look at it in the CK? It seems like something that should be fixed with the USKP, but I'm not sure what info they would need to fix it. Any ideas?

I know you're not adding new mods for the time being, but I wanted to mention this one, since you mentioned the borderless window previously. I often see mention of the "Simple Borderless Window" mod which has a lot of endorsements, but for me personally I had problems getting it to work. I actually found the following, less endorsed mod to work much better for me. You may find it useful. Borderless Windowed Fullscreen - AutoHotkey Script https://skyrim.nexusmods.com/mods/24 Uses the popular AutoHotkey toolSmall script in the AutoHotkey file simply checks if Skyrim is borderless when launched and makes it full screen Works for me every time and is fairly quick (goes full screen before main menu appears)Benefits: You can also use AutoHotkey for launching other applications with simple shortcuts too! DDSopt (I launch using AutoHotkey all the time)Skyrim executablesAny other utilities/applications (not just related to gaming)Easy to edit the script from the Windows Task Bar (tray) and easy to reload changes from there tooIssues: None that I'm aware ofI'm not familiar enough with all the script commands, but it seems fairly simple to learn, but not necessary. The only thing I ran into when first trying it out for the Borderless script is after installing AutoHotkey the first time it will create an AutoHotkey.ahk file (i.e. the script that is loaded) with some sample script commands included. For the Skyrim script to work, it has to be placed at the top, above any other commands. It will not work (for me) when placed anywhere else in the file. Here is what my AutoHotkey.ahk looks like as a reference (stored in \My Documents):

Thanks for elucidation! I'm always looking for ways to get the most out of my rig where Skyrim is concerned, and NeoValen's mod list demands a lot, so I've been trying to understand some of the underlying architecture. It's too bad that a lot of the limitations appear to exist within Skyrim itself. Unfortunately this is the case yes. Hope Beth does a full engine for the next TES game. I think the effective "cap" is just a little over 3gb as the game starts losing things after that point. Going to pause on mod adds for a bit while I do some optimization work since I've maxed out. (I used max sized textures for everything). @Neovalen I just managed to go through every mod in your list, which had textures, and ran DDSopt upd 3 on all of them. My method used in all cases was I first processed all the *.dds files except *_n.dds as an initial pass using the recommended settings from the STEP Wiki Guide (for DDSopt). Then as a 2nd pass I only selected the *_n.dds files and unchecked both options under the "Apply" menu and in "Constraints" set the "Resolution-limit" to 50%, which effectively reduced all Normal Maps without applying any compression. My goal is to eventually go through and try to find any and all textures that are messed up in-game as a result of compression and if I do find any I'll report them so you and others here are aware. I will also mention the same in the other discussion regarding "DDSopt & Texture Overhauls". Do you think this will be useful here? Seems like it could be. I've already noticed a fairly significant improvement in my FPS/VRAM usage in-game after doing this and I'm using 2048K textures for most mods (4096K for caves with "Snow and Rocks") on a GTX 580 1.5GB RAM with 2048x1280 resolution. Outdoor areas that were previously choppy due to lag and maxed out VRAM now seem smoother and my FPS has stayed at ~55 ...WITH uGrids=7 configured! And I'm not using ATTK, HiAlgo Boost, or anything like that yet. One mistake I made is I only reduced the tangent-space normal maps (*_n.dds) by 50% and forgot to do the same with the model-space normal maps (*_msn.dds). Instead I compressed all *_msn.dds and as a result discovered some mods that DDSopt didn't handle so well, while others seem ok. I just wanted to mention what I found here in case youd find it useful. DDSopt really messed up *_msn.dds files in these mods (i.e. faces, hands, bodies) and somewhat noticable in-game: UNP Blessed BodyFitness BodyAll In One FaceBetter MalesThe *_msnd.dds files in these appeared lightly modified, but didn't seem as bad as mods above or noticeable in-game: UNP BaseNo More Ugly Bronze ShineCoverKhajiits (*_msn.dds files looked noticably different outside game, but couldn't tell in-game / RaceMenu)Dagi-Raht KhajiitIt will take a lot of time to go through all these mods, checking in-game. Hopefully the pay off will be worth it though, because I'm really liking the improved performance! :)

Kind of off-topic, but I'm wondering how you got the orange horizon color all the way down to the water. Is that normal? I always have a grey-ish horizon at a high enough altitude, as seen here: That's a 100% vanilla game, .inis and all. I echo this question ... @PCG4m3r, were you using any lighting enhancements in that screen? Also, thanks for posting the screens. I will investigate this texture specifically. My guess is that it needs different treatment in the INI. AFIK, the earlier pre5b had a basic coding flaw, so I would not use that version. Yes, sorry guys! I thought I had disabled RCRN 3.6, but it was still on in those screenshots. I redid them and added the new ones to the same album, this time without RCRN (I kept the orginal 2 in there but labeled them as having RCRN). The problem is still somewhat noticeable, especially when comparing the images, but definitely not as noticeable in game as it is with a lighting mod like RCRN. I'm not sure if other lighting mods would also make the purple more obvious.

@Spartacii z929669 has indicated that the Wiki Guide is how DDSopt should be configured now. It was updated after his Post #430. The only info in Post #430 that you would need to look at (because that info is not in the Guide yet) are the numeric values under the >>Behave >>Textures sub-menus. Here are a couple other related posts that may be useful, which include links to the relevant posts. Post 560 (z confirming the below post (450) is accurate): https://forum.step-project.com/showthread.php?tid=228&pid=20100#pid20100 Post 450 (references Wiki Guide / Post 430 settings and also tips about resizing Normal Maps): https://forum.step-project.com/showthread.php?tid=228&pid=16394#pid16394 Hope that helps! :)