z929669

If you have 2x 1 GB graphics cards in SLI, then GPU-z is reporting the additive VRAM (2 GB) ... so does Precision-X, so does Process Explorer, ... so does (n)... Drop fNearDistance .... further (default is 15)

RE your VRAM, GPU-z reports 2x VRAM when in SLI or CrossfireX (see Performance section of the DDSopt Guide on the wiki). This means that you will not begin to see lag until GPU-z reaches soumething more than double your actual VRAM (for some reason, the software adds the memory of both cards even though the GPU memory is mirrored). For the clipping issue, lower your:fNearDistance=18.0000

I have yet to test, but it would seem that ENB could alleviate any striping (maybe not at default settings though).

Kelmych was kind enough to provide some useful information on STEP mod optimization results with DDSopt.

@acindron At this point, you need to uninstall all mods and revert to a clean vanilla install. IMPORTANT: delete your existing INIs! If you follow the clean install procedure, you will not have the graphics glitches any more. If you do, then it is related to your hardware or your GPU drivers. ;)

What is the GPU and what are you using to measure VRAM? What is your method for assessing VRAM?

Examples? This won't impact VRAM, so I would not trim PP unless FPS is a real issue Isn't this redundant with ATTK? Actually, you can get a pretty accurate measure with GPU-z by getting a baseline for windows first ans subtracting this from Dedicated/Dynamic values when running Skyrim ... or you can use Sysinternals' Process Explorer utility, which breaks down dedicated/system VRAM allocation by process. I agree that this user should be able to run at high res, but I strongly recommend capping at 1920x1200 for a 1 GB card and running Baseline STEP with 1k-capped textures for all clutter and many world textures (interiors and dungeons can be 2-4k though)

Any value LESS than 3 causes massive artifacting in shadows. Even 3 has some, but it is slight, and tolerable (to me). ENB suggests 3-5. Higher values cause significant performance reduction though. So the lowest value you can handle should be used. Can you point to your references? The past recommended setting has always been 2 with no reported issues for the past year now. Also, as it is described, it would seem that lowering the value to zero would be optimal for ENB configs. I'd like to vet the best settings with real data if possible (others have indicated that this settings has no noticeable impact on performance).

I created ENB presets for use with the major lighting mods (most evolved for RLwC), including simple instructions to get set up to use ENB. Just read the description. You should disable FXAA and use SMAA (instuctions as above). Your driver settings should be suspect for the graphic anomolies you are eeing, unless it is mod related (i.e., do you get this in a vanilla setup?), and I use ATI graphics, so I am not privy to the Nvidia Inspector settings. For ATI, we try to leave most graphics-related settings to be application controlled. AA and AF can be matched by driver though, probably V-sync too, but I would leave that alone unless you are getting tearing. When in doubt, revert all INIs back to default (same with Nvidia Inspector) and see if that fixes. As a last measure, revert to a clean vanilla install and test.

v8.0 revision 3 is best (second main file)

set your ini files to read only .... Do you get the above artifacts only with ENB?

I am intrigued by the shaders rewrite and the description of this in general. Also updated for ENBSeries v0.132, which is pretty damn updated. Screens may not be true to the product.

The BSA will always contain files within folders under skyrim/Data. Therefore, it will never contain any plugins (ESM/ESP). The BSA is simply a compressed version of the Data directory structure containing only files related to the mod. Thus, never ignore the plugins! (The plugin tells the game to load the BSA when they are named alike, but the plugin usually does much more than this ... it contains instructions that modify the vanilla game usually, and it is very rare that a plugin is used only to load a BSA) I always extract my BSAs and throw them away, but I am a control freak :P

Yes. I chose the example file because the log file is simple. There are 9 textures, and the log says 9 processed files and 8 modified textures. The only notes, on 3 of the textures, say "Alpha-channel has 1 distinct value(s), without black or white." The log does say "i/o delta: -1362 bytes" which might mean that DDSopt recompressed the textures in the .rar file using a more efficient rar compressor. This isn't the only example. You might look at your log files and see if you can match the "modified textures" number with the comments. I can usually match it with some of the textures but not all. For this example I can't match the "modified" value with any textures. Basically I don't know what "modified textures" means, and whether DDSopt changes textures even when there is no change in the texture size. Posting this for Ethatron's comment.

A.5: The .ini's purpose is two-fold. Defining the compression on a joint texture-type (3 channels can mean 3 independent channels, or colour or a vector, or xy + height etc.). And defining the content of the alpha-channel. As there is no 4 channel joint data-format in use in games that I know (CMYK would be one fe., even though even there it's arguable if K is really in dependency with CMY). So a texture is always "joint"+"extra", "joint" is always present, that's the seed-plane, and "alpha" is optional. You define compression on the seed. This are the supported seeds: ; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; - mark textures to be tangent-space normal-maps, enables specific compression ;Â Â taking unit-halfsphere property into account ; - [b]compression-format is supported here[/b] [NormalsTangentSpace] ; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; - mark textures to be model-space normal-maps, enables specific compression ;Â Â taking unit-sphere property into account ; - [b]compression-format is supported here[/b] [NormalsModelSpace] ; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; - mark textures to be color converted ; - [b]compression-format is supported here[/b] [DiffuseColor] ; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; - mark textures to be greyscale converted ; - [b]compression-format is supported here[/b] [DiffuseGrey] The supported extras are: ; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; - mark textures to have an alpha-channel with opacity, enables specific ;Â Â compression taking this into account ; - [b]compression-format isn't supported here[/b] [AlphaOpacity] ; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; - mark textures to have an alpha-channel with foilage, enables specific ;Â Â compression taking this into account ; - [b]compression-format isn't supported here[/b] [AlphaFoilage] ; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; - mark textures to have an alpha-channel with something custom, disables ;Â Â specific compression only working for opacity ; - [b]compression-format isn't supported here[/b] [AlphaCustom] All of them (seed + extra) have their own processing. Normals are normalized, tangent-space vectors are possibly stored partially derivative, opacity gives importance to colour (the more transparent the less important the exact colour-value), foilage is possibly made sharper. The settings (in the menu) correspond exactly to each of these types. I think that I understand the terminology you are using ... joint texture = multiple channels containing diff info?seed-plane = "joint" = main channel?Under the [behave] menu, there are five different main settings and four modifier settings. Are these what correspond to the "supported seeds & extras" you point out above?Is the INI simply allowing one to define specific textures as receiving one of those "Behave" treatments?Is this necessary when the file name does not properly confer the "joint" and "extras" types?Point me to another resource if this is too much to answer conveniently ;) (I am still in the process of reading your other refs, so if they contain these clues, let me know)

This seems like a template issue, as the URLs are still valid. maybe s4n has changed the template call? EDIT: Confirmed. I fixed the first Gallery, so just change the rest to match. Keep in mind that case matters. EDIT2: The Gallery/GalleryItems Templates are a great candidate for a form in and of themselves, such that we only need to input the file URLs and paths (i.e., it would be great if they could point to local files rather than just URLs)

Great mod, but do all foreign ingredients interact as they did previously? This and over-prevalence of certain foreign ingredients would be the only blockers I can thin of to being in STEP.

I am American, but British English is perfectly understandable ... so I need to deal with the occasional 's' instead of 'z' or 'ou' instead of 'o' meh

@EthatronQ5: Does the INI file only let the user declare compression overrides and exclusions (i.e., by listing full texture path/file), or are the section names meaningful in a programmatic sense (i.e., are textures listed under different sections treated differently by DDSopt)?

OK, If I am understanding you correctly, you are recommending that the most recent DDSopt v8.0 pre-v1.0 on the Nexus is the preferred implementation and that the community users should examine the results and note all of the oddballs so that they can be added to exceptions list of DDSopt (and the "needs-texture-replacers" list for the modding community)? In which case, we SHOULD be using the latest release you have posted on the Nexus and reporting our findings here as per usual :P so it is written, so it shall be done ...

Everything' date=' just point to whatever you think is a good starting point for someone like me trying to understand the basics for getting the most out of someone like you ;) Introductory stuff that you think is pertinent to our purposes in modding and optimizing textures, including prerequisite topics that you might think are building blocks to understanding the relevance of various compressed (and uncompressed) texture formats. the links you have already provided are a great start. & thanks for A2. that is helpful ;)[hr']

We may get flag-post functionality sometime in order to point to posts of interest from the User CP or some such.