NifSkope 2.0 Dev

[Jon]

NifSkope 2.0.dev4 (2015-11-26)

• Vertex colors now rendering for FO4 meshes.
• Editor support for new Vertex Color format (i.e. color wheel).
• Other general rendering improvements for FO4 meshes.
• Visualization for BSSubIndexTriShape segments which are used for dismemberment or occlusion.

[A.J.]

Hello, I wanted to share this. When I work on skeletons, when I select a node with default render settings (nodes don't render), I will see it highlighted in yellow. But if I enable the node rendering (in green), then I won't see any more nodes highlighted. I also can't manage to refresh the render window, so when I change these render parameters I must quit and reload.

I wish a good day and thank you so much for the wondrous work.

[Nephatrine]

This may be a dumb question, but do we know how the snap-together points on the buildable meshes like walls work yet and does this version of Nifskope let us add those markers to existing meshes?

[Jon]

Hello, I wanted to share this. When I work on skeletons, when I select a node with default render settings (nodes don't render), I will see it highlighted in yellow. But if I enable the node rendering (in green), then I won't see any more nodes highlighted. I also can't manage to refresh the render window, so when I change these render parameters I must quit and reload.

I wish a good day and thank you so much for the wondrous work.

I'm aware of the node highlight issue.   You need to hit Save/Apply to see changes to the colors and other rendering settings.  You do not see the changes as you change stuff in the Settings.  This is an intentional departure from 1.1.x.

 

This may be a dumb question, but do we know how the snap-together points on the buildable meshes like walls work yet and does this version of Nifskope let us add those markers to existing meshes?

The snap together points have always been the object origin AFAIK and have never been done with any kind of special markers.

[A.J.]

You need to hit Save/Apply to see changes to the colors and other rendering settings.

 

I was referring to the node visibility, but I just noticed they are labeled "Startup options", so I guess it's normal that I must quit and reload to refresh them.

[Jon]

I was referring to the node visibility, but I just noticed they are labeled "Startup options", so I guess it's normal that I must quit and reload to refresh them.

 

You do not need to exit the program and change those settings to see the Nodes. You can just use the buttons on the Render toolbar.   The Startup Defaults are just that... how you would like the program to start up. 

[A.J.]

That was what I was looking for, thank you!

[z11]

Hi.

 

First of all: Thank you for nifskope, it's great!

 

I hope I can bother you with a question:

 

Not knowing driving me crazy.

 

In the workshop lightbulb vanilla mesh was bugged by bsconnectpoint::parents not having a connectpoint with p-attachlihgt.

 

I was experimenting and finally I found the way to move the point of emittance on a mesh by the unknown floats which was not that hard to figure out,  but I can't find a way to change the angle, i'm trying to figure it out for 3 days now.

 

Please help me if you can and keep up the good work!

[Jon]

Just a small progress update:

 

I am now reading Material files for textures.  There are ~13,000 NIFs with no BSShaderTextureSet at all, meaning their textures come solely from the BGSM reference.  Also, I am retrieving some shader information.  Not all of it yet, but I'm working my way through the various shader features I already support.   I haven't yet ported my B.A.E. updates to the BSA code back to NifSkope, so the Materials BA2 has to be extracted for it to work.

 

I am also now supporting Grayscale to Palette lookups on NIFs which use it for BSLightingShaderProperty blocks.  This was previously only used in BSEffectShaderProperty blocks in Skyrim as far as I am aware.

 

For example:

 

 

The diffuse is more or less a "dirt map" and the palette file is a lookup table.  This is a pretty smart way of doing recolors. You don't even need multiple palette files to swap colors either.  The game uses a "Grayscale to Palette Scale" to modify the input and change what the palette outputs.

 

Anyway stuff I'm currently using from the BGSM:

 

- Textures

- Tiling flags (Tile U or Tile V)

- bSpecularEnabled, cSpecularColor, fSmoothness, fSpecularMult

- fFresnelPower, bRimLighting, fRimPower

- bGrayscaleToPaletteColor, fGrayscaleToPaletteScale

 

I also linked back all but one of the new floats to settings that are duplicated in the BGSM files:

 

 

And also "Glossiness" is now the same as "fSmoothness" in the BGSM.  Glossiness used to be 80 or higher and was used in the exponent of the specular power.  Now it's 0-1 and acts as a multiplier on the gloss channel.

 

I don't like putting out a release without the corresponding commits on my branch, and the code needs to be cleaned up significantly before I will make any commits.  So hopefully I will get out a release tomorrow.

[z11]

This is great! Thank you for your great work.

 

Please answer my question about the attachlight connection point pretty please!

I can't find where to set the angle.

 

And again, thank You for nifskope ( I found it 3 days ago, when I decided to make my first ever mod and then I was disappointed by the shadows, so I started looking but no info out there ,  your software taught a lot about the game, thank you. please support my quest for knowledge by answering )

[Jon]

It's not really relevant to the development of NifSkope so it's not a question you should have asked here.  There are plenty of places to ask..  you should have asked in the NifTools forum instead:  http://niftools.sourceforge.net/forum/viewforum.php?f=31

 

Anyway, just like any other NiNode,  p-AttachLight has a Rotation parameter directly below its Translation.  Whether it uses the Rotation is beyond me, and like I already said I don't want to discuss it any more here.  If the Rotation value doesn't work,  create a thread over at NifTools.

[z11]

Thank You for your answer and the pointer, I'm going to to go to that forum.

 

I am sorry about the wrong forum stuff.

 

That NiNode is not used by the engine, this is: (you might wanna know)

 

BSConnectPoint::Parents / connection points / p-attachlight. has one float + array of 6 shorts and an array of 4floats. This last one has the coordinates(first 3) but the last float is rotation?(1 parameter rotation sounds kind of weird)

 

NiNode with the value Attachlight does not seem to work, but you can find it in a lot of vanilla meshes, not all though,then  some are right, with wrong direction.

I know it is not a spotlight but I tested it as one, oh and a lot of other lamps for that matter.

 

Thank you again.

[Arthmoor]

Hey Jon,

 

Is this something that would be useful for Nifskope in some way? https://software.intel.com/en-us/articles/intel-texture-compression-plugin-for-photoshop

[Jon]

Is this something that would be useful for Nifskope in some way? https://software.intel.com/en-us/articles/intel-texture-compression-plugin-for-photoshop

 

Not directly, no.  It's for texture authors.  I'm signed up for the beta though, but who knows if they're ever going to actually release it.

 

You could actually say that if it's ever released it will make my life more difficult.  It can write out full DX10 headers and that means it's something I'm going to have to support in NifSkope.  Right now NifSkope can only understand DX9 DDS headers, and I extract the BC5U files as if they were DX9 ATI2 with B.A.E. so that more things can actually open them.  

 

Luckily Microsoft has a library that I can use to read and decompress DX10 textures.  I have already toyed around with it for B.A.E. in order to extract the textures to different types, but nothing I've released yet.

[Tovosh]

Hello there !

 

Sorry for the kind of off-topic post, but... Even though Nifskope is a great tool, and is getting closer completion every day as it seems, will there be any way to export the models themselves alongside their rig information in the future ? (Not as OBJ, i mean, which is just the mesh)

 

Being able to export it as .fbx or as a 3ds file would be exactly what i need, and as i'm pretty new in the whole nifskope world i don't know if this is an intented to be included feature, or something that is not useful in the moding community.

 

I've seen plug-ins mentionned for older versions of Nifskope, or plug-ins for direct import of .nif into 3d modeling softwares. Do you know of anyone that would have / be working on such a thing for Fallout 4 Nifs ?

[Jon]

I'm signed up for the beta though, but who knows if they're ever going to actually release it.

LOL.. and mere hours later they release it.  I think they're onto me.

 

Sorry for the kind of off-topic post, but... Even though Nifskope is a great tool, and is getting closer completion every day as it seems, will there be any way to export the models themselves alongside their rig information in the future ? (Not as OBJ, i mean, which is just the mesh)

 

No, sorry.  Export in NifSkope has only ever been a courtesy and not really a primary feature.  The import/export scripts have been in disarray for years,  that is, years before I even took over two years ago.  I thought about replacing the current import/export with a library so that I could support multiple formats but it's a lot more work than I realized just to get the library built for the multiple compilers that I use.  Since other apps deal with skinned meshes way better,  I would rather focus on other things.

 

I will defer to the Max plugin as the de facto skinned importer/exporter,  which figment is definitely in the process of working on.  I already have a version that can import stuff, but he's still working on the exporting.  It'll be ready when it's ready. 

 

 

P.S.  Not to mention there is an entire area of the skinned mesh block that we don't know the function of and cannot reproduce.  So expect importing your own skinned meshes into Fallout 4 to have completely broken features until we figure it out.  There is a block of dismember segments which we understand, and another block related to those segments that we do not.  So without this block dismemberment will likely be completely broken.

[Tovosh]

Oh well, that's still good news for me, as i'm more willing to go and use the model for 3D animation, fan art creation, etc etc, than for direct modding of the game.

 

So not being able to re-import the modified models in the game wouldn't be such a problem for me ^^

 

Anyways, thanks for the quick and complete answer, i'll wait patiently for the plugin to get released then

[Jon]

Just an FYI, there are several architecture meshes which NifSkope reports having an issue with upon opening.   While this is accurate it's actually been discovered that some of the UVs on these meshes are corrupted.   Not just Bethesda's typical UV stretching and what not, but the values in these fields are literally not a valid number ("NaN").  With the change to half floats for UVs there is a large range of byte values that do not create valid half floats.

 

The NIFs in question are:

Meshes\Architecture\Buildings\DecoKit\DecoMainC1x1DoorSingle01.nif
Meshes\Architecture\Buildings\DecoKit\DecoMainC1x1DoorSingle01Full01.nif
Meshes\Architecture\Buildings\Hightech\HighTechChairBuilding.nif
Meshes\Architecture\Buildings\HouseKit\HouseKGrndAddonGarage01.nif
Meshes\Architecture\Buildings\HouseKit\HouseKGrndAddonSunRoom01.nif
Meshes\Architecture\Buildings\HouseKit\HouseKGrndAddonSunRoom02.nif
Meshes\Architecture\Buildings\HouseKit\HouseKGrndFrameA01.nif
Meshes\Architecture\Buildings\HouseKit\HouseKGrndFrameA01Back01.nif
Meshes\Architecture\Buildings\HouseKit\HouseKGrndFrameA01Front01.nif
Meshes\Architecture\Buildings\HouseKit\HouseKGrndFrameA02.nif
Meshes\Architecture\Buildings\HouseKit\HouseKGrndFrameA03.nif
Meshes\Architecture\Buildings\HouseKit\HouseKGrndFrameA04.nif
Meshes\Architecture\Buildings\HouseKit\HouseKGrndFrameABasement01.nif
Meshes\Architecture\Buildings\HouseKit\HouseKSocketDoorFrame01.nif
Meshes\Architecture\Buildings\HouseKit\HouseKSocketWideFrame01.nif
Meshes\Architecture\Buildings\Shell\BldgShellComDoor01.nif
Meshes\Architecture\Buildings\Shell\BldgShellComDoor01b.nif
Meshes\Architecture\Buildings\Shell\BldgShellComDoor02Flat.nif
Meshes\Architecture\Buildings\Shell\BldgShellMetalRoofCorner01.nif
Meshes\Architecture\Buildings\SmallTown\Bld01AddPorch01.nif
Meshes\Architecture\Buildings\SmallTown\Bld01FreeSidingARes01.nif
Meshes\Architecture\Buildings\SmallTown\Bld01FreeSidingARes02.nif
Meshes\Architecture\Buildings\SmallTown\Bld03FreeSidingARes03.nif
Meshes\Architecture\Buildings\SmallTown\Bld03FreeSidingARes04.nif
Meshes\Architecture\Buildings\SmallTown\Bld03FreeSidingARes05.nif
Meshes\Architecture\Buildings\SmallTown\Bld03FrontSidingACom02.nif
Meshes\Architecture\CovenantSettlement\CovenantHouse01.nif
Meshes\Architecture\CovenantSettlement\CovenantHouse02.nif
Meshes\Architecture\CovenantSettlement\CovenantHouse02yellow.nif
Meshes\Architecture\CovenantSettlement\CovenantHouse03.nif
Meshes\Architecture\DiamondCity\ShackRV_Ext\DiamondShack09.nif

As far as prevalence of the corruption, only 318 vertices across all these NIFs have corrupted UVs.  So, it's not that bad.  But looks like we have our first batch of meshes which need fixes for UFO4P.

 

We think that it's possible that however these vertices were exported that the UV being invalid is due to a glitch in their vertex merging code.  When the UVs for these merged verts were created they computed them incorrectly.  The reason it seems to be limited to architecture meshes is probably an artifact of all the right angles/corners and hence duplicate vertices. 

[Arthmoor]

Is that something that can be fixed prior to gaining access to the CK? We still don't have a proper .ba2 packager, right?

[DDProductions83]

I am wondering if there is anyway to maintain the string names on copy from one nif to another? 

I was bored and did some mash ups like adding disco balls to my fat man and teddy bears, and while it worked initially with a copy/paste, I had to rename a lot of the parts particularly the bsshader propertys that would then be named something if they were blank with a string number assigned, or soemthing new if they had a name, if they were blank to begin with there was no issue. 

Obviously not a top tier issue in any event, but it would be very very very nice to have at some point I like to create crap from existing a lot.

 

I also garnered something about someone working on a max plugin?           

 

And I shot you a PM on reddit Jon (I think) I don't know if ya all or you have any donate links or can, but if you do let me know. 

[JET]

Would it be possible for copying branches from Skyrim or FO4 .nif's to another .nif to remember the name? Say I want to copy the NiTriShape branch with the name "Corset" from SUBody_0.nif(Neo's Selene outfit) and paste it into the FemaleBody_0.nif it will be named "Corset" after pasting instead of what looks like a random name picked and usually a bone. (I just copied that and it was named "NPC R Thigh [RThg] [31]" after pasting into the CBBE FemaleBody_0.nif file just to see what Nifskope would pick). Having it remember the name of the branch when copying and pasting will help prevent errors caused by not changing the name of the branch and expedite the workflow.

 

Also question about copying from 1 .nif and pasting into another is there a good reason it throws an error if the root NiNode/BSFadeNode is not named exactly the same? If that little bit of annoyance can be removed it would make the workflow much faster if root nodes do not need to be renamed for copy and paste. If that's game specific that the root node needs to be named a certain way then possibly have the error for only those versions?

 

Other news... Thanks for making the collisions in Skyrim .nif files the same scale as the mesh. No more having to go into the game for a minor adjustment when it is clearly visible in Nifskope.

[Roy Batty]

+1 for remembering the name of the node, needed for a long time.

 

Would it be possible to add a feature that can remove unneeded/unused entries in the string index.

[Jon]

It's been brought up so many times I've lost count.   I've had a ticket up for it for over two years:  https://github.com/niftools/nifskope/issues/18

 

However it's actually extremely complicated so that's the reason it's stayed open for two years.  I tend to shy away from the area of the code which actually modifies the NIF data simply to keep the program stable.  All of my additions over the past two years have been frontend improvements, or at least they do not influence how the NIF is read/written.

 

Block management in general is kind of a mess to deal with, and copy/paste of blocks is a lot more difficult than you may think.   There isn't really any way I can send the actual string over to the other file because the string doesn't exist in the other file.   It's a string index, a number, which references a string in the header.   I would have to change the way copy/paste for blocks works just to support this.   And off the top of my head I don't even know exactly how it's doing it now, since that's a part of the code I stay clear of.   I know what it uses mimedata and the clipboard.   I would have to replace any string indexes with their actual strings and then on the destination block run some kind of function to either retrieve the string index if that string is a duplicate or create a new one.   At a high level / in plain English that sounds fast and easy,  but I am positive I'll run into 40 ways why it couldn't possibly work without rewriting another part of the code.

 

Anyway, that ticket also covers a lot more than just the copy/paste issue. 

 

Also question about copying from 1 .nif and pasting into another is there a good reason it throws an error if the root NiNode/BSFadeNode is not named exactly the same?

 

It's not about the name, it's that the target is probably invalid.  It's the same issue as string indices.   The data on the block is just a number, which references another block number.   That number stays the same on the block after pasting so if you paste into a NIF where that number does something illegal, like pointing to the wrong block type or infinite recursion, yadda yadda,  then it will error.   You just have to clear the refs before copy/pasting.

[JET]

I think you misunderstood me on the question about the root node. I wasn't talking about between the 2 different types, that should throw an error. It is the name itself like "Scene Root" for an exported from 3DS Max bra and "BaseShape" for the CBBE body mod. Both have the same NiNode type for the root node but the two are named different and it throws an error. Anyway if making it ignore the "name" of the node is just as much a pita as keeping the names when copying then backburner it for later, getting full FO4 support is more important.

 

As far as copying from 1 nif to another and keeping the correct name Oblivion .nifs do that so that's why I thought it might not be a huge hassle to make it work the same for Skyrim or FO4. Again FO4 support is more important and even making it better for Skyrim.

[zilav]

As far as copying from 1 nif to another and keeping the correct name Oblivion .nifs do that so that's why I thought it might not be a huge hassle to make it work the same for Skyrim or FO4. Again FO4 support is more important and even making it better for Skyrim.

Oblivion nifs don't use strings table but store names directly inside nodes, that's why you can copy them.