ousnius / nifly Goto Github PK

nif file version is 20.6.0.0, nifly check failed in NifFile::Load()

This is more a question than an definite bug report or PR.

In OptimizeFor, shouldn't the normals, if they exist, be copied to the particleNorms before particleNorms is resized? Or is the intention that if the number of normals and vertices differ then all of the particleNorms are populated with <1, 0, 0>?

You can see what I mean on this branch, renngar@db550f2.

My expectation was that if there were more vertices than normals, the particleNorms would be extended using <1, 0, 0> and if there were fewer vertices, then normals would be copied to particleNorms, which would be truncated to match the length of vertices. I don't know if my assumption is correct or not, so I thought I would ask.

For OptimizeFor and SSE NIF Optimizer, add a new option to find mismatching external emittance flags between BSXFlags and shaders and env map shader type without the env map shader flag.

See https://gitlab.com/G_ka/Cathedral_Assets_Optimizer/-/issues/116

bulk convert nif static meshes to fbx?

Hello!
When I'm building nifly DLL as a static library, it's size is 18 mb(in Release mode). Is this normal or am I doing something wrong?
I previously used cmake-gui to build the .sln project. This is my first time building dependencies on other libraries so I'd appreciate help with this.

Hey, I have made a fork of this for use as a git submodule in a separate repository that adds C# adaptation via SWIG. I want to use that SWIG repository to output a Nuget package in support of a planned Synthesis patcher that updates NIF files. I'd like to include a DLL built from my fork, and credit you, in my Nuget package. Is this OK? Thanks for the library.

NifFile::SetVertsForShape calls BSTriShape::Create if shape is a BSTriShape and the size of verts does not match the old number of vertices. And the first thing BSTriShape::Create does is flags = 14; So in my case it resulted in the flags switching to 14 seemingly out of nowhere when I added a vertex here, deleted a vertex there in already existing files/shapes.

Hello!

I know Fallout 76 isn't fully supported as of now, but I did some testing with a modified version of PyNifly and found most models, skeletons, and etc seem to load perfectly. The only issue I've come across so far is that texture are not populated correctly it seems. I'd be willing to toss a PR your way if you could give me some pointers on where to get started. 😄

It works in Skyrim SE, it probably works in other games that use a NiSkinPartition too, it works in NifSkope, it works in the NifTools Blender NIF Plugin.

But it doesn't work properly in any program based on Nifly.

Hey, I have a small thing to report:

For FO4, if you define a set of, say, 7 segments and assign all the tris to the 4th (so 5-7 are empty) then nifly will assign all those tris to the last segment, not the 4th.

Arguably, this is a case where if you do stupid things, stupid things happen. I found it because all the body parts in FO4 use the same segmentation scheme: 7 segments representing nothing, head, right arm, torso, left arm, right leg, left leg, in that order. So I just defined all the segments and assigned faces as needed. Some of the armors only needed a torso segment, leaving segments 5-7 empty. Took me quite a while to figure out what was going on.

I dug into the nifly code and the issue is below, in geometry.cpp, SetSegmentation(). The original code is commented out below. It was searching for the last filled part, but the trailing empty segments were confusing it. Capturing lastFilledPart during the first loop fixed the problem. (I can submit this as a pull req if you'd prefer, but I wasn't sure you'd even consider it a real bug.)

size_t lastFilledPart = 0;
for (int i = 0; i < static_cast<int>(triInds.size()); ++i)
while (triParts[triInds[i]] >= j) {
lastFilledPart = j;
partTriInds[j++] = i;
};

//for (size_t i = 0; i < partTriInds.size(); i++)
// if (partTriInds[i] > 0)
// lastFilledPart = i;

Almost all "Get/Set...ForShape" methods of NifFile class identify the shape by its pointer:

const std::vector<Vector3>* GetVertsForShape(NiShape* shape);
const std::vector<Vector3>* GetNormalsForShape(NiShape* shape);
and so on

But a couple of "Colors" methods go with the name of the shape instead:

const std::vector<Color4>* GetColorsForShape(const std::string& shapeName);
void SetColorsForShape(const std::string& shapeName, const std::vector<Color4>& colors);

And this is a bit confusing. I would suggest adding NiShape* shape overloads of these two for consistency and predictability.