Jump to content
  • 0

[WIP] DDSopt & Texture Overhauls


z929669

Question

  • Answers 1.7k
  • Created
  • Last Reply

Top Posters For This Question

Recommended Posts

  • 0

Sadly I do not have much time atm to make a guide. But if you give me a mesh I will give you the texture applied to it.

 

Fairly easy to locate once you know the procedure.

I know how to use NifSkope to locate a texture associated with a mesh (assume same can be done in CK). The problem is that I don't even know what the mesh is, and there are tons of possibilities. :P
Link to comment
Share on other sites

  • 0

The strangely-colored snowy pine LODs look to be caused by Detailed Terrain & Tree LOD, which is not currently a STEP mod (please confirm that you have this installed). I will contact the author and ask him to fix the color issue with that specific LOD.

Yep, I'm using it/SFO 1.81b version/, but will remove it until gets update.
Link to comment
Share on other sites

  • 0
The strangely-colored snowy pine LODs look to be caused by Detailed Terrain & Tree LOD' date=' which is not currently a STEP mod (please confirm that you have this installed). I will contact the author and ask him to fix the color issue with that specific LOD.[/quote']

Yep' date=' I'm using it/SFO 1.81b version/, but will remove it until gets update.[/quote']

I am doing a detailed investigation of all LODs and finding that DTTL is actually quite good with SFO but for this one issue. SFO 181 even has some undesireably yellow-ish snowy pines, so I am trying to put together the best combination of trees and tree LODs (SFO has many versions available for download).

 

I asked SparrowPrince to help us isolate the missing "ice island" texture, but he is almost as uncertain as we are. He did cover this one in EDT2, because installing that mod fixes it.

Link to comment
Share on other sites

  • 0

I added this to the Alpha Custom exception list in DDSopt.ini on the wiki. I looked at the optimized version with Compressonator's compare function and found it is very similar but not identical to the unoptimized version in Skyrim - textures.

The problem is in the Mip levels. The lower you go, the worse it gets in the preview compare diff. It winds up creating a tiled pattern in game. The same may be true for other snow normals, but I haven't seen them yet.
Link to comment
Share on other sites

  • 0

I noticed that also. At full resolution it seemed very similar, with the similarity decreasing at lower mip levels. I'm still surprised it caused a purple texture since the normal map remained fairly reasonable if not exactly similar.

 

I wonder if the DDSopt recalculation of the mipmaps uses a different algorithm for normal maps than for ordinary textures.

 

Of course, as you suggested, it could be the steepness parameter. I'm not exactly certain what that parameter does. How (larger or smaller) would we need to change it so it handles the texture properly?

Link to comment
Share on other sites

  • 0

There's a discrepancy in the DDSOpt guide on the wiki. It concerns the default configuration of constraints as depicted on the images in your guide.

 

- Under the 'Using DDSOpt' tab, the constraints picture says that tin/tone maps should be compressed using DXtx format

 

Posted Image

 

- Under the 'DDSOpt optimization' tab, the constraints pictures all say (whether high quality or standard quality) that tint/tone maps should be compressed using R5G6B5 format. All other settings are equal to the ones under the 'Using DDSOpt' tab. There are 9 images total. They al hae the R5G6B5. One example is here:

 

Posted Image

 

Which is the right one to use? Or does R5G6B5 only apply to the vanilla textures and DXtx to all other textures? If that is the case, does it mean there is an error in Neovalen's SR:LE guide with regards to optimizing the Bethesda textures?

Link to comment
Share on other sites

  • 0

Hmmm I see, thank you for responding Neovalen.

 

I just did a little test. When using the High Quality settings (2k textures & 1k normals) of the DDSOpt guide on 'Skyrim - textures.bsa', both DXtx and R5G6B5 result in the exact same filesize 2.00 GB. I guess there must be a difference in quality between the two, but it doesn't translate in a different filesize.

 

Anyways, I am hoping that someone can provide me a definite answer whether to use R5G6B5 tint/tone-maps on Vanilla texures (and HRDLC etc.) or whether to use DXtx. Same question for textures that originate from installed mods.

 

Also, all the settings of the DDSOpt wiki guide with regards to Mode-space normal-maps are the same, R5G6B5. Just out of curiosity, why is this setting in that format and not in DXtx?

Link to comment
Share on other sites

  • 0

There's a discrepancy in the DDSOpt guide on the wiki. It concerns the default configuration of constraints as depicted on the images in your guide.

 

- Under the 'Using DDSOpt' tab, the constraints picture says that tin/tone maps should be compressed using DXtx format

 

 

 

- Under the 'DDSOpt optimization' tab, the constraints pictures all say (whether high quality or standard quality) that tint/tone maps should be compressed using R5G6B5 format. All other settings are equal to the ones under the 'Using DDSOpt' tab. There are 9 images total. They al hae the R5G6B5. One example is here:

 

 

Which is the right one to use? Or does R5G6B5 only apply to the vanilla textures and DXtx to all other textures? If that is the case, does it mean there is an error in Neovalen's SR:LE guide with regards to optimizing the Bethesda textures?

Neo has probably done the most on body/face textures so we'll use whatever suggestions he and the group looking at these for Skyrim Revisited has for these parameters.

 

If the mod's tint/tone values are uncompressed then it is a good idea to leave them as uncompressed; using R5G6B5 vs. R8G8B8 provides a little file size reduction while keeping them uncompressed. The tint/tone values in Skyrim - textures are DXT1 so its probably best to have this set to DXTx; note that when I ran DDSopt on the vanilla textures the resulting tint/tone maps stayed as DXT1 so the parameter setting didn't seem to matter perhaps because the textures are quite small (256x256). For some mods it might be better to use R5G6B5 for tint/tone maps.

 

The model space normal maps in the vanilla textures are all uncompressed so we tried to keep them uncompressed with a little file size reduction. This isn't true for all mods; some use DXT compression for MSN textures. The MSN setting for other mods would depend on the format the mod uses for these textures.

 

The parallax setting should have been set to DXTx; for the vanilla textures this is moot since they don't include any parallax textures so the parameter isn't used for these textures.

 

The "Using DDSopt" tab has a single set of settings which is fine for many mods. The settings for the vanilla textures reflects additional testing that showed advantages in using different settings for normal map textures than for color map textures. Some mods, especially those with exterior textures, also benefit from using different parameters for different texture types especially particular normal maps. There is some discussion in the guide on this, but no detailed recommendations yet. There currently isn't much discussion or recommendations on optimizing body/face textures other than for model space normal maps.

Link to comment
Share on other sites

  • 0

simple answer: for vanilla textures I'll change the settings in the pictures but it won't actually affect what you get. For non-vanilla textures it isn't as simple and depends on the mod. Are there some representative mods that you are interested in optimizing?

Link to comment
Share on other sites

  • 0

@Kelmych

 

RE snow01_n and other landscape ground normal maps, I think that all mipping has a problem in DDSopt ... most will not be apparent in game, but I have seen enough subtle tiling/striping in the vanilla ground landscapes to be convinced that I do not want to touch the ground landscape normals. I tried various settings under Behave, and none resulted in any noticeable changes in the mip diffs. Basically, I suspect that any compressed, smooth TSNs will have this problem and suggest that we handle all that we know of in the BAT process.

 

I only fixed my TSN under the landscape ROOT of STD and HRDLC2.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Guidelines, Privacy Policy, and Terms of Use.