Blender 2.80+, (2.63->2.79) TRI file import/export plugins

[PaulGreen]

Blender 2.80+  --  Plugins for Importing and Exporting TRI files
 

   These are updated plugin files for Blender for importing and exporting Skyrim TRI files. It might work with other games that use similar morph file formats.

   1) Remove  "-Blender2.XX" from the end of the filename if it exists
   2) EITHER:
       (preferred) Use the 'Install' button at the top of the Add-ons panel and select both .py files
          -- or --
       Place both files in the addons folder of your blender installation, for example:     ./blender 2.80/2.80/scripts/addons
   3) Activate the new plugin using User Preferences in blender options (under Import / Export section), by checking its checkbox

   Multiple .tri files can be imported at once by just selecting more than one in the file dialogue.
   Multiple mesh objects can be exported at once, using the option in the export dialogue. They are named according to the object name.  obj.name = "Head"  means the file "Head.tri" is automatically created in the selected directory, overwriting any Head.tri already there. CAREFUL: It is easy to accidentally overwrite filenames if the directory selected contains names already matching any mesh objects in the blend scene.

 

   The scripts are modified versions of  http://www.nexusmods.com/skyrim/mods/14589/?

 

   Permission is GPL as stated in the plugin files.

 

 

   The different morphs are created in Blender as "Shape Keys" in relative mode.

• The morphs can be shown by moving their magnitude slider between 0.0 and 1.0 (or greater by typing in a number). Shapes can be combined at different magnitude through these sliders.
• The morphs can be edited by clicking on a shape key and entering Edit mode. The mesh presented for editing will be the shape key position at 1.0 magnitude. The changes are saved back to the shape key when exiting Edit mode.
• The shape key names have some relevance. See the export header notes (listed below). As mentioned in them, the index number in the morph name actually has no effect for now, and isn't checked at all.
• The names of the shapekeys have relevance in the game. They are linked and used by name in the game, so don't change any pre-existing names. You'll need an .esp mod, I think, along with a plan for getting the game to make use of them somehow to make use of new morphs created. Don't ask me how, I dunno!

 

Updates
 

Spoiler

V2.2  2020-11-08
   Importer:

      * Allow importing of files with invalid UV-to-face index arrays, using import option
      * Remove the requirement for numuv == numverts. This was a misunderstanding of the file-format.

   Exporter:

      * Re-implemented the minimized UV export from the original script. Whoops

 

V2.1  2020-11-07
   Importer:

       * Allow importing multiple files

       * default object name no longer includes .tri

   Exporter:

       * Default export name is name of object
       * Added option to export all selected meshes

V2.0  2020-11-07

   Importer:

      * Added 2.80+ version

   Exporter:

      * Added 2.80+ version

 

V1.1  2018-10-12

   Importer:

      * Fixed logging output

   Exporter:

      * Fixed logging output
      * Added 'reorder verts' option
         This is to accommodate programs that re-order vertices on import based on order of
         reference in the face list. It will export the .tri file with the same re-ordering
         so that the exported file and main model file will have matching vertex orders for morphs.
      * Significantly sped up export speed
         Changed the way the byte strings are created to stop creating thousands of list copies

 

 

 

 

 

Importer

This is a copy of a portion of the header from  io_import_tri.py  in the spoiler below:

 

Spoiler

It should be noted that the "Mod-Morph" sections are much less tested, so may have problems

 

 

Original author listed as "Core script by kapaer, modvertice support by deedes"
updated by PaulGreen to work with newer blender ( version 2.8+), I hope

Usage: Imports a TRI file, expecting the format used by the shipped TRI files (those from
the retail game)

NOTE: There are some 'non-standard' TRI files, such as those exported by a program
called Bodyslide. These will NOT work with this. Those files should just be dealt with via their
respective programs.

 

 

 

 

Exporter

This is a copy of a portion of the header from  io_export_tri.py  in the spoiler below:

 

Spoiler

It should be noted that the "Mod-Morph" sections are much less tested, so may have problems

 

Original author listed as "Core script by kapaer, modvertice support by deedes"

 

updated by PaulGreen to work with newer blender ( version 2.8+), I hope

Usage: Have the main selection be a mesh object, and select any other objects to export, in Object mode.
There are export options in the export dialogue.
The object along with its shape keys are exported into a Skyrim compatible TRI file. The names of the morphs are the names of the
shape keys, minus the " []" or " ()". The file format may work with other games, just only intended for Skyrim
   The shapekey names are not entirely arbitrary. Every name should have an index number at the end
suchas "Anger [5]" or "EyebLeft (2)" with the index number starting at 1. The used of [ ] or ( )
around the index number has some meaning. [ ]'s indicate a "full" morph (the entire list of vertices
are in the morph) and ()'s indicate "additional" or "mod" morphs (only a subset of the vertices are in the morph
data). My understanding is that the original engine used these partial morphs for mixing morphs (you
can blink while also looking angry) but (speculation warning:) the engine no linger has this limitation.
A small number of .tri files shipped with skyrim uesd mod morphs, the child heads, and 6-7 others.
   In short, shapekey names should have a number in brackets after them, like "Angry [5]".
   For the current method of this plugin, the index numbers don't actually have any meaning. No check is
made on them, nor are they used for anything.

NOTE: As of this writing, it seems that the chargen plugin from Racemenu that reads
in and applies new morph files will trip up on any .tri file with 'mod morphs' in it, and it won't work,
(the whole file, not just the mod-morphs)

NOTE: There are some non-standard TRI files, such as those exported by a program
called Bodyslide. These will NOT work with this. Those files should just be dealt with via their
respective programs.

 

 

Bonus!- Bodyslide .tri importer

Only for Blender 2.63 -> 2.79
This script is dirty, and there are no plans to make it better, nor to create an 'exporter'. If you really want, you can export the morphs as .obj, then import as slider data in bodyslide.

I created this more out of fun than any particular use. No one should really need this. Import the base model into blender by either importing the built .nif from bodyslide's output, or import an .obj taken from the .nif or exported from bodyslide. Select the model in blender then import the bodyslide .tri file. The morphs will be applied to the model.
 

 

Noob trying to figure out the TRI file format. It might lead to clues for someone else doing the same:
 

Spoiler

 

 

 

 

 

 

 

Note that this site requires logging in to download, otherwise there will be an error "File not found" or similar.

Blender 2.80+

 

io_export_tri.py     io_import_tri.py

 

 

 

Blender 2.63->2.79
Note that these remain with the older capabilities they were created with.. no functionality backported from 2.X version.

 

io_export_tri.py-Blender2.63-2.79 io_import_tri.py-Blender2.63-2.79

 

Silly little bodyslide importer
 

io_import_tribodyslide.py

 

 

[PaulGreen]

Added exporter. Modified the import script to fix a few non-critical issues when using older blender versions.

[greenmango12]

Hi I am really exciting to find this tool   and thank you!

 

I have thought, tri importer may work only about blender 2.49 , then I have no plan to install another version only for tri.

But these days, I feel I want to make new tri morphs for my character body in racemenu.

(Now there is already importer ,exporter for nif about blender 2.7)  

I must try your tool, and may ask some quesiton if I need,,, anyway, thank you !!!

 

It should be "must" tool for me!

[Bad Dog]

So this is great and works like a charm, but...

 

Has anybody got some good advice for when it stops working? I have a mesh, exported tris, worked beautifully. Now I have a mesh that gives me an error: "See console window for more info - Error exporting tri file - Tri Export Error" But the console window just says the same thing. There are no messages related to the export before this. 

 

Does anyone have thoughts about what makes tri exporting fail? Any possibility of better error messages?

[PaulGreen]

On 3/31/2018 at 7:53 PM, Bad Dog said:

 

 

Hello, I have not been here in a long time.

 

If I remember, this worked but was not very well written. I hack things together more than make well-considered programs. It is likely that there is some unforseen format,  or that blender has since changed the API further,  so that the export does not work under all conditions again.

 

The best thing to do would be zip a .blend file with a failing .tri import (Blender to .tri) or the .tri file with failing export (.tri to Blender) and I can see if I figure out what fails.

 

[ipodtouchiscool]

hello I have a bit of a problem here. I exported tri and mesh using same mesh and made sure I kept the vertex order when exporting to obj but the animations in game just move random verticies instead and im baffled. maybe you can take a look and figure out what's going on? tool used for import export of obj to NIF is outfit studio. blender verson 2.79. also I have done this before with another mesh and it worked so im quite sure its not fallout 4 that's causing the problem.

tri.blend

[PaulGreen]

16 hours ago, ipodtouchiscool said:

 

 

  Hello, by luck, I very recently re-discovered a condition that is also the cause of this. Here are the two post texts copied from yesterday:

 

 

Spoiler

 

I think I remember what it was..

 

Review of the the code for outfit studio, it develops the array of vertices in memory by reading them in from the face list (things call it the 'index list' sometimes) in the order in which they are encountered. When the obj, .nif, or whatever is later exported, the vertex array is exported in the order in which it resides in memory.

   So, if the face list references the indexes of the vertex list in order, then nothing happens and is fine. If the verticies are referenced not in order in the face list, then the verticies are re-ordered on import and will be changed in any subsequent export.

 

For instance, try saving this as an OBJ and importing it, then just directly exporting it. See if it changes the order of the V:

v -1.000000 0.000000 1.000000
v 2.000000 0.000000 1.000000
v -3.000000 0.000000 -1.000000
v 4.000000 0.000000 -1.000000
f 2 4 3
f 1 2 3 

   If this is correct, then the exported obj should have a V list like:

v 2.000000 0.000000 1.000000

v 4.000000 0.000000 -1.000000

v -3.000000 0.000000 -1.000000

v -1.000000 0.000000 1.000000

 

   Then, any program that changes the order of the face list will likely cause outfit studio to alter the vertex order when this is imported. This might not be a great practice for a program to do, but it is also entirely valid. There is no requirement for obj files to reference vertex indicies in order.

 

 

 

 

Spoiler

 

   I tested what I mentioned above in outfit studio. It is indeed still the case... So any obj file with non-sequential vertex index reference in the face list will cause the vertex list to re-order. The case of 'non-sequential' lists is common when using other programs that work on OBJs.  Most programs don't bother to change the order of the face list if you don't adjust the topology, so anything exported from bodyslide will still be okay when imported as long as the list wasn't changed,  but anything generated outside or if the topology is adjust has a good chance of causing alteration.

 

   For instance, maybe the NIF you are working from already has a non-sequential face list, so that order is preserved through NIF export, through to blender, and then the import into outfit studio re-orders them. Additionally, changing the topology in blender has a good chance of causing a non-sequential face list as well.

 

   Additionally, I observe that the newest versions of Nifskope ALSO now do this... the same code style that re-orders verts on import made its way into nifskope apparently, heh.  The old versions like 1.3.3 do not do this,  but the latest 2.X versions do.

 

   So, basically, you have to be careful. Since bodyslide / outfit studio,  and now nifskope 2.X have a good chance of vert re-order when working with OBJs generated from outside,  it might be best to simply import / export as soon as possible in your working chain to get it in the style of OBJ those programs demand.

 

   I might even be able to write a script to fix this situation...  One can maintain the vert order, but just move around the order of the face-list lines (which no program should care about either) to try and maintain sequential order. It might not always be possible if doing so would mess up winding orders on the face lines, but some obj's could be fixed.

 

 

 

 

 

 

   Your OBJ file exported from blender has this 'non-sequential' face list condition, which as mentioned is also entirely fine for an OBJ. Howeber, Outfit Studio   AND   the new nifskope 2.X versions will re-order vertices on OBJ import for any OBJ that references vertices out of ascending order in the face list. Here is the example of the  first few lines of the face list in your OBJ. The first number in each set is the vertex index "v" reference (the 2nd is the UV "vt"  index and the 3rd is the normal "vn" reference). So, the list references in order 5,6,7,8,4,9,10,11,13,14,15,12   which is obviously not  1,2,3,4,5,6,7,8 ...

f 5/1/1 6/2/2 7/3/3
f 5/1/1 8/4/4 4/5/5
f 9/6/6 10/7/7 11/8/8
f 13/9/9 14/10/10 15/11/11
f 15/11/11 12/12/12 11/8/8

 

So, this means the the TRI file and the NIF file will have different vertex orderings..

 

I don't think the .NIFs  have to have the data represented this way. I presume it is this way for optimization, but I don't really know. Presuming that the vertex array has locality, like is stored sequentially in memory, then if one is walking the face list and loading data from the arrays, when vertex  1  is referenced and data grabbed from memory, a cache line is stored in the cache of the processor along with the the next X bytes of the array which would be vertex 2 through X/12 ...  So the subsequent references of verticies in the face list will find that the next X references' data is already in cache.

   Or there's no  "why"  and it was just programmed this way without intention, heh. 

 

    It might be useful if the programs presented a warning mentioning that they are about to re-order the vertex data array to make clear that it is altering the data in a way that may break a workflow unexpectedly.

 

Let me see if there's an easy way to fix this..

 

 

[PaulGreen]

Try this..   I added an option checkbox to the EXPORT called something like "reorder verts".

 

Based on the above, it will re-order the verticies and faces on purpose,  to match what outfit studio and nifskope 2.X will do when importing an OBJ. If the data is already in a format such that importing into these programs would not cause any change, then this will also not cause any change. Otherwise, the .tri file will be exported so that they contain data ordering to match that of files exported from these programs (that were created by importing an obj).

 

 

Try re-exporting your tri files with this option selected and just overwrite the tri files for the game. It should work right away. If it works, I'll update the main post.

 

One should still be careful in other contexts, working with OBJs created or with modified topology in other programs. Once this is done, (exporting with this option, importing into outfit studio as an obj, or importing into nifskope 2.X as an obj) morph data will no longer match from the original obj's without work to fix it. Probaly just import / export the model in outfit studio to get a re-ordered version.

 

 

 

 

io_export_tri.py

[ipodtouchiscool]

Wow thank you for the quick and professional replies. And the new plugin worked like a charm! Thank you very much.

[PaulGreen]

On 10/13/2018 at 11:12 AM, ipodtouchiscool said:

 

 

  Good to know it worked. As a note, I updated again, fixing logging and significantly improving export speed. The main download link in the first post has the most updated files.

 

[ipodtouchiscool]

I have a small suggestion for this plugin its more of a quality of life thing. Is it possible to add a slider or something similar in the export screen so you can put your tri shape through a multiplier? basically when I was doing the animations I found out that doing the tri shape mesh 1:1 with the target mesh made the movements barely visible. I then made the trishape mesh 10 times the size and redone the animations and finally the animations are visible but still not as much as it is supposed to.

[PaulGreen]

On 10/16/2018 at 7:32 AM, ipodtouchiscool said:

I have a small suggestion for this plugin its more of a quality of life thing. Is it possible to add a slider or something similar in the export screen so you can put your tri shape through a multiplier? basically when I was doing the animations I found out that doing the tri shape mesh 1:1 with the target mesh made the movements barely visible. I then made the trishape mesh 10 times the size and redone the animations and finally the animations are visible but still not as much as it is supposed to.

   Do you mean the size of the mesh as in scaling the whole mesh,  or do you mean the magnitude of the morph slider?

 

   It probably is better long-term to use options already available in blender if possible, since more options in plugins may add complication or be confusing, or those options themselves can become outdated and not work/require fixing if the blender API changes. The native methods will always work since they are part of main blender.

 

If the size of the mesh:

   Depending on where and how one imports / exports the mesh, I notice that some programs scale OBJ exports / imports by factors like 10. Blender can be set to do this too. This could maybe be happening? I think I remember 3dsmax, poser, daz, I think the steam animator program and such scale by default. OLDER blender's OBJ import/export also scaled by default, a factor of 10.0. Maybe check to see if "Scale" is something other than 1.0 for OBJ import?

 

   The TRI exporter exports using the actual vertex information positions,  ignoring "whole-object" scaling seen in object mode.  (  mesh = ob.to_mesh(scn, False, 'PREVIEW', False, False) for anyone who knows blender API).

     So, you can scale the whole object in OBJECT mode  X,Y,Z  all by 10.0 and then, in OBJECT mode, do  Object -> Apply -> Scale  to apply the object adjustment to the actual vertex information. This should keep all shape-key data intact. If not, try using a newer version of blender.. I think older versions didn't update shapekey data correctly when the basis was altered.

 

 

If magnitude of the sliders:

   You can adjust the "max range" of a slider below the shape-key box, then set the slider at "10.0" or whatever you'd like it to be,  then click the down-pointing arrow near the top-right of the shape-key box and do "New shape from mix". Delete the original shape and name the new one the same name. This will create a new shape where 0.0 -> 1.0  does whatever 0.0 -> X.X you created the shape from was doing. Currently, the TRI export will always export whatever "1.0" magnitude" does.

 

   If you'd need to do this for all shapkeys, it can be done by blender script. Be in OBJECT mode, and select the mesh.  Open another pane, swtich the main context to "Text Editor" mode (little button at bottom-left of all panes), create a NEW text file (or else you can't type / paste anything in the pane),  then paste this script and press "run".  Save before this in case I messed up, heh.

   Edit the scale factor in the script to whatever

 

Spoiler

import os
import bpy


# Max is 10.0. Can just do this script multiple times to get higher numbers
scaleFactor = 10.0

o = bpy.context.selected_objects[0]
scn = bpy.context.scene

#Switch to object mode
bpy.ops.object.mode_set(mode='OBJECT')

numSK = len(o.data.shape_keys.key_blocks)

#Basis morph is 0

morphNames = []
morphNames.append(o.data.shape_keys.key_blocks[0].name)


i = 1
while i < numSK:
    morphNames.append(o.data.shape_keys.key_blocks[i].name)
    o.data.shape_keys.key_blocks[i].name = o.data.shape_keys.key_blocks[i].name + "_old"
    
    o.data.shape_keys.key_blocks[i].value = 0.0

    i = i + 1
    
i = 1
while i < numSK:
    o.data.shape_keys.key_blocks[i].slider_max = scaleFactor
    o.data.shape_keys.key_blocks[i].value = scaleFactor
    
    o.shape_key_add(from_mix=True)
    o.data.shape_keys.key_blocks[numSK+(i-1)].name = morphNames[i]
    o.data.shape_keys.key_blocks[numSK+(i-1)].value = 0.0
    
    o.data.shape_keys.key_blocks[i].value = 0.0
    
    i = i + 1
    
#Note that as shape keys are removed, the indicies change, so index to remove is always "1"
i = 1
while i < numSK:
    o.active_shape_key_index = 1
    o.shape_key_remove(o.data.shape_keys.key_blocks[1])
    
    i = i + 1

 

 

 

[ipodtouchiscool]

The script only gave me a python script failed error and tells me to look in console but there is nothing there

[PaulGreen]

11 hours ago, ipodtouchiscool said:

 

 

The site is interpreting some of the code as markup language for the post. Let me see if I can fix it.

 

EDIT:  Fixed in the post above

 

[ipodtouchiscool]

Thanks! that worked!

[greenmango12]

Hi Paul Green  thanks your work!!   Hope if you will up-date for 2.8, someday,,,

 

register_module() have been removed,, for 2.8

https://wiki.blender.org/wiki/Reference/Release_Notes/2.80/Python_API/Addons

 

there have been some changes about ob.to_mesh()  arguments, for 2.8,, and depthgraph things.  blender bpy.

and to get mesh shape key modified, ob.to_mesh() not work anymore. though I still not test with 2.8..

 

https://docs.blender.org/api/blender2.8/bpy.types.Depsgraph.html?highlight=new_from_object

 

depth = bpy.context.evaluated_depsgraph_get()
eobj = ob.evaluated_get(depth)

mesh = bpy.data.meshes.new_from_object(eobj)

 

though I sitll keep 2.7,    but hope to test with 2.8 .

 

of course,,  I will try to up-date too,,  but I hope officially you up-date for 2.8 (it should be more stable,,)

[greenmango12]

I play this tool  with 2.79 version (recent beta, though it seems last version for 2.79)

this plug in still work without problem. then I could add  new slider for ECE SE.   (I hope to know way to add slider for Racemenu, but I can not find clear infomation,,

it seems not so different though,,,)  Thanks!!

 

Then  I do not know, PaulGreen still have plan to up-date this tool,   hope a few enhancement

 

1.  import export multi selected tri files.  

2  when save (export) tri files  ,auto set name as current selected obj name in blender .

it can make  easy overwrite or export  tri with correct file name,,  without check which tri file is correspond to .

(when make head morph slider, usually I need to import multi tri files,,(eye mouse,, full head,, etc) 

 

Anyway I really thanks you offer good tri import tool for blender 2.7.. I know there have been  some tools for blender to import tri,

but they only work with blender 2.5 , the  ui was nightmare for me ^^;  

 

[Heliostorm]

I am trying to use this plugin to import the .tri files for the Tera Elin mod here: 

 

 

However, it reports the following error:

Quote

----=| Tri Import Error |=----
Number of verticies differs from number of UV coordinates
TRI file has valid header, but file appears to be corrupt
   !! Since 'Base Verticies' != 'UV Coordinates', file is probably corrupt.
However, if TRI file is *not* corrupted, then it is possible that Author's
assertion regarding TRI files always correlating V and UV array indices
might be wrong.
   Probably should post if you see this error and are sure file is not corrupt
Collected Data:
Base Verticies: 2389
Faces:          4600
UV Coordinates: 2387
Morphs:         47
Mod Morphs:     0 with 0 verticies

 

I am quite confident that the file is not corrupt, so the assumption that V and UV arrays always correlate is incorrect.

 

Does anyone have a way around this? Obviously the mod author had some way to create this TRI file in the first place, so there has to be some way to open and edit it, but I've tried the plugins for both 2.49 Blender and this one and had no success. My goal is to import the TRI files to use the expression morphs in Blender.

[meister_tuete]

I updated this Plugin to work with Blender versions 2.80.0+ I tested it in 2.80.0 and 2.90.1 and it should work.  No new functionality added, just API changes. I'm still a beginner in all things Blender, so let me know if you run into any problems.

 

Edit: deleted files since PaulGreen updated the scripts again

[Zhoulia]

On 10/10/2020 at 11:45 AM, meister_tuete said:

I updated this Plugin to work with Blender versions 2.80.0+ I tested it in 2.80.0 and 2.90.1 and it should work.  No new functionality added, just API changes. I'm still a beginner in all things Blender, so let me know if you run into any problems.

io_export_tri.py 22.76 kB · 6 downloads io_import_tri.py 22.76 kB · 7 downloads

it does not work, I tried to import and nothing showed up

[PaulGreen]

On 8/18/2019 at 11:18 AM, greenmango12 said:

1.  import export multi selected tri files.  

2  when save (export) tri files  ,auto set name as current selected obj name in blender .

it can make  easy overwrite or export  tri with correct file name,,  without check which tri file is correspond to .

(when make head morph slider, usually I need to import multi tri files,,(eye mouse,, full head,, etc) 

 

This seems good. I will see if I can later, if I do not dissappear again.

 

 

On 9/4/2020 at 1:45 PM, Heliostorm said:

I am quite confident that the file is not corrupt, so the assumption that V and UV arrays always correlate is incorrect.

 

If you can, post or send me the exact .tri file, I will see. I am fiarly sure that all UV should be 1:1 on vertex, but as error states, not 100%. I need an example of otherwise.
I need to remind myself of tri format before I understand how to work with this, if the file is fine.
There are two possibilities, and I need to see which:

1) Some vertex do not have any UV. Then, either just don't assign them in  Blender, and exporter/importer have to be adjusted to deal with not all vertex having UV, OR just assign all vertex UV in blender, some with 0,0..
2) the uv is 'packed', and the .tri format has an ability to assign one uv entry to multiple vertex, that I've never encountered.

 

 

On 10/10/2020 at 4:45 AM, meister_tuete said:

I updated this Plugin to work with Blender versions 2.80.0+ I tested it in 2.80.0 and 2.90.1 and it should work.  No new functionality added, just API changes. I'm still a beginner in all things Blender, so let me know if you run into any problems.

Yes, thank you :3 .  Oddly, this is multiple times where I come back after a long time and someone fixes something just before. I updated the files and our changes are almost identical, heh. Importer worked fine, exporter had a bug which is fixed in main post file.

I see you have one post, so maybe this isn't a name you use often. Would you like me to credit you in the files I have in the main post,  with this username?

 

 

On 10/25/2020 at 8:52 PM, Zhoulia said:

it does not work, I tried to import and nothing showed up

Importer for this file worked for me, exporter had a bug where shapes would not be exported. Try files in main post, see if it is working.
 

[PaulGreen]

On 9/4/2020 at 1:45 PM, Heliostorm said:

 

EDIT LATER: I attached a fixed version. No UV, since that data is missing.

I looked at the whole package. The file named "FemaleHead.tri" in that package seems to be corrupt. It it is possible that it has a data form I'm unfamiliar with, as I've never found a Bethesda-sourced document that clearly defines all possible uses of a .tri file, but this seems unlikely.

The file claims to have 2387 UV coordiantes, and in fact does,  but then there should be an array of  (face_count * 3) integers that tell which vertex each UV coordinate attaches to. In this file, the correct length of array exists, but the data is all "0xFFFFFFFF" which is clearly wrong in the intent of that array to be indexing the UV to verticies.

 

The file may work in the game, because I think the UV are just ignored (at least in skyrim.. Again, not 100% sure), but technically, the file is corrupt as far as I know.

 

This is seen here (if you understand the implication of the image, heh). That is supposed to be the end of the (float, float) UV array and the start of the (int, int, int)  Face-Vertex-to-UV-Index array, but that whole array is just FF.
 

Spoiler

 

.

.

 

 

 

The other vertex data can be extracted out of the file, since the other arrays are fine, just no UV information will be saved.
 

 

FemaleHead-FIXED.tri

[PaulGreen]

Ok, so I also added the abilities mentioned above... Took longer than I thought .

Added ability to import and export multiple files at once. Export requires a checkbox, since it is potentially dangerous (can easily overwrite files accidentally).

 

Also, just cleaned up the files alot, removed old things that didn't need to be there.

[PaulGreen]

So, I realized a big mistake in what I originally thought about TRI and about UV in them. I used a concerning amount of time to look into this..  Here are collected information I could find. I still don't see much reference to them other than by what other 'fan'-projects have done:

 

Racemenu, Facegen, NiOverride  Info:

 

Spoiler

 

* nioverride from racemenu reads two types of .tri files
"Bodymorph" tri files, with a header of either TRI\0 (a line of text with a newline)  or "PIRT" (read as an int in little-endian, so technically compared to the string 'TRIP' in the code)
"TRIFile" which is the files that come from bethesda, only for 'head' objects, with header "FRTRI003"

* For the Bodymorph tri files, there are two types, "packed" and "not packed". Files with header+newline "TRI" are considered 'nonpacked', PIRT header files are considered 'packed' files

* Bodymorph files reference the trishape name from a NIF file (like, a mesh object), whereas the TRIfile file does not. Multiple trishapes can be referenced in a single Bodymorph TRI file

* bug in current github, looks like created Oct 18, 2018, nioverride means that the "not packed" files will never work. Morphs will always be just the base shape.
   This leads me to believe that is is likely infrequently or never used...

* in Aug. 2019, added the ability to read UV to the end of the Bodymorph style file

 

* nioverride uses TRIFiles for the facegen stuff, and Bodymorph for the body-morph data (Full body morphs)

* nioverride completely ignores the UV  in the Trifiles for the facegen data

* A small collection of .tri files shipping with Racemenu have off-by-one UV index errors in the files, so are technically corrupt

 

 

 

Bodyslide program Info:

 

Spoiler

 

* HAs support for what is called triheadfile and trifile.
   triheadFile are the bethesda-style FRTRI003-header files
   trifile are the equivalent to the PIRT-header files in Racemenu
* support for reading the FRTRI003 files was added in 2018
* The FRTRI003 file code does not support the 'modmorphs' at all (this is the old morphs set for older gamebryo stuff, I think, skyrim used it on first release for child head models, I think since is gone)

* I think, as I can see, Bodyslide formats and processes UV data as if the UV existed 'on the vertex'. So, each vertex can only have 1 UV co.

 

 

.

 

So, other observations:
 

Spoiler

 

* For the PIRT-header files: packed files use 2-byte shorts for the vertex count, and vertex offset data, and a 4-byte float for the morph scale (one per morph)

  unpacked files use 4-byte ints

* facegen plugin will be tripped up by any .tri file with "mod" morphs.. the code that reads it does not skip mod-morph vertices before polygons.. since basically no .tri's use this anymore, it's probably fine.

 

 

* NIF files store UV per-vertex
* As far as I know, the game engine uses per-vertex UV, no support for multiple UV per-vertex

* I can't find any reference to the who designed the PIRT-header tri files.. was it created by NiOverride / bodylside programmers, or are these also used by Bethesda? I guess I could just ask, heh...
* No skyrim .tri files from bethesda use PIRT, only FRTRI003, and there are no .tri files used on  non-head meshes.

* Tri files of both PIRT and FRTRI003 type can have UV-list arrays  !=  to the number of verticies, so this assumption on my part was just bad. Looking back at this, it was clearly wrong, so I'm not sure what I was thinking a couple years ago.
 

 

So Results:

 

Spoiler

 

* It seems like Bodyslide was designed to work with these PIRT-header,  packed files generally. The NiOverride fullBodyMorph plugin was designed to read these files and apply them to non-head-part meshes in the game (something not supprted directly by bethesda, I think).

* The Facegen plugin was designed to work with the FRTRI003-header style files that are used for head-parts. These are the only types of files that come from Bethesda (as far as I know).

* Skyrim is the last bethesda game I bought, so I can't look at any other game's files to test the above, heh.
* Bodyslide has, as of 2018, now been able to also import and export head-mesh tri files (FRTRI003) to create facegen morphs (I guess..)

* Although the FRTRI003 file format has the UV placed 'on the face", no other tool, nor the game engine (I think), nor the nif format store or work with UV in that manner... everything else appears to  work with split-topology meshes so that each vertex has, at most, one UV co.

 

 

So..
 

* importer should be able to hand variable-size UV lists.
* Exporter can look to see if UVs are ~ identical, and pack them onto one entry for the face-list-index array.. I realize now that this is what the original script was doing. I misunderstood previously.
* Making a PIRT import/export script has some use, I  guess.. If anyone wants this, post here, otherwise it may be not worth it.

[meister_tuete]

On 11/7/2020 at 7:35 PM, PaulGreen said:

Yes, thank you :3 .  Oddly, this is multiple times where I come back after a long time and someone fixes something just before. I updated the files and our changes are almost identical, heh. Importer worked fine, exporter had a bug which is fixed in main post file.

I see you have one post, so maybe this isn't a name you use often. Would you like me to credit you in the files I have in the main post,  with this username?

No need for any credit. This was just a fix I did for myself to look at some TRI files and then decided to share. I'm really glad that you are now back updating the scripts!