Jump to content

NifSkope 2.0 Dev


Jon

Recommended Posts

On Skyrim meshes, how exactly do Lighting Effect 1 and 2 and Rim and Back lighting interact?  Would a translucency map override the two lighting effect values?

Link to comment
Share on other sites

  • 2 weeks later...

Something got messed up on how FO3 NIFs are handled in Dev 5.  I tried to Stripify a NiTriShape in an exported NIF and instead of converting the entire NiTriShape into a NiTriStrips, it pooked out an entirely separate orphaned NiTriStripsData... that appeared to be malformed according to the following warning generated when I tried to copy it for splice-in to the production mesh:

 

 

 

block 2 Strip Lengths array size mismatch

 

The NiTriShape remained a NiTriShape as well. Triangulating a NiTriStrips in a FO3 mesh into a NiTriShape in turn appears to obliterate its geometry, as it completely disappears.  It isn't even just "hidden"

 

I also noticed that even with Skyrim meshes that it sometimes complained about there being 2 NiTriShapeData blocks in a mesh at the same time when I was swapping them out.

 

Dev 3 does not appear to be affected.  I have not tried in Dev 4.

Link to comment
Share on other sites

  • 4 weeks later...

Hey Jon,

 

Saw a post on Reddit, which led to a post on STEP, which led to a tool Zilav made for scanning meshes for errors. I got curious and ran it on my Data folder (and then on USLEEP) and while discussing it with MadCat and Hana, we wondered what the following error means and if it's actually something that needs to be fixed:

 

 

 

architecture\farmhouse\interior\farmintend01.nif
    Block [1]: Bit 9 or higher is set in BSXFlags, unstable on static objects. Used only for FX/Animated ones.

 

It comes up on numerous statics, but nowhere near ALL of them. As far as any of us can tell, the BSX flags are correct on these meshes.

 

The tool, for reference: http://www.nexusmods.com/skyrim/mods/75916/

Link to comment
Share on other sites

It comes up on numerous statics, but nowhere near ALL of them. As far as any of us can tell, the BSX flags are correct on these meshes.

This tool was made for Skywind in the first place, and they told me that the high bits in BSX caused them instability problems in static meshes. Since they created hundreds of new meshes from scratch, I believe them. Vanilla meshes also use those bits in nifs having anims or particles when I checked last time.

Link to comment
Share on other sites

That may be, in their case, but vanilla has hundreds of them with the "Bit 9" error on completely static meshes that obviously are not causing stability issues. That's why I was wanting to know if Jon could shed some light on what the error refers to, because Nifskope has no checkboxes for bit values past 32 to even look at on these.

Link to comment
Share on other sites

The Flags widget is a manually constructed UI and not taken from the XML definitions in a generic way like Shader Flags for various reasons.  This is something we have a ticket open for in the nifxml repo, but not just for BSXFlags, but also anywhere there is a field that uses the Flags type such as NiAlphaProperty.

 

nif.xml is documented and says this:

        Bit 0 : enable havok, bAnimated(Skyrim)
        Bit 1 : enable collision, bHavok(Skyrim)
        Bit 2 : is skeleton nif?, bRagdoll(Skyrim)
        Bit 3 : enable animation, bComplex(Skyrim)
        Bit 4 : FlameNodes present, bAddon(Skyrim)
        Bit 5 : EditorMarkers present
        Bit 6 : bDynamic(Skyrim)
        Bit 7 : bArticulated(Skyrim)
        Bit 8 : bIKTarget(Skyrim)
        Bit 9 : Unknown(Skyrim)

Their own scenegraph in the Preview app does not say what the Bit 9 is. 

 

However, looking into FO4 stuff... the 9th bit according to the exporter files is supposedly External Emit, and the 8th bit does not say "IK Target" but instead is worded "Needs Transform Updates", so it's possible the 9th bit does not have the same use in FO4 as it does in Skyrim.  (Edit:  I'll also note that Bit 9 does not show up in the scenegraph UI for Fallout 4's Preview app either, despite higher bits having a UI entry like "bLights" / Bit 11)

 

BTW, does this tool mean Bit 9 counting from 0 or 1?  In any case, and for FO4 at least, Bit 9 has nothing to do with static vs dynamic meshes.  And if hundreds of vanilla Skyrim static pieces have Bit 9 set as Arth says, then I'm guessing it has nothing to do with static vs dynamic either and the BSXFlags validation with this tool is too vague. 

 

If I could get a good list of files that are static but have Bit 9 set (if that means 2^9 or 512) I would easily be able to see if Bit 9 has anything to do with External Emit in Skyrim as well.  Because there is definite instability surrounding External Emit when the NIF and the in-game Ref do not agree on its emittance.  If someone doesn't post a list I will eventually get around to making one myself.

 

Edit: Fixed some math (Bit 9 is 2^9 not 2^10 as I didn't need to compensate for 0/1 indexing there).

Link to comment
Share on other sites

Error output for the vanilla files, most of which is Bit 9 errors. I removed all the junk facegen files from this.

 

errors.txt

 

If it has something to do with external emmitance, then in the case of some of the architecture that would make sense because of the way the windows light up at night, but then that would imply the Bit 9 errors are false alarms.

Link to comment
Share on other sites

Yeah just after a cursory glance (dozen or so NIFs) ...  It would appear that anything with BSXFlags Bit 9 (512) set there is at least one shader property with SLSF1_External_Emittance set.

 

Edit:  And a few times I accidentally opened the wrong NIF without Bit 9 set and none of the shader properties had External Emittance set.  What I could probably do with NifSkope's XML checker is output a list of NIFs with that BSX bit set, and a list of NIFs with at least one shader property with External Emit set and see how well the two lists overlap. 

Link to comment
Share on other sites

Maybe the tool could be slightly refined to only show a Bit 9 error if SLSF1_External_Emittance is not set? Seems like it may be a case where they both have to be in order for that to work.

Link to comment
Share on other sites

Well there are multiple errors if the assumptions about the bit are correct and the likelihood they both need to be set.

 

1. Shader flag for External Emit set without having a BSXFlags block at all.

2. Shader flag for External Emit set but not having BSXFlags bit 9 set.

3. Having BSXFlags bit 9 set but no shader properties with the External Emit flag.

 

The tool might not be set up to be able to go over the file once to collect the shader flags and then compare with BSXFlags values, since the BSXFlags block comes before any shader properties.

Link to comment
Share on other sites

Bit 9 in report starts from 0.

Checked those meshes and it is indeed looks like some kind of connection with emittance shader flag.

Link to comment
Share on other sites

Well there are multiple errors if the assumptions about the bit are correct and the likelihood they both need to be set.

 

1. Shader flag for External Emit set without having a BSXFlags block at all.

2. Shader flag for External Emit set but not having BSXFlags bit 9 set.

3. Having BSXFlags bit 9 set but no shader properties with the External Emit flag.

 

The tool might not be set up to be able to go over the file once to collect the shader flags and then compare with BSXFlags values, since the BSXFlags block comes before any shader properties.

I updated my scanner to check all those cases and there are zero errors in vanilla meshes. If a mesh uses SLSF1_External_Emittance, it always has BSXFlags with bit 9 set. And vice versa - there is no BSXFlags with bit 9 set if there are no appropriatly flagged shaders present.

NifScan.zip

Link to comment
Share on other sites

That produced a much more manageable report on the vanilla meshes. No more bogus errors for facegen files, and no more suspect Bit 9 errors. It went from hundreds to maybe 50 or so that have duplicate node names.

 

Only one Bit 9 error is left:

cameras\trailer_sh22_cam.nif
    Block [0]: Mesh uses SLSF1_External_Emittance but BSXFlags with set bit 9 is missing.

 

So that one might just be legit and need to get looked at :P

Link to comment
Share on other sites

I updated my scanner to check all those cases and there are zero errors in vanilla meshes. If a mesh uses SLSF1_External_Emittance, it always has BSXFlags with bit 9 set. And vice versa - there is no BSXFlags with bit 9 set if there are no appropriatly flagged shaders present.

 

Cool.  Glad that it was easy for you to implement.  I usually hack things temporarily into XML Checker in NifSkope to go over all the NIF files for stuff like this, but it's meant to validate the XML itself not the actual NIF data so I take it out for releases.  Guess I should probably start some kind of NIF Checker instead. :)   Do you have any kind of list of all the rules you use?

 

I would also like to overhaul "Auto-Sanitize on Save" to where it fixes way more than it currently does.  Re: Duplicate node/shape names that is easy enough to auto-sanitize for.  I'm not sure where Beth gets the "SomeName:0", "SomeName:8", etc. format from.. might be from the Max exporter and the Max scenegraph.  But the number after the colon doesn't actually seem to have any significance to the engine, so fixing duplicate node names is as simple as taking the name of the parent and then adding a :N at the end where N is the first unused number.

 

Also now with FO4 I should probably be stripping the Name fields for shader properties and such when the string is not a valid BGSM path.  When pasting shader props from another NIF they will often get renamed to some other string since the indices differ.  But I still have auto-sanitize disabled for FO4 even if the option is checked since I haven't yet properly assessed if sanitization spells need to be changed.  So first things first. :P

Link to comment
Share on other sites

That produced a much more manageable report on the vanilla meshes. No more bogus errors for facegen files, and no more suspect Bit 9 errors. It went from hundreds to maybe 50 or so that have duplicate node names.

I was testing on static, clutter, armors and weapons only. The type of meshes Skywind creates. But those facegen meshes have separate env map flag and shader for eyes which were not properly covered.

 

So that one might just be legit and need to get looked at :P

Camera paths are invisible, I doubt it really matters.

 

Guess I should probably start some kind of NIF Checker instead. :)   Do you have any kind of list of all the rules you use?

Would be nice to have an automatic fixer based on niflib that can not only find errors, but fix them too. In my scanner I just read bytes from stream I want to check, so fixing errors is not an option without total rewrite. But it does work fast because of that :)

 

Here is the list of checked issues:

  • String indexes out of bounds, that crashes the game as we all know.
  • Duplicate children names. Causes random elusive crashes in game, but not on all meshes. Vanilla meshes have dups in skeletons and some armours, so maybe it affects statics and clutter only. I myself experienced crashes when dups were in tree meshes. Keep in mind that there are several exceptions like 'InvMarker' and 'EditorMarker' which can be few. I think the blood nodes on weapons are also can be repeatable.
  • BSXFlags node must have BSX name. No crashes, but disables collision and finding the reason could be a pain. Experienced myself.
  • If NiAlphaProperty is before shader property in children of shapes/strips, that will crash
  • SLSF1_Environment_Mapping and EnvMap shader type are both set together, the same for eyes envmap flag and shader. Crashes CK and random crashes in game.
  • SLSF2_Vertex_Colors and HasVertexColor flag in shapes/strips match. No problems in CK or game, but a sign of broken mesh import since vanilla meshes don't have that issue.
  • Our beloved bit 9 flag in BSX and SLSF1_External_Emittance. Random crashes in game.

 

Not much, basically what Skywind team reported to me and what I experienced myself when fixing their meshes.

Link to comment
Share on other sites

1. Shader flag for External Emit set without having a BSXFlags block at all.

That is interesting since all my glow LOD meshes with external emittance have no BXSFlags block. I would expect reports/complains.

Nevertheless I will add the BSXFLags block with bit 9.

Link to comment
Share on other sites

That is interesting since all my glow LOD meshes with external emittance have no BXSFlags block. I would expect reports/complains.

Nevertheless I will add the BSXFLags block with bit 9.

Better not change what already works and proved to be reliable. Maybe LODs don't need that flag at all.

Link to comment
Share on other sites

Anyone using the pre-pre-dev builds I've posted here for testing purposes since Apr 20, please update to this version:

 

https://drive.google.com/open?id=0B9F4jSOO-JcpUzZrNVhoNlhqdEU

 

(Edit: Updated package)

 

It fixes any remaining issues from the new caching implementation.  There were still lingering issues with array length updating (could require a save/reload to edit new array items) and also a few Spells were not working correctly due to the way they were implemented.

 

@MadCat ... this fixes Stripify/Triangulate.

 

 

If there are no issues with this build I will probably make it an official GitHub release over the weekend.

Link to comment
Share on other sites

@Jon: I'm pretty new to the world of git, and a VS-only coder, so I'm having some troubles... The VS importer fail to clone sub-modules. I'll take care of it, one way or another, that's not really important, however it made me discover a little something:

 

The qhull sub-module is still pointing to the old gitorious repo. Since the repo is rather outdated and abandoned, (qhull moved to github), wouldn't it make more sense to use this repo instead ? No idea if NifSkope would require some updates or not though.

Link to comment
Share on other sites

Pointing to the old gitorious repo where?   You're not looking at the right branch then.  I changed the qhull submodule a long time ago. 

Link to comment
Share on other sites

In the .gitmodules file. If you did update, then I'm definitely looking at the wrong branch ^^ 

 

Edit: Could be an issue with VS only willing to see the main branch. Not sure, as I said I'm fairly new to this, and even more with the git/VS integration.

Link to comment
Share on other sites

When starting up that newest version you just linked a few hours before this post, I get the following error:

 

 

 

There were errors during shader compilation:

 

 

 

fo4_default.frag:

 

Fragment shader failed to compile with the following errors:

ERROR: 0:170: error(#132) Syntax error: "=" parse error

ERROR: error(#273) 1 compilation errors. No code generated

 

 

fo4_env.frag:

 

Fragment shader failed to compile with the following errors:

ERROR: 0:165: error(#132) Syntax error: "=" parse error

ERROR: error(#273) 1 compilation errors. No code generated

 

 

fo4_default.prog:

 

depends on shader fo4_default.frag which was not compiled successful

fo4_env.prog:

 

depends on shader fo4_env.frag which was not compiled successful

 

I am opening both Skyrim and FO3NV meshes with it, and both produce this error.

 

Is this because I do not have FO4?

 

FO3 stripification/triangulation doesn't FUBAR them anymore though.  The fretting over multiple data/skin blocks when splicing remains, though.

Link to comment
Share on other sites

Just delete the fo4_* files from your shaders folder.  I've dealt with the error (which only happens on AMD cards, naturally) and will update the package soon.

 

I'll have to debug the link issue later.  It's either out of sync for a few updates or the list of links isn't clearing the old link and so it's going through extra links a few times in the mesh update function.  Either way the end result is fine, it just spits out errors in the middle. 

 

Here is an updated package:

 

https://drive.google.com/open?id=0B9F4jSOO-JcpUzZrNVhoNlhqdEU

Link to comment
Share on other sites

Not sure if anyone else has noticed this or posted on it in here, there allot of posts to read through and Google is not pointing to any answer. I am working with Ga-Knomboe Boy porting some of his trees to Fallout 4. I have come against a strange issue that is tied to the tree animation on the trees and the weather system. I have been basically using preexisting trees and copying similar setting to get them to work after export from MAX using the Fallout 4 export. I can get the trees into the CK and in game without issue. But if i change the weather in the CK or in the game the branch planes/splines detach and tilt off the trunk. Now as a means to try and compensate for this, I have added animation to the trunk as well and it partially works. But it does not match the angle of the branches. Of course the logical thing to do is to fuse the branches to the trunk, and that does work. The trees will work and tilt with weather changes in game, a bit to much in my opinion. But the animation has to also be set fairly low. As an example the Far Harbor pines only animate at the tips of the branches and the sections that intersect the trunk do not move. So what I  am wondering is, is there a chance that the new Nifscope is not seeing some kind of weighting code to lock the branches to the trunk or the collision mesh and we can't see it. I have been at this for over a week and I am just at my wits end. These branches have a mind of their own and simply do not seem to behave the way they did in Skyrim. I know, updated engine and different game. But something has to be missing somewhere. There has to be code that we are not seeing that tells the CK and the game that this portion of the branch should move and this part shouldn't. If anyone has any ideas I am totally open to try anything. I just don't get what I am missing if anything in the nif at present. And of course the present build of Nifscope does not display any kind of bone node or weighting data for the games original trees either. Thanks and hoping someone has an idea.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...