Jump to content
COMBATSIM Forum
Krycztij

TAW terrain format

Recommended Posts

....but not far off. :thumbsup:

um, I think I'll just let you get on with it. :)

btw, here's the static Chinook from TAW's custom combat screen:

chinook.jpg

Share this post


Link to post
Share on other sites

The strange thing is: Without a matrix stack, no rotors are drawn at all.

With a single matrix which is set upon 0049 and reset upon 0000, the rotor blades are drawn correctly, but in the center of the model.

And with a matrix stack, it looks like that. Something is weird here. I suspect: Only rotations are popped; translation is overwritten. Could actually make sense so that you don't have to define a position at 0;0;0 to use it in the instruction if you just want to rotate something. If only rotations are performed, then we only need 3x3 matrices, too. This could, then again, explain why there are nine words of whom six are unused. It's just space to set up a rotation matrix.

By the way: How does TAW control rotation of model parts? E.g. the ZSU-23-4 tower always faces you in the game ...

Share this post


Link to post
Share on other sites

By the way: How does TAW control rotation of model parts? E.g. the ZSU-23-4 tower always faces you in the game ...

That would be via 'Parameter 0000' which would be supplied from elsewhere.

EDIT: and if the default is 0000, this may support my billboarding theory for 002d if the turret always points towards you.

0138; 0062007a000000000000    ; Vertex :122  X=0  Y=0  Z=0

0139; 0075007a    ;

0140; 00480000    ;

0141; 0021000001b4    ; If Parameter 0000 = 0 then jump to line 215

0142; 0021000101b6    ; If Parameter 0000 = 1 then jump to line 217

0143; 0021000201ca    ; If Parameter 0000 = 2 then jump to line 219

..

..

0210; 002100450706    ; If Parameter 0000 = 69 then jump to line 353

0211; 00210046071a    ; If Parameter 0000 = 70 then jump to line 355

0212; 00210047072e    ; If Parameter 0000 = 71 then jump to line 357

0213; 002200470004    ; If Parameter 0000 > 71 then jump to line 215

0214; 0000    ;

0215; 002d007a073a    ; Vertex Test 122 , jump to line 359

0216; 0000    ;

0217; 0049000003800000000000000000000000000000007a0720    ; Vertex 122 , jump to 359

0218; 0000    ;

0219; 0049000007000000000000000000000000000000007a0706    ; Vertex 122 , jump to 359

0220; 0000    ;

..

..

0352; 0000    ;

0353; 00490000f5400000000000000000000000000000007a0038    ; Vertex 122 , jump to 359

0354; 0000    ;

0355; 00490000f8c00000000000000000000000000000007a001e    ; Vertex 122 , jump to 359

0356; 0000    ;

0357; 00490000fc400000000000000000000000000000007a0004    ; Vertex 122 , jump to 359

0358; 0000    ;

0359; 0062007bffe8ffe50016    ; Vertex :123  X=-24  Y=27  Z=22

0360; 0064000b    ; Vertex :124  X=-13  Y=27  Z=22

0361; 00660003    ; Vertex :125  X=-13  Y=27  Z=25

..draws turret

Share this post


Link to post
Share on other sites

This gets stranger by minute ...

0049 works with chinook1.3, a50.3, cobra1.3. It also works with the tower in crotale.3. But it produces weirdest results otherwise. Some models seem to expect rotation first, translation after. Others seem to expect translation first and rotation after. Even worse: Most models don't care at all; they draw their rotors and jet engines with some other displacement function I don't know of. See for yourself here:

http://www.mediafire.com/?23f12p88ze24267

Open 707.3, chouse parameter 1 and increase it. Everything's alright with the radar, but the engines are still drawn in the middle. Then open zsu_23_4.3 and increment parameters 0 and 1.

Share this post


Link to post
Share on other sites

What really disturbs me is that 707.3 does not draw its engines correct although there are no unknown instructions executed except 0061 and 0075. 0061 is very likely just a flushing instruction, but 0075 is a mystery to me. I just implemented a green point light whenever 0075 is executed on a position index. This is the result:

0075i.png

As you can see, 0075 does not only mark visible vertices -- it also marks the middle of decals and some other points I don't understand. The point under the wing (between the two rudders) is exactly where the inner engine should be. But there is none for the outer (see http://en.wikipedia.org/wiki/File:Boeing.e3-d.sentry.underside.arp.jpg). Forget about that. It's actually the upper vertex of the rudder shining through the wing :(

Furthermore, I found a major bug in my code: 002D is not a jump, it's a call. Almost all models which have been blank before are now drawing. All the missing parts in planes like the tornado are visible now. I'll see what else is jumps.

Share this post


Link to post
Share on other sites

I downloaded your latest release, and am impressed by how much new stuff is visible now. :beer:

The more I think about 002d, the more I think it has to do with billboarding. A bit like it's an order to point one of the axes towards the camera.

Share this post


Link to post
Share on other sites

This engine was quite old by the time TAW came along, and we may be seeing a mixture of different ways to do the same thing.

Feel free to correct my assumptions...

Vertex related, fairly well understood  


0040;a101.3       Same form as 003f, Test for value 128 only


Just an FYI Previous work on 0040 revealed these in para.3 and crate.3:
004000600005
Tests for value 96 instead of 128. Makes me wonder if these simply contain an older code compared to:
004000800004

Share this post


Link to post
Share on other sites

Previous work on 0040 revealed these in para.3 and crate.3:

004000600005
I looked for that, but couldn't find it: The sequence is there in crate.3 though, at the end of line 945 and start of line 946. We changed our theories a lot around the 0060 opcode....and maybe it still isn't right.
00600006000100d000000004000000d0001b0003000100d0001c0003000000d0001d0002000100d0001e0002000000d0001f0001    ;

0944; 0000    ;

0945; 002200010040    ; If Parameter 0004 > 1 then jump to line 949

0946; 00600005000100d1001b0004000100d1001c0004000000d1001d0003000000d1001e0003000000d1001f0002    ;

0947; 005f000200d10020000200d100210001    ;

0948; 0000    ;

0949; 002200020048    ; If Parameter 0004 > 2 then jump to line 953

0950; 00600006000200d2001c0005000200d2001d0004000100d2001e0004000100d2001f0003000000d200200003000000d200210002    ;

0951; 005f000200d20022000200d200230001    ;

0952; 0000    ;

0953; 002200030030    ; If Parameter 0004 > 3 then jump to line 957

0954; 00600004000200d3001f0003000100d300200003000000d300210002000000d300220002    ;

0955; 005c00d300230001    ;

0956; 0000    ;

0957; 0000    ;

0958; ffff    ;

0959; ffff    ;

Share this post


Link to post
Share on other sites

I downloaded your latest release, and am impressed by how much new stuff is visible now. :beer:

I am surprised because it does not yet include the 002D fix which makes so much more visible ;) It's a 0049 test only; I'll upload a 002D-fixed version when I'm done with 0049. I'd do it earlier if the viewer wasn't really messy and slow due to all my experiments with rotation and translation matrix stacks.

The more I think about 002d, the more I think it has to do with billboarding. A bit like it's an order to point one of the axes towards the camera.

I don't know; I just know it is a function call and not a jump. I also tested about ten more flags, but I did not get any usable results. It was not inconsistent, nothing disappeared, but there wasn't anything more visible either (except for the visibility test, which is definitely NOT a call). However: With 002D being treated as a jump, EVERYTHING is visible now. This is true not only for all the buildings which didn't show up, but also for the player F-22:

playerf22.png

I am, however, sure that 0075 has an ENORMOUS importance. It marks all important points on a model: The weapon pylons, the position of the pilot's head, the position of the afterburner etc pp. Whatever you need to know to spawn weapons or otherwise let the model interact with its environment: It is marked by 0075.

ef0075.png

Share this post


Link to post
Share on other sites

The more I think about 002d, the more I think it has to do with billboarding. A bit like it's an order to point one of the axes towards the camera.

No. To prove you wrong: 002D is the same as 0049, but without rotation. It means: "Pick position #n, push it as an offset onto the transformation stack, and call the subroutine at x B". The offset is popped when the subroutine returns. To prove you're wrong, this is 707.3 rendered with this interpretation:

002di.png

Or kc135.3:

21058465.png

Another one decoded and almost all planes are rendered properly (when not in action) now. :thumbsup: If you open the player F-22, it will even properly put its gear out. :woohoo:

The rotation in 0049 is still a mystery to me, though. And there are new problems: The clouds are not rendering any more. I haven't checked if that's because of 002D or 0049. Here's my current build -- it's slow and messy but it's also a leap forward:

http://www.mediafir...43xv18d2h8 Updated; see below

From memory, 008D is the same as 008E but for triangles instead of quads.

Done

0073 produces a >4 sided polygon, with palette colour set by a previous 0004 line like the 0002/0071 and 0003/0072 combinations.

Done, but I can't test it because one of the 0047 instructions in all ian_*.3 files is misinterpreted :(

004d,004f & 007e I can't remember right now, but will explain tomorrow if required.

Would be nice if you did :)

Removed these lines from the list of opcodes, since they don't exist in TAW. So, we're back to 99 opcodes. I'm fairly sure they exist in my parser due to experiments with the earlier games, TFX and EF2000.

New, need to scan for examples 

0036 

0050 

0006 

002c

001f

Done

Then there are these opcodes, which even though we don't know what they do, we might as well assume the jump is always valid or we won't see anything. Thus there is no need to display an option to toggle them at this time:

0076

007b

007c

0087

0093

Done

Now, onto the unknown polygons.

001a and 001b seem to define a triangle and quad respectively.

Suggest that they are temporarily rendered as brightly coloured polygons to see where they turn up.

Done:

001at.png

001bzh.png

The second word in the operand gives the color palette index.

Current version:

http://www.mediafire.com/?0yq06o6u4gen6lq

:icon_salute3:

Share this post


Link to post
Share on other sites

I'm very happy to be proved wrong about 002d. :thumbsup:

It'll be a couple of hours before I can try out your latest release, but in the meantime I can speculate a bit about some of the remaining opcodes.

I'm afraid I don't know the full story with 004c & 004f. They seem to do the same job as 0080 and 0081 respectively, by specifying the vertices associated with palette colours defined in the preceding 004c/004e lines.

Again, 007e is a bit of a mystery, but as it has the same format as 001b, maybe we can do the brightly coloured polygon trick, then investigate later.

Investigating further, 003e also has the same format.

007e000000be001800190017001a

001b00000026000e00010012000f

003e000000b00000000100020003

This looks to define 5 palette colours for some reason....and I think only occurs in one place, ses.3

0031000500c400ba00c400c400c4

These have the same form as 0003, so could be drawn that way for now...

00a200040025004e004f0028

003800b000bf00be00bd00bc

Share this post


Link to post
Share on other sites

Now downloaded the latest release, and WOW! Such progress. :thumbsup:

I've just spent the last hour just looking at stuff. :) Nothing technical to contribute whatsoever...

Share this post


Link to post
Share on other sites

Glad to hear you like it :)

Still no progress with the rotations :( Also, the 001A in the dam screenshot above is actually drawn textured in the game, I think. So this is not necessarily just a Gouraud-shaded polygon as I thaught.

Also, my plan is to have a look at SSD files now that most models are O.K. ...

Share this post


Link to post
Share on other sites

I see what you mean about the rotations. Some of the ships are interesting in that the gun turrets move as though the ship should be rotating with them.

You already have my ssd parser code. The .ssds aren't as 'easy' to interpret as the .3 files though. ;)

Share this post


Link to post
Share on other sites

The rotation issues become even more apparent if you open v221.3 and play with parameters #2 and #3 (or zsu_23_4.3 with parameters #0 and #1). This really annoys me.

Share this post


Link to post
Share on other sites

Does the simplest rotation work? eg for hdha_180.3, there is a single 0049 opcode for each LOD which, which as I understand it, would have the effect of rotating the model 180 degrees around the y-axis.

Share this post


Link to post
Share on other sites

It depends. For many models (e.g. V-22), rotations and even chains of translations work up to a depth of three. But some polygons, as the nationality marks on the left and right of each plane, are either inverted or pointing forward or backward instead of leftward or rightward. Then there are some rotations which do not make any sense at all -- the Y rotation is inverted on the Tornado (its wings will point forward), but if I invert the value, the MiG 27's wings will point forward instead.

I must admit that I was trying out usual approaches by chance until now. I'm just starting to analyze bytecode ... I'm working with amx_10rc.3, which is quite simple. A dump with the turret rotatet by 45° degrees and the cannon pointing upwards reveals:

0049 transformation: rotate by 0. -45. 0. degrees; translate by 0 0 0 // this is the turret

...

0062 write XYZ #197: 0 -22 20

0075 ??? (197) // This is the offset of the barrel relative to the turret

...

0049 transformation: rotate by 13.7109 0. 0. degrees; translate by 0 -22 20 // this is the barrel

This is quite obvious: Apply the rotation and translation of the turret, then apply the rotation and translation of the barrel. It does, however, not work with other models if I do it like that.

I must also check if I'm not accidentially inverting the rotations because I'm mirroring on the Y axis (it is inverted in TAW, you know). The order of rotation, translation and inversion is extremely important.

It is possible that the translation is not done by 0049, but by 0075. It's all a big mystery to me.

Share this post


Link to post
Share on other sites

It's possible the z axis may also be inverted, I'd need to check on a chiral model like dhow.3 that the model looks the same in the viewer as it does in the game.

I made a crude terrain viewer in VB a couple of years back, and the only way I could get the terrain to line up properly was by inverting the z axis. I may have made a mistake somewhere though...

Share this post


Link to post
Share on other sites

Oh no no no :banghead: My mistake was so stupid I'm almost ashamed to confess:

The multiplication of matrices is not commutative. When you push a new transformation onto the stack, you must not multiply the previous transformation by the new one, but instead multiply the new one by the previous one -_-

It does mostly work now — even chains of rotations and translations:

transv.png

The program is mature now. I think we have decoded most instructions which are related to renderijng; we have LOD support, can adjust many parameters. I'll look into the inverted rotations (orange arrow in the screenshot) and if I can fix them, I'll post the second public beta this evening.

What's still missing is INI files, building textures, AGP and those last unknown instructions. Finally, the finish line is visible at the horizon :)

Share this post


Link to post
Share on other sites

Fixed the rotation issue (you need to compute 65536-rot for rotation on Y axis), but with great success comes great failure. Here's my current build (also fixed minor errors like ten models not loading due to mistyped LOD offsets):

http://www.mediafire.com/?yd5v5711hg8w666

Personally, I don't think you have to invert the Z axis – it would make all "no step" signs etc become mirrored. But I don't want to exclude the possibility until all transformation issues are resolved.

I'm running through each and every file to identify the remaining problems, and it's still a lot:

  • The visibility tests on all rotated models fail. This is a huge problem: The visibility tests work with transformed coordinates, but I do the transformation in the renderer (because there's no point in matrix-vector multiplication with 16-bit integers). Applying the transformation to all data right in the processor will take quite a lot of time; it might even become a rewrite if I have bad luck.
  • Rotation on some parts of F-14 and player F-22 still doesn't work (see screenshot).
  • f22usa1.3 uses a wrong texture.
  • Translation on apache1.3 rotors doesn't work. Comanche looks ... interesting. There are misplaced polygons in truck_n.3 and zsu_23_4.3.
  • Many canopies (e.g. MiG 21's) are drawn as dark blue. I have no clue what's going on there.
  • chalenge.3 tracks and chinook1.3 loading ramps are duplicated for some reason.
  • Some polygons in crain.3 (is it really spelled like that?) are drawn without transparency. We must look if they use special draw instructions for them and apply transparency in that case.
  • ian*****.3 and neil_10.3 won't load because of a misinterpreted opcode.
  • radar.3, rdr_90.3 and rdr90.3 use unexpected texture positions.
  • ufo2.3 crashes if parameter #7 is above zero.

However, I think I'll release the public beta anyway. There's just too much progress compared to beta 1.

dam.png

playf22.png

Share this post


Link to post
Share on other sites

I fixed the anomalies with the decals. All transformations seem to work now, with the exception of duplicate or misplaced polygons in the cases I stated above. I consider 0049 being decoded now:

// 0049 <xRotation> <yRotation> <zRotation> <0> <0> <0> <0> <0> <0> <translation> <offset>

// Draw Transformed Submesh

// A transformation is pushed onto the stack and the subroutine at <offset> - 2 B is called. The

//	transformation is popped when the subroutine returns. It consists of (in that order):

//	— a rotation around the z axe by <zRotation> ÷ -65536 × 2pi

//	— a rotation around the x axe by <xRotation> ÷ -65536 × 2pi

//	— a rotation around the y axe by <yRotation> ÷ 65536 × 2pi

//	— a translation to the <translation>'th position.


// 002D <translation> <offset>

// Draw Displaced Submesh

// A translation to the <translation>'th position is pushed onto the stack and the subroutine at

//	<offset> - 2 B is called. The transformation is popped when the subroutine returns.

The zeroes are certainly legacy for something like scaling, mirroring etc. Next challenge, please! :lol:

Also, the 0007 parameter in the player F-22 is really cool. It adjusts the registration number between AF22040 and AF22056.

Share this post


Link to post
Share on other sites

[*]Some polygons in crain.3 (is it really spelled like that?) are drawn without transparency. We must look if they use special draw instructions for them and apply transparency in that case.

Unsure as to why they spelled it that way :rolleyes:

Looking at the instructions I am curious to know if 0083/0084 (terminator?) are currently understood?

009F00080008010300B9009E0043004400410042

00830000000000200020

002E0000000400000000000000800020008000200000

008E0004000700430042000A

0084

00830000000000200020

002E0000000400000000000000800020008000200000

008E00040043000700080044

0084

00830000000000200020

002E0000000400000000000000800020008000200000

008E00040044000800090041

0084

00830000000000200020

002E0000000400000000000000800020008000200000

008E000400410009000A0042

0084

00830000000000200020

002E0000000400000000000000800020008000200000

008E000400430007000A0042

0084

00830000000000200020

002E0000000400000000000000800020008000200000

008E00040044000800070043

0084

00830000000000200020

002E0000000400000000000000800020008000200000

008E00040041000900080044

0084

00830000000000200020

002E0000000400000000000000800020008000200000

008E00040042000A00090041

0084

009F0008000A010300C2009D000400420041

009F00080010010300C0009D000400430042

009F0008000C010300C0009D000400410044

009F0008000E010300BE009D000400440043

0000

Share this post


Link to post
Share on other sites

Looking at the instructions I am curious to know if 0083/0084 (terminator?) are currently understood?

No, we have no clue. But these could indeed control alpha blending. I'll have a look at them :icon_salute3:

Currently releasing Beta 2. In case anyone is interested in the source code: I didn't get it clean for this release, but it'll be included in the next release, I promise.

Share this post


Link to post
Share on other sites

No, we have no clue. But these could indeed control alpha blending. I'll have a look at them :icon_salute3:

Currently releasing Beta 2. In case anyone is interested in the source code: I didn't get it clean for this release, but it'll be included in the next release, I promise.

:thumbsup:

You really do some amazing work ;)

A thought on the last 2 screenshots you posted. Both of those models, if I understand your concern correctly, call associated .3 files. The f22usa1.3 uses the f22_xx.3 series models for control surfaces. The port rudder, for example, is F22_31.3. The Dam breach uses a wake/splash file to give a unique 3D image, I believe it's one of the ian.3 files. It could possibly be a problem with the communication of the transformations between the base file and its subordinates.

Thanks :thumbsup:

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...