Looking at the 0015 opcodes in your A50.3 file, reminds me of the discussions I used to have with Polak regarding a visual phenomenon with the the A50's in TAW that displayed what I refered to as a "ghosting" quality. It made the A50's less visible/detectable in-game. IIRC this was exclusive to the Glide API installations, but I could be mistaken.

As to your statement regarding the evolution of the .3 file system, I would be interested to see if the Typhoon files show any progression?

One more question please?

In an effort to understand more fully, before you move on, I recall your statement regarding Back-face culling and am curious about (non-krus) file 11253 which is a blue square but only visible from one side:

FFE23E80000000007FFF00000000000000000000
0002000300030000000000000000000E022C022C022C0000000000000023
00620000FFE2FFEC0000
0065000A
0065000A
0065000A
0065000A
0064000A
0065FFE2
0065000A
0065000A
0065FFE2
0064000A
0065000A
0065000A
0065000A
0065000A
0064000A
0065FFE2
0065000A
0065000A
0065FFE2
0064000A
0065000A
0065000A
0065000A
0065000A
0064000A
0065FFE2
0065000A
0065000A
0065FFE2
0064000A
0065000A
0065000A
0065000A
0065000A
006100230000
00020010000000090001
0071000100090006
0071000100060002
0071000200060007
0071000200070003
0071000300070008
0071000300080004
0071000400080005
00710009000A0006
00710006000A000B
00710006000B0007
00710007000B000C
00710007000C0008
00710008000C000D
00710008000D0005
00710005000D000E
0071000A0013000B
0071000B00130010
0071000B0010000C
0071000C00100011
0071000C0011000D
0071000D00110012
0071000D0012000E
0071000E0012000F
0071001300140010
0071001000140015
0071001000150011
0071001100150016
0071001100160012
0071001200160017
007100120017000F
0071000F00170018
00710014001D0015
00710015001D001A
00710015001A0016
00710016001A001B
00710016001B0017
00710017001B001C
00710017001C0018
00710018001C0019
0071001D001E001A
0071001A001E001F
0071001A001F001B
0071001B001F0020
0071001B0020001C
0071001C00200021
0071001C00210019
0071001900210022
0000
FFFF
002000200020

Any comments would be informative.

Questions are what will make this thread live or die, the more the better.

I don't anything about Typhoon since I haven't managed to extract the files.

That 11253 file is interesting, they don't come much simpler than that. I don't have time to analyse it today, but the following line defines the colour (I think):

00020010000000090001

The value in red gives the palette position which should be blue.

A bit more detailed comment on DrKevDog's example above:

The file describes a vertical blue rectangle made out of 48 triangles, only visible from one side. Which side is shown depends on the order the vertices appear in the polygon descriptors (the lines starting with 0002 and 0071).
If we take the first 0071 line:
0071000100090006
This describes a triangle made up vertices 0001,0009 and 0006. If you could see a pointer which circulates between these vertices in space in this order 1->9->6->1->9->6, the pointer would be moving in either a clockwise or anticlockwise direction depending on which side you were looking at.
This is used as a test by the graphics engine to decide whether to show the triangle or not. The opposite side can be displayed instead if the vertices are swapped thus:
0071000100060009

In TAW if both sides need to be seen, then both are described separately, ie:
0071000100090006
0071000100060009

Note that if this line to added to the file above, then there are some bytes in the 'header' which would need to be changed as well to maintain integrity.

If we take the header:
FFE23E80000000007FFF00000000000000000000
0002000300030000000000000000000E022C022C022C0000000000000023
...and split it up further
FFE23E80000000007FFF00000000000000000000
0002000300030000000000000000000E
022C
022C
022C
0000000000000023
..and if we count the number of bytes to the end of the file following the last 022C, we find there are 556 decimal or 22C hex. So, for reasons currently unknown, if we add an extra 0071 line, then we have to add 8 to each 022C, giving 0234 hex....or we get a crash.

Bravo, very well done, and you described the process as a skilled educator would communicate: clearly and effectively.

So to summarize, I would say we started with my erroneous statement of a blue square which has now been described as a blue

rectangle comprised of 48 triangles with 23 Vertices. The anticlockwise polygon winding convention utilized by the graphics

engine to determine the face only shown feature is a destinctly dfferent convention than back-face culling and thank you for

that.

The area of some question is in your statement regarding the line which defines the colour: 00020010000000090001

You stated the value in red gives the palette position which should be blue, however, in your previous description of the

control surface file, 'f22_30.3' you described the following:


Then comes 3 shaded polygons in lines 0027 to 0032. The following must be trated as a pair:
004CBABAC000
0080000500060004

The '004C' opcode is for shaded triangle, and taken together with the following '0080' line, can be interpreted thus:

Vertex 0005 uses palette colour BA
Vertex 0006 uses palette colour BA
Vertex 0004 uses palette colour C0

Should not the colour determinants for the rectangle be the conventional analogous pair:

006100230000
00020010000000090001

???

Looking back at Polaks index of palette colors and applying this to the control surface file, vertex 0004-0006 use palette colours BA & C0 which are the correct Plane
camo.

I do see how your 16 (Dec) gets us blue for the rectangle (00020010000000090001) and are we then, perhaps, describing a vertex colouring scheme that involves a
non-shaded triangle opcode which extends over vertex 0009 and 0001?


As to 006100230000 and the potential for palette colour pairing, 0=Black and 23=Terrain Textures...

The '006100230000' line has something to do with vertex description rather than polygons.

There are various ways that the polygons are defined. Polygons can be 3 or 4 sided, although lines will be included in this category as well.

1. ‘004C’ and ‘0080’

Example

004CBEBEB000 The ‘004c’ line is always followed by one or more ‘0080 line:
0080002B00280003
00800028002C0003

This relates to non-textured triangles, and the ‘004c’ line gives which palette position will define the colour at each of the 3 vertices. So, using the first ‘0080’ line, vertex ‘2b’ will be coloured with the colour at palette position ‘be’. Vertex ‘28’ with colour ‘be’ and vertex ‘03’ with colour ‘b0’.
This will result in a triangle with different colour corners, but the colours are somehow blended together as a gradient between the vertices.

2. ‘004E’ and ‘0081’

This are the 4 sided version of the above:

Eg
004ED4CCCCD4
008100560052002C0028

3. ‘0002’ and ‘0071’

These relate to triangles of uniform colour. The ‘0002’ line sets the colour and used vertices of the first triangle. If there are more triangles of the same colour needed, the ‘0071’ line is used.

Example:
000200C4004000420039
0071004100400039
00710008003B003A
007100090008003A
000200D0004000390042
0071004100390040
00710008003A003B

Here, the first ‘0002’ line sets the colour at palette position c4 to be ‘used’. This colour will be used for the following ‘0071’ triangles, after which the second ‘0002’ line changes the colour to ‘d0’.

4. ‘0003’ and ‘0072’

This is the 4 sided equivalent of ‘0002’ and ‘0071’.

Example

000300B900210020001D001C
0072001C001D00250026

5. ‘009F’

Example:
3 sided
009F000C0032030100CA00C900CB009D000900020001
00000000____0000____________0000____________
__________T_______C1__C2__C3______V1__V2__V3
(the 0's are used as filler to try to create some 'whitespace' on this site, although it still doesn't line up properly )

This is used for textured polygons, but if the texture is not used, also contains the colours (C1,C2,C3) to be used at the vertices to produce a ‘shaded’ polygon instead. In the example above, which is taken from ‘tent_3.3’, the texture(T) is defined by the number 32h or 50 in decimal notation. Some cross referencing is needed to find out what this means.
In the ‘3’folder there are some ‘.ini’ files. Here are the relevant parts of ‘red1000.ini’

[dir]
TM=red1000
[globaltextures]
1=cam3_9
2=cam3_10
3=plane_21
4=material
5=mattdead
6=mob_5
7=fx_4
.
.

[surface]
.
.
48=txtr 10,(192,128),(223,128),(223,159),(192,159) ;BOT ROCK
49=txtr 10,(224,128),(255,128),(255,159),(224,159) ;TOP ROCK
50=txtr 4,(0,160),(31,160),(31,191),(0,191) ;N CANVAS
51=txtr 4,(32,160),(63,160),(63,191),(32,191) ;NE CANVAS
.
.
In the [surface] section, it can be be seen that 50 corresponds to ‘txtr 4’. According to the [globaltextures] section ‘4=material’ which finally gives the filename of the texture to use. This is ‘material.tm’ from the ‘red1000’ directory in this case.

The coordinates given in the [surface] section give which part of the texture to use since the texture size is fixed as 256x192. So, in this case the part used is outlined in red.


The 4 sided example is shown here:
009F000E0036040100CA00C900C800C9009E0004000300060005

There is also a simpler version of ‘009F’ to be used when it is not required to have separate colours for each vertex if the texture is not used. A single colour is specified instead.

Example:
009F00080038010300CC009E0009000400050008

Here the colour ‘cc’ is applied to the whole 4 sided polygon if the texture ‘0038’ is not used.

6. ‘002E’ and ‘002F’

This is used where specific parts of a texture need to be used. The following example is a 3 sided polygon taken from ‘sea.3’:

002E0000000300BF000000880032008F0000
002F0003001800120017

The ‘002E’ part gives x any z coordinates to define which part of the texture (the filename of the texture is given in the ‘header’ of the .3 file) shall be used with the vertices defined in the ‘002F’ line. Here, the coordinates are:
Vertex 18, x=bf ,z=00
Vertex 12, x=88,z=32
Vertex 17, X=8f, z=0

There is also a 4 sided version of this

7. ‘0047’ and ‘008E’

Example:
00470009000400010020002000200020003F0001003F
008E000400110010000E000D

The ‘0047’ opcode can be treated the same as the ‘002E’ opcodes except the texture used is taken from the ‘redseaXXXX.ini’ file and not that as described in the header. Immediately after the ‘0049’ is the index of the texture used, which in this case ‘0009’. Since the index system starts at 0 in the .3 file, but 1 in the ‘.ini’ file, we have to add 1 giving (in this case) the texture ‘fx_13’.

8. '0001’

This is used to draw a line.

In this example:
000100C800420041
A line is to be drawn between vertex 42 and 41 using palette colour C8. Since there is no thickness parameter, it is currently unknown how this system works at different viewing distances.

Well, that's a lot to digest and I have been trying to review your previous 'tent' posts as well. That will take some time so

I'll see if I'm on the right track.

I was curious about how the models are called with respect to time-of-day/shadows, angle-of-view, etc. The T.O.D of the .ini

files answers the first question so is it correct that the angle of view polygon texture is consistent with the directional

labels in the txtr file index (N,NE, etc.) ? If so, what is BOT?


50=txtr 4,(0,160),(31,160),(31,191),(0,191) ;N CANVAS
51=txtr 4,(32,160),(63,160),(63,191),(32,191) ;NE CANVAS
52=txtr 4,(64,160),(95,160),(95,191),(64,191) ;E CANVAS
53=txtr 4,(96,160),(127,160),(127,191),(96,191) ;SE CANVAS
54=txtr 4,(128,160),(159,160),(159,191),(128,191) ;S CANVAS
55=txtr 4,(160,160),(191,160),(191,191),(160,191) ;SW CANVAS
56=txtr 4,(192,160),(223,160),(223,191),(192,191) ;W CANVAS
57=txtr 4,(224,160),(255,160),(255,191),(224,191) ;NW CANVAS
58=txtr 10,(192,160),(223,160),(223,191),(192,191) ;BOT CANVAS
59=txtr 10,(224,160),(255,160),(255,191),(224,191) ;TOP CANVAS

009F000E0035040100D000D000CD00CD009E0001000000040009
009F000E0033040100CE00CE00CF00CF009E0000000100020003
009F000C0036030100CA00CB00C9009D000400000003
009F000C0032030100CA00C900CB009D000900020001
009F000E0036040100CA00C900C800C9009E0004000300060005
009F000E0032040100C900CA00C900C8009E0002000900080007
009F000E0038040100CC00CC00CA00CA009E0009000400050008
009F000E0034040100C800C800C600C6009E0003000200070006

The eight polygons use only SE, NE, S, N, W, and E, is that as a function of the simplicity of this particular tent3.3 model?

As to the determination of whether a polygon receives texture or not, what is the switch...ie., is it determined by the TAW 'OPTIONS' selected or are there other determinants?



Since we're on the subject of textures, I have been curious to see if I could understand the transitional textures better. You describe, very well, how the textures for the above 3 files are determined. Have you any insight as to how the transitional textures are utilized? I was hoping to see if it was possible (or advantageous) to make the transiton from the default:

[transtxtr]
A=(0,0)
B=(95,0)
C=(191,0)
D=(0,95)
E=(95,95)
F=(191,95)
G=(0,191)
H=(95,191)
I=(191,191)

To the expanded list from the extracted hardware.tm file:

[transtxtr]
A=(0,0)
B=(95,0)
C=(95,95)
D=(0,95)

E=(96,0)
F=(191,0)
G=(191,95)
H=(96,95)

I=(0,96)
J=(95,96)
K=(95,191)
L=(0,191)

M=(96,96)
N=(191,96)
O=(191,191)
P=(96,191)

All I know about shadows is contained in another thread from this post onwards:
http://simhq.com/forum/ubbthreads.php/topics/2455256/Re_New_topic_for_reopen_3_form.html#Post2455256

I don't think the comments 'N CANVAS' etc serve any practical purpose since objects can be rotated based on a parameter given in the ssd file:
http://simhq.com/forum/ubbthreads.php/topics/2124630/Re_Luxor_ssd_and_its_3_files.html#Post2124630
So, 'N CANVAS' may not always be facing north.

I think it's just 'TAW OPTIONS' since the LOD based on distance is handled in a different way.

As for the [transtxtr] stuff, I have no idea....or have forgotten. We really miss Polak for this.
The only comment I can make is that these describe 96x96 squares which are used for the terrain.

Okay, thanks for the references. I'll work on the transtxtr stuff over time and report what I find.

Your speculative theory of the elusive '0015' opcode caught my attention. previously you refered to your noticing that the extra non-visible vertices you found in the terrain tiles were somehow linked to some of the visible vertices and were described by the following lines:
0015001a0003000d000c
00080192
000801ce
0000
000801c8
00080184
0000

I have a theory but I'm not able to confirm nor deny it yet, but here it goes...

TAW extracted Noname file 3158 is the 3D file for the AGM86 Air launched cruise missile.
TAW extracted Noname file 802 is the 3D file for the Air launched Decoy.

Both files describe a functional set of wings which are only deployed/visible at specific conditons met (eg: launch) [Decision opcode?] [back-face culling?]

3158 has 12 such blocks and 802 has 9. Could these be the description of the extra vertices for the extended wings when deployed?

Eg: (noname3158)

0015001000050013000C
000800E4
00080086
0000
00080080
000800D6
0000

Let's take noname3158.3. After converting to text I ran the file through my rudimentary .3 to .ac formatting program. This was quite successful since the vertices, in this case, are described in one contigious block. All decisions are ignored, and the program converts all polygons it recognises:


So, we can see that there are two positions the wings can be in, and presumably a third stowed position where nothing is drawn.

Looking at the file, there is a likely looking decision block:
00480000
0021000000C4
002100010064
002200010004
0000

From the 0048 line, we are dealing with variable 0000. The value of this must be set elsewhere,but my theory is that it is placed in a defined place of the .3 file 'header' at runtime so the subsequent 'code' knows where to find it.

Anyway, if the value of this variable is zero, then we jump 00C4 bytes, if 1 then the jump is 0064 bytes, and anything greater than 1 gives a jump of 0004 bytes. This last case takes us to the line immediately following the decision block. Note that the jump distance includes the 2 bytes which give the distance.

If these jumps are followed to their destinations, it can be seen that they all point to 0015 lines:
0015000400090003000C
000800E4
0008000E
0000
00080008
000800D6
0000

I'm still not sure what these do, but it could be either for backface culling or z-buffering purposes....or something else, of course.
Either way, they define the order in which the polygons are sent to the screen.

I interpret the 0015 line as:
Perform 'test' on vertices 0004,0009,0003. If TRUE then GOTO next line. If FALSE then jump 000C bytes.
If the result was TRUE then we are at the line 000800E4, which I interpret as a GOSUB to the polygon block 00E4 bytes distant. When returning from this sub, the line 0008000E is executed which takes us to the line following this block,which is another 0015 line.

If the result was FALSE then, using this logic, we handle the next 0015 block before coming back to execute the 000800D6 line and this is where I gave up trying to follow the thread of execution. I still haven't got to grips with how these files.branch.
All help gratefully received.....

There are some further decisions based on distance, performed by 0027 lines, ie
0027000A0122
004E70707E7E
0081001900180010002D
...etc

or
0003007B001900180010002D
...etc

This means that if the viewing distance is less than 000A units (about 80 feet I think) then the polygon with vertices 0019,0018,0010,002D is a polygon with a colour gradient given by the 004E line. ie the polygon corner colours are 70,70,7E,7E respectively. These numbers represent the palette index.
At a distance of greater then 000A units, a uniformlly coloured polygon is used instead with colour 7B as defined in the 0003 line.