Some models appear black when importing into Blender

[Crash180]

I understand this is a pathing issue where Blender can't find the materials but I have noticed from importing a variety of nif's that the texture and material paths vary. The ones that import with visible textures use a relative path while the ones that appear black use an absolute path. Also in Nifskope the visible ones have a BSShaderTextureSet which is absent from the black ones. I tried recreating this path and placing the necessary materials and textures there but it did not work. So I have a couple questions.

1. Is there a way to make the absolute path work like I tried?
2. Each layer of the imported models have their own .mat file. If I link the associated .dds file under Base Color->Image Texture in the materials properties it all looks good. Is this a working solution or a problem waiting to happen?

[RoNin1971]

I bet you are using pynifly. As nice as it is to have, it comes with flaws & a stubborn author.

1. It only looks at the texture set, ignoring the material.

2. it expects the textures\blah\blah.dds files to be relative to the path of the mesh, truncated at .\Data\

3. it does not check if the texture is actually there, nor does it use the path set for textures in blender.

 

Note:
Only opaque textures turn black, anything with transparency turn completely invisible.

 

I reported all of this long ago and told author the textures fail frequently, especially as I keep my own nifs separate while working on them, but still use vanilla materials & textures.

But that's where textures should/must be according to the author.

 

Afaik, a full path doesn't work any better. It cuts everything before & up to the \Data\ and replaces it with the one from the mesh. The game-engine does a similar thing. (Some vanilla nifs contain full paths and they still work, although the path does not exist)

 

Re-linking the right dds files is a "working solution" within blender, BUT keep in mind that although the materials are not used/displayed it does store them on import and re-adds them on export.

Changing the texture this way will be a "problem waiting to happen" as you will get to see the textures from the material everywhere, instead of the one you added to the texture set.

 

I usually import a nif after making sure a material is present, preferably, and a texture set to correspond with it (mandatory). (which both is not always the case)

 

In case of sets, I now put them inside my exported data folder (on a separate drive, not under fallout install) I import one. Make sure the textures are ok and rename the .mat to match the texture name. Then import the rest and set the texture .mats to the same ones. So they all use the same .mat for the same texture. Saves a lot of copies & clutter.

Change one and you change all. Otherwise you'll have a truckload of *.mat.001 to *.mat.999.

 

Sometimes (especially on individual nifs) I just replace the material node for a correct one using Nifskope afterwards.

 

Keep in mind that nifskope, CK & the game will all ignore any textureset unless no material is set. This is the 'reverse' of what you get in Blender!

 

Edit:

BTW do not copy/paste but create duplicates. When you copy a mesh blender will also copy the material & texture. Leaving you with long lists of copies. When using duplicate, it uses the same as original. Saving you from the clutter.

[Crash180]

The internet told me the black textures were from missing links hence my "working solution". I would open the Nif, identify the BGSM file, open that, see what texture it was using and then relink that in Blender.  I wasn't sure about this as a solution so I decided to ask. The one model I did do this way looked good in game so maybe I was lucky.

I am currently working only with vanilla items and I can find the materials and texture sets for the meshes in their appropriate place under /Data in the files I extracted. So while I think I understand the workflow you described I still don't understand how to get the textures to show in Blender. If the source Nif looks good, the materials and texture sets are accounted for and where Pynifly thinks they should be then it should work.? That's why I thought the absolute path was causing the problem because it was looking in a place where the files did not exist. Kind of like Nifskope showing pink textures when it can't find them. Also in Blender all the visible textures have a .dds file in the materials property palette for each component layer while the black textures lacked a .dds file. This is where my logic is stuck at. Feel free to knock it loose.

Looks like I did do a copy/paste once instead of a dupe but easily fixable. Thanks for that tip.

[RoNin1971]

Quote

The internet told me the black textures were from missing links hence my "working solution".

That's correct, as pynifly creates the "missing links", by adding a non-existent texture (path), without any checks. (...and using blenders path to textures instead, or ask the user, or have a setting to tell it where they are...)

 

Your "workaround" is good. As long as you point it to the same texture as the material. You don't even have to look it up most of the time. The correct filename is usually there, you just need to adjust / point it to the right (relative) path.

The only time you need to search for it, is when there is no textureset (or its empty). You should however not use this method to load a different/alternative/custom texture, as it will not show up anywhere else since the texture from the material is still used.

 

Note: Purple in nifskope means the material is wrong/can not be found, -OR- if no material is set, it means the texture can't be found.

When there is no material & no textureset, it shows up white.

 

Nifskope, CK & the game all show the textures as supplied by the material, ignoring the textureset. UNLESS no material was set. (empty string)

Pynifly ignores the material and ONLY looks at the textureset. (which is wrong, but alas, its the way it is)

& it adds the relative path to a truncated version of the mesh path.

 

So, when you have a mesh in: D:\FalloutExport\Data\Meshes\Mymesh.nif

& a texture at: Textures\Mytexture.dds

The texture is expected to be at: D:\FalloutExport\Data\Textures\Mytexture.dds

 

If you have a mesh inside D:\Temp\WIP\mymesh.nif (note the lack of \Data\) it has no idea what to make of it.

In case that would be: D:\Temp\WIP\Data\meshes\mymesh.nif, but the texture is actually at: D:\FalloutExport\Data\Textures\Mytexture.dds Niskope has no trouble with it, since you can supply a path for finding (texture)files (D:\FalloutExport\Data\)

Pynifly is however hardcoded to look only at D:\Temp\WIP\Data\textures\mytexture.dds in this case. "Not there? Though luck".

 

[MrShadowBlood]

I'd like to throw in some stuff in the flames. I am having same issue as well but for Skyrim. All my stuff is in the backup drive which I import to blender which you may know becomes black. Modded stuff installed in my main drive show textures perfectly but all the bones have become un-connected. Nifs when shown in nifskope always have the texture showing up.

 

Forgive me if the answer is clearly out there but how would I make the textures show up in blender without modifying the Nif texture path. Again forgive me if I am being ignorant, I just have trouble understanding things.

 

[RoNin1971]

You should not adjust/change paths. Only make sute the texture+path are the same as inside the material file.

 

second, make sure to use a .\Data\Meshes & .\Data\Textures (within the same folder structure)

 

That way the nif & textures should work everywhere.

[MrShadowBlood]

 

Thank you very much!

[BadPup]

OMG. As the "stubborn author" of pynifly, I have to say there's a fair amount of misinformation on this thread.

1. Pynifly does read the materials file and gets textures from there, has for quite a while. 
2. Pynifly looks for textures in two places: first, the file tree that the nif was loaded from. So if the nif is in C:/something/meshes/etc/foo.nif then the textures should be in C:/something/textures/... Then, if that fails, it looks in Blender's textures file directory (Edit > Preferences > File Paths > Data > Textures). That's new behavior as of, like, a year and a half ago, at the urging of people like the above posters. (@RoNin1971 did you file a bug report? And are you sure I didn't close it as "fixed"?)
3. (It should probably look in the game folder and doesn't. I'd have to figure out how to find the game folder and mostly Fallout 4 archives aren't unpacked, anyway.)
4. I'd have to read the code to be sure how absolute paths are handled. RoNin1971 says everything up to data is truncated and if the remainder is handled like a relative path I would consider that correct. 
5. Pynifly does check to see if the texture is there. If it can't find one it creates an empty image node so you can put in the texture yourself. @Crash180, you're doing exactly what I intended. 
6. As RoNin1971 points out, the way FO4 works any texture paths you put in the nifs--so any texture paths in your shader nodes--is entirely ignored by the game engine if you link to a materials file. The materials file rules.
7. RoNin1971's pointers for how to handle blender materials when you have multiple meshes that share a FO4 materials file (make all the meshes share one materials file) are sensible and how I handle mine.  I suppose it would be possible to have the importer look for materials that reference the same materials file and reuse them on import. But I can think of a lot of ways that could screw up, too.
8. For things to show up correctly in Blender, the thing that matters is the shader node tree. Look there for problems.

The workflow of:

1. Unpack all vanilla (+ DLCs, + mods you care about) to a folder tree outside the game folder;
2. Do all your work in your own folder tree;
3. Have vanilla textures loaded by pynifly automatically through the File Paths mechanism

...works, and is how I work. Works for both Skyrim and FO4.

If you want my attention, the place to post is the github issues or discussion tabs. That's github FROM WHERE YOU DOWNLOADED pynifly, so I know you know where it is.  Anyplace else, I might find it or might not. 

[RoNin1971]

I might have sounded a bit harsh, but fact is: I love you for creating pynifly and consider it a must have essential.

Nothing comes without flaws though. Least of all me

Anyway, the info might be old. For sure. Haven't updated for a long time as the older versions fit my needs better. Last time I tried updating (everything, not just pynifly) I couldn't produce a working collision for months. So, I'm definitely sticking to the old.

[BadPup]

No worries. I understand liking a stable dev environment, but some of the fixes might be useful to you.