Resources for USSEP

[alt3rn1ty]

That msdn article is producing mipmaps in powers of 2 just from a 256x256 texture, which can only produce 5 steps if they finish at 16x16 ( for some reason, I dont understand there .. All DDS plugins we have ever used from NVidia or Open Source plugins for GIMP go down to 2x2 )

 

From 1024 going down in powers of two, there are nine to finish with a 2x2 texture. The tenth mip is the main surface you start with

 

1024, 512, 256, 128, 64, 32, 16, 8, 4, 2 = 10 mips, 9  reductions of the main surface

 

See the notes on textures and scroll down to Power of two note http://www.afkmods.com/index.php?/topic/4283-all-about-textures/#entry157417

 

 

Edit : Hint, that linked topic would be a good place for such a discussion too, adding to the knowledgebase article if anything new crops up for SSE and Intels Newbie Plugin.

[InsanePlumber]

@ lmstearn

....Confusing....

This is Confusing this option circled by me is used to generate new mipmaps.

Someone not entirely rethink its location on the interface.
To clarify, it always loads all DDS without MipMaps as alt3rn1ty said for all new MipMaps to been correctly updated.

 

 

Are there docos on it anywhere?

I have no idea

Most of the things that I know about nVidia Plugin it result of trial and error.

I am self-taught, I have been so from the time when there was no Internet for Help.

[alt3rn1ty]

So after a brief interlude ..

 

Back to the remaining puzzle in Post #21 - The lighter shaded head .. I am now getting PMs reference the same

 

I cant repro because its meant to be PM, but the thought is maybe it has something to do with Body meshes instead

 

 

Didnt SSE make a change to nifs to Has Normals values ... or something to do with UV changed ???

Any mesh experts feel free to join in and dispel any myths or confirm any suspicions ..

 

Because I am mostly clueless in this field.

[Hana]

I gotta be honest here, it just looks to me like the head texture is "cleaner" than the body (a reason I have a serious dislike for vanilla bodies).

 

I'm also confused why Beth changed the texture format from DXT1 to 8888. Has anyone tried just resaving like the originals in DXT1? Hasn't it already been determined DX11 doesn't like certain formats? Could it also be differences in video cards - AMD vs. Nvidia?

 

And/or, has anyone tried running the meshes through the SSE Nif Converter to look for errors? (both head and bodies)

 

Either way, I don't think this is something we should include in USSEP. Mostly because not everyone and their brother is reporting it, and the other mostly because we may not determine the real cause, just bandaiding something.

 

Note; I don't have SSE so my opinion may be meaningless.

[Nico coiN]

Bug or poor design, this is worth a fix imo. What has to be done is another matter, though. It's probably out of question to replace the texture with smoothed and upscaled Oldrim model space normal map and rebuild a bunch of facegen data.

[alt3rn1ty]

Bug or poor design, this is worth a fix imo. What has to be done is another matter, though. It's probably out of question to replace the texture with smoothed and upscaled Oldrim model space normal map and rebuild a bunch of facegen data.

 

No need to upscale the old msn, the one fixed above is perfect as far as I can tell, but what you said makes me wonder :

 

Is facegen data generation dependant upon the face normal map that is in use at the time it is generated ?

And if so, would regenerating it with the fixed normal in Post #21 installed make a difference to the output files ?

 

@Arthmoor would you be willing to try this if that is the case ?, using the fixed normal in Post #21 installed, do a regen of face data and tint masks and see if it makes a difference

 

If it did, that would make sense with migals find that if you custom edit the brightness of tint masks per skin type ( give or take a bit lighter / darker ) you can get rid of the problem.

If the resources installed make a difference to the output of the CK, then that SSE Red / Blue mixed up normal could have been the source of the problem.

 

 

Edit : @ Hana, the new diffuse is just an upscale of the old head texture, its no cleaner, and part of everyones process so far to determine what this is was to replace all textures with the old = Same problem. 8888 is acceptable for DX11 ( see this post by Jon correcting the OP of that topic ).

The Nif Converter ( presume you mean ousnious SSE Nif Optimiser ) cannot deal with Face geom, Head, Hair or particles yet.

Resaving the fixed normal map as DXT1 made no difference to the in game lighter head problem.

[alt3rn1ty]

Also @Arthmoor

 

If you do decide to follow through on post #31 above, aswell as the fixed female normal map in post #21, you will be needing the following :

 

.. Yep they did the same with the male head normal map too, the Red and Blue channels were swapped

 

Male Oldrim Normal 512 with artifacts evident especially at the ears

 

Male SSE no artifacts but switched Red and Blue channels 1024 8888

 

Fixed SSE corrected Red and Blue Channels 1024 8888

 

 

 

Edit : Files for this fix redacted - See Post #46

[Jon]

I'm also confused why Beth changed the texture format from DXT1 to 8888. Has anyone tried just resaving like the originals in DXT1? Hasn't it already been determined DX11 doesn't like certain formats? Could it also be differences in video cards - AMD vs. Nvidia?

 

Because DXT1 is ruinous to quality, especially normal maps.  Causes tremendous block artifacting on them.  That was the whole basis for the "No more blocky faces" or whatever the mod was called.  However with DX11, BC7 is now an option which is smaller than uncompressed but way better looking than DXT1.

 

Which, btw, I believe the original HD DLC also switched all the _MSN normal maps to uncompressed did it not?

[Hana]

I'm just saying, and this'll be the last thing I say about it, if it's that major an issue - and why wouldn't characters be a major issue - Bethesda should be accountable for it and fix it, not us.

[Arthmoor]

Well until they do (which is simply not going to happen) we'll fix it. That same logic would apply to all things we fix. THEY should have fixed every single one of them but didn't.

[Nico coiN]

Arth, before starting a huge facegen regeneration process that will probably critically increase the USSEP archive, may I make a suggestion ? Facegens are uniques and that's why so many fixed meshes will be required. On the other hand bodies are a single mesh copied and pasted (with the weight slider applied on it). So, instead of generating an insane amount of new facegen files may we just modify the body/hands/feet model space normal map so as they match and fit with the one from heads ? 

 

...aka all _msn textures that are not related to heads (18 textures / 29.6 mb in total)

[PrinceShroob]

Y'all do know that exported face textures are just tints and the mesh is just headparts, right? New textures shouldn't affect anything, else they'd have needed to export facegen with the HD texture pack.

[Arthmoor]

Someone please explain why this would require any new facegen to be generated at all?

 

Facegen generation produces nif files which reference the various available textures. The only texture files generated by this process are standard color maps. It does not generate normal maps. This _msn file is referenced in each facegen nif but there is no indication that it's being modified in any way because in order to do so that normal map would have to get altered, and that's quite clearly not happening.

[alt3rn1ty]

For my part its just a hunch / speculation / trying to determine still what the cause of the lighter heads is, if its not texture related ( which apart from tint maps has been mostly excluded )

 

My hunch was, if the installed normal maps are related to what gets churned out, then both bethesda and the USSEP are generating textures based on a normal map which has flipped Red and Blue channels

 

What if the fixed normal is installed on the machine regenerating face geom related data / tint maps, does it churn out a setup that no longer makes the in game heads look lighter than the body.

 

Thats the theory - Whether anyone goes through with it .. Is it worth it, not sure. Until someone points this stuff out it doesnt leap out at you, its probably a poke in the eye with a sharp stick for the screen archers and people who like to make a porn movie out of their game .. But they are all probably going to be using better bouncing booty mark 8 with pimples and vanilla jam accessories ( ..or something )

 

Having suggested it I kind of think it may be going into the realm of body mod makers .. And the more I look, the more I can find too ...

 

Right now I am looking at vampires normals, I am having a premonition that maybe the Orcs / Elves etc etc all will have redone head normals too with flipped Red and Blue because the same artist did all the rebaking with the same settings, and ultimately my idea that regenerating everything with all necessary normals redone may not achieve the aim of solving lighter heads.

 

I honestly dont know if its worth attempting at the end of the day.

 

 

Aand, Princeshroob makes sense, I think hes right that the HD Texture pack would have warranted the same treatment if it was necessary - That I think applies good logic to this, and proves it to be quite possibly a waste of time doing a regen

[Arthmoor]

Obviously I need to know if this is going to require new facegen or not. If it is, then I'm not going to accept this into the USSEP because it would mean literally regenerating it for every single NPC in the game. That's simply not going to happen. So someone needs to figure this out.

 

Can it go in as-is with no other changes? Do we need all new facegen? These questions need answering.

 

I'm also not willing to entertain the alternative of flipping body texture normals the other direction. If this is really this big of a deal then lay it at Bethesda's feet and make THEM fix it properly.

[alt3rn1ty]

Yep having thought it through a bit more and the valuable input from other members here I think it needs completely figuring out by someone who knows for sure what needs doing first. The process sounds a lot more complex than I imagined it to be, and by the sound of it a hell of a lot more work / time involved .. I would bin the idea until someone can say without a shadow of a doubt exactly what needs to be done.

 

You guys put in way too much lifetime already on these projects

[Nico coiN]

I spoke too fast. Shroob is correct. The _msn textures are generic in facegens. There is however a facetint texture generated by the CK (how is it generated ? we probably have no mean to know...) :

 

 

I upscaled the Oldrim one for side-by-side comparison :

 

 

There is a slight but obvious difference that imo is not generated by my upscale process. This purple halo may be the final culprit. We should generate a few facegen data and check ingame (Ysolda looks like a good candidate). I guess if alt3rn1ty's source texture makes the problem vanish then we'll know for sure that facegen regeneration is required (facetints textures only).

 

You guys put in way too much lifetime already on these projects

 

You're probably right. However I'll speak for myself : life's not especially fun and fair. What you may describe as a chore is a hobby for me, a mean to think about other things.

[Jon]

@alt3rn1ty

 

So... you and some others who have opened the female head MSN and have discovered the red and blue channels are switched... are just using some kind of broken plugin.  With the Intel plugin the blue channel is exactly where it should be.

 

 

 

So... basically there's no real issue with the MSN files.  Though there is still a neck seam, it's just not because of swapped channels.   I should have verified this myself way back when,  but it was ousnius who finally looked for himself and saw no issues.

[Arthmoor]

For routine viewing of DDS files I've been using WTV. Some thing nVidia put out that's been good for quick checks. It shows the channels reversed. The copy I have is version 0.89b so it's probably old as the hills.

 

I don't have Photoshop and can't afford to blow that kind of money anyway so I get by with what I can.

 

In any case, this wasn't included in any USSEP updates yet and I'm not seeing any evidence for it needing to be either since using either of the 2 versions of this normal are not producing one bit of difference in neck seam for me.

[MIgal130]

In any case, this wasn't included in any USSEP updates yet and I'm not seeing any evidence for it needing to be either since using either of the 2 versions of this normal are not producing one bit of difference in neck seam for me.

 

Yay!  I can finally reply here.

 

I was able to correct for heads appearing lighter by manually reducing tint mask brightness for each of my own character mods in Photoshop.  Darker skin tones required a greater reduction than lighter skin tones.  However, this is merely a compensation hack, not a discovery or a clue in figuring out the cause.

 

I believe the tint masks are being made correctly.  Using SSEedit, you can check two entries:  QNAM Texture Lighting and Tint Layers Index 24 (skin tone).  These are RGB values, on a 0-255 scale.  As an example, Nord Female Skin Tone 2 is Red 206, Green 205 and Blue 204 for both QNAM TL and TLI 24.  I can go into Photoshop and check these values against the tint mask the CK created (or against an Oldrim tint mask I wish to use in SSE) and I will find that the areas unaffected by makeup, such as the border along the neck, are exactly the same values that are seen in the plugin.  This tells me the plugin matches the tint mask.

 

The subtle difference between the old game and SSE is that an Oldrim plugin will contain QNAM Lighting values represented on a scale of 0.0 to 1.0, whereas SSE will display those same values on a scale of 0 to 255.  However, doing the basic math results in a like/like comparison.  The values are not actually different, they are just represented/interpreted on a different scale.

 

So, the SSE CK is not producing bad tint masks or plugins that think the body skin tone should be different than the head skin tone.  Either the game is misinterpreting the plugin data, or it's a NIF problem, or it's a driver problem.  A couple people have told me they've never seen the issue.  The vast majority of those I've asked have said they've noticed that heads are lighter than bodies.   It might help to know the differences between the systems of those who can discern the problem and those who cannot.

 

I use an Nvidia GTX 970 with the most recent certified drivers.  My SSE INI has graphics set to High, 1920x1080.  I'd be really curious to know of any video cards or INI settings that weren't displaying the problem.

[alt3rn1ty]

@alt3rn1ty

 

So... you and some others who have opened the female head MSN and have discovered the red and blue channels are switched... are just using some kind of broken plugin.  With the Intel plugin the blue channel is exactly where it should be.

 

So... basically there's no real issue with the MSN files.  Though there is still a neck seam, it's just not because of swapped channels.   I should have verified this myself way back when,  but it was ousnius who finally looked for himself and saw no issues.

 

O_o ( I missed this post before now )

 

Now there is a good case against what I'm seeing, I have been assuming that the new Intel Plugins being the new kid on the block, and which differs in its loading of the files to ..

 

NVidia DDS and Normal plugins for Photoshop

And the Open source DDS and Normal plugins for G.I.M.P

And the most recent IrfanView with DDS plugins

 

.. Are Bethesda now also using Intel plugins .. In which case all the old setups we have used for previous games are no longer valid for Skyrim SE ( and probably Fallout 4 ) ?

 

And it follows .. We should all now be using Intel Plugins ? ( I tried them but thought they were getting things wrong  )

 

 

That would also make sense of why all the new face normals are the same.

 

 

Edit : Feck, you're right, just trying out the Intel plugins myself and the new face normals edge match the body normals and there is no channel swapping required ..

 

@Arthmoor definitely bin the face normals channel swapping idea, going to purge this topic of the file links for those.

 

 

 

 

The follow up thought would be - Has my setup also made anything else so far worked on wrong ? ..

 

No I dont think so. Will check everything ( taking laptop on shift with me next couple of weeks so I can look over things during quiet moments )

 

The only possible I think would be those pelts .. Will get back with a re-upload if theres anything wrong with them.

 

Edit : They look as intended in game though so no immediate concerns here.

 

Edit 2 : Pelts are still good, they did need the colour inversion of the red and green channels, but the face normals and channel swaps are most definitely not needed.

 

Edit 3 : The only other normal I worked on was the stonewall but that was just manually painting out the edge artifacts to get rid of that seam, and everything else was diffuse textures = I am pretty sure there will be no other problems in all the files redone by me. Still going to go through them thoroughly to be sure.

[MIgal130]

....

 

It's my fault.  I'm the one who noticed the swapped channels in the normal maps when I was looking for reasons behind the head shading issue.  I think Beth is using the Intel plugin or its equivalent in the CK now.

 

BTW, the older Nvidia plugin isn't just swapping red and blue on SSE normal maps.  It does it on most face tint maps.  Heck, it might do it on any kind of map.  I uninstalled both the Nvidia DDS and Normal plugins and switched to Intel and it stopped.

 

Still totally stumped on the head shading issue.  Either few of us can see it, or few people care.  I'm going to wait to see what happens after Cal and Ousnious release CBBE-SE.  Ousnious said they haven't seen the issue in their alpha testing.

 

It isn't graphics card/drivers.

[alt3rn1ty]

Anyone with a DropBox account, if you have not received an email yet I would expect one along the same lines as the following one I received :

We’re always looking to improve the Dropbox sharing experience. The Public folder was the first sharing method we introduced, and since then, we’ve built even better ways for you to share securely and work together with your team.

 

As a result, we’ll soon be ending support for the Public folder. Dropbox Basic users will be able to use the Public folder until March 15, 2017. After that date the files in your Public folder will become private, and links to these files will be deactivated. Your files will remain safe in Dropbox.

 

If you’d like to keep sharing files in your Public folder, you can create new shared links. [1] Just make sure to send the new URLs to your collaborators.

PITA

 

So all links for files throughout this topic have been moved to a private share area on DropBox, and then a new link has been created for all of them