.BTO / .BTR file support about nifskope HOT 5 CLOSED

I'm not sure I knew this when I made the ticket, but dragging these files directly to the EXE works perfectly. So the biggest issue is just making the file association, which is up to the installer (See: #40).

The rest are updating all the filesystem models/filters to allow for the extension.

from nifskope.

I noticed the reason that these do not show up as textured for BTR/BTO files is that the Bethesda prepends Data/ to all the texture paths which is abnormal and not something NifSkope has ever dealt with.

from nifskope.

I've just discovered that the rather large scale of the BTR/BTO pieces causes them to render extremely dark. It seems that the LOD size (4, 8, 16) matches the scale, so the "4" pieces have a scale of 4.00. When scaling the mesh down to 1.00 it becomes normal brightness.

Clearly there is some kind of issue with the GL lighting and shading.

Update: It seems it only happens because they lack normals. This is an issue with how the renderer doesn't bother doing face normals on its own and instead the mesh uses one giant normal. This is also why the body components of armors change color strangely dependent on viewing angle.

I will need to create a ticket for this in conjunction with supporting model space normals. (Which BTR files also use)

from nifskope.

@jonwd7:

I noticed the reason that these do not show up as textured for BTR/BTO files is that the Bethesda prepends Data/ to all the texture paths which is abnormal and not something NifSkope has ever dealt with.

At first I thought you were confused, but now I see what you mean: for reasons probably not even known to Bethesda, the BSShaderTextureSet nodes in these files include Data\ at the beginning of the texture paths, even though resource paths are normally already relative to Data\ (or the root of whatever archive it is actually found in), making the Data\ prefix on these texture paths entirely spurious, and necessitating the removal of this spurious prefix prior to actually searching for the resource.

Nevertheless, it seems that you are [now] incorrect on one point: NifSkope 2 seems to find the textures despite the spurious Data\ prefixes. Also, the normals look fine here, maybe the relevant shader is utterly reliant on the normal map?

from nifskope.

@SamB Well, given that this issue predates my work on the matter, I wouldn't consider myself "incorrect on one point" since I'm the one who has done the work to fix the texture searching. See the pull request directly above you. :) Note I have done additional work since then, but I don't really keep these tickets up to date as much as I should.

from nifskope.