Dev 9 Fallout New Vegas models not occluding models behind them

[dpcollier128]

This seems to occur with any nif file from the game. A comparison between Dev 8 and Dev 9 is shown below:

This effect does not occur in the game, only in nifskope Dev 9.

[gavrant]

Looks like the "z-buffer/depth testing" bug I've encountered with Dev 9 in Fallout 3 meshes.

Could you test the meshes with this version of Dev 9 : https://github.com/gavrant/nifskope/releases/tag/v2.0.dev9a
It's an "alpha release" from my fork, with some fixes and improvements accumulated since September 2023. This includes a big fix for FO3 shader support, including the "depth test" thing. I believe that fix should help with FNV meshes too.

[dpcollier128]

Kool. This alternate version seems to work for solving my issue. I'll keep playing around with it, but the first results are promising.

[fo76utils]

The same issue has also been fixed in this fork, as well as a number of other bugs that have been introduced between dev8 and dev9.

[gavrant]

@fo76utils Your fork did not fix the issue in question. As far as I see from a quick test on one of my FO3 meshes and a quick look at src/gl/glproperty.cpp, it still does not support the FO3 shader blocks (BSShaderLightingProperty and the blocks inherited from it).

Off topic: my Windows AV (the one from Microsoft, built into Win 10) does not like your most recent NifSkope_2_0_2024-07-24-windows_x64.7z from 14 hours ago and insists on killing it with fire. The .7z's from older releases are fine. A screenshot from my browser:

[dpcollier128]

Well, it worked for me for a little bit, but it stopped working for some reason. Oh, well. Oh, and I didn't get any warnings from Windows 10 about it being infected with something. First thing I did was scan the files.

[gavrant]

@dpcollier128

Well, it worked for me for a little bit, but it stopped working for some reason.

Do you mean the version of mine or of @fo76utils ?

[dpcollier128]

yours. I was working on something earlier, and the meshes started to do that same hollow-looking thing it would do... maybe windows forgot what exe I had set it to prefer, and it used the official Dev 9 build I still have installed. I'll try your version again later.

PS: Nevermind. I was messing with that nif in Blender, and for some reason, Blender didn't apply ZBuffer_write on export, just ZBuffer_test. False alarm.

[fo76utils]

@fo76utils Your fork did not fix the issue in question.

I did fix the specific issue reported by the OP, here is what the same or similar model looks like with my current build of NifSkope:

In the original dev9 code, the default was Z write off, changing that to on fixes most models (other than effects), although I did not make extensive modifications to code related to older games.

Regarding the AV warning, a number of people report that for every new release, but I cannot really do anything about it, and it only seems to affect very recent releases (the same older releases that you say are fine were also incorrectly flagged before).

[dpcollier128]

Yep. Though I don't have experience with your build, fo76utils, I know that false AV warnings happen all the time, too.

[dpcollier128]

Anyway, I think this issue is solved.

[gavrant]

@fo76utils

In the original dev9 code, the default was Z write off, changing that to on fixes most models (other than effects)

Yes, so it did not fix the bug, because your code just defaults to some values WITHOUT actually reading them from the shader block. I implemented a proper fix - full support for BSShaderLightingProperty blocks, with reading the flag values from them.

It's not only about z-buffering. Example with my "guinea pig" FO3 mesh:
This is how it looks in NifSkope from fo76utils:

And this is how it looks in my NifSkope:

[fo76utils]

Yes, so it did not fix the bug, because your code just defaults to some values WITHOUT actually reading them from the shader block. I implemented a proper fix - full support for BSShaderLightingProperty blocks, with reading the flag values from them.

I never claimed to have implemented a full fix to every issue with pre-Skyrim games, only that I fixed the specific problem reported by the OP. I am not sure why you keep fighting over this. And for what it is worth, I do not think you have "full" support either, because that would involve (re)implementing the shaders for those games, with normal mapping and all the other effects.

[gavrant]

@fo76utils Sorry, getting a bit "competitive". But to be clear, I just think that my fix in comparison to yours a) fixes the z-buffer issue properly, actually picking data from mesh files instead of always defaulting to some hardcoded constants, and b) covers the whole FO3 shader thing, not just z-buffering.

And for what it is worth, I do not think you have "full" support either

"Full support" as far as it goes to reading the data from the mesh file, not the stuff from shaders folder. And truth be told, my solution does not support the "Falloff" fields from BSShaderNoLightingProperty and some refraction/parallax settings from BSShaderPPLightingProperty (yet?). So it may not be "full full", but still is definitely "fuller".

[fo76utils]

Sorry, getting a bit "competitive".

You do seem to be the type that just keeps fighting until they get the last word. I made it abundantly clear enough already that I am well aware of the limitations of my previous fix, and that older games are not the focus of my fork. I will have a look at implementing a complete fix though, including restoring shaders. Mostly as a matter of principle, as very few people use my fork for anything other than Starfield, and I am quite sure not even a single change from it will ever be merged into "official" versions.

Also, I am going to block you because I had more than enough of pointlessly fighting people on forums. Bye.

[gavrant]

@dpcollier128 If you still use the version of NifSkope I uploaded here 3 days ago, please replace it with this: https://github.com/gavrant/nifskope/releases/tag/v2.0.dev9a . It got a major fix for saving .nif's with collisions and a few other lesser tweaks.

[dpcollier128]

o7 (salute)

[dpcollier128]

Oh... uh. Guys, I found another bug with Nifskope to look into. This one's weird. Dev8 is first followed by Dev9a/Dev9 gavrant's initial fork (same result). I didn't want to post one from the Dev9 from before gavrant's fork, as the model is half-naked there, what with the clothing not occluding her chest, but that example doesn't have the bizarre stretching shown. This is a model derived from the Type 3 body on NexusMods to reinterpret vanilla NV clothing to a degree. Still, I have also witnessed similar stretching in the dismemberment meat caps from strictly vanilla clothes models, but this only happens in the female models for some reason. The example shown is easily the most severe:

[gavrant]

So, as I understand, you got this bug in 3 versions - Dev 8, Dev 9 and Dev 9a?
And do the "good" pic 1 and the "bad" pic 2 feature the same .nif, without some imports from Blender or any other edits between them? And if yes, what did you do to get from pic 1 to pic 2? Or in other words, how to reproduce this? Also, could you upload that .nif?

[dpcollier128]

Hold up. Picture one of the female models is from Dev8 Nifskope, which appears entirely normal. Picture two is from Dev9a, but the same effect can be seen within your previous Dev9 fork (July 2024). I didn't want to post the picture of the original Dev9 build (September 2023) while viewing the same .nif as there is nudity from the Type 3 body fully shown due to lacking Z_buffer_test and/or _write processing. I don't know what the policy on nudity is for this site or repository. It simply has the same "clothes not occluding or inconsistently occluding the body's skin" bug I reported initially with this post but with a different body type beneath the clothing, so it didn't seem necessary to show it here. I hope this clarifies things.

This latest .nif file comes from a mod marked for adults, so I likely shouldn't link it here. However, the file is named greatkhan_v1_f.nif from the mod Type3 Body and Armor replacer (version 2.1 complete variant) found on the Nexus Mods website. Maybe the original .nif file that this one replaces can showcase similar issues that need fixing. I'm not sure, but the Dev8 version of Nifskope doesn't show any of this skin/meat cap stretching on any .nif file I have viewed so far, while Dev9a has. I might look into viewing other .nif files for testing later to identify common traits among them. So far, it seems to affect female models for clothing from the game the most, and only the skin or dismemberment caps from their limbs. It's rather odd.

Let me know if a separate issue ticket should be created for discussing this new issue within the new Dev9 forks.

[dpcollier128]

I just found the described stretching happening to the nif file at "...\Fallout New Vegas\Data\meshes\Armor\1950StyleSuit\f\outfitf.nif" from the original game files and only while using Dev9a or the Dev9 July 2024 fork. This occurrence is likely more independently repeatable than the previous one. Here's a picture:

And below is the same .nif file rendering normally with Nifskope Dev8:

[gavrant]

I've seen repos of sex mods here on github, so I guess a .nif would be fine, and as long as we don't go too graphical with screenshots here, no one would care. Please upload the .nif or at least a searchable full name for the mod on Nexus.

[dpcollier128]

greatkhan_v1_f.zip
This is the other .nif file giving me severe skin-stretching issues. Thank you for clarifying what's generally acceptable.

And here is the link to that mod if you want to see the model somewhat textured. There may be other requirement mods to complete the custom body texturing. I can't recall. https://www.nexusmods.com/newvegas/mods/34825

[gavrant]

OK, I do reproduce the bug - the .nif from your .zip looks fine on Dev 7 but goes nuts on Dev 9a. I'll look into it today-ish.

One thing though: it's not the same greatkhan_v1_f.nif from "New Vegas Type 3 Armor Pack Complete V2_1"? Because that one looks different and not bugged in Dev 9a.

Thank you for clarifying what's generally acceptable.

To be clear, I think uploading a NSFW-ish .nif is fine if it's actually issue-related, because a mesh by itself is just a bunch of untextured triangles, you would need to open it locally to see anything "unsafe" anyway.

[dpcollier128]

I see. It might be that my version of the crazy .nif comes from a collection. I'm not sure what could be causing the issue or how the collection itself changes the .nifs in comparison to the individual mods, but the collection on Nexus is named "VeryLastKiss's TTW" which is a whole other can of worms to check out if you feel like it. I hope what I have provided so far is enough. I'm not planning to turn this into a full-time job for anyone.

[fo76utils]

If you are also testing my fork, I recommend using the most recent builds from here, as I made several changes to rendering pre-Skyrim models since the last release. I restored shading, so effects like normal mapping and specular now work, but it still needs testing.

[gavrant]

@dpcollier128 Here's a release with a fix for the "greatkhan_v1_f" bug: https://github.com/gavrant/nifskope/releases
This should fix all skinned meshes with strips, not just that one.

"VeryLastKiss's TTW" which is a whole other can of worms to check out if you feel like it. I hope what I have provided so far is enough. I'm not planning to turn this into a full-time job for anyone.

Feel free to report any issues you see in NifSkope, including the ones from the "can of worms". I just would like to suggest to follow the "one problem = separate issue ticket here" rule. That is, if you encounter a problem that looks unrelated to anything else you've already reported, create a new issue. It's usually more manageable for everyone (not just me and you) in the long run than keeping everything in one thread.