z929669

I added it to DDSopt.ini in the DDSopt guide.Great, thank you ... I could also use some help isolating exactly which of the effects textures are borked by DDSopt defaults. Right now the whole directory is in there, but it really shouldn't be, as only about a third of the textures should be. I have begun looking at the primary and alpha channels of source/destination starting alphabetically in the effects root. If someone wants to begin looking at efects\gradients, that would be awesome ...The file I posted earlier on the effects\gradients problem had a list of all the files I was sure were borked; it was over 80% of the textures in that folder. I used DDSopt Preview mode to view the primary and alpha channels of all textures in that folder. There were 30+ files where I wasn't sure there was a problem. You might want to look at the ones I didn't include just to make sure. There were a few I didn't report because the primary texture was very dark and if there were any problems it was hard to tell. There were also a number of textures that seemed perfectly fine after DDSopt processing.OK cool. I will grab that and edit the INI then. Sti9ll need help with Root though ;) I have checked the first 20 or so files and found a handful so far.

I added it to DDSopt.ini in the DDSopt guide.Great, thank you ... I could also use some help isolating exactly which of the effects textures are borked by DDSopt defaults. Right now the whole directory is in there, but it really shouldn't be, as only about a third of the textures should be. I have begun looking at the primary and alpha channels of source/destination starting alphabetically in the effects root. If someone wants to begin looking at efects\gradients, that would be awesome ...

Has anyone tested this thoroughly? I'd like to add it to this release if it is well vetted.

Yep, a good example of a bad snow texture :P

All of the above examples should be added to the AlphaCustom portion of the INI. This will fix. The same happened with clouds.

Naw. I think that we have completed the guide enough for a lot of people, and they are simply playing the game ;)

I really don't think we're terrorizing anyone - my terror mode looks quite different! There's no problem at all with trying things out, that's how we move forward, but a newcomer might assume these are recommended tweaks, and when you say "It's clear STEP don't recommended it anywhere" he'd have to read every word of the site to prove that negative. We're just making it clear that it's not, and asking for evidence in case it's something we should consider. Nothing to worry about. Agree, and these tweaks have been advertized for many moons now. They have likewise been discredited as beneficial for nearly as many, and thus the default settings are probably best in such cases.

Textures to be added to INI: sky\masser_full.dds sky\masser_half_wan.dds sky\masser_half_wax.dds sky\masser_one_wan.dds sky\masser_one_wax.dds sky\masser_three_wan.dds sky\masser_three_wax.dds sky\moonshadow.dds sky\secunda_full.dds sky\secunda_half_wan.dds sky\secunda_half_wax.dds sky\secunda_one_wan.dds sky\secunda_one_wax.dds sky\secunda_three_wan.dds sky\secunda_three_wax.dds sky\skyrimconstellations01.dds sky\skyrimconstellations02.dds Why do these particular textures cause this problem? Is there something unique about them? I worry that there are other textures like this which havent been discovered yet. If Ethatron drops in maybe he could shed some light on whether DDSopt could detect and process these types of textures automatically without manually discovering them and adding to INI. I checked and most of these probably will not have any issues (I defer to Ethatron though) ... Either the alpha channel will mask the pieces that are pixelated in most cases (e.g., around the edges of the moon in the primary channel), or the pixelated parts are not visible on the model. The constellations seem problematic though, so I will add them.

Please feel free to update it or anything else where it is obvious ;)

When i view several other sky\ textures the Primary (Destination) doesnt look right after optimization.      Im using the Nexus DDSopt, all settings as per OP and Wiki. When i view the textures in IrfanView they look fine. Is DDSopt just displaying the texture incorrectly or has it been corrupted? Order of images - Vanilla, Optimized, Vanilla, Optimized, Vanilla, Optimized If you provide those texture names, I will add them to the INI on the wiki ... I could have sworn that I added all of these, but I may have missed a couple ...?

Assuming you have multicore CPU. Try and give your feedback. Do you have a reference for these tweaks and their effect? These have no positive effect in my XP, and can even destabilize the game AFAIK.

You need to defragment your HDD any time after installing a batch of mods (if you use a HDD). I have seen major stuttering as a result of inefficient disk behavior. I use a pair of HD-6850s too, but I don't see that you have mentioned what your max on-card VRAM is (that card comes in either 1 or 2 GB). My max is 1 GB VRAM, and I begin to see stuttering after installing Section G of the guide. (DDSopt and constraint of large normal maps fixes). Run a performance benchmark using the guide's instructions and provide your results back here if you want. My numbers are here.

Anyone feel like creating a thread for each of these Tavern mods?

I think the one is the sign, but I'll also check the other. Thanks!

OK, I just verified all of the sky textures and am now updating the INI to reflect. Will do the same with effects, so I am wiping the giant list I currently have in the INI out and only including affected textures. It turns out that there are 4 textures that suffer the strange conversion associated with purple sky. I can only see the problem in the DDSopt previewer, but the Primary (destination) gets messed with these four: sky\alpha.dds=SKP sky\masser_new.dds=SKP sky\secunda_new.dds=SKP sky\skyrimcloudsfill.dds=SKP

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.

Adding SKP just prevents processing altogether. Have you verified the purple sky is associated with this texture and that you can fix it by replacing this file? I have verified using the Compressionator that adding these files to the INI indeed changes the result as evidenced by the diff. I do notice the purple sky only on the very distant horizon from high altitude. I see this even with unoptimized vanilla. Can you post screens of your purple (and corrected) sky issue? Also, DDSopt will change 32x32 to 1x1 if there is no variation in the texture (i.e., it is a single color). This is a good thing, and Ethatron mentions it somewhere around here ...

Definitely need to test this one

Yep, Looks like I left a couple of directory paths in there. I pulled the paths out of a log file ... I'll get rid of them

The WBG has been updated. Installation and BAIN sections were updated as were several other things throughout.

The only thing I would qualify is that, for Wrye Bash users, when packing up into the archive, use non-solid compression. This may slightly decrease the compression ratio, but the benefit is huge when you are (un)installing upstream packages, re-unpacking from the huge vanilla archive ... extraction goes much faster.If this isn't in the WB guide, it needs to be. I'll re-archive mods even with no changes for this very reason.Updated the WB Guide to include this. Also updated a lot of other stuff on that one.

I just posted my DDSopt INI on the wiki. This lists all of the textures underneath effects/ and sky/ (many, if not most have custom alphas that get messed up, so just listed them all). I confirmed that this fixes, but Ethatron may want to explicitly handle these within the application at some point, so it would be great if we could get a complete list of all textures that have weird alpha channels.

True, but WB needs compressed files so that it does not have to scan an entire directory each load. It scans the archive once and then uses the CRC to verify subsequently. I assume that this may be why MO ?duplicates? packages? Compression is not really optional for WB

The only thing I would qualify is that, for Wrye Bash users, when packing up into the archive, use non-solid compression. This may slightly decrease the compression ratio, but the benefit is huge when you are (un)installing upstream packages, re-unpacking from the huge vanilla archive ... extraction goes much faster.