Blackface. What it is and how to fix it.

[ruddy88]

I see people ask about this all the time, and since I'm sick of typing out explanations each time I figured I'd type up a bit of a informative guide on what blackface is and how to fix it, hopefully in a relatively easy to understand way.
I'm sure we've all come across it, but for those who haven't, blackface is when you you load in to game only to find a bunch of your NPCs have dark skin textures.

 

 

Before we continue, we should address how NPCs faces are actually handled in game.
When we start a new game, we are taken to the character creation screen where we alter a bunch of sliders to create our players face.
These sliders can represent what type of headparts are used (hair, brows, beards etc), as well as represent a morph value for the shape of these parts (nose length, eye height, chin width etc).

NPCs are technically created the same way, theyre head is just the result of a bunch of sliders that were created by the developers.
the difference, is that NPCs heads arent generated dynamically in game based off the slider data, but are instead pre-generated and exported as a standalone mesh and texture, we call this FaceGen and FaceTint respectively. This is, to my knowledge, because loading a pre-generated mesh is much less taxing than having to generate a mesh dynamically based of slider data.

So, what causes blackface?
Basically, a NPCs facegen mesh (.NIF) consists of multiple mesh shapes (TriShapes). These shapes each correspond to the various headpart's that makes up the complete head.
Headparts are the individual head building blocks that make up a face (head, eyes, hair, brows, beards etc), each of these have an individual headpart record stored in the game plugins.
The Facegen's TriShapes are labelled with a string (text) that matches the name of the headparts in the game plugin. With me so far?
An NPC will also have an NPC record inside a plugin (ESP/ESM), and in this NPC record it will list all the headparts that the NPC uses.
It will also list any other slider data used to "morph" those headparts, as well as tint data for any overlays (scars, warpaints, complexion etc) and colors (makeup, skin tint etc).
Blackface occurs, when the headpart labels in the facegen mesh dont match the headparts listed in the actual NPC form in the plugin.
If the NPC form says that the actor has a hair headpart named LongHair002 but the facegen mesh has a string labelled HairShort001, then the game will get confused and the result will be a blackface NPC.
Thats the basics of it anyway.

The basic fix, by the way, is to make sure that the winning NPC record and the winning facegen assets match. But we will go in to more detail in a moment. First lets discuss a few scenarios.
This mismatch in data can happen for a few reasons, and I'll cover the ones that I can think of.

Scenario 1:
Load order vs Asset order.
Mod organisers like MO2 and Vortex allow independent managing of both assets (meshes, textues, scripts etc) and plugins (esp, esm, esl) independently of each other.
This is an important concept to comprehend.
Let's say you have two mods that modify NPC looks. They both handle multiple NPCs, but unfortunately they overlap and both edit Lydia.
You install MOD A first, by default it gets added to the bottom of your load order.
Now you install MOD B, which is now the new last loaded mod. You realise that you prefer MOD A's visuals, so you move the plugin for MOD A down to the bottom.
BUT, you havent moved the actual mod folder down to match it (Vortex can use rules to handle this but I am a MO2 user and not too familiar with it).
What this means, is that the GAME RECORDS are expecting all the visual changes from MOD A, but the actual assets being loaded are going to be coming from MOD B as the folder order wasnt adjusted when you moved the plugins around.
Simple fix for this is to just move MOD A's asset folder back below MOD B. Done.

Scenario 2:
BSA's.
Another important concept to understand is how asset loading works in Skyrim. Skyrim can use BSA's to archive and compress assets in to a single file (basically a Bethesda version of a .rar/.zip file).
This is great for loading times, but can cause issues at runtime. Why? Because loose files will ALWAYS take priority over files in a BSA, no matter what the order is.
So, using the same scenario as above, we have MOD A and MOD B both affecting Lydia. This time however, you make sure that both the assets and the plugins from MOD A gets loaded last.
The problem, is that MOD A uses a BSA, and MOD B uses loose assets.
This means, that even though MOD A is loaded last, the loose assers of MOD B will still take priority over anythign in MOD A. Which is bad for us, because it means we will still be getting Facegen from MOD B while trying to load NPC data from the plugin in MOD A.
The solution? again, manage your load order correctly first, then extract all the files from MOD A's BSA so that it is instead using loose files. Bethesda Archive Extractor on Nexus can handle this for you.
Just run the program, navigate to your mod managers installed mods folder, extract the BSA in the same location then delete the BSAs after to free up space. Done.

Scenario 3:
Unexpected mods.
This is another common cause of blackface and one that catches a lot of people out. Unexpected mods that load later which may also affect NPC records.
We spoke about NPC records before and discussed how they contain a lot of data about how the NPC looks, but they also have a lot more data on them, things like raw stats, names, inventory, spells, ai packages and classes. There's quite a lot of data in an NPC record and its quite likely that other mods will need to make changes to various non visual changes to NPCs.
An obvious example would be mods like "AI Overhaul". This mod alters NPC packages, which requires making changes to NPC records to add those packages to them.
The problem with this, is that these are the same NPC records that contain all those visual changes needed for your NPC visual ovrhauls to work.
So, again, we have our MOD A and MOD B, both affecting Lydia. We want MOD A's changes to win so we've managed our load order so that MOD A loads after MOD B, we've adjusted our assets order the same way and we've ensured we've extracted the BSA's for these mods where necessary. Everythings working, then we install a few mods, and suddenly Lydia has black face again.
We do some digging and we find that MOD C is trying to change Lydia's default armor and inventory items, but all the visual data from MOD C is still the same as vanilla. As such, MOD C also doesnt have any facegen data, because on its own it wouldnt need it. But this means we now have Facegen From MOD A, and visual data that matches the vanilla NPC face. Mismatch = Blackface.
This time though, we can't just move MOD A below it again, or we will lose the changes the MOD C brings about.
I mean, it IS an option, if you come across a mod conflict that doesn't do anything major and you can live without then you can just move your load order around, but if you want the changes for both there's only two options. Option 1, is look for a patch. AI Overhaul for example, has gotten a lot of traction, and many of the big NPC overhauls will come with an AI-O patch that you can use.
But if no patch exists, then you're only other option is to patch it yourself using XEdit (collective name for TESVEdit, SSEEdit, FO4Edit etc).

Now, I won't be explaining how to use XEdit, there is other guides out there and it's far too confusing to type in an article that is already long winded. But, Once you have gotten the hang of basic XEdit functionality here is what you can do to make a quick patch of an NPC, in our case Lydia.
First, navigate to the plugin of the mod that has the visual changes you want, expand it, then expand NPC group. Find the actor, in our case Lydia, right click the form and choose copy as override. Scroll down to the bottom and choose to copy it to a NEW ESP. Name your new plugin (LydiaPatch.esp for example). Now, select Lydia again. You will see on the right window that all versions of the Lydia record are displayed with the plugin name at the top of the window thats making that versions changes. To the far right there will be your freshly copied patch version, which currently is just a duplicate of our MOD A (the one with the visual changes). You will however, also see a bunch of colored highlighting, this all representes various states of conflict. Green background means its all gravy, there is no conflict, but the other colors (yellow and red mostly) indicate that there is some sort of conflict. This makes it easy to see what fields have changes in earlier versions of the record that may not be present in the winning override.
Now, conflicts are not the end of the world, they are often unnavoidable. The goal isnt to make the whole column green, it is instead to make sure that you've inspected each colored conflict to confirm it is using the changes you want. In our case, we will see that there is conflicting data on the "Default Outfit" field, as well as on the "Items" field, as this is the two fields that were modified by MOD C. We can safely drag data from MOD C over to our patch as we see fit. Our main concern here is to make sure that we do not make any changes to any of the visual fields, these all need to remain the same as they were in MOD A because we will still be using the Facegen from MOD A.
Once we're done, we can close XEdit and save our patch, now all we need to do is make sure our patch is active and loaded after MOD A and MOD C.
Note, if you are still adding more mods then it's entirely possible another mod will come along and make more edits to Lydia, just keep an eye out and if you run in to problems then just fire up XEdit and add further changes to yoru Lydia Patch, or make a new patch.


Ok, so those are the three most common scenarios that I can think of.
Let's talk about other possible solutions, and the issues that can come with them.

Export Facegen! I see this answer a lot, and honestly, it's just asking for problems.
Basically, a lot of people will say to fire up the creation kit and re-export facegen for that character, that way the facegen and the plugin data will match.
And, yes, that is correct. But the problem with this is that there is limitations to what the CK can export.
See, most NPC visual overhaul mods arent actually made in the Creation Kit, but are instead made in Racemenu or ECE or an alternative.
These mods unlock morphs and slider ranges that are well and truly extended past vanilla ranges. But the creation kit doesn't know about these ranges, it only knows about vanilla morphs ranges.
Lets say a modder makes a face, Eye height is at the minimum, but due to Bethesda's often terrible headparts, the eyes still seem too high. So, with the help of racemenu they use one of the secondary racemenu eye sliders to reduce the height further.
They then adjust features of the nose to thin the bridge, flare the nose wings, minimise the nose tip and point it up a tad. Getting there, but we need some work on the mouth, lets add some mouth corner depth and a hint of a cheeky smile, bring the teeth forward. Now lets add some weight to the lower cheeks, round out the jawline... pretty good! All of those changes were made using racemenu only sliders. None of them other than the first eye height slider actually exist in the vanilla game. But we're not done yet, lets take it in to racemenu sculpt and really fine tune it!
7 hours later the modder is done, theyve got a face they like, and they export it using racemenus built in export functions. To make the mod an NPC they now also have to go through a bunch of workarounds to merge that exported data in to a CK exported facegen (its a pain in the ass to do).
Finally hey have a functioning facegen for their NPC character, they upload it as a mod, we download it, aaaaand because of our other mod conflicts we have blackface. Soooo we decide to head on in to Creation Kit so we can just re-export the facegen... And here's the rub, virtually all of those changes the mod author had made to perfect that face, have now disappeared. We are left with an NPC face that DOES have all the right headparts, but the vast majority of morphs and tweaks that were made to actually shape the head are now gone, only the basic handful of vanilla slider changes will be brought across. The result will be a horribly ugly potato shaped mess.
Now, that's not to say you CAN'T export facegen, if its for an NPC that's only been modified with vanilla sliders then it will work just fine, it's just not very common to see that these days, and in most cases you'll end up with borked faces. I mean, they wont be blackface anymore but they'll sure be ugly.


Anyway, this has already taken quite some time, I think I will leave it there for now and will add more if I think its necessary.
Leave any comments if you see any mistakes, or suggestions, or if you have any questions and I'll try get to them when I can.