Jump to content
PaulGreen

Blender 2.63+ TRI file import/export plugins

Recommended Posts

Blender 2.63+  --  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.

 

   Place both files in the addons folder of your blender installation, for example:     ./blender 2.80/2.80/scripts/addons

   Also, activate the new plugin using User Preferences in blender options (under Import / Export section)

 

 

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

 

   I list myself as "anon" in the plugin just 'cause I'm weird like that. 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

 

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 the header from  io_import_tri.py  in the spoiler below:

 

 

Spoiler

REQUIRES Blender 2.63 or greater
The changes from use of Mesh.faces to Mesh.loops is a big one.

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


Anon's version: Version:  1.1


Changes:

2018-10-12  1.1
 * Fixed logging output

 


Original author listed as "Core script by kapaer, modvertice support by deedes"
updated by anon (me) to work with newer blender ( version 2.63+), 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 the header from  io_export_tri.py  in the spoiler below:

 

 

Spoiler

REQUIRES Blender 2.63 or greater
The changes from use of Mesh.faces to Mesh.loops is a big one.

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

 

Anon's version: Version:  1.1


Changes:

2018-10-12  1.1
 * 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

 

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

Usage: Have a *single* object selected in the active panel. That 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.
Apparently skyrim models except the child models use only full morphs.
   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: 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

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.
 

 

 

 

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

 

io_import_tri.py

io_export_tri.py

io_import_tribodyslide.py

Share this post


Link to post

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!

Share this post


Link to post

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?

Share this post


Link to post
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.

 

Share this post


Link to post

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

Share this post


Link to post
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..

 

 

Share this post


Link to post

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

Share this post


Link to post
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.

 

Share this post


Link to post

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.

Share this post


Link to post
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

 

 

 

Share this post


Link to post
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

 

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×