Import/export TR meshes with Blender

[sapper]

Found a python script on Lara's Levelbase that allows you to import/export TR meshes in TRviewer's .trmsh format into/from Blender.

Requires Blender 2.44, Python 2.5.

Trmsh import/export at Lara's Levelbase
-----------------------------------------------------------------------
edits:

Tutorial about using scripts in Blender from Alienhelpdesk. (Offsite)

Go to this post for link to updated versions from T4Larson's page.

To export from Trviewer open your .TR1, .TR2, or .TR4 level in Trviewer and right click on an object to get the options. The .trmvb option is presented for moveables and .trsmh for statics.

If you expand a moveable object you get the list of individual meshes. Right click on one of these to get the export options. The .trmsh option is presented.

Note you can input .TRC item into TR4 etc with fexmerger or convert .TRC to TR4 with TRC2TR4 or Turboconverter. Set your PC date to 2002 to get Turboconverter working.

Reecemix's post with all the download links.

Here's a link about UV mapping via 3DSmax. (Offsite)

Blender script that exports a mesh in DXF 3Dface format suitable for Meta & StrPix.

Blender script that import/export metasequoia format in this thread. (Offsite)

How to export Tomb Raider room geometry as 3DS and program to convert Rview dxf to PixStr dxf here.

How to get your model the right way up etc for export here.

How to change the shine (specularity) and get to the script config editor here.

Blender script to remap vertices here.

Program to convert Rview Msh files to Meta MQO here (Need python installed.)

[ReeceMix]

Are they textured/ uv mapped?

I dont think anyone uses TRViewer for meshes , just importing 3ds animations, apparently theres a milkshape plugin that convert msd>3ds for TRviewer too

[sapper]

Originally Posted by ReeceMix

Are they textured/ uv mapped?

Yes.

[ReeceMix]

Cool , But...(and its a huge Butt) is it possible to reverse the process by UV mapping lara and then importing it back into TRViwer ??

[T4Larson]

Originally Posted by ReeceMix

Cool , But...(and its a huge Butt) is it possible to reverse the process by UV mapping lara and then importing it back into TRViwer ??

It is. You can also use arbitrary oriented tris/quads, which means you can use blender's uv-unwrapping tools, just as you would do in a regular model-texturing procedure.
Even more, you can use blender's texture-baking mechanism to render model materials right into the texture (with lighting, if needed).

The import/export package contains an example file that uses this feature: The example model (a small table with a green transparent orb) was created from scratch, uv-unwrapped in blender, textured with procedural texture materials (which were then 'baked' onto the model texture area) and then exported (there's an ingame screenshot of the model as a static on LLB).

[ReeceMix]

Originally Posted by T4Larson

uv-unwrapped in blender, textured with procedural texture materials (which were then 'baked' onto the model texture area) and then exported (there's an ingame screenshot of the model as a static on LLB).

The table is included in the download of the plug in



This is a pre-existing uv mapped turtle head, i want to replace with laras head (I suppose it could have been the TRL head, but lara does nothing for me anymore and turtles are fun)

I simply tried to export it to trmsh and import it with trviewer, no suprise it didnt work 'out of memory' which is Trviewers way of saying ' wtf are you trying to import you freak that wont work'

so.... not that i understand half of what you typed, im guessing it has to be un uvmapped and turned into the classic squared textures (ive been saying for a long time that there should be a program somewhere that can cut up a uv map and turn them into compatible squares.. i just really hope this is what you mean and this is what i can do)

so basically, how do i get this turtle head into trviewer

-----
Edit 1, Ive imported laras head from trviewer into blender and its textured properly I just cant find the commands i want Blender is a CRAZY program lol

Edit2: Ive havent done it yet but I've read enough, This plugin is the real deal ! ... Ive just gotta learn how to use it lol

What It Does !

Import objects from .trsmh or .trmsh file

Meshes are imported from a .trsmh or .trmsh
file with texture and uv mapping data.
(trmesh files can be exported via the 
 trviewer tool by e.popov)
For each texture page in the imported meshe a new
texture image is created.
By default, these images are not saved to
disk automatically, but there's a toggle button
in the script configuration if you don't want
to do this manually.

Please see the trmesh_export.py help for
extended documentation about the supported
features.
=========================================================

Exports the selected object's mesh to trsmh/trmsh format.

**************
* Objects/Meshes
Meshes are exported to .trsmh (for static objects)
or .trmsh (for moveable meshes) format with all
required texture and uv mapping information.
These meshes can be imported into trviewer (by e.popov).

The mesh object's local axis correspond to the game axis, where
positive y points down and the objects x and z axis
is parallel to Blender's x/y plane.
Objects are automatically adjusted to their upright position
during import, but you should consider this when creating
models from scratch (which still can be rotated later to the
correct position)
Please remember:
- only the last selected object will be exported
- the meshe must have uv mapped faces, or they will not be exported.
- Meshes will be exported with local scaling, this means, that object
  scaling must be applied manually to the mesh (CTRL-A) before exporting


***********
* Textures

Textures and UV Mapping:
Due to the way how textures are handled in TR (which has
it's roots in the old software based rendering and is responsible
for the 'blocky' texturing look), all uv vertices are adjusted
'inward' 1 pixel during mesh import and expanded 'outward' during
mesh export.
The reason for this is to prevent neighbouring pixels, which are not
part of this texture fragment, to 'bleed' into the texture borders
(which happens due to texture interpolation), but o.t.o.h. produces
the well known seams.

So, keep a 1pixel texture border around the face's uv-area: If
your texturing looks right in Blender, will most likely look
right in the game.

There are no restrictions on the texture uv layout: You may use
arbitrary shaped uv's - they don't have to be rectangular (however,
only 3- and 4-sided faces are supported).
...BUT:
Every unique piece of the texture, that is mapped to a face, produces
a set of texture info in the mesh file. The goal is, to keep this
amount as low as possible.

During export, all congruent uv mappings are optimized
to produce the least possible amount of texinfo data for this mesh. 

For you, the mapper, this means:
Re-use texture mappings for multiple faces:
All faces that use the same uv-vertices (that is, the same piece of the texture)
are reduced to just one texinfo entry:
- even if the mapping is rotated (in facemode(F): press R),
- but NOT if it is mirrored, which produces another texinfo entry
  for all flipped faces (in facemode press M)

It is probably a good idea to enable 'snap to pixels'
(uv-editor's 'UVs' menu).
(uv coords are still rounded to the nearest pixel during export)

Maximum texture size is 256x256 pixels per texture image (page).
While you can have much larger texures in blender, they are not
supported in tr meshes and will be cut at the right and/or bottom border
to a maximum size of 256*256 pixels per texture image.

You can have multiple texture images per mesh (each with max 256*256 px),
but be aware that the slowest part of the script is the per-pixel texture
writing: Exporting a mesh with a lot of small (< 256x256) texture images 
will expand each image to full page size (except for the last image) and
make take a few seconds to export/import.

Besides that, it is not required to use every little space on a texture
image - multiple pages will be optimized when trviewer saves the
level file (as long as you click 'no' when asked to 'keep unused textures?')


Two sided textures:
TR-meshes do not support two sided texttures, so setting this texture flag
has no effect on the exported mesh.

All tr meshes with textures on both sides of a tri/quad basically have
to texture faces, sharing the same vertices. And here's the catch:
Such faces are imported and exported (if present) correctly,
but Blender does not allow to manually create new faces sharing the same
vertices. This isn't really a problem, but it would be nicer to
generate extra mesh-faces for twosided polys (TODO)


***********
* Lighting

Tr-meshes can only have one of either vertex lights (internal lighting)
or vertex normals (external lighting), not both.

Internal lighting:
If the mesh has vertex colors it will be exported with
internal lighting, where each vertex has it's own (fixed) brightness.
The vertex colors of the current active vertex-color layer are
reduced to their grey value and exported as "vertex lights",
so it may be a good idea to vertex-paint your model
with greyscale colors only.

External lighting / specularity:
To export a model with specularity or dynamic ingame-lighting,
it must not have an active vertex-color layer (which currently
means, none at all). In this case the model will be exported
with vertex normals.
Specularity strength for each face is taken from the
face's material "Spec" value (materials page, the "Shaders" tab),
but only if the faces "Collision" button is active (or the
"Light" button, see blender script config dialog settings for the im/exporter config)
(This solution is a bit awkward, the main reason being that enabling "Light" for
uv-faces mostly shows black faces in the uv-rendermode, if there's no properly
placed light source in the scene)

****************
* Bounding boxes

Collision boxes and visibility:
The collision sphere (for moveable-meshes) and the visibility- and
collisional boxes (for statics) are calculated on export according
to the meshes bounds.
This should work for most cases - for now, you have to adjust
the collision boxes externally if you need to.

Edit 3: Doh , i didnt have python installed lol

[T4Larson]

Originally Posted by ReeceMix

I simply tried to export it to trmsh and import it with trviewer, no suprise it didnt work 'out of memory' which is Trviewers way of saying ' wtf are you trying to import you freak that wont work'

Trviewer behaves a bit unstable under certain conditions (i.e., when saving the final .tr4 file, make sure you have the root entry selected in the treeview, so that no model is shown in the right half, otherwise it may error on saving - this is a trviewer problem, not related to the models), and I don't know what the problem is in this case.
However, check the blender output window after export and see if there were any warnings/aborts, in which case the model may not have been exported completely.
Another thing is, that each texture page in blender can be max. 256 pixels wide/high - this is due to the tr4 engine, where each texture page is 256x256 pixels and as such cannot have textured polygons crossing the tex-page borders (i've also mentioned this in the plugin documentation). If a texture is larger in blender, it will be clipped (the uv coord will not be scaled down automagically and may still be wrong, though).
It is hard to see how big your texture is on the screenshot (might be zoomed in), but I was trying not to produces invalid output files with at least a warning in the output
If it is larger than 256x256 you can scale down the texture and replace it for all marked uv-polygons.
You could also split the big texture up into multiple textures with 256x256 max each, if you want to keep the texture resolution, but this would also mean that you have to adjust the uv-polygons of the texture splitted parts.

so.... not that i understand half of what you typed, im guessing it has to be un uvmapped and turned into the classic squared textures (ive been saying for a long time that there should be a program somewhere that can cut up a uv map and turn them into compatible squares.. i just really hope this is what you mean and this is what i can do)

The thing is, uv-unwrapping of complex models isn't a trivial task - it cannot be fully automated to give satisfying results in complex cases. Blender has nice tools and features to accomplish this (ie. by using 'seams') which even comparable multi-thousands-euro tools like 3dsmax don't have.
The exporter doesn't need rectangular quads or tris: The tr4-engine supports them in any shape or orientation without any tricks or patches, so you can freely uv-map your models (given that you consider things like the texture-size limit)
The downside is that you have to take the time and learn to use blender (there's lots of documentation out there), and once you've mastered the awkward seeming interface you may find that it allow fast and efficient working.

[ReeceMix]

Im stuck, i am just guessing my way through blender but I seem to get a little further each time, I get this error in the control box when I try to export my turtle head

Python error check console

'The Console says'

Exporting mesh to c:\\ blah blah turtle.trmsh

found 113 unique textures

**** face tri uv data not cached - aborting: <<241, 245>, <225 ..etc

----------------------
just saw your post , i will read it now

[ReeceMix]

I saw the note about not being able to use more than 256 (it was 512x512) so I resized it and when i changed the texture to the new one the uv mapping was still the same (though the colours had changed slightly)

Would it be possible for you to write a short step by step tutorial for us?

[T4Larson]

Originally Posted by ReeceMix

**** face tri uv data not cached - aborting: <<241, 245>, <225 ..etc

This may happen if uv-polys are discarded during the collection, which may happen due to uv-coords being out-of-bounds, having zero-size or possibly other oddities in the uv-data.
If this problem persists and you are sure that everything is correct, you could send me the mesh (or the blend file) and I'll see if this is a bug in the script.

I saw the note about not being able to use more than 256 (it was 512x512) so I resized it and when i changed the texture to the new one the uv mapping was still the same (though the colours had changed slightly)

Ah yes, you are right, scaling the uvs isn't necessary in this case (because uv-data is usually in the range 0-1 in relation to the assigned texture bitmap, so the proportion and alignment basically stays the same) - I fixed that in the post

Would it be possible for you to write a short step by step tutorial for us?

I'm really sorry, but I don't want to do this again. People kept asking for instructions in the LB-forum, so I wrote a simple texture-mapping tutorial, but to little effect - they still found it to complicated compared to what they are used to, like metasequoia.
And I can't and don't want to blame them, blender (or modeling and texturing in general) isn't just something which you can learn just with a short tutorial without getting to know the program itself (oddly enough, I hardly see anyone asking for a step-by-step 3dsmax tutorial )
Blender is a powerful modeling/animating/rendering tool, and there is a lot of blender tutorials on the web, but I'm afraid you may not be happy with it if you don't spend a little time on getting used to it.