Data fields not preserved on import/export, in BSLightingShaderProperty

[dev-nll]

Various fields in BSLightingShaderProperty don't get preserved when importing into Blender followed by exporting back to mesh.

Not all BSLightingShaderProperty have this problem, only the highlighted ones:

These are the altered data fields in BSLightingShaderProperty:

Original mesh prior to Blender import/export:

pinus04_599919f0passthru_lod.zip

[BadDogSkyrim]

I'm about to play with shaders. I'll include this stuff when I do.

[dev-nll]

I'm about to play with shaders. I'll include this stuff when I do.

One more thing: The shape sometimes doesn't get preserved when importing/exporting; the ".001" at the end is deleted sometimes. I've attached a mesh where this happens. This is fairly important since DynDOLOD requires correct shape names in this data field.

mesh.zip

Also, this is off topic, but it would be extremely useful if default export settings/options are preserved each time we save something (for example, it remembers whether we have the "save modifiers" box checked, and it remembers the previous filepath we exported to, only within the same session of course). Although I'm not sure how easy that would be to implement, just thought I'd throw that out there.

[BadDogSkyrim]

Huh. So there are meshes out there in the wild that have .001 extensions in the name?

The .00n extensions are generally added by Blender to keep object names unique. In pynifly on export I've been assuming any such extensions were added by Blender and were not part of the original nif mesh, so I've been stripping them.

[dev-nll]

Huh. So there are meshes out there in the wild that have .001 extensions in the name?

The .00n extensions are generally added by Blender to keep object names unique. In pynifly on export I've been assuming any such extensions were added by Blender and were not part of the original nif mesh, so I've been stripping them.

Yeah, all of the original meshes in Nature of the Wild Lands, like this:

When I export from PyNifly, it will delete the suffix ".*" (e.g. ".001") if and only if that suffix exists on the first BSTriShape. Any such suffixes on the 2nd, 3rd, .. BSTriShapes will be left alone.

Ideally, for my application, all suffixes are left alone, since they exist in the original model. Is there a way to detect whether the suffix already exists when the mesh is first imported, and if it already exists, do not delete it when it gets exported?

[BadDogSkyrim]

Yes, a flag like that could be created, or it could be an option on export, or both. I have a number of flags that are set on import so they can be the default on export.

[dev-nll]

I'm running into the same issues with V13.0.0.

I've attached an example. Upon export, the name "picea_8(1).001" changes to "picea_8(1)", and Texture Clamp Mode "CLAMP_S_CLAMP_T" changes to "WRAP_S_WRAP_T".

test.zip

[podvornyakva]

Maby it is cause of multiply import, where the same material is present? Only new scene and one object of a type import. Or do handwork to change material to duplicated/similar meshes... either disable material copying in blender. Like if you will import body, hands and foots - you will get three copies of one material. Same with most of the trees and grass. They have same material settings. Only difference may occur in texture path. Those not in shader settings. They are in the custom data on material tab. Check it out and make sure that one copy of material did not override other upon export. Also. Te naming wrong - "picea_8(1).001". It should not happen anyway. It is a copy of object, as Bad Dog say. Blender interpret that so. Each object in the game have unique name. Why should that be otherway in Blender? It is across a logic.

[BadDogSkyrim]

I'm guessing this is just a bug. I was a bit lazy with shader attributes the first time around. I just revamped the whole scheme and could have gotten something wrong.

@podvornyakva, the problem is when a nif already has .001 at the end of a name. pyNifly thinks it's irrelevant and strips it, so the exported name doesn't match the import.

[podvornyakva]

the problem is when a nif already has .001

Probably it is a bug. Bethesda's or other moder. I've never come to that kind of "behavior". @dev-nll Give me *.esp/esm/esl where is an object with that name scribed. I check it with xEdit.

[dev-nll]

I'm guessing this is just a bug. I was a bit lazy with shader attributes the first time around. I just revamped the whole scheme and could have gotten something wrong.

@BadDogSkyrim To clarify, it's not a newly introduced bug in v13.0.0, It's the same behavior as with the previous version. I just wanted to bring it to your attention, that's all. Mesh example future reference

@podvornyakva It's from this mod: NOTWL

[podvornyakva]

It's from this mod: NOTWL

Curiously that i'm also try to lay my hands on that stuff. But meshes of that mod do not imports with pynifly...

[dev-nll]

It's from this mod: NOTWL

Curiously that i'm also try to lay my hands on that stuff. But meshes of that mod do not imports with pynifly...

Try my example above, it comes from NOTWL and works. Also, try deleting the parts of the mesh you're not working on (e.g. collisions) and then import only the part you're working on (e.g. trunk). If this doesn't work, something strange is happening because it works for me. I suggest also looking for error log messages when the import fails.

[podvornyakva]

Try my example above, it comes from NOTWL and works.

Nevermind. My fault, BSA browser stripped away all files while unpack. After running WINE with .NET prefix all come to normal.

[BadDogSkyrim]

Should be fixed now. Let me know if there are still issues.