A start on the .MESH file format

Hi

I've been looking at the .MESH format and although it's not complete, I thought I'd share what I've found and maybe kickstart others to finish it.

I've mainly been looking at figure meshes (siege engine and other meshes are a bit different) and the information relates to these. All values identified as integers are 4 byte integers.

MESH files are stored as follows:-

.at byte 69 of the initial header - integer value for number of different mesh groups = num_group

.at byte 83 - start of first mesh group, integer showing length of mesh type (ie body ,arms, legs,etc) name string

.mesh type name string

.integer showing length of mesh group name(ie legs 01, arms 04, etc) string

.mesh group name string

.2 bytes of dummy data (only in first mesh group)

.integer showing number of triangles in mesh group = n

.n * 3 * 2 byte shorts for triangle values

.29 byte header/footer (only between first and second mesh groups all others are 23 bytes)

repeating below for 1 to num_group-1

.integer - length of mesh type string

.mesh type string

.integer - length of mesh group name string

.mesh group name string

.integer showing number of triangles in mesh group = n

.n * 3 * 2 byte shorts for triangle values

.23 bytes of header/footer

Then you have another 24 byte of header/footer

.integer - number of vertices = n2

.n2 * 2 * 4 byte float - texture coord u and v values (note here the uv values are based on a composite texture ie 2048 x 1024 - the figure texture on the left and the attachment texture on the right)

.28 byte of header/footer

.integer - number of vertices = n2

.n2 * 2 * 4 byte float - vertex weights (primary weight, secondary weight - from left)

.38 bytes of header/footer

.integer - number of vertices = n2

.n2 * 3 * 4 byte float - vertex vector

.36 bytes of header/footer

.integer - number of vertices = n2

.vertex/bone assignments, information in series of four bytes - (from left) byte1 = 0, byte2 = secondary bone, byte3 = primary bone, byte4 = 0

That's as about as far as I've got so far. There is another block of code following the vertex/bone assignments that I haven't worked out yet. It seems to be in series of three bytes followed by a zero byte - maybe something to do with shader systems - any ideas?

After this block is just a listing of the skeleton bones in hierarchy order. Hopefully somebody can use this to go further.

Cheers

GrumpyOldMan

Very nice work mate, keep it up if you can. Should be enough here to try some kitbashing

Quote:

---

Originally Posted by GrumpyOldMan

.integer showing number of triangles in mesh group = n

.n * 3 * 2 byte shorts for triangle values

---

Correct me if I'm wrong here but these arent xyz co-ords but references to the vertices the triangle uses? If so what part are the coords given? I've been trying to hand convert some geometry to obj but I'm getting nowhere slowly.

A polycount of a model based on grumpyoldmans finding for those that are interested ( arquebusier)

Head 246
Body 344
Arms 322
Legs 482
Prim 74
Sec 122

Total of 1590 plus an additional 52 in powderbag and 116 in the strap

Btw again good work, after a couple of hours messing about with the info you've provided i can appreciate how much time effort and patience you put into working it out.

Really good work guys! I'm still trying to get my head around it.:wall:
Is this how it works?

n2 vertex vectors (each entry a 4-byte float)

Code:

---

1.15  3.47  -1.04    [  0  ]
2.65  2.54    0.98    [  1  ]
3.77  2.15    1.44    [  2  ]
  .      .      .      [  .  ]
  .      .      .      [  .  ]
  .      .      .      [  .  ]
0.15  -2.38    3.72    [n2-1 ]

---

(The numbers in square brackets are meant to
be 0-based indices.)

n mesh group triples (each entry a 2-byte short int)

Code:

---

  0      4      5      [  0  ]
  5      4      3      [  1  ]
  4      0      6      [  2  ]
  .      .      .      [  .  ]
  .      .      .      [  .  ]
  .      .      .      [  .  ]
  7      3      2      [ n-1 ]

---

So each triple in the mesh group block are three
indices into the vertex vector array and this
defines a facet? I suppose the order of indices is
important as that and the right hand rule would define
an outward pointing vector so a rendering system would
know what the "outside" of the body is.

What would the vertex weights be used for?

Guy not guys, this is all grumpyoldmans work and thats how it seems to work. Are you converting this by hand grumpyoldman? I'm trying to write something which will automate at least some parts but I've no prior experience at coding so its an uphill struggle.

@casuir
Sorry, you're right. Point taken.

I've put together a Python script that
goes up to the bones section but I've
only tested it on a fake .mesh file that
I made according to GrumpyOldMan's
prescription. Do you have Python?

Yes, what does it export it too? For mesh extraction the vertex vectors, uv co-ords and tris are all thats really neccessary, the rest of it will be needed for putting stuff in though

Right now it doesn't export to anything
other than writing out the data to an
ASCII file so I can look at it. I'm not at
home so I haven't looked at a real .mesh
file yet. Probably it will be huge.

Edit: Have to take off, I'll check back
in a couple of hours.

They're fairly large alright, even the lowest lod of the smallest file has 818 vertices each with at least 5 values that have to be converted plus a similar number of tris. If its outputting as ascii it shouldnt be to hard to convert it to obj, obj format is a text file anyways.
http://www.eg-models.de/formats/Format_Obj.html

Well from the pics the guy posted at TWC it looks like each .mesh contains all the different body/head types for a unit which would account of the very large vertices count.

And it looks like he's working on making it open in 3ds max.

http://www.twcenter.net/forums/showp...14&postcount=2

I saw those pictures this afternoon. That's pretty impressive
what he's done. I tried my program on the arquebusiers_lod0.mesh.
It made it through all the tris but borked on the first set of texture
coords.:furious3: That was only 6000 lines of ASCII so not as bad as I
thought. I'll try to figure out the problem and then I need to start
deciding on a scheme to store this in memory for later outputting
to a binary.

Hi Guys
Thanks for the replies.

Casuir

Yes I've written something that takes the mesh, splits it up into component groups and writes it out in Milkshape ascii format. I was using this format to make sure that I was getting the mesh info out correctly. Unfortunately Milkshape doesn't have a facility for vertex weighting :no: . But I was able to check it against a skeleton I extracted from m2tw and the vertex weighting looked pretty accurate. I'll have a look at combining the skeleton and mesh and saving it in a format that supports vertex weighting. And then see if I can convert it back - as anyone that has taken apart a clock will tell you, the dismantling is easy, it's the reassembly that's the killer :laugh4: .

Lusted

Sorry the screenshot is from Milkshape not 3ds max. Unfortunately I've got no knowledge of Maxscript :embarassed: .

Knight Errant

Vertex weights are used for a more realistic movement of vertices. It's where a vertex can be affected by more than one bone, eg think of a vertex in the middle at the bottom of a tunic, either leg could make it go backward or forward. In RTW all vertices were only affected by one bone only.

Incidentally I've managed to extract info from siege engine files now. There's a pic of the war wagon at https://i150.photobucket.com/albums/.../war_wagon.png You should note that UV values for siege engines are for a normal texture ie 1024 x 1024.

I'll go back and look at the mystery block of code now and the header/footer arrangement. If I can I'll try to come up with something simple like a Mongol Arquebusier or Pikeman seeing there's lots of space on their attachment texture.

Cheers

GrumpyOldMan

@GrumpyOldMan
Thank you for the feedback. I'm trying to use your
information to write a Python parser to pull out the facet
information and see if I can image the meshes in MatLab
just to see what's there. I don't have 3dmax so I'm just
doing this for the fun of it.

PS: With your permission, may I just do @GOM in the future
to direct a reply to you.~:)

Hi KnightErrant

Yeah you can all me @GOM if it saves your typing :laugh4: . Can I call you @KE :laugh4: ?

Milkshape3d is a reasonable program that has a 30 day trial period, and the ascii file format is pretty easy to understand, maybe consider this?

Cheers

GrumpyOldMan

Thanks. Actually I like KE because the big dudes around here
seem to go by acronyms of their user names. I'll look for
Milkshape3d tomorrow, getting kinda tired right now. I have to
ask, because I'm sure everyone wants to know, are you going to
make a .mesh to 3dmax-whatever converter? The anim modders are
chomping at the bits for something like this. I must confess I
haven't the first clue about these things, I'm just a radar engineer
who likes cool programming puzzles.:thrasher:

Quote:

---

Lusted

Sorry the screenshot is from Milkshape not 3ds max. Unfortunately I've got no knowledge of Maxscript .

---

Sorry thought it was max, i know Max is what CA use to edit the .mesh files with their own script, so iom guessing that we might need to use max for editing .mesh files.

I finally got my program to process down through the bones
section. When I comment out the lines that write out the
data here's what the output file has showing what the sections
look like for arquebusiers_lod0.mesh.

Code:

---

22serialization::archive
3 4 4 4 8 1 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 4 0 1 3 1 0 0 0 0 0 7 0 1 0 2 0 0 0 0 0 26 0 0 0 0 0 11 0 1 3 3 0 0 0 6 0 0 0 72 101 num_groups = 26
mesh type name: Helmet
mesh group name: hat_01
n = 236
mesh type name: Head
mesh group name: head_01
n = 246
mesh type name: Attachments
mesh group name: strap_01
n = 116
mesh type name: Body
mesh group name: RN_Light_Body_01
n = 344
mesh type name: Arms
mesh group name: arms_light_01
n = 322
mesh type name: Legs
mesh group name: Legs_light_01
n = 482
mesh type name: Head
mesh group name: head_02
n = 246
mesh type name: Body
mesh group name: RN_Light_Body_02
n = 344
mesh type name: Body
mesh group name: RN_Light_Body_03
n = 344
mesh type name: Legs
mesh group name: Legs_light_02
n = 482
mesh type name: Legs
mesh group name: Legs_light_03
n = 482
mesh type name: Legs
mesh group name: Legs_light_04
n = 482
mesh type name: Head
mesh group name: head_03
n = 246
mesh type name: Head
mesh group name: head_04
n = 246
mesh type name: Head
mesh group name: head_05
n = 246
mesh type name: Head
mesh group name: head_06
n = 246
mesh type name: Helmet
mesh group name: hat_02
n = 300
mesh type name: Helmet
mesh group name: hat_03
n = 180
mesh type name: secondaryactive0
mesh group name: ren sword secondary_12
n = 144
mesh type name: secondaryactive1
mesh group name: ren sword secondary_13
n = 144
mesh type name: primaryactive0
mesh group name: arquebus_32
n = 74
mesh type name: primaryactive1
mesh group name: arquebus_33
n = 74
mesh type name: ramrod0
mesh group name: hand ramrod_42
n = 28
mesh type name: equipment20
mesh group name: powderbag_43
n = 52
mesh type name: equipment20
mesh group name: powderbag_44
n = 52
mesh type name: equipment20
mesh group name: powderbag_45
n = 52
number of vertices in texture coordinates: 4949
number of vertices in vertex weights: 4949
number of vertices in vertex vectors: 4949
number of vertices in vertex bones: 4949

---

@GOM
I have two questions on header/footer sizes.

Quote:

---

.at byte 69 of the initial header - integer value for number of different mesh groups = num_group

.at byte 83 - start of first mesh group, integer showing length of mesh type (ie body ,arms, legs,etc) name string

.mesh type name string

.integer showing length of mesh group name(ie legs 01, arms 04, etc) string

.mesh group name string

.2 bytes of dummy data (only in first mesh group)

.integer showing number of triangles in mesh group = n

.n * 3 * 2 byte shorts for triangle values

.29 byte header/footer (only between first and second mesh groups all others are 23 bytes)

repeating below for 1 to num_group-1

.integer - length of mesh type string

.mesh type string

.integer - length of mesh group name string

.mesh group name string

.integer showing number of triangles in mesh group = n

.n * 3 * 2 byte shorts for triangle values

.23 bytes of header/footer

Then you have another 24 byte of header/footer

---

Shouldn't the red line be a 34 byte header/footer line?

Second question, right before the bones section you have a
36 byte header/footer but I only see four zero bytes there.
Should it be a 40 byte skip because there I see
85 19 0 0 or little endian 4949.
I'm going to look at the headers some more to see if there's any
information in them.

Thank you very, very much for making this info available:bow: . This will
be a fun weekend.:laugh4:

There look to be 3 more blocks of data after the vertex-bone assignments part preceded by the no of vertices in the mesh. All 3 seem to be 4 bytes per vertex 3 values and a blank although some have two values and 2 zero bytes.

I tried looking at them as shorts as well as bytes but couldn't
see anything more as a pattern that way.

Here's whats in the header/footers, seems to just be count
sequences but in a sort of backwards pattern.
4 3 5
6 5 7
8 7 9
etc

I've no idea what that block of 112 bytes is after the mystery
block but before the bone strings start.

Code:

---

mesh type name: Helmet
mesh group name: hat_01
n = 236
0 0 0 0  0 0 0 0  0 10 0 1  0 4 0 0  0 11 0 3  0 0 0 11  0 5 0 0  0
mesh type name: Head
mesh group name: head_01
n = 246
0 0 0 0  0 10 0 6  0 0 0 11  0 5 0 0  0 11 0 7  0 0 0
mesh type name: Attachments
mesh group name: strap_01
n = 116
1 0 0 0  0 10 0 8  0 0 0 11  0 7 0 0  0 11 0 9  0 0 0
mesh type name: Body
mesh group name: RN_Light_Body_01
n = 344
0 0 0 0  0 10 0 10  0 0 0 11  0 9 0 0  0 11 0 11  0 0 0
mesh type name: Arms
mesh group name: arms_light_01
n = 322
0 0 0 0  0 10 0 12  0 0 0 11  0 11 0 0  0 11 0 13  0 0 0
mesh type name: Legs
mesh group name: Legs_light_01
n = 482
0 0 0 0  0 10 0 14  0 0 0 11  0 13 0 0  0 11 0 15  0 0 0
mesh type name: Head
mesh group name: head_02
n = 246
0 0 0 0  0 10 0 16  0 0 0 11  0 15 0 0  0 11 0 17  0 0 0
mesh type name: Body
mesh group name: RN_Light_Body_02
n = 344
0 0 0 0  0 10 0 18  0 0 0 11  0 17 0 0  0 11 0 19  0 0 0
mesh type name: Body
mesh group name: RN_Light_Body_03
n = 344
0 0 0 0  0 10 0 20  0 0 0 11  0 19 0 0  0 11 0 21  0 0 0
mesh type name: Legs
mesh group name: Legs_light_02
n = 482
0 0 0 0  0 10 0 22  0 0 0 11  0 21 0 0  0 11 0 23  0 0 0
mesh type name: Legs
mesh group name: Legs_light_03
n = 482
0 0 0 0  0 10 0 24  0 0 0 11  0 23 0 0  0 11 0 25  0 0 0
mesh type name: Legs
mesh group name: Legs_light_04
n = 482
0 0 0 0  0 10 0 26  0 0 0 11  0 25 0 0  0 11 0 27  0 0 0
mesh type name: Head
mesh group name: head_03
n = 246
0 0 0 0  0 10 0 28  0 0 0 11  0 27 0 0  0 11 0 29  0 0 0
mesh type name: Head
mesh group name: head_04
n = 246
0 0 0 0  0 10 0 30  0 0 0 11  0 29 0 0  0 11 0 31  0 0 0
mesh type name: Head
mesh group name: head_05
n = 246
0 0 0 0  0 10 0 32  0 0 0 11  0 31 0 0  0 11 0 33  0 0 0
mesh type name: Head
mesh group name: head_06
n = 246
0 0 0 0  0 10 0 34  0 0 0 11  0 33 0 0  0 11 0 35  0 0 0
mesh type name: Helmet
mesh group name: hat_02
n = 300
0 0 0 0  0 10 0 36  0 0 0 11  0 35 0 0  0 11 0 37  0 0 0
mesh type name: Helmet
mesh group name: hat_03
n = 180
0 0 0 0  0 10 0 38  0 0 0 11  0 37 0 0  0 11 0 39  0 0 0
mesh type name: secondaryactive0
mesh group name: ren sword secondary_12
n = 144
0 0 0 0  0 10 0 40  0 0 0 11  0 39 0 0  0 11 0 41  0 0 0
mesh type name: secondaryactive1
mesh group name: ren sword secondary_13
n = 144
0 0 0 0  0 10 0 42  0 0 0 11  0 41 0 0  0 11 0 43  0 0 0
mesh type name: primaryactive0
mesh group name: arquebus_32
n = 74
0 0 0 0  0 10 0 44  0 0 0 11  0 43 0 0  0 11 0 45  0 0 0
mesh type name: primaryactive1
mesh group name: arquebus_33
n = 74
0 0 0 0  0 10 0 46  0 0 0 11  0 45 0 0  0 11 0 47  0 0 0
mesh type name: ramrod0
mesh group name: hand ramrod_42
n = 28
0 0 0 0  0 10 0 48  0 0 0 11  0 47 0 0  0 11 0 49  0 0 0
mesh type name: equipment20
mesh group name: powderbag_43
n = 52
0 0 0 0  0 10 0 50  0 0 0 11  0 49 0 0  0 11 0 51  0 0 0
mesh type name: equipment20
mesh group name: powderbag_44
n = 52
0 0 0 0  0 10 0 52  0 0 0 11  0 51 0 0  0 11 0 53  0 0 0
mesh type name: equipment20
mesh group name: powderbag_45
n = 52
0 0 0 0  0 10 0 54  0 0 0 11  0 53 0 0  0 6 0 1  0 55 0
number of vertices in texture coordinates: 4949
0 0 0 0  17 0 1 0  57 0 0 0  18 0 56 0  0 0 18 0  58 0 0 0  1 0 0 0 
number of vertices in vertex weights: 4949
0 0 0 0  17 0 59 0  0 0 18 0  58 0 0 0  0 0 1 0  0 0 0 0  23 0 1 0  60 0 0 0  0 0 0 0  0 0
number of vertices in vertex vectors: 4949
0 0 0 0  22 0 1 0  61 0 0 0  23 0 60 0  0 0 0 0  4 0 0 0  0 0 28 0  1 0 62 0  0 0 2 0  0 0 0 0 
number of vertices in vertex bones: 4949
0 0 0 0  27 0 1 0  63 0 0 0  28 0 62 0  0 0 28 0  64 0 0 0  3 0 0 0 
number of vertices in mystery block: 4949
104 211 220 0  138 248 166 0  116 251 100 0  146 251 104 0  116 253 139 0  117 251 155 0  132 253 112 0 
149 42 34 0  212 35 104 0  157 250 142 0  24 196 97 0  57 42 192 0  150 35 212 0  155 250 145 0 
50 196 53 0  0 0 0 0  27 0 69 0  0 0 28 0  68 0 0 0  0 0 0 0  0 0 0 0 
0 0 163 234  138 61 211 32  148 62 220 16  18 63 237 205  184 63 0 0  0 0 26 0  0 0 0 0 
11 bone_pelvis 0
11 bone_rthigh 1
14 bone_rlowerleg 2
10 bone_rfoot 3
8 bone_abs 4
10 bone_torso 5
9 bone_head 6
8 bone_jaw 7
12 bone_eyebrow 8
14 bone_rclavical 9
14 bone_rupperarm 10
11 bone_relbow 11
10 bone_rhand 12
14 bone_lclavical 13
14 bone_lupperarm 14
11 bone_lelbow 15
10 bone_lhand 16
11 bone_lthigh 17
14 bone_llowerleg 18
10 bone_lfoot 19
13 bone_weapon01 20
11 bone_weapon 20
13 bone_weapon02 21
13 bone_weapon03 22
13 bone_shield01 22
11 bone_shield 22

---

What I meant was the mystery block is actually 3 seperate blocks with similar structure seperated by header/footers

Oh! Thank you, I totally missed that. I was wondering why there
seemed to be left over stuff from the mystery block. I mean I'm
seeing extra # # # 0 byte blocks afterwards so I must be missing
the header/footers.

After some searching on the web re 3D formats, could the
mystery block be smoothing groups for the vertices? Some
software uses 24 bits for smoothing groups but 3dsmax uses
32 bits so maybe that's why the fourth byte is 0, its to be
compatible with other software.

Edit: Sorry GOM, reread your first post and you already suggested
this.

I've looked at a few other mesh files and the block after the vertex weighting (mystery one) sometimes has a value other than 00 in the fourth byte nor does it follow this sequence right through the block, sometimes theres whole strings of 00s or 00 alternating with another value. Same goes for the other two blocks after it.

Look at as_light_fancy_cuman_archer_lod0.mesh or crossbow_militia_ug2_lod0.mesh and you'll see what I mean

I'm getting thin on ideas. Here's what I've tried this weekend.
Downloaded milkshape 3D as per GOM suggestion. No info in the
help or in its forums on the ASCII format so I tried the quick
tutorial and exported it to Milkshape 3D ASCII format but the simple
format doesn't really look like the blocks we see in the mesh file.
(Meshes seem to be more than triangles.)

Other tries: the .max format for 3dsmax isn't really a file format, its
more of a capture of the executable at the moment the user saves it
and it isn't really documented in anything I've seen. Drop back and
punt, maybe the old Autodesk format .3ds which is a binary format
which is simple chunking for the blocks we've seen in the .mesh
files. This can be loaded in Milkshape 3D as well as 3dsmax. Here's
a printable link to its format specification:

http://www.martinreddy.net/gfx/3d/3DS.spec

Maybe try this, write a program to extract the blocks from a mesh,
see if Milkshape 3D can read it (GOM already said Milkshape 3D can't
handle vertex weighting so leave this out). If so, use the spec to write
a .3ds file and then ask if somebody with 3dsmax can read it?

My head hurts when the walls are hard.:wall: Did I say that this would
be fun a couple of posts back?:surrender:

If ms3d is giving you headaches you could try obj, another asci format thats readable by nearly all 3d progs. Your program would have to output a file structured like this:
First vertex vectors, pull from the 3 floats in the . mesh files and write as follows: one vertex per line, 3 values per vertex seperated by a space and preceded by a lower case v (vertex) , ie:

v 1.0 2.6 3.5
v 3.2 2.3 0.91


next would be u.v. co-ords, same deal sept 2 values, preceded by vt (vertex texture):

vt 0.34 0.67
vt 0.23 0.69

next would be the meshs, pull the mesh name and the 3 integers per tri and write as follows: first line would be g (group) followed by the name of the mesh, next lines would be f (face) and the values for the three vertices in the group and their texture co-ords, v and vt seperated by a / i.e:

g head_01
f 324/324 367/367 356/356
f 356/356 366/366 344/344

first value is the v, second is the vt, they should be the same as each other. Your finished .obj file should look something like this:

v 1.0 2.6 3.5
v 3.2 2.3 0.91
vt 0.34 0.67
vt 0.23 0.69
g head_01
f 324/324 367/367 356/356
f 356/356 366/366 344/344
g head_02
f 533/533 567/567 556/556
f 556/556 566/566 544/544

except much bigger. That should give you an exported model with texture co-ords and seperate meshs for each bodypart.

Thanks Casuir! I think I was too focused on other things to notice
the thread you posted on post 9. I'll try coding this tonight and see
if Milkshape 3D imports it.

Processed an arquebusiers_lod1.mesh file. Turns out
the lower res mesh only has 1 block of data in the mystery
block, not 3.

@GOM
Does this information help in determining what the mystery
data is?

Hi Guys

Still here. Main problem at the moment is I'm having mystery reboots so it means taking my pc apart and trying to find what's wrong. So far eliminated software, dust and power supply as problems, now to look at video card or motherboard (shudder).

Haven't really progressed much myself, but it's really great to see you guys getting involved too.

Milkshape - There is an SDK available for download that includes file formats, it's at http://chumbalum.swissquake.ch/files/ms3dsdk177.zip. Also looking at their forum the next release of Milkshape will have native vertex weight support http://www.chumba.ch/chumbalum-soft/...ad.php?t=18854. The only problem I can see is internally storing the information within Milkshape to get all the information required for Mesh files.

I'm going to concentrate on the header/footers now because if we can understand those then we can at least do cutting and pasting to come up with new figures if the mystery block numbers can be just transported with the mesh bits.

Thoughts on the mystery block -

shadow system data? - why have three separate entries for hi-res figures?
normal data? - why not preprocessed and again three for hi-res figures?

Sorry not much there. Still looking. GOSH A ROAD MAP OF THE FORMAT WOULD BE HANDY AT THIS POINT (Do you think anybody from CA is reading this?). Don't despair if you don't hear from me for a while - might mean I've lived up to my name and put my boot through the pc :furious3:

Cheers

GrumpyOldMan

Nice to hear from you again. Bummer about your PC:embarassed:.
Casuir got me pointed to the obj format so I'm trying that right now.
There's a guy over at TW center doing a tutorial on 3D graphics like
normal maps and shading. I will try to pester him re shading sets to see
if we can get info that way. I've looked briefly at the wrl format which
Milkshape can export but not import but 3dsmax can read in. Its sort of
a meta 3D graphics format in that it allows all sorts of other things like
jpegs to be input into its "world". If it allows vertex weighting and shading
sets, if thats what they are, it might be a viable target format. It's also
ASCII so simpler that way.

Best of luck with the computer.

I am blown away at how promising this work is. Keep up the good work!!!

-wikiman