Kotor/TSL Model Format (MDL/MDX) Technical Details

[ndix UR 218]

I don't know how you figured that, because I'm just a user of the tools, I don't know how to make them .

 

Yeah that was my bad ... it basically came down to me misreading a forum that had less-obvious 'quote' styling, so when everyone was congratulating and thanking FairStrides it looked like they were all claiming to have taken over the project ... and I just picked wrong (and tried to use my memory instead of looking it back up, classic error!).  Sorry again for suggesting that you were a skilled toolmaker 

 

I have lately been elbow-deep in the MDLOps code, and I feel like I can address the discussion of vertex normals on some level now.  I have definitely noticed all the visual issues that redrob41 pointed out (especially the neck issue, which he is definitely correct in his assumption of the reason).

 

I just want to mention one important limitation of vertex normals as part of the MDL/MDX format. (Please forgive misuse of 3d modeling terminology ... it's not my primary focus). When you have a sharp edge between two faces, you have two very different vertex normals for the vertex locations defining the edge.  The MDL/MDX format stores the vertex normals per-vertex in the MDX file (similar to UV vert info), so it will never be possible to have perfect sharp edges across an edge defined by welded vertices/connected geometry. The vertices along sharp edges must be 'copied' or duplicated or unwelded or whatever the term is (I call it 'adjacent unconnected geometry' in my head because  ) when you have the vertices of different faces lined up in the same/overlapping position.

 

So yeah, wherever you are going to want sharp edges, don't weld your vertices.

 

In terms of the more sophisticated approaches to defining sharp edges that VarsityPuppet mentioned, I think the only thing that makes sense at the mdlops level is to use the smooth-group information.  My reasoning is that modeling software generally handles the 'sharp angle to smooth group' calculations (with varying levels of success ... but that's software for you) so the smooth-group info in the ASCII model should already have that built in (if that was the artist's intent).

 

Also, regarding the shadows, other than misclassified models, I have seen a lot of shadow errors creep in from modeling software munging the bone element trimeshes in various ways.  I can only speak from experience with 'soft shadows' turned off, but in that situation, it is definitely the 'bone' (*_g) elements that cast the shadows (at least for bodies. I just did quick research into this because one of my models was getting oddly stretched shadows). The two things I notice modeling software messing up most often for my bone trimeshes are: dropping the tvert indices in the faces list (because there is probably no texture assigned and definitely no actual tverts, so ... what do they mean exactly?) and messing up the orientation. Also, for me, I have seen munged hooks somehow affect shadows ... so yeah, it's complicated.

 

I have not yet purposefully undertaken bone geometry modification ... I'm afraid of what it will do to animations.

 

On an unrelated but on-topic note, I will probably take my first crack at some of the format tables and/or controller lists soon.

[redrob41 86]

I just want to mention one important limitation of vertex normals as part of the MDL/MDX format. (Please forgive misuse of 3d modeling terminology ... it's not my primary focus). When you have a sharp edge between two faces, you have two very different vertex normals for the vertex locations defining the edge.  The MDL/MDX format stores the vertex normals per-vertex in the MDX file (similar to UV vert info), so it will never be possible to have perfect sharp edges across an edge defined by welded vertices/connected geometry. The vertices along sharp edges must be 'copied' or duplicated or unwelded or whatever the term is (I call it 'adjacent unconnected geometry' in my head because  ) when you have the vertices of different faces lined up in the same/overlapping position.

 

So yeah, wherever you are going to want sharp edges, don't weld your vertices.

That's a nice summation.

 

Just to be clear though, on my shirtless body model example, I welded vertices on the ring around the chest, but did not weld the neck hole. I even showed the unwelded edges with green lines in the third figure of that screenshot. The problem, as far as I can see it, is that MDLOps 0.7a2 treats all edges as soft ones. It was done to clear up the hard edges on the head models (like the jaw line in this v1 head http://deadlystream.com/forum/files/file/451-twin-mullet-men/ which was fixed for v2 http://deadlystream.com/forum/files/file/780-twin-mullet-men/) so that unwelded vertices would be calculated as if they were welded. The side effect is that it does this even when I want a hard edge (like the body model neck hole).

In terms of the more sophisticated approaches to defining sharp edges that VarsityPuppet mentioned, I think the only thing that makes sense at the mdlops level is to use the smooth-group information.  My reasoning is that modeling software generally handles the 'sharp angle to smooth group' calculations (with varying levels of success ... but that's software for you) so the smooth-group info in the ASCII model should already have that built in (if that was the artist's intent).

I often do use smooth groups on my models in 3ds Max, but MDLOps seems to ignore that info. Either that, or it is lost when exported from Max. I'll double check my body model, but I'm pretty sure the faces of the "neck hole" are a different smooth group from the rest of the torso.

[Fair Strides 509]

That's what he's saying. Right now, MDLOps ignores the smooth groups and doesn't use that in calculations. However, it's possible to add with the changes he's made so far. I just need to find time between School and Sleheyron (mostly school at the moment) to get this straight on my computer.

[redrob41 86]

That's good. I'm looking forward to it .

 

I feel your pain FS, I know how hard it is to find time. I'm only posting right now because work gets slow in the summer, and I'm waiting for my boss to hand me a new file (which he just did, so I'm off).

[ndix UR 218]

Still haven't had time to write tables, so, another teaser, MDX data!
 
I have some knowledge/theories about the MDX data layout that I would like to relay.  First off, let's talk about the MDXDataBitmap (this is what MagnusII calls it). It is the UInt32 at offset 256 in the common mesh header, directly following the Int32 known as MDXDataSize.  The MDXDataBitmap tells you what common mesh elements are contained in an MDX row. What I mean by saying common mesh there, is that the Bitmap does not indicate subtype MDX row content, such as the bone map for skin nodes.  Why is that interesting?  Because the MDXDataSize (length of a single 'row' of MDX data) includes all the vertex-related data in its size number, including sub-type stuff such as bone map.
 
The MDL contains all the information you need to know what is in the MDX rows for a specific node, and the exact offsets at which you can find said data.  For those with limited understanding of programming etc, the MDXDataBitmap uses each bit across a 4 byte UInt32 (aka, 32 bits) to indicate that a particular thing is present (1) or not present (0). Each of the bits represents a power of 2, so, the first is 1, then 2, 4, 8, 16, 32, ... you can add or boolean OR each bit's value together to get a full value, so, for example, 39 = bits 1,2,4, and 32.
 
Without further ado, here is what I currently know(ish) about the MDXDataBitmap:
Value/Bit      Meaning
1               Vertex coordinates
2               Texture0 coordinates ('tverts' in ascii models)
4               Texture1 coordinates ('tverts1')
8               Texture2 coordinates? (no vanilla models use either of these)
16              Texture3 coordinates? (no vanilla models use either of these)
32              Vertex Normals
64              ???
128            Tangent Space
256            ???
512            ???
1024          ???
 
Why 11 values? This is the number of offsets that are stored immediately following the MDXDataBitmap in the common mesh header structure. In semi-typical Bioware fashion, the offsets are almost in the order the fields appear in the bitmap.
 
So, now I am going to reveal a theory that just occurred to me while writing this ... I have learned a great deal about that coveted '128 Tangent Space' (I say coveted because this is the structure required to support normal/bump mapping) ... and ... I think there is a pretty good chance that 256, 512, and 1024 could all be Tangent Spaces, one per texture (calculating Tangent Spaces uses texture UV coordinates for orientation of the tangent vector). That would mean we might actually be able to normal/bump map 4 separate layered textures individually! (stress on the might at this point, 100% untested theory)  The vanilla models only use 2 textures max and as far as I know the second one is only used for lightmaps, so there's no data anywhere in vanilla-land to support my claim. Although the lack of those extra 3 texture slots ever being used for bump mapped textures would explain why their corresponding MDX row offsets are never used...
 
Anyway, back to the known universe. In the MDL common mesh header, after MDXDataBitmap are the 11 offsets I mentioned earlier, these are a number of bytes into an MDX row where you find each particular thing.
Offset   Meaning
260      Vertex XYZ coordinates (12 bytes, 3 floats)
264      Vertex Normal (vector in 3-space) (12 bytes, 3 floats)
268      ??? Unknown bit 64 ??? (Unused, Unknown)
272      Texture0 UV coordinates (8 bytes, 2 floats)
276      Texture1 UV coordinates (8 bytes, 2 floats)
280      Texture2 UV coordinates (8 bytes, 2 floats)
284      Texture3 UV coordinates (8 bytes, 2 floats)
288      Tangent Space vectors for Texture 0 (3 vectors in 3-space (defining a 'space')) (36 bytes, 9 floats)
292      ???Tangent Space vectors for Texture 1 (3 vectors in 3-space (defining a 'space')) (36 bytes, 9 floats)
296      ???Tangent Space vectors for Texture 2 (3 vectors in 3-space (defining a 'space')) (36 bytes, 9 floats)
300      ???Tangent Space vectors for Texture 3 (3 vectors in 3-space (defining a 'space')) (36 bytes, 9 floats)

If my offsets are off by 4 here or anything like that, I apologize. The tables I have drawn up for myself use mdlops unpacked array indices, not byte offsets, so I am roughly translating on the fly here. The order of things is all accurate (to the best of my knowledge).
 
Some of you might be asking ... but where do I find the bone map in my MDX row?! Glad you asked. Offset 12 in the skin mesh header leads to the bone weights and offset 16 leads to the bone indices.  MDLOps was programmed to just assume it was the last 8 floats if you had a skin mesh.  That 'works', but this is about information, not functionality.

The additional tangent spaces hypothesis could actually be tested by an intrepid model hex editor (MDL file changes only).  The idea would be, start with a bump-mapped model like goto or c_malbeast, find a mesh node w/ the bump-mapped texture on it, move texture0 name to texture1 slot (move it by +32 bytes), then change the MDXDataBitmap (add 128 to it (changing 128 to 256 basically), also add 2 to it (changing '2' to '4', moving Texture0 coordinates to Texture1 coordinates), then you have to move the -1 at offset 276 to offset 272 and put the value at 272 (often the number 24) at offset 276 (swapping Texture0 and Texture1 MDX offsets), then you would move the -1 at 292 to 288 and the offset at 288 to 292 (swap TangentSpace0 into TangentSpace1). Something like that. Success would basically be 'it doesn't look different'. I know that is a really quick and maybe incomplete description of the experiment, so, you know, hex-heroes only
 
As usual if anyone has contradictory information, or is in a position to confirm or deny my findings, please correct, augment, etc. anything I might have said, thanks!  I won't be around again until mid next week, so don't expect any quick responses   
 
Also, for anyone that is a fan of the cruel and twisted nature of our universe, read this:

 

I think I have the tangent space calculations figured out almost, but I can't test my results because the bump-mapping effect doesn't work at all on my machine (even with vanilla bump-mapped models and textures)...  very. very. disappoint. anyway, that's all for a later post to the bump-mapping thread.

 

[DarthParametric 3,782]

Would 32/64/128 be likely to be normal, binormal, tangent?

[ndix UR 218]

Not quite. 128 is a tangent, bitangent (or binormal), and normal vector in a single 'field' (the vertex normals here vary slightly from the normals defined by bit 32, but are almost exactly the same values).  The vectors are I think definitely averaged with surrounding faces but I haven't yet figured out if they are weighted by area and or angle, and what the exact orientation of the tangent should be (all I can say right now is that it might be different from what 'the standard' (of today) says it should be).  I have been using your test pyramid   I just started making major progress on it a couple days ago, so not sure yet on some aspects.

 

Edit: Yeah, I meant to define that term 'Tangent Space' explicitly but forgot because it was kinda late. (I was hanging out w/ a mathematician on Tuesday nite. This stuff is all way below him, but he did school me a little bit). Mathematically speaking, 3 vectors define a space. A tangent space in particular is the space defined by a tangent, bitangent, and normal vector. So yeah, the '128 bit' data item is a tangent 'space', meaning it is these three vectors.

Edited July 21, 2016 by ndix UR

[Farmboy0 2]

Hi,

xoreos side dev here.

I have looked into KoTOR's model format but only briefly. (I am focused on Jade Empire atm)

I have a basic 010 editor template for KoTOR and KoTOR 2 MDL files. (mostly copied from JE)

I also wrote a 010 editor script that with some minor adapting can help find MDL files which meet certain criterias.

Or find out which values are used for a certain variable.

It does this by running though all the MDL files for a game, applying the template and then printing the stuff youre searching for.

 

If that is of any interest to anyone here please let me know.

[DarthParametric 3,782]

If you are willing to post those, that would certainly be appreciated. The script especially sounds very useful (manual hex editing is such a pain in the ass).

[Farmboy0 2]

Script: https://gist.github.com/farmboy0/81a61c261cb1402c486707fed8418395

KoTOR 1 Template: https://gist.github.com/farmboy0/e1b2b98991204af0e4ff0f60aa6e4d97

KoTOR 2 Template: https://gist.github.com/farmboy0/cd6d87cdee77cd507eda0fc521a18aae

 

The Templates will eventually find their way into xoreos-docs.

 

Edit:

Almost forgot the bash script.

Using 010 editor to analyze model files will become slower and slower per file.

So I wrote a bash script to only analyze 100 models at once before creating a new instance of the editor.

The bash script is here:

https://gist.github.com/farmboy0/d5ac9f82b46d0722ce236015b683aae6

[Farmboy0 2]

I have updated the KoTOR1 model template its almost complete now.

If you see anything wrong in it I would be interested to know.

 

I also updated the Analysis Script and the bash script for calling the editor.

Hopefully both are more usable and easier to understand and work with.

[Otaka 1]

Farmboy0, does your KOTOR1 model template handle animation in the placeables(doors, lockets)?

I checked Xoreos and mdlops and also told to the DrMcCoy about this.

Example of the problem:

 

There is a placeable (dor_lda01.mdl converted via mdlops 0.6). And I see in the animation section:

 

orientationkey

2 0 0 -1 3.14159265358979

positionkey

 

0 -0.041916698217392 0.096728503704071 0 0 0 0 0 0 0 -0.0645015016198158 0 0 0 0 0 0 0 0 -0.0474167987704277

0.100000001490116 -0.041916698217392 0.096728503704071 -0.00970267038792372 0 0 0.0229321997612715 0 0 -0.0474167987704277 0 0 0 0 0 0 0 0 -1.90687000751495 0
0.200000002980232 -0.041916698217392 1.33635848760605 0 0 0 0 0
0.533333003520966 -0.041916698217392 0.096728503704071 0
2 -0.041916698217392 0.096728503704071 0

 

Orientation is the same as in creature's orientation(time, quaternion[4]), but it seems there is something wrong with PositionKey. It seems that mdlops interpret controller data wrong.

 

Similar problem is in the plc_footlker.mdl and in other placeables. In creature models positionkey and orientation keys looks fine.

[Farmboy0 2]

I dont interpret controller data at all atm.

Its merely shown as an array of floats.

[sELFiNDUCEDcOMA 98]

Haven't read through the whole thread yet; been a while since I was last here.

 

Nice to see people are actually looking into this area of modding seriously, as it needs attention. However, I think it would be nice if someone who has the time to actually put all this model data into a bunch of tables. They could do it by creating a Google Docs Sheet that is read-only and only accessible if you have the link, and then posting that link here.

 

Otherwise its bits and pieces spread out in various posts -- not all in this thread. Just a suggestion.

 

Oh and my last suggestion... Use MDLops to learn from but don't update it if you want real longevity and to greatly expand what you can do in the future.

 

EDIT: probably should have read the last bunch of posts though before posting the above

[DrMcCoy 40]

However, I think it would be nice if someone who has the time to actually put all this model data into a bunch of tables. They could do it by creating a Google Docs Sheet that is read-only and only accessible if you have the link

Frankly, I for one would rather have the information free for anybody to access and use.

[sELFiNDUCEDcOMA 98]

Frankly, I for one would rather have the information free for anybody to access and use.

 

Yeah me too but it's up to the person who takes the time to create the resource to decide who can edit it and find it in the first place.

[Malkior 476]

If we hope for this community to survive, we need to allow new users to see which steps we took to achieve our goals.

 

Very few people have created our current best mods alone, and technology itself is built on the discoveries of previous generations.

 

Some amazing modders I personally know shot into the modding scene with the open information we provided on this site and LF.

 

However, it would be great to return to the topic at hand, as MDLOPS has a lot of potential to allow us to do even cooler things once we update it, and I am interested to see what people find out about the MDL and MDX format. (The bumpmap info was quite useful)

[sELFiNDUCEDcOMA 98]

Normally don't do this, just kind of go do something else for a while, but, this one has me stumped.

 

I was looking to work on my model tool project, that I haven't touch in some time. It's still at a point here I am building up a byte map of sorts by loading in a model file and then spitting out what every byte does and how the file is structured. There are a lot of unknown bytes, but, my main aim is to have all of the structure mapped out -- I can figure out what the finer details of the nodes at a latter point.

 

Anyway, I picked off where I last stopped off, and that was processing all the node information. Made good progress with a model file that doesn't have MDX, then I switched to one that does and then I got stuck. Essentially the mesh header points to data in the mdx, not what immediately follows on from that node. That's what's been the case so far.

 

So upon processing the Mesh Header, I have no friggin idea what node is supposed to come next. I did a little exploration of about 32 bytes and all I can say is that it looks like it has a pointer (6463) to data in the mdx file. Nothing else tells me what that node (or whatever you want to call it) is supposed to be. I've checked through the various sources that I'm aware of, and most are kind of vague about this area.

 

Anyone have any idea..? I pasted the last part of the generated text below; would really like to finish mapping out the structure by the end of the week.

 

EDIT: well looks like I missed the Face Array pointer pointing to 1467. The unaccounted for 8 byte gap probably helped throw me off; not sure what the deal is there, probably unaccounted mesh header data. But the rest I think is the list of face data.

 

 

 

 

> MESH HEADER (???): 

 

1139_Unknown-INT32 (4): 4216880

1143_Unknown-INT32 (4): 4216896

1147_Face-Array-Index (4): 1467

1151_Face-Array-Childs (4): 156

1155_Face-Array-Childs-DUP (4): 156

1159_Bounding-Box-Min-X (4): -0.10

1163_Bounding-Box-Min-Y (4): -0.28

1167_Bounding-Box-Min-Z (4): -0.12

1171_Bounding-Box-Max-X (4): 0.40

1175_Bounding-Box-Max-Y (4): 0.28

1179_Bounding-Box-Max-Z (4): 0.87

1183_Mesh-Radius (4): 0.65

1187_Mesh-Point-Avg-X (4): 0.17

1191_Mesh-Point-Avg-Y (4): 0.00

1195_Mesh-Point-Avg-Z (4): 0.31

1199_Diffuse-Col-R (4): 1.00

1203_Diffuse-Col-G (4): 1.00

1207_Diffuse-Col-B (4): 1.00

1211_Ambient-Col-R (4): 1.00

1215_Ambient-Col-G (4): 1.00

1219_Ambient-Col-B (4): 1.00

1223_Transparency (4): 0

1227_Diffuse-Map-01 (32): PLC_Chair1

1259_???-Map-02 (32): 

------START Unknown Bytes 

1291_Unknown-INT32 (4): 0

1295_Unknown-INT32 (4): 0

1299_Unknown-INT32 (4): 0

1303_Unknown-INT32 (4): 0

1307_Unknown-INT32 (4): 0

1311_Unknown-INT32 (4): 0

------END Unknown Bytes 

1315_Verts-Num-Index (4): 6459

1319_Verts-Num-Childs (4): 1

1323_Verts-Num-Childs-DUP (4): 1

1327_Verts-Loc-Index (4): 9295

1331_Verts-Loc-Childs (4): 1

1335_Verts-Loc-Childs-DUP (4): 1

1339_Unknown-Array-Index (4): 9299

1343_Unknown-Array-Childs (4): 1

1347_Unknown-Array-Childs-DUP (4): 1

1351_Unknown-INT32 (4): -1

1355_Unknown-INT32 (4): -1

1359_Unknown-INT32 (4): 0

1363_Mesh-Type (2): 3

1365_Unknown-INT16 (2): 0

1367_Unknown-INT32 (4): 0

1371_Unknown-INT32 (4): 0

------START Unknown Bytes 

1375_Unknown-INT32 (4): 1

1379_Unknown-INT32 (4): 2752527

1383_Unknown-INT32 (4): 1507368

1387_Unknown-INT32 (4): 3670041

------END Unknown Bytes 

1391_MDX-1-Strut-Size (4): 32

1395_MDX-Bit-Flags (4): 35

------START Bit Flag Values 

1399_MDX-Vert-Coords-Offest (4): 0

1403_MDX-Vert-Norms-Offest (4): 12

1407_MDX-Unknown-Pointer (4): -1

1411_Tex0-UV-Coord-Offest (4): 24

1415_Tex1-UV-Coord-Offest (4): -1

1419_Tex2-UV-Coord-Offest (4): -1

1423_Tex3-UV-Coord-Offest (4): -1

1427_Tex0-Tang-Vec-Offest (4): -1

1431_Tex1-Tang-Vec-Offest (4): -1

1435_Tex2-Tang-Vec-Offest (4): -1

1439_Tex3-Tang-Vec-Offest (4): -1

------END Bit Flag Values 

1443_Vertices-Num (2): 236

1445_Textures-Num (2): 1

1447_Lightmapped-Flag (1): 0

1448_Rotate-Tex-Flag (1): 0

1449_Unknown-Flag (1): 0

1450_Shadow-Flag (1): 0

1451_Beaming-Flag (1): 0

1452_Render-Flag (1): 1

------START Unknown Bytes 

1453_Unknown-INT16 (2): 0

1455_Unknown-INT16 (2): 1

1457_Unknown-INT16 (2): 1

1459_Unknown-INT16 (2): 0

1461_Unknown-INT16 (2): 178

------END Unknown Bytes 

1463_MDX-Data-Pointer-??? (4): 1074020455

1467_Vert-Coord-Pointer-??? (4): 0

 

Byte-Count: 332

Byte-Index: 1471 (1459)

 

1471_Unknown-INT16 (2): 0

1473_Unknown-INT16 (2): 0

1475_Unknown-INT16 (2): 6463

1477_Unknown-INT16 (2): 0

1479_Unknown-INT32 (4): 0

1483_Unknown-INT32 (4): 0

1487_Unknown-INT16 (2): 0

1489_Unknown-INT16 (2): -16512

1491_Unknown-Float (4): -0.12

1495_Unknown-INT32 (4): 2

1499_Unknown-Float (4): 0.00

 

Byte-Count: 32

Byte-Index: 1503 (1491)

 

 

[ndix UR 218]

@FarmBoy0 thank you very much for posting your K1/2 binary templates for 010. I purchased 010 because of this and have been quite happy with it. Before that I was using vim + xxd! I did heavily modify your originally posted templates for my own use. The recently updated versions are clearly much further along, there are only a couple major issues I find in them.
 
1 - a few emitter controller numbers are off or missing, here is a diff between your version and my newly edited (not finished) version:
 

 

@@ -190,24 +193,33 @@
emitter_lightning_delay=184,
emitter_lightning_radius=188,
emitter_lightning_scale=192,
- emitter_detonate=228,
+ emitter_lightning_subdiv=196,
+ emitter_lightning_zigzag=200,
+ emitter_alpha_mid=216,
+ emitter_percent_start=220,
+ emitter_percent_mid=224,
+ emitter_percent_end=228,
+ emitter_size_mid=232,
+ emitter_size_mid_y=236,
+ emitter_random_birthrate=240,
+ emitter_target_size=252,
+ emitter_num_control_pts=256,
+ emitter_control_pt_radius=260,
+ emitter_control_pt_delay=264,
+ emitter_tangent_spread=268,
+ emitter_tangent_length=272,
+ emitter_color_mid=284,
emitter_color_end=380,
emitter_color_start=392,
- emitter_alpha_mid=464,
- emitter_color_mid=468,
- emitter_percent_start=480,
- emitter_percent_mid=481,
- emitter_percent_end=482,
- emitter_size_mid=484,
- emitter_size_mid_y=488
+ emitter_detonate=502
};

 

 
2 - the alpha controller is 132. 128 is just p2p_bezier2.
 
3 - the first byte of uint32 field_50 in the model header is the 'classification' of the model, pretty important, so I break it out like this:
 

 

@@ -123,7 +123,10 @@
 
 typedef struct {
 	header_geometry geometry;
-	uint32 field_50 <format=hex>;
+	ubyte classification;
+	ubyte b_unknown1;
+	uint16 field_50 <format=hex>;
+	//uint32 field_50 <format=hex>;
 	uint32 count_child_model;
 	array animations;
 	uint32 p_supermodel <format=hex>;

 

 
4 - in the mesh header, int32 garbage[6] is where the animation of UVs goes, this is used for flowing rivers, rotating planets, cloudy skies, and is completely separate from TXI animations:
 

 

@@ -413,7 +427,12 @@
  int32 always_zero_2;
  ushort type;  // mesh type 3 = triangle list?
  ushort type2; // always 10 if set
- int32 garbage1[6];
+ int32 garbage1[1];
+ int32 animateuv;
+ float uvdirectionx;
+ float uvdirectiony;
+ float uvjitter;
+ float uvjitterspeed;
  int32 mdx_vertex_struct_size;
  vertex_struct_flags flags;
  int32 mdx_vertex_struct_offset_vertex;

 

 

 

5 - the unknownFlag following rotatetexture is 'background_geometry'. I do not know how it is interpreted by the game.

 

6 - the emitter header has a few things that are different from what I've been using. I have little idea which of us is closer to correct here. I think I would like to PM you about this stuff and/or do more research on my end before just posting info or a diff.

 

@Otaka, I am not diving into mdlops 0.6 to see why it produces that output, but it is probably stemming from the fact that the animation there uses 'positionbezierkey' animations, which mdlops tries to dumb down into linear 'positionkey' keyframes. Bezier animations have 3 floats for every piece of value data, rather than just 1. I cannot really explain what all the numbers do for these, but the extra numbers must be related to the interpolation around each value. I assume that you were looking at the opening1 animation in dor_lda01, at the position animation for Box04? If so, the raw controller data looks like this:

    positionbezierkey
       0  0  0 -0.04  0  0  0.1  0  0  0
       0.0333333 -0.0167227  0 -0.04  0  0  0.1 -0.0143337  0  0
       0.1 -0.0645015  0 -0.04  0  0  0.1  0  0  0
       0.2 -0.0474168  0 -0.04 -0.00970267  0  0.1  0.0229322  0  0
       0.533333 -0.0474168  0 -0.04  0  0  0.1  0  0  0
       2 -1.90687  0 -0.04  1.23963  0  0.1  0  0  0

Or, made into linear:

    positionkey
       0  -0.04  0.1  0
       0.0333333 -0.04  0.1  0
       0.1 -0.04  0.1  0
       0.2 -0.04  0.1  0
       0.533333 -0.04  0.1  0
       2 -0.04  0.1  0

Current and older mdlops has more than one issue that creates problems with controller and animation decoding, so I'm not sure which ones you are hitting. Hopefully this will help you at least understand where some of the weird numbers are coming from. On a side note, that is a really weird controller/animation node, because it doesn't seem to be changing the position at all (-0.04, 0.1, 0) ... just changing the interpolation (which would define the motion between changing values). So I kind of have no idea what to make of that animation. Sorry.

 

 

[DarthParametric 3,782]

5 - the unknownFlag following rotatetexture is 'background_geometry'. I do not know how it is interpreted by the game.

Could be what they termed vista objects in Eclipse. Low poly models outside the play area for distant objects on the horizon like mountains, forests, buildings, etc.

[sELFiNDUCEDcOMA 98]

Does anyone know of a TSL model that has an (161)  AnimMesh, or, are these only used in NWN..?

[Farmboy0 2]

AnimMeshes were only used with NWN1.

[sELFiNDUCEDcOMA 98]

AnimMeshes were only used with NWN1.

 

Thanks, I suspected as much having not seen a single model that makes use of them. Now just to implement animation events upon finding a model that makes use of them!