View Single Post
Old 04-11-07, 21:37   #6
ReeceMix
Explorer
 
ReeceMix's Avatar
 
Join Date: Aug 2007
Location: UK
Posts: 569
Default

Quote:
Originally Posted by T4Larson View Post
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 !
Code:
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

Last edited by ReeceMix; 05-11-07 at 00:29.
ReeceMix is offline   Reply With Quote