This change is necessary for kd_tree to be able to handle more than 65536 points, which could happen if it's processing a list of triangle centers (since triangle indices are not limited to 65536).

Unfortunately, this change will probably result in warnings being generated about uint32_t being converted to uint16_t.

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;

• Added functions to MatTransform: ToGLMMatrix, ApplyTransformToDiff, ApplyTransformToDir, and ApplyTransformToDist.
• Made MatTransform::ApplyTransform an inline function.
• Added some constructors for Matrix3.
• Made many of the functions in Object3d.hpp constexpr. For some, this necessitated changes to the implementation in order to comply with the rules for constexpr functions, but in no case was functionality changed. I was not thorough; there are lots of functions that could still be made constexpr.

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.

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.

The original (written by me) had two bugs. One would make the code segfault if a partition number in inTriParts was negative; it was probably never triggered. The main bug would cause all triangle segment assignments to be lost if there was an empty partition at the end of the list.

Two commits were added to this code over the past two years to try to fix the empty-partition-at-end bug and additional bugs introduced in those commits: eae5755 and https://github.com/ousnius/nifly/commit/bb1f7a6f56f045ddb321b329a3bfc8542b5eaa92. Neither fixed the original bug, and each had problems: the resulting code would tend to reassign triangles in some circumstances. So I reverted both of those commits and fixed the original bug.

The mistakes in the two bug-fix commits suggest that the original code was unclear. I've tried to make it more clear by adding comments, renaming variables, and deleting blank lines that made closely related code seem unrelated.

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. 😄

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

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.

For review, I suggest looking at each commit individually.

For 05db039 (memory management), I suggest you do not look at the headers. It's only noise, the real changes are in the source files

Going to test the changes soon

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.

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.