NifSkope 2.0 Dev

[mechanicalsnowman]

Hi Jon,

Thanks a ton for NifSkope! I have a couple of questions which hopefully you can answer, sorry if they've been asked and answered before -

Is there any way to view vertex IDs for meshes? I was hoping I could do some rudimentary mesh changes by exporting the mesh from NifSkope, making the changes in a modeling program, and then manually editing the vertex position by viewing the vertex ID in Maya / Max, finding the corresponding ID in NifSkope and typing in the value. This would only be for small changes obviously, since it would take ages, but I was still hoping it would be possible. That brings me to my next question -

 

Since you can select vertices by clicking them in the Block Details window, and make edits to them in that same window, how difficult would it be to make it so that you can click the vertex on the mesh instead, and make changes with a transform 'gizmo' in the model window? Turning NifSkope into something of an extremely light modeling application, just for tiny changes and clipping fixes.

 

Thanks again!

[Jon]

Yes it would be nice if things in an array would list their number.  I'm just not sure if I can go about doing that without messing up other stuff.  Will have to look into it.

 

The vertex selection question is asked constantly.  I'll just refer you to one of the more recent answers:  http://www.afkmods.com/index.php?/topic/4136-nifskope-20-dev/?p=157625

 

And I've said elsewhere I think I have a quick and dirty way of implementing it without overhauling the renderer too much,  but my next effort will be in porting my BA2 reading from B.A.E. back to NifSkope.

[mechanicalsnowman]

Thanks for the reply, I had guessed there would be a good reason that I wouldn't understand and I was totally right. It's nice to know it's on everyone else's wishlist too, though.

 

When plugins come out will Maya, Blender and Max all have the same functionality / workflow, or will one be significantly easier to use, or be significantly more supported than the other?

 

Edit: this may be off topic but I've been playing around with NifSkope 2.0 and realized there is no way of applying a scale to a mesh. If I edit the scale from 1 to 1.2 and save out and reload, the scale still has a value of 1.2, and the mesh remains unchanged in FO4. Is there currently no way to apply / freeze transforms?

[VaultDuke]

Jon, that isn't you who posted nifskope on nexus, is it?

http://www.nexusmods.com/fallout4/mods/5295/?

[Jon]

LOL.  Reported.  They couldn't even get the name right...

[Zaldir]

And gone.

[VaultDuke]

game, set and match. that was swift!

[Aldebaran 90]

Hi guys, I'm new here

I'd like to ask about transform/translation feature. I know how to do it in Skyrim. But can't seem to get my changes to show up in game for Fallout 4's meshes.

If i reposition a mesh, the changes show up in Nifskope, but not in game. Also the option to apply the changes to the shape is not there, there is one in NiNode only. And since there is no NiSkinData anymore, I don't know how to properly do this anymore.

If this is already an implemented feature, would you mind letting me know how to do that for FO4's meshes? Thank you so much

[Nico coiN]

@Aldebaran 90 : for Skyrim meshes you have to enter translation/rotation numeric values in the NiTrishape block you want to modify. That's what you're probably already doing, and the values are properly applied in the Nifskope render window. However, if you want the game to take it into account then you have to left-click once on the NiTrishape block to highlight it, then make a right-click Transform -> Apply.

[Aldebaran 90]

Edit: Double post.

[Aldebaran 90]

@Aldebaran 90 : for Skyrim meshes you have to enter translation/rotation numeric values in the NiTrishape block you want to modify. That's what you're probably already doing, and the values are properly applied in the Nifskope render window. However, if you want the game to take it into account then you have to left-click once on the NiTrishape block to highlight it, then make a right-click Transform -> Apply.

Sorry, it was a mistake on my end. I forgot to say that I couldn't get it to work with Fallout 4's meshes. I can do it fine with Skyrim's meshes:) thanks

[Nico coiN]

Most part of FO4 meshes have different blocks & structures than those from previous Bethesda games. The actual Nifskope release only has a partial support for FO4, mainly just displaying/viewing some of them without the help of any other sophisticated or licensed app. Jon is working on it. I guess it's only a matter of time, but it may be long before we have the same support level as for Oblivion/FO3/Skyrim meshes.

[Jon]

NifSkope 2.0.dev4 (2015-12-11)

 

Summary

 

- BA2 support

- Materials support

- Rendering updates -  Environment mapping, better specular, grayscale to palette color, glow/emissive,  effect shaders

- BSLightingShaderProperty/BSEffectShaderProperty new values fully decoded

- Spell update for Face/Smooth Normals

- Bounding Sphere visualization for BSTriShape and BSSkin::BoneData.

 

Gallery of rendering improvements

 

Update Notes

 

If you continue to use loose texture files, you must re-extract the cubemaps if they were extracted with B.A.E. v0.03 or earlier. The cubemaps were extracted incorrectly and will break the shaders in NifSkope.

 

You must add the Materials BA2 to Settings > Resources > Archives if you want to load BGSM/BGEM files without extracting them.

[InsanePlumber]

Thank you for the update.

[mechanicalsnowman]

Awesome, thanks!

[JET]

Not sure if this is important or not but the " \ " for texture paths are showing as " / " like it's on the internet instead of our HDD.

 

*Edit, is it important to change texture paths, double sided, and add alpha channels to the .nif as well as the .bgsm, or just add those to the .bgsm?

[Jon]

It's intentional.  And no, it makes no difference.  Qt (library NifSkope uses) actually deals with things best as "/" because you don't have to escape it.  With "\" you actually write out the paths as "\\". 

[Kesta]

Jon,

 

Any thought on that : http://forums.nexusmods.com/index.php?/topic/3525000-new-body-tex-doesnt-look-wet-in-the-rain/?p=31900360 ?

(you're about the only expert I know how to contact on this kind of subjects ^^)

 

The underlying question is : do those "texture optimisation" mods on the nexus actually don't degrade the visuals way more than intended by their authors ?

[Jon]

From what I can tell they solved their own issue?  They were using the wrong BC formats.  They're also not grasping that normal/spec are two-channel maps now, as evidenced by their attempt to save _d as BC5 also.

 

> do those "texture optimisation" mods on the nexus actually don't degrade the visuals way more than intended by their authors ?

 

The actual issue is that "texture optimization" is a misnomer when they're actually removing optimizations by taking the file out of the texture-optimized BA2 and forcing the engine to load it as a loose file.   So, the entire file has to be read in order to access the lower mips.   The whole point of the texture BA2 optimization is that the lower mips are split from the higher mips.   This means that for nearly all things you are using much less VRAM until you get close, when the higher resolution mips need to be loaded.

 

The "texture optimization" mods are undoing all of this work by forcing the entire file into VRAM regardless of distance.

[JET]

Thanks for clarifying the \ or / difference in texture paths. Use either/or and it's all good but it prefers /.

 

You didn't clarify the .bgsm issue though and I assume the game will use those over what the bsshadertextureset says or any flags in the bslightingshaderproperty. A test file of mine is showing that the .bgsm overrides the .nif settings

 

.BGSM = Bethesda Game Studios Material.... Yo Bethesda take that file and stuff it where the brown stinky stuff comes out of when you sit on a toilet. That's my opinion lol.

[Jon]

It's because I'd already started responding before you ninja edited.

 

Pretty sure it's Bethesda Game(studios) Shader Material btw.  Because there is BGEM also,  Bethesda Game(studios) Effect Material, which applies to BSESP instead of BSLSP.

 

AFAIK you need to have NiAlphaProperty blocks if using alpha in a BGSM/BGEM.  You also probably need to have the correct Shader Type set in the BSLSP (Glow, Environment, Skin Tint, etc).  But other than that if you have a BGSM set I don't think anything else in the BSLSP matters.

 

There are about 13,000 files which don't have a BSShaderTextureSet at all, meaning the textures are defined solely in the BGSM.

[fireundubh]

The actual issue is that "texture optimization" is a misnomer when they're actually removing optimizations by taking the file out of the texture-optimized BA2 and forcing the engine to load it as a loose file.   So, the entire file has to be read in order to access the lower mips.   The whole point of the texture BA2 optimization is that the lower mips are split from the higher mips.   This means that for nearly all things you are using much less VRAM until you get close, when the higher resolution mips need to be loaded.

 

The "texture optimization" mods are undoing all of this work by forcing the entire file into VRAM regardless of distance.

 

Faster lookups for unoptimized textures is less performant than slower lookups for optimized textures.

 

Those texture optimization "mods" aren't "undoing" any work; that's an incredible fabrication.

[Jon]

Faster lookups for unoptimized textures is less performant than slower lookups for optimized textures.

 

Those texture optimization "mods" aren't "undoing" any work; that's an incredible fabrication.

 

Really don't think you understand then.  If a texture is being loaded on a building 5 cells away,  it only needs one of the lowest mip levels.  Let's say it is split up in the BA2 like so:

 

Chunk1:  Mip0-1 @ 2048 and 1024

Chunk2:  Mip2-6 @ 512 through 32

Chunk3:  Mip7-11 @ 16 and below

 

The game loads only the Chunk3 containing Mips 7 through 11, so the 2048x2048 file is essentially being treated like a separate 16x16 file at that distance.  Chunk1 and Chunk2 are not loaded.

 

These so called "texture optimizations" are taking the 2048x2048 file and reducing it to 1024x1024, and then adding it as a loose file.  This loose file is always loaded fully into VRAM regardless of distance.   So this house 5 cells away is now taking up ~666KB with the 1024x1024 "optimization" instead of **312 bytes** with the optimized BA2,  assuming nothing closer than that house is using the same texture.  That's ~2000x the memory.

 

If you were halving the texture sizes and then sticking them into an optimized BA2 maybe then there would be some kind of argument. 

 

----

 

We could also look at some of the "incredible fabrications" of the mod:

 

> Vanilla textures are HUGE 2048x2048 (2k) ground textures and 2048x2048 plant textures 4096x2048 tree textures and so on (for example) most computers cannot handle this.

 

2K is suddenly huge?  And for TERRAINS of all things?  Ludicrous.  This person probably doesn't even know the term "texel density".

 

> I have replaced the high-resolution textures with properly compressed and resized textures

 

With no description of what was wrong about the compression before nor any kind of quantification of the extent to which it had to be fixed.   Translation:  99% of them were already properly compressed, but I'm putting that word here to make it sound like I'm doing more than I really am.

 

> seeing massive improvement!

>  a VERY good fps boost

> it is the BEST fps boost you can get

 

** Citation Needed **

 

> So apparently leaving vanilla files in my mod is against the rules. so ill be editing about 5600 files or looking into why they are "exactly identical to vanilla" so to say the least ill be very busy for the next little while..

 

Padding numbers?  Either way it was funny.  You claim it's not removing any optimizations yet there were **5600 files** identical to vanilla.

 

----

 

Anyway, yes, if you're taking almost all of the game's textures and making them 1/4th the filesize, you might eventually break even with the tradeoff between the loss of optimizations and the overall lower size of all the textures.    Needless to say this doesn't change the fact that the mod is removing said optimizations.  That cannot be argued against.

[Jon]

NifSkope 2.0.dev4 (2015-12-14)

 

Summary

• Wider vertex format support
  • Generated meshes in Meshes/SCOL now fully supported
  • BTR files now have the correct vertex format
  • Many atypical vertex formats now handled correctly, such as certain editor markers
• Archive Browser fixes
• Faster BA2 loading
• Double Sided / Alpha Blending rendering fixes (Gallery)
• Scrollbar minimum height fix

 

And a sidenote:

 

I've sort of reached an impasse with nif.xml in terms of the vertex format.  We've known how to treat the vertex flags for quite some time but getting this translated into XML has proved difficult. My wider vertex format support in this release heavily complicated the XML for that block.  For the end user, it is very minimally slower to load skinned NIFs, but you wouldn't likely notice.  The thing is, it's already terribly slow even with my optimizations, at least compared to vertex loading in Skyrim.

 

Basically, the way the new vertex data works is impossible to encapsulate in the XML, and I will be experimenting with a custom type in NifSkope to deal with the vertex data solely in C++.   It will not only be far more rigorous but it should be several orders of magnitude faster.

[KatzSmile]

Greetings!

Is it possible to make a feature to NifSkope to import/export loaded NIFs to xml or at least to its nodes? It will make modding and my life much easier.