NifSkope 2.0 Dev

[vurt]

the labeling is correct, i just checked.. nonworking is super dark even with full brightness, the other one gets extremely bright if you turn up the brightness even slightly. i have tried reversing normals on the super dark one, it doesnt make any difference.

 

Thanks for the suggestion about using Ortographic mode!

 

Texures: https://www.dropbox.com/s/6bxp1r7sx43ytnn/textures.rar?dl=0

[Jon]

You didn't include the normals which was the important part.

 

Anyway, the normals are clearly wrong on the working.nif you sent me.  Try turning off Textures (Alt+T) to see what it looks like without texture information.

 

Here's the normals visualized: https://i.imgur.com/fWlXrbR.png  ... i.e. a total mess.

 

Actually after fixing them, they're just reversed:  https://i.imgur.com/lWWpTvz.png

 

So, I'm going to guess that your normal maps are totally backwards, which for you makes working.nif work, and nonworking.nif break.  For me, without normal maps, it's the opposite.

[vurt]

ah you are quick i actually updated the link almost directly with the normal maps  so try the new link.

 

Not sure why reversing the normals doesnt work :/

 

The normals looks good in game, the trees are bright. when i did try to reverse one of them that did look like it was backwards, that tree became very dark in-game.

 

For now i would be glad if i could just get this Brightness thing working on all the trees so that the rendering turns out nicely.

[Jon]

OK so I thought it was maybe that double-sided materials are being lit incorrectly.  So I turned off SLSF2_Double_Sided and noticed that the real faces on one tree point down and the real faces on the other point up.   Skyrim doesn't really seem to care about this,  but I would say it's bad practice to have the faces pointing different ways.

 

But...  This wasn't even the issue.  The issue is that one tree is missing tangents/bitangents.  Your tree has normal maps so it needs them.  I'm not sure why exactly Skyrim isn't showing the tree super darkly like NifSkope.  Maybe it tries to generate them for you if they're not there.

 

Also, you have many inconsistencies in your SLSF flags. 

 

working.nif:

SLSF1_Recieve_Shadows | SLSF1_Cast_Shadows | SLSF1_Own_Emit | SLSF1_ZBuffer_Test

SLSF2_ZBuffer_Write | SLSF2_Double_Sided | SLSF2_EnvMap_Light_Fade | SLSF2_Tree_Anim

 

nonworking.nif:

SLSF1_Vertex_Alpha | SLSF1_Recieve_Shadows | SLSF1_Cast_Shadows | SLSF1_Own_Emit | SLSF1_ZBuffer_Test

SLSF2_ZBuffer_Write | SLSF2_Double_Sided | SLSF2_Vertex_Colors | SLSF2_EnvMap_Light_Fade | SLSF2_Rim_Lighting | SLSF2_Tree_Anim

 

One thing I want to point out is that SLSF2_Rim_Lighting should use a rim lighting mask in texture slot 3.  If one is not provided the game uses textures\default_n.dds which is a purple-bluish tint.  I don't think you want your trees to have a purple-blue highlight, but I dunno.   You could just use textures\white.dds in slot #3 instead.

 

---

 

So... I think that this particular lighting issue without tangents/bitangents is one where I can't really support emulating the engine.  I try for 100% WYSIWYG but in the case of your tree mesh,  it is just hiding the fact that you don't have tangents/bitangents when you should.

[vurt]

That's super helpful Jon. As you probably can tell i am not very "tech-savvy" when it comes to this.  Will read up about tangents.. 

 

Thanks a ton

[Jon]

shaders_2016-03-27

 

If anyone, AMD users especially, who had rendering issues with FO4 meshes could please test this updated shader package,  I'd appreciate it.  Please let me know if it resolves your issues.  For AMD users, certain meshes would be totally black or invisible until disabling shaders.

[Jon]

NifSkope 2.0 Pre-Alpha 5

 

- Vertex Selection mode

- Load speed improvements

- Node rendering improvements

- [Fix] Issue causing UV Editor to not load textures

- [Fix] Lack of #version pragma in vertex shaders causing issues with AMD/Intel

- [FO4] Connect Point and PreCombined visualization

- [FO4][Fix] The appearance of wireframes, vertices, etc. was not consistently following the colors the user defines in the Settings.

 

See changelog for full details.

 

----

 

Also, would like to apologize for sitting on several of these features for over 3 months.   I took a bit of a break from NifSkope dev and stuff I already had done basically sat there unreleased.

[InsanePlumber]

Thank you Jon and the whole NifSkope Team!

[sialivi]

Small request, but oh so important; please add a ctrl+s hotkey for saving, I'm a keyboard guy.

[Jon]

I was actually just asked about this this morning/yesterday.   I don't want people to be able to accidentally overwrite a vanilla file especially without full undo.   At the most Ctrl + S would mean Save As and not Save.

[Roy Batty]

What does it matter when they can just extract the vanilla again?

 

Also thanks for the update, and looking forward to more.

[sialivi]

I was actually just asked about this this morning/yesterday.   I don't want people to be able to accidentally overwrite a vanilla file especially without full undo.   At the most Ctrl + S would mean Save As and not Save.

I think that's underestimating the nifskope users. And as Hana pointed out in the chat; you shouldn't be working on files in your data folder any way, you should be working on copies. Also, if users can't be trusted with a save shortcut, then they surely can't be trusted with a save button in the toolbar either?

[Jon]

I think that's underestimating the nifskope users. And as Hana pointed out in the chat; you shouldn't be working on files in your data folder any way, you should be working on copies. Also, if users can't be trusted with a save shortcut, then they surely can't be trusted with a save button in the toolbar either?

 

I've absentmindedly hit Ctrl + S without meaning to, out of habit with other programs (the kind where you save after every change).  Without full undo/redo implemented yet, there's no way to recover from this.   Also, the save button in the toolbar doesn't save.  You have to physically navigate a dropdown after clicking it,  which takes a lot more intent than hitting Ctrl + S.  So I don't get your comparison.

 

This was also decided on back when NifSkope didn't have an archive browser.  Now that it does it's fairly trivial to get at the vanilla NIF if you make a mistake, so I suppose I can revisit it.

 

I also was waiting on implementing a backup system, like Edit/Bash has.  Again, Ctrl + S is still irrevocable, whereas in most other applications you can undo back to the original state.  So if I made Ctrl + S save without prompt I would definitely have a backup system in place first.

[Roy Batty]

Full undo/redo would be a most welcome feature, looking forward to that.

[Hana]

What's the possibility of getting a Cancel button on the Transform - Edit box? Or possibly, when closing the box out with the X in the corner undoing any changes that might have been made?

[Arthmoor]

Possibly off the wall, but is anything in this useful at all? https://github.com/Microsoft/DirectXTex/wiki/Texconv

 

I see it mentions things like BC2 and BC7

[sialivi]

Bug / Keyboard Usability Improvements

1) After you've edited a value in the block details, you have to press the down arrow key 3 times to move to the next entry in the list. The first two keypresses doesn't seem to do anything. This does not happen if you cancel out of the editing, or don't change the value, in those cases you only need to press the down arrow once to move to the next entry as expected.

2) When navigating the list using the arrow keys, there doesn't seem to be a button to actually edit the values. Instead you're forced to double click with the mouse. Would speed things up if a simple 'enter' keypress would toggle editing.

[Roy Batty]

Texconv is cool, downloaded that already.

 

If you edit the background color for preview it doesn't detect the change until you edit a different color, then you can save the changes.

[kikaimegami]

shaders_2016-03-27

 

If anyone, AMD users especially, who had rendering issues with FO4 meshes could please test this updated shader package,  I'd appreciate it.  Please let me know if it resolves your issues.  For AMD users, certain meshes would be totally black or invisible until disabling shaders.

 

Nope, doesn't seem to change anything

 

Also I apparently just up and totally forgot to make that mesh pack. Did you still want it?

 

EDIT: Also, is it me, or does ctrl+up/down arrow (move block up/down) function differently now (alpha5)?

 

It used to keep the same block selected and just moved it up in the block numbering while preserving parent/child/tree structure. Now it can change my selection and if there's say a bstrishape above the block I'm relocating, it'll go into the bstrishape block (while kicking another block out of the way) instead of just being renumbered (which tosses errors if you're moving something that has no natural business being referenced in a shape block). You can also get stuff to end up with the same index causing a recursive link error.

[Arthmoor]

Hey Jon, is this what you're talking about when you asked if people are having problems rendering Fallout 4 meshes?

 

http://imgur.com/f1dvFPs

 

meshes\armor\leather\f_arm_heavy_r.nif

 

Was looking at it because the material on node 20 is pointing to the wrong thing and was going to fix it for UFO4P.

 

There should obviously be more in the image than just blackness with green outlines

[Jon]

Yeah, apparently there are still issues with AMD cards.   If you turn off cube mapping (Alt + R or Render menu) does it show up?
 
---
 

It used to keep the same block selected and just moved it up in the block numbering while preserving parent/child/tree structure. Now it can change my selection and if there's say a bstrishape above the block I'm relocating, it'll go into the bstrishape block (while kicking another block out of the way) instead of just being renumbered (which tosses errors if you're moving something that has no natural business being referenced in a shape block). You can also get stuff to end up with the same index causing a recursive link error.

 

Probably another side effect of my attempt to speed up parsing...    I didn't test every block operation because they're all "Spells", i.e. disconnected from the actual data model class.  I'm starting to think at this point that I should just completely torch all the block operations and do them over again with better native operations on the data model.  Biggest reason being that Ctrl+Del is a complete mess.  It runs into huge speed issues due to its implementation and I just need to replace it.  

[Arthmoor]

Nope. Turning off cube mapping doesn't help. Still blank

[kikaimegami]

Yeah, apparently there are still issues with AMD cards.   If you turn off cube mapping (Alt + R or Render menu) does it show up?

 

Not sure if this was directed at both of us, or just Arthmoor, but turning off cube mapping doesn't do anything for me, either.

 

Just a note, but I also noticed that the 'eating ram until the whole thing keels over' issue I blathered like an idiot about a while back in here is still happening. I'm curious if other AMD users experience this too, or if it's some unrelated thing.

 

Probably another side effect of my attempt to speed up parsing...    I didn't test every block operation because they're all "Spells", i.e. disconnected from the actual data model class.  I'm starting to think at this point that I should just completely torch all the block operations and do them over again with better native operations on the data model.  Biggest reason being that Ctrl+Del is a complete mess.  It runs into huge speed issues due to its implementation and I just need to replace it.

 

Well, now I know why they're called "Spells"! I mean, I'm sure it's really just because someone earlier in development was a cheeky shit and named them that, but hey.

 

Honestly, I don't really mind things taking a bit to finish, but I know some people can be super impatient.

[Nico coiN]

Here's how the mesh and its _l brother are rendering on my rig (GTX 780 GPU) :

 

 

The _r mesh is obviously darker, and turning off cube mapping makes it looking like the _l one.

[Jon]

Yeah, because of the improper material that Arth was talking about. The right one is not supposed to be so reflective.    The left one has a separate shape for the metal buckles, the right does not.  But they gave the whole piece the metal buckle material.   Technically, the metal buckle should be split off into its own mesh to match the _l piece, but modifying skinned stuff and keeping segment data is basically impossible right now.

 

Anyway, that's not the issue.  The issue is just that AMD refuses to run the shaders without breaking on some NIFs, esp. those with environment mapping.  

 

edit:  Bit of confusion with terminology because you put the _l on the right and the _r on the left....  

 

edit2:  And after realizing that... you do actually have an issue, just not the same as Arth.  Your shaders error on the _r but the mesh doesn't go invisible like Arth's.  So your _r is dark because there is no shading.   Is there no shading even if it's the first mesh you open?  Sometimes I've noticed shaders break when switching between meshes.   It's odd that my 980 Ti works fine on the _r but your 780 does not. 

 

I'm going to have to upload some trial-and-error shaders later for people to test.