Fallout 76 and CMake Support

[SK83RJOSH]

Hello,

I've recently found myself wanting to rip some game assets from Fallout 76 for 3D printing. Unfortunately this is the only plugin with any hope of supporting it, so I made the necessary changes to both nifly and the plugin myself. I also updated this project to use CMake, fixed up some of the C++ errors, and added the ability to load PNGs from disk when available.

If you're interested, I can also go ahead and implement support for loading newer DDS files automatically and storing them inside the .blend file by adding some code to the C++ wrapper. This would make the PNG code obsolete and be the most ideal for your users, but it means you'll definitely need to merge this so we can make it easier to deal with the C++ side of things.

This branch also disabled the test suite for C++, but I can fix that before merging and add some scripts to generate the visual studio solution too. Shouldn't be a major problem to add some FO76 specific tests either since you don't have much interest. 🙂

Cheers, Josh

[BadDogSkyrim]

You did whut.

Okay, wow. Some things:

• Gotta have that test suite, I can't maintain this thing without it.
• Did you get the latest version of nifly? I'm a few versions behind and I want to stay close enough to their version that I can keep up with them.
• Also too anything you did to enable FO76 support at the nifly layer may be of interest to them.
• I'm not sure what you've done with png files. I just did something on export to replace a png extension with a dds extension so you can work with pngs in Blender but export for dds files. Sounds like you have something more sophisticated going on. As for supporting the latest dds formats, YES that would be fabulous. But what would it look like in Blender? My workflow is often: import the model; switch the texture files to pngs; muck with the texture files in blender on the 3D model; export edited textures as pngs; convert to dds. Normally blender can't manipulate dds files, tho it can show them. Would your fix make them editable?
• I'm about to be on the road for two weeks, and this is going to require real attention to review and merge and all that. So give me some time and I'll have a look in the second half of September.

[SK83RJOSH]

You did whut.

Too much free time on my hands last week... 😇

Gotta have that test suite, I can't maintain this thing without it.

I can get that sorted out today 👍

Did you get the latest version of nifly? I'm a few versions behind and I want to stay close enough to their version that I can keep up with them.

Yeap! It's based on the latest release, with some additions made for FO76 materials

Also too anything you did to enable FO76 support at the nifly layer may be of interest to them

I hope so, I made a pull request with the material support here: https://github.com/ousnius/nifly/pull/37

I'm not sure what you've done with png files. I just did something on export to replace a png extension with a dds extension so you can work with pngs in Blender but export for dds files. Sounds like you have something more sophisticated going on.

I added a simple check on import that scans for textures with their extension changed to png. If they all exist, we load those instead, and your code takes care of restoring the old DDS extension on export. Otherwise it falls back to the old code. Fairly small change luckily 😁

As for supporting the latest dds formats, YES that would be fabulous. But what would it look like in Blender? My workflow is often: import the model; switch the texture files to pngs; muck with the texture files in blender on the 3D model; export edited textures as pngs; convert to dds. Normally blender can't manipulate dds files, tho it can show them. Would your fix make them editable?

My fix would be to include Microsoft's DDS tools in NiflyDLL so we can import them as PNG and export to DDS from python. The workflow could be as simple as some checkboxes during import and export. Depending on what's the most useful, we could embed them inside the .blend file, or make a copy on disk with the extension changed (for external tools like photoshop).

I'm about to be on the road for two weeks, and this is going to require real attention to review and merge and all that. So give me some time and I'll have a look in the second half of September.

No problem! There's no rush on my end, I just wanted to bring this to your attention before you made any big changes. 🙂

[SK83RJOSH]

By the way, this pull request looks very scary, but most of it is just file renaming and so on. The bulk of the relevant code changes are in two files within pynifly, with some very small changes to NiflyDLL. Unfortunately GitHub chokes on stuff like this... so apologies in advance for when you get around to reviewing 😅

[BadDogSkyrim]

Jeebers, converting images on import so blender can handle them would be fabulous. I'm inclined to make them internal because you can always save out the image. But I can easily have a dozen or so models in blender at once and if they all have 3 or 4 texture files it might become a problem. I guess if we keep the current dds->png code and make it a flag, the user can choose either one.

Maybe keep this change a clean follow-on to the others so we can look at it separately.

One other point: I've heard it's best not to have project files like build tools etc under source code control. What's your opinion on that?

I took a quick skim through the changes and they seem fine at first glance. Will do a proper review later.

[SK83RJOSH]

I can easily have a dozen or so models in blender at once and if they all have 3 or 4 texture files it might become a problem.

Aye, I think this definitely is one good reason to make it an option for the user. Maybe also add some tool menus to embed/export everything on demand depending on your use case. Simple additions, but very powerful for those who need them. 🙂

Maybe keep this change a clean follow-on to the others so we can look at it separately.

I think that's wise, as there's a lot to discuss there certainly. So perhaps we can track it in a separate issue and weigh our options? 😄

I've heard it's best not to have project files like build tools etc under source code control.

Largely depends on what they are, I'd say. Configuration files for build tools, scripts to install required tools, and things of that nature are generally fine. Not a great idea to have a lot of binary data, such as executables and dlls themselves, but that's generally down to git not handling these types of files well in the past.

These days git has large file support that makes those a bit better to work with, so, when necessary I think it's okay to bend the rules so long as you've got that configured and have permission to share them.

That said, I typically only ever include what's necessary for a new contributor to come along and build things. With documentation on anything else they may need in the wiki. 🙂

[BadDogSkyrim]

Okay, I'm back and ready to merge this in. We discussed re-enabling the test suite, which I'd prefer you do before I merge, since I don't know what you did to disable it. If you can add some basic FO76 tests, that would be excellent. Just export/import of a mesh at the blender level is fine. I only do tests at the C++ level if I need to or if it helps with development.

Once we get this integrated we can talk again about your idea for importing texture files.

[BadDogSkyrim]

I wasn't able to merge the pull request because of the build system changes. Instead I cherry-picked the relevant changes and incorporated them into the latest version. Thanks!