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.