Grimrock

So I thought one of the first things I'd try is making a new environment tileset. Will I have to match the existing tilesets exactly? As in, just one wall, one floor, one ceiling, one archway, and one column to stick in between wall segments? Just wondering so I know how to plan it out.

I believe I read somewhere that it is surprisingly complicated, I suspect there are a lot more parts to it than that.

Daniel.

You can see all the texture maps if you unpack them from the dat file. After making new 2d art, I assume it's just a matter of building matching meshes. In any case, if it weren't complicated it would be pretty boring.

That brings up another question: will I need to arrange custom assets so that secret buttons are in the same locations as they are currently?

That's a good question, I was curious about this too since I plan to make a lot of custom assets.. looking forward the answer

I made a python script in blender to import .mesh files, I'll see if I can get it up somewhere later.
This was only done for non skinned meshes but I guess it should work for skinned as well if stuff such as weights etc is taken into account.
I did not write a script to put it back out in the files again, and while I tried to figure out how the .model files where arranged I noticed that the geomtry scale isn't the same in them.

If you do know how to do stuff in code or write importers here's basically what I came up with (from the top of my head and some scribbles).
4 byte magic 'MESH'
int32 - seems to be 2 for the stuff I checked, could be anythin, version etc.
int32 - number of vertices

Now the following is repeated 15 times (15 vertex attributes?), lets call them block_headers
int32 - component type (2=int32, 3=float) ?
int32 - number of components ? (seems to be accurate)
int32 - byte width ? (seems to be accurate)
<block_data> - see <block_data> description

int32 - number of indices
int32 * num_indices - each triplet defines a triangle and is an index pointing to the vertex

int32 - number of materials

Now the following is repeated num_materials times
int32 - material name length (string length more or less)
<string> - material name (points to a material in assets/materials/default.materials)
int32 - No idea what this represents, seems to be 2 for everything
int32 - index offset
int32 - number of primitives

Last there seems to be some center of bound and min and max bounding info plus some unknown.
float - center x
float - center y
float - center z
float - ? (could be a w component for center I guess)
float - min x
float - min y
float - min z
float - max x
float - max y
float - max z


<block_data>
Depending on the block_header you have a block of bytes (num_vertices * block_byte_width)
So for the first 'vertex attribute' which always seems to be vertices it's 3 floats repeated num_vertices times.
What I could see comparing skinned models with static models this seems to be what goes into them
1. Vertices (3, 3, 12)
2. Normals (3, 3, 12)
3. Tangents (3, 3, 12)
4. Bitangents (3, 3, 12)
5. <Empty>
6. Texture coordinates (3, 2, 8)
7. <Empty>
8. <Empty>
9. <Empty>
10. <Empty>
11. <Empty>
12. <Empty>
13. <Empty>
14. Weight indices (2, 4, 16)
15. Weights (3, 4, 16)
So if the header is (0,0,0) you don't have a block and can start to read the next header immediately.

Hope it helps.

.models starts a little bit diffrent, they are basically

4 byte magic 'MDL1'
int32 - ? (seems to be 2)
int32 - num nodes (seems to be correct)

<node>
int32 - name string length
string - name of node
48 bytes - <3x3 rotation matrix> + <matrix translation>
int32 - Child node (0xffffffff if root node I guess ?)
int32 - Mesh index (? seems to be 0xffffffff for most stuff in skeleton setup except actual mesh node)

4 byte magic 'MESH'
<mesh block>

Didn't have a closer look at the bottom data of this file but for example the skeleton_warror.model it seems to be something like
int32 - number of transform nodes
<transform_block> * num_transforms
13 bytes - seems to be (00 00 00 00 00 00 00 00 00 00 00 00 01) for the stuff I looked at


<transform_block>
int32 - node index (?)
48 bytes - <3x3 rotation matrix> + <matrix translation>

<3x3 rotation matrix>
float float float
float float float
float float float

<matrix tranlation>
float float float

I did some tweaks on the Python import script for Blender and put it here
http://pastebin.com/2NkuGzCn

Make sure you extract the materials file
assets/materials/default.materials

Then extract your .mesh file you want to import.

It doesn't tell you what textures you need to extract, but if you do have the texture extracted it will put it in the material otherwise it will just leave it as blank.
It will attempt to load the .tga or whatever extension the materials file first before fallbacking to the .d3d9_texture

To install the add-on in Blender just copy the Python script and place it in your add-ons folder.
Example
C:\Program Files\Blender Foundation\Blender\2.62\scripts\addons\io_import_grimrock.py

Thanks a ton for that, the 3D aspect was going to be the hardest for me because I'm least experienced with it.

Welp, this is the result of a free weekend spent in Painter and learning a bit of Blender. (Fun fact: Painter's bristle brushes are perfect for making a layered sandstone appearance.) The normal map was a quick and dirty auto-generated one, so there's a lot of room for improvement.



The columns are going to be thin wooden struts. Creating actual movable buttons as well as compiling the meshes into Grimrock-friendly model files are still beyond my ken.

I also realized that each type of wall segment (wall with drain, with alcove, with secret button, etc) are each different models, so I should be able to apply a different texture to each of them as well. (Because this sandstone texture needs some variation to not look so obvious when repeating along a wall.)

I'll try and do something that exports the model back out into the game format as soon as I get home. Don't know if it's enough to patch the dat file with a custom model to reskin the first levels. I guess I can try and see if it works.