|
|
#2735378 - 06/01/09 12:35 PM
.3 Files
|
SimHQ Member
Registered: 02/26/01
Posts: 1694
Loc: UK
|
Due to overwhelming demand, I'm starting a thread to summarize the current knowledge of .3 files, and to spur a new thrust for additional insights. The idea is to break down this task into smaller chunks, producing simple tools as necessary. The .3 files are scripts which tell the game engine how to draw objects. On first glance, they are just binary data. But, after some research, it has been found that the files can be broken down into lines of 'opcodes' which describe how the vertices and polygons go together. First, we need a tool to take the binary data and reformat it into ASCII text, so it can be edited more easily, then be able to produce a binary file again for testing in the game. I've created an extremely user-unfriendly tool here: http://rapidshare.com/files/239704747/parse_3.zipYou can put any .3 files you want to process in the '3_in' directory. When you press the 'Convert to Text' button, all the files in the directory will be processed and the results placed in the '3txt_out' directory. A similar procedure is used to convert back to .3 format again.
|
Top
|
|
|
|
|
#2735600 - 06/01/09 07:37 PM
Re: .3 Files
[Re: mikew]
|
SimHQ Member
Registered: 06/27/06
Posts: 591
|
Thanks M, I will look forward to working on this when I dig out from the meltdown that once was my TAW data/test PC. I lost about three years worth of unsalvagable data and am currently reformatting the HDD by necessity. Fortunately I think most of it can be reconstructed from my backup files so please make sure your files are backed up. Thanks for your continuing work on this project 
|
|
Top
|
|
|
|
|
#2736042 - 06/02/09 11:45 AM
Re: .3 Files
[Re: DrKevDog]
|
SimHQ Member
Registered: 02/26/01
Posts: 1694
Loc: UK
|
DKD, hope you get sorted out soon. I need all the help I can get, especially since Polak is absent. Anyway, if we take one of the simplest examples of a .3 file, one of the F22 control surfaces, 'f22_30.3' and pass it through the parser in verbose mode, we get this: f22_30.3;
header;FEC03E80000000007FFF00000000000000000000
header;0002000300030000000000000087000700040005
header;00060000000000000020000000200000002000000007
0000;007B0004
0001;0000
0002;00620000000000000000
0003;00750000
0004;00490000E3C0000000000000000000000000000000000004
0005;0000
0006;00620001FEF000000140
0007;0066FFA8
0008;00650007
0009;00680228FE20
0010;0065FFF9
0011;00660050
0012;006100060001
0013;0048000A
0014;002100000016
0015;0021000100AE
0016;002100020146
0017;0021000301DE
0018;0000
0019;0047001D00030000008900B70089000E007B
0020;002F0003000500020006
0021;0047001D000300C5007B000E007B00B70089
0022;002F0003000100060002
0023;0047001D0003000E006B00B7007900000079
0024;002F0003000600030004
0025;0047001D000300B70079000E006B00C5006B
0026;002F0003000300060001
0027;004CBABAC000
0028;0080000500060004
0029;004CC0BABA00
0030;0080000300010002
0031;004EBAC0C0BA
0032;00810005000400030002
0033;0000
0034;0047004500030000008900B70089000E007B
0035;002F0003000500020006
0036;00470045000300C5007B000E007B00B70089
0037;002F0003000100060002
0038;004700450003000E006B00B7007900000079
0039;002F0003000600030004
0040;00470045000300B70079000E006B00C5006B
0041;002F0003000300060001
0042;004CBABAC000
0043;0080000500060004
0044;004CC0BABA00
0045;0080000300010002
0046;004EBAC0C0BA
0047;00810005000400030002
0048;0000
0049;0047000C00030000008900B70089000E007B
0050;002F0003000500020006
0051;0047000C000300C5007B000E007B00B70089
0052;002F0003000100060002
0053;0047000C0003000E006B00B7007900000079
0054;002F0003000600030004
0055;0047000C000300B70079000E006B00C5006B
0056;002F0003000300060001
0057;004CBABAC000
0058;0080000500060004
0059;004CC0BABA00
0060;0080000300010002
0061;004EBAC0C0BA
0062;00810005000400030002
0063;0000
0064;0047002700030000008900B70089000E007B
0065;002F0003000500020006
0066;00470027000300C5007B000E007B00B70089
0067;002F0003000100060002
0068;004700270003000E006B00B7007900000079
0069;002F0003000600030004
0070;00470027000300B70079000E006B00C5006B
0071;002F0003000300060001
0072;004CBABAC000
0073;0080000500060004
0074;004CC0BABA00
0075;0080000300010002
0076;004EBAC0C0BA
0077;00810005000400030002
0078;0000
0079;FFFF
0080;FFFF The 2nd,3rd and 4th lines can be classed as a 'header'. The header is likely the area where data specific to a particular object is placed during runtime. Other than that, not much is known. The last two bytes (0007) do give the total number of vertices used by the model.
|
|
Top
|
|
|
|
|
#2736113 - 06/02/09 01:11 PM
Re: .3 Files
[Re: mikew]
|
SimHQ Member
Registered: 02/26/01
Posts: 1694
Loc: UK
|
If we want to create some sort of viewer, the only things we need to worry about are the vertices and one of the 4 sets of polygons, ie the following lines: 00620001FEF000000140 0066FFA8 00650007 00680228FE20 0065FFF9 00660050 0047002700030000008900B70089000E007B002F0003000500020006 00470027000300C5007B000E007B00B70089002F0003000100060002 004700270003000E006B00B7007900000079002F0003000600030004 00470027000300B70079000E006B00C5006B002F0003000300060001 004CBABAC000 0080000500060004 004CC0BABA00 0080000300010002 004EBAC0C0BA 00810005000400030002 A script can then be created to transform these lines into a file that can be read by a 3d modelling program. I use AC3d because it has an ASCII text file format. You don't need to buy the program if only using it as a viewer, and it can be downloaded here: http://www.inivis.com/I've uploaded the 'f22_30.ac' example file here: http://rapidshare.com/files/240108397/f22_30.acIf all goes well, you should see something like this: 
|
|
Top
|
|
|
|
|
#2736302 - 06/02/09 07:25 PM
Re: .3 Files
[Re: mikew]
|
SimHQ Member
Registered: 06/27/06
Posts: 591
|
Any questions before we move on?  Captivating display of knowledge and insight. Most appreciated! One question on the decision blocks, are they exclusively identified by the '0048' opcode?
|
|
Top
|
|
|
|
|
#2736624 - 06/03/09 10:48 AM
Re: .3 Files
[Re: DrKevDog]
|
SimHQ Member
Registered: 02/26/01
Posts: 1694
Loc: UK
|
The '0048' opcode is used for certain types of decisions. We've seen that '0048000A' for camo selection. '00480007' is used to select different damage states in other .3 files. I don't know whether this is a general rule. I guess I should find out. In some .3 files, the '0027' opcode is used to make decisions based on distance. Also '0043' is used for time of day. Even more speculative is the theory for the '0015' opcode. This looks like it's making a decision on whether a polygon's 'normal' is positive or negative for backface culling purposes ( http://en.wikipedia.org/wiki/Back_face_culling ) . Again, I don't know whether this is relevant in anything other than software mode since DirectX is supposed to handle that. After looking at these files for a while, it wouldn't surprise me if this .3 file system has evolved over many years...even going back to the Amiga days.
|
|
Top
|
|
|
|
|
#2736895 - 06/03/09 09:03 PM
Re: .3 Files
[Re: mikew]
|
SimHQ Member
Registered: 06/27/06
Posts: 591
|
Even more speculative is the theory for the '0015' opcode. This looks like it's making a decision on whether a polygon's 'normal' is positive or negative for backface culling purposes . Again, I don't know whether this is relevant in anything other than software mode since DirectX is supposed to handle that.
After looking at these files for a while, it wouldn't surprise me if this .3 file system has evolved over many years...even going back to the Amiga days.
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?
|
|
Top
|
|
|
|
|
#2737296 - 06/04/09 01:37 PM
Re: .3 Files
[Re: DrKevDog]
|
SimHQ Member
Registered: 02/26/01
Posts: 1694
Loc: UK
|
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): 0002 0010000000090001 The value in red gives the palette position which should be blue.
|
|
Top
|
|
|
|
|
#2746240 - 06/19/09 08:46 AM
Re: .3 Files
[Re: mikew]
|
SimHQ Member
Registered: 02/26/01
Posts: 1694
Loc: UK
|
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.
|
|
Top
|
|
|
|
|
#2747965 - 06/22/09 07:50 PM
Re: .3 Files
[Re: mikew]
|
SimHQ Member
Registered: 06/27/06
Posts: 591
|
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... 
|
|
Top
|
|
|
|
|
#2749127 - 06/24/09 02:21 PM
Re: .3 Files
[Re: DrKevDog]
|
SimHQ Member
Registered: 02/26/01
Posts: 1694
Loc: UK
|
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 3folder 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.
|
|
Top
|
|
|
|
|
#2751292 - 06/26/09 07:34 PM
Re: .3 Files
[Re: mikew]
|
SimHQ Member
Registered: 06/27/06
Posts: 591
|
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)
|
|
Top
|
|
|
|
|
#2752344 - 06/28/09 06:29 AM
Re: .3 Files
[Re: DrKevDog]
|
SimHQ Member
Registered: 02/26/01
Posts: 1694
Loc: UK
|
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.
|
|
Top
|
|
|
|
|
#2753561 - 06/29/09 10:16 AM
Re: .3 Files
[Re: mikew]
|
SimHQ Member
Registered: 06/27/06
Posts: 591
|
...We really miss Polak for this...
I agree 100%. I did receive an Netlog related email from him recently but it was difficult to understand and I'm not sure what his TAW return time is. Perhaps if he can see just how much amazing progress you've made since he left, he'll re-engage. My current job responsibilities and time constraints won't allow me to devote much for the next couple weeks  but I'll keep plugging away.
|
|
Top
|
|
|
|
|
#2763796 - 07/05/09 05:51 AM
Re: .3 Files
[Re: mikew]
|
SimHQ Member
Registered: 02/26/01
Posts: 1694
Loc: UK
|
Continuing the theme of gradual progress, I've produced a tool '3text_to_ac' which takes the text output file of 'parse_3' attempts to produce a model file in AC3D format based on the current understanding of how the .3 file is constructed. Here's the link: http://rapidshare.com/files/252196488/3_to_ac.zipUnzip the file to a new directory, then place any *.3.txt files created with 'parse_3' (Don't use verbose mode) into the '3text_in' folder. Then double click on the exe. It will try and convert any file it finds. The output .ac files will be found in the 'ac_out' folder. Unfortunately, this folder also contains the texture files, but sorting files by type in Win Explorer will bring these files to the top. Note, that this program will convert any vertex and polygon info that it understands and pays no attention to LODs, damage etc. So, everything is superimposed, like this A50 example.  There is an interim tool required between 'parse_3' and '3text_to_ac' which sorts through the way the .3 file branches, so that only the relevant parts of the .3 file are converted. I'm looking into this now.
|
|
Top
|
|
|
|
|
#2764678 - 07/06/09 05:09 PM
Re: .3 Files
[Re: mikew]
|
SimHQ Member
Registered: 06/27/06
Posts: 591
|
Mikew, Thanks for the program  Just an FYI, I thought I would tinker with the affect of altering object colors in TAW so I took the Decoy file (fzdecoy.3) and converted the decoys rear gray Polygons to red for better visual tracking. So I modified: 0258;000200 B40001001E001F to 0258;000200 090001001E001F That worked beautifully, during the daytime T.O.D.'s and especially well at night as the bright red polygons are easily visible. The problem occurs when NVE (Night Vision Equipment) is toggled "ON". At that point the polygons are rendered transparent. I'm assuming that is a function of the Palette transition with red to transparent at position 180 (09h). Your thoughts?
|
|
Top
|
|
|
|
|
#2764747 - 07/06/09 07:15 PM
Re: .3 Files
[Re: DrKevDog]
|
F22 Air Dominance Project
SimHQ Member
Registered: 01/01/01
Posts: 714
Loc: Greater Washington DC Area
|
DKD,
If you look at the rest of the natural light palettes, you will notice the same library of bright colors in the first row and a half. These are used for HUD/MFD colors, nav lights, runway/taxiway lights, and basically any color that involves artificial illumination. As you well know, position 9 is a bright red.
Compare these palettes with the NVG palette, and all of a sudden you no longer have the same colors, but a slew of blacks and greens. Position 9 in the NVG palette is a fairly neutral green, and may not show up when seen surrounded by other greens on the 3 object.
FWIW, there is no "transparent" color, except for what is defined by what color at what time/position (you can see the chroma keying scheme on many of the texture files). That said, the 0,0,0 black is often used as a transparency.
This may not be exactly what you're looking for, but it's my $.02 anyway.
_________________________
-Home Fries The average Naval Aviator, despite the sometimes swaggering exterior, is very much capable of such feelings as love, affection, intimacy, and caring. These feelings just don't involve anyone else. F-22 Air Dominance Project
|
|
Top
|
|
|
|
|
#2814282 - 07/09/09 12:25 PM
Re: .3 Files
[Re: DrKevDog]
|
F22 Air Dominance Project
SimHQ Member
Registered: 01/01/01
Posts: 714
Loc: Greater Washington DC Area
|
DKD, Interestingly enough, Eagle Flight found this during beta testing of some new skins. The screenshots were done in Direct3D in 1024x768. The skin is a photorealistic version of hte YF-22 paint scheme.  There's not even illumination of a neutral green color. You may be on to something here.
_________________________
-Home Fries The average Naval Aviator, despite the sometimes swaggering exterior, is very much capable of such feelings as love, affection, intimacy, and caring. These feelings just don't involve anyone else. F-22 Air Dominance Project
|
|
Top
|
|
|
|
|
#2817216 - 07/13/09 01:04 PM
Re: .3 Files
[Re: mikew]
|
SimHQ Member
Registered: 06/27/06
Posts: 591
|
Mikew, Going back and reviewing the previous information on the board regarding the default newhoriz.3 vs the extracted version with its additional blocks at the end of the file. In AC3D they look identical, however, looking at the code reveals the differences. The files diverge at line 0491 where the new file has: 0491; 00A300900492;000300800013000000030012 0493;00720012000300040011 0494;00720011000400070014 0495;007200000009000F0003 0496;00720003000F00100004 0497;00720004001000080007 0498;0072000900160017000F 0499;0072000F001700180010... The 00A3 opcode appears to be an operator associated with a jump. If you jump 0090h you are at the start of the additional lines not found in the default newhoriz.3 file. In a previous thread discussing the 3 files you mentioned that: "Regarding the Header, it sounds like good progress has been made by breaking them down into 5 categories. It would be interesting to know whether all pure terrain files have the 00A3 'tag' with no exceptions." I believe you are correct that the 00A3 opcode, which is found in the Header of many terrain files, is related to a fairly global TAW process and am curious if this opcode could be used for certain types of decisions such as AGP vs Standard texture mapping, for example. If you recall my earlier discussions regarding the global textures and the implementation of the new AGP "SKY" .RAW files, http://simhq.com/forum/ubbthreads.php/topics/2605948/2.htmlI proposed that the additional lines in the new file would accomodate the implementation of the AGP set. To follow this logic further and if my use of your extremely insightful guide to the interpretation of the .3 files is accurate, I could start with the lines: 0508;0047014200040000000001FF000001FF000100000001 0509;002F00040012001300000003 0047 This is the opcode for a textured polygon 0142 Index number of texture from the file 'redXXXX.ini' in the 3 folder (322d). 322 is not in the TAW default .ini file series but is added manually with the following AGP .raw file related lines: 322=sky0800 323=sky1000 324=sky1200 325=sky1400 326=sky1600 327=sky1800 328=sky2000 329=sky2200 310=sky0000 311=skynvg 0004 Special 4 sided Polygon? 0000 0000 Texture coordinates of vertex 12 01FF 0000 Texture coordinate of vertex 13 01FF 0001 Texture coordinate of vertex 0 0000 0001 Texture coordinate of vertex 3 etc..? This maps the raw textures onto the newhoriz.3 grid when AGP is active using the 00A3 operator. (?)
|
|
Top
|
|
|
|
|
#2817229 - 07/13/09 01:22 PM
Re: .3 Files
[Re: HomeFries]
|
SimHQ Member
Registered: 06/27/06
Posts: 591
|
There's not even illumination of a neutral green color. You may be on to something here. I agree, it's a very curious finding, perhaps we can explore it further?
|
|
Top
|
|
|
|
|
#2818138 - 07/14/09 01:58 PM
Re: .3 Files
[Re: DrKevDog]
|
SimHQ Member
Registered: 02/26/01
Posts: 1694
Loc: UK
|
Seeing that all of the 0047 opcodes in the file give only the 0142 (322h=sky0800) textures, there must be a mechanism to advance with T.O.D. to the appropriate texture index position. (?) Doesn't seem to be, but you could just put the appropriate 'skyXXXX.raw' file in slot 322 for each of the corresponding 'redXXXX.ini' files. I had a look at some of those 384kb files and they definitely look like sky, when opened as 24 bit colour with size 512x256. If zoomed in, the colour gradient isn't smooth, which is maybe why it looks course in the game.  DKD, you've made a great find here.
|
|
Top
|
|
|
|
|
#2818414 - 07/14/09 04:21 PM
Re: .3 Files
[Re: mikew]
|
SimHQ Member
Registered: 06/27/06
Posts: 591
|
Seeing that all of the 0047 opcodes in the file give only the 0142 (322h=sky0800) textures, there must be a mechanism to advance with T.O.D. to the appropriate texture index position. (?) Doesn't seem to be, but you could just put the appropriate 'skyXXXX.raw' file in slot 322 for each of the corresponding 'redXXXX.ini' files. I had a look at some of those 384kb files and they definitely look like sky, when opened as 24 bit colour with size 512x256. If zoomed in, the colour gradient isn't smooth, which is maybe why it looks course in the game. Mikew, I am grateful for the knowledge you share regarding this project, it makes this TAW puzzle more fun to discover  I don't believe I have the SKY.raw files exactly matched up with their correct T.O.D. in the AGP folder so some of the sky textures don't match the horizon band of color... that said, I do get different sky textures based on the T.O.D. so I am wondering, since there is only one newhoriz.3 file with only 322 position references, if there is an algorithm (somewhere in the process) that selects for the correct redXXXX.ini index position? I tried substituting the SKY1000.raw for SKY0800.raw at the 322 position I get: "fadetab: invalid fade table 12". Apparently the fade tables must be compatible with the Sky texture used or TAW crashes. IIRC the fade tables are related to the sky as visualized in the AWACS 3D window. I did find a number of unused "noname" fade tables in the Multiex extracted files. Thanks for posting the pics of the raw files, for some reason my photoshop and irfanview pics were less well defined. I did some comparison last night with the AGP-sky at 2200 vs the non-AGP-sky on my PCI/Glide PC and the textured sky at night is far superior
|
|
Top
|
|
|
|
|
#2818810 - 07/15/09 06:04 AM
Re: .3 Files
[Re: mikew]
|
SimHQ Member
Registered: 06/27/06
Posts: 591
|
Doesn't seem to be, but you could just put the appropriate 'skyXXXX.raw' file in slot 322 for each of the corresponding 'redXXXX.ini' files.
I am not sure I communicated my point on the T.O.D. issue very well, so I'll try expanding it. The information that motivated me to consider the utilization of .ini positions 322-329 was obtained from a noname .ini type file that begins with: [dir] TM=hardware.tm tha section of current interest is listed: 322=sky0800 323=sky1000 324=sky1200 325=sky1400 326=sky1600 327=sky1800 328=sky2000 329=sky2200 310=sky0000 311=skynvg What you say regarding the lone 322 position seems logical, and I'll plan to do some further testing this evening, however, I am interested in finding out if the above .ini file is a clue to how the AGP-SKY textures are used in general or if their is seperate special TAW application which utilizes only the above .ini file 
|
|
Top
|
|
|
|
|
#2818838 - 07/15/09 06:48 AM
Re: .3 Files
[Re: DrKevDog]
|
SimHQ Member
Registered: 02/26/01
Posts: 1694
Loc: UK
|
I'm sure it was me that misunderstood, but I can't see a mechanism to change TOD in the newhoriz.3 file...even the one you found. There may be a way around this though. For the building .3 files, there is a decision point based on TOD which is used to draw the shadows. It may be possible to use the same process to select different skyXXXX.raw files. I really need to get the textured sky working on my machine, as I am still not sure what is going on here. Is it really possible to use textures of 512x256 and colours which are not from a palette???? Sounds too good to be true.
|
|
Top
|
|
|
|
|
#2818934 - 07/15/09 08:44 AM
Re: .3 Files
[Re: mikew]
|
F22 Air Dominance Project
SimHQ Member
Registered: 01/01/01
Posts: 714
Loc: Greater Washington DC Area
|
Gents, This might be something huge. Being that hexidecimal is not my strength (too long looking at it and my head explodes), I apologize if I ask questions that may have already been answered. 1) Are you saying that the skyxxxx gradients are actually being used in extracted TAW (D3D renderer), or that files are called which are still unnamed (which explains the coarse gradient)? 2) If the gradients are in use in D3D, I understand that they must be matched to the palette. Does this mean they also must be matched to the time of day? (a way to find out might be to swap the names of two palettes, then swap the names of sky files or swap addressses of sky files in the noname.ini)? Just thinking out loud, this discovery might be the key to fix my NVG mod in D3D by swapping the rednvg and redmoon/rednomo palettes without having to deal with the green gradient that isn't swapped. See this thread for further details. Thanks,
_________________________
-Home Fries The average Naval Aviator, despite the sometimes swaggering exterior, is very much capable of such feelings as love, affection, intimacy, and caring. These feelings just don't involve anyone else. F-22 Air Dominance Project
|
|
Top
|
|
|
|
|
#2819166 - 07/15/09 01:49 PM
Re: .3 Files
[Re: HomeFries]
|
SimHQ Member
Registered: 02/26/01
Posts: 1694
Loc: UK
|
HF, I'm having problems understanding what's going on as well. I thought I'd take it step by step and just swap the original newhoriz.3 file with the one DKD found. I was expecting a crash but instead, the game ran as normal. The particular PC I tried this on has a hardware problem in that even though an AGP graphics card is fitted, the AGP capability is not recognised by the video driver or DirectX. So, this may prove that the 00A3 opcode is related to AGP since then the newhoriz.3 'code' will select the coloured polygons instead. DKD, is this a correct assumption?
|
|
Top
|
|
|
|
|
#2819281 - 07/15/09 04:33 PM
Re: .3 Files
[Re: mikew]
|
F22 Air Dominance Project
SimHQ Member
Registered: 01/01/01
Posts: 714
Loc: Greater Washington DC Area
|
Mike,
Feel free to send me any files. I can test them on an agp platform.
_________________________
-Home Fries The average Naval Aviator, despite the sometimes swaggering exterior, is very much capable of such feelings as love, affection, intimacy, and caring. These feelings just don't involve anyone else. F-22 Air Dominance Project
|
|
Top
|
|
|
|
|
#2819302 - 07/15/09 05:17 PM
Re: .3 Files
[Re: mikew]
|
SimHQ Member
Registered: 06/27/06
Posts: 591
|
HF, I'm having problems understanding what's going on as well. I thought I'd take it step by step and just swap the original newhoriz.3 file with the one DKD found. I was expecting a crash but instead, the game ran as normal. The particular PC I tried this on has a hardware problem in that even though an AGP graphics card is fitted, the AGP capability is not recognised by the video driver or DirectX. So, this may prove that the 00A3 opcode is related to AGP since then the newhoriz.3 'code' will select the coloured polygons instead. DKD, is this a correct assumption? Yes, that is the working hypothesis. I believe opcode 00A3 is related to AGP. Over the years I have modified many aspects of my TAW files and so there are many potential confounding variables in this equation, that said, I am now in the process of reinstalling and rebuilding TAW from it's default configuration and adding the extracted components, progressively and incrementally until the AGP Sky appears. Hopefully I can get a read on how this is implemented. I should be back with some results momentarily.
|
|
Top
|
|
|
|
|
#2819352 - 07/15/09 06:47 PM
Re: .3 Files
[Re: DrKevDog]
|
SimHQ Member
Registered: 06/27/06
Posts: 591
|
I believe the series of tests confirm my hypothesis and the results are reproducable. I started with a new TAW install, converted it to a virgin extracted files program and added components until I arrived at the point of viewing a non-palette derived textured sky. The necessary components are: 1. AGP Graphics card/ Extracted TAW running in hardware mode 2. Collection of 384kb SKYXXXX.raw textures placed in the AGP directory 3. The extracted noname newhoriz.3 with expanded AGP code 4. modified redXXXX.ini files to include: 322=sky0800 323=sky1000 324=sky1200 325=sky1400 326=sky1600 327=sky1800 328=sky2000 329=sky2200 ;310=sky0000 ;311=skynvg One of the curious observances on this trial was the fact that placing only the "322=SKYXXXX" line, as opposed to the entire block, in the redXXXX.ini file resulted in the entire sky (minus the lower horizon band) being black
|
|
Top
|
|
|
|
|
#2819387 - 07/15/09 07:43 PM
Re: .3 Files
[Re: DrKevDog]
|
F22 Air Dominance Project
SimHQ Member
Registered: 01/01/01
Posts: 714
Loc: Greater Washington DC Area
|
DKD,
Is there any reason skynvg is remmed out?
_________________________
-Home Fries The average Naval Aviator, despite the sometimes swaggering exterior, is very much capable of such feelings as love, affection, intimacy, and caring. These feelings just don't involve anyone else. F-22 Air Dominance Project
|
|
Top
|
|
|
|
|
#2819411 - 07/15/09 08:27 PM
Re: .3 Files
[Re: HomeFries]
|
SimHQ Member
Registered: 06/27/06
Posts: 591
|
DKD,
Is there any reason skynvg is remmed out? HF, The reason is we have yet to find that file or the Sky0000.raw file. What I do know about them is they are not 384kb files like the other Sky .raws. Since you are on the NVG subject, there is a NVG file in TAW that is analogous to the newhoriz.3 file for the standard sky projection. It is 'nvg_hori.3' and there are more than one, one of which was a noname file and not used in the game. A quick look at the code structure seems to suggest some polygon and color differences which may be of some benefit in your search for a NVG solution. The file is TAW noname11364.
|
|
Top
|
|
|
|
|
#2819747 - 07/16/09 07:43 AM
Re: .3 Files
[Re: HomeFries]
|
SimHQ Member
Registered: 06/27/06
Posts: 591
|
2) If the gradients are in use in D3D, I understand that they must be matched to the palette. Does this mean they also must be matched to the time of day? (a way to find out might be to swap the names of two palettes, then swap the names of sky files or swap addressses of sky files in the noname.ini)?
Interestingly enough, the textured sky is not at all effected by the color palettes. The color palettes do greatly effect the sky color of the standard polygon colored sky but have but appear to not be associated with the .raw files rendering. The time of day match is a little tricky. If you look at mikews post of the 384kb files, you'll see that the T.O.D. name designation could be guessed at, which is what I have done  until a more accurate method is found. I am curious to know what methods (eg: layering, etc.) could be used to effect the textured sky appearance.
|
|
Top
|
|
|
|
|
#2819777 - 07/16/09 08:18 AM
Re: .3 Files
[Re: DrKevDog]
|
F22 Air Dominance Project
SimHQ Member
Registered: 01/01/01
Posts: 714
Loc: Greater Washington DC Area
|
DKD,
Here's the genesis of my questions:
1) You might be aware that the gist of the NVG mod is to swap the nvgpal.col and the moonpal/nomopal.col files so that a night mission starts with NVGs on by default (in essence, tricking TAW). This allows for the NVG palette when using LANTIRN at night, which enables a tool that is otherwise useless (especially in the nomo palette).
2) Problem is with D3D mode. When selecting the "natural light" palette (which TAW thinks is actually enabling NVGs), a boatload of green hues are present in a number of cases. These cases include the horizon gradient, the HUD, the lighting (afterburners and nosewheel lighting as examples), the canopy arrows, and various 3D objects in the game (such as hangars).
What I would really like to see is if swapping sky2200 with skynvg (or just all black since skynvg is unlocated) will help alleviate this issue. I'm not as concerned with dropping skynvg into moonpal/nomopal (in the mod NVGs look fine without a nighttime gradient) as I am about dropping sky2200 into the skynvg position.
If you can send me the files, I'll be happy to test it myself.
Thanks.
_________________________
-Home Fries The average Naval Aviator, despite the sometimes swaggering exterior, is very much capable of such feelings as love, affection, intimacy, and caring. These feelings just don't involve anyone else. F-22 Air Dominance Project
|
|
Top
|
|
|
|
|
#2819984 - 07/16/09 12:39 PM
Re: .3 Files
[Re: HomeFries]
|
SimHQ Member
Registered: 02/26/01
Posts: 1694
Loc: UK
|
It does appear that the 00A3 opcode is a decision point for AGP, but exactly how it obtains that determination is unclear to me at this time. I would really like to get these textures running on one of your PC's, so what do I need to send to you? . Mikew, on your PC with the AGP card, do you get colored missile trails, etc. in TAW? Do you have an AGP folder/files? HF, do you have an AGP folder with .raw files? The AGP capability is read from Windows, so a flag will be be set when the game starts. The only reason I have an AGP folder is that it was part of a certain package. This explains why some people who ran Krus's original extractor in 2006 got an AGP folder and some didn't. If the PC wasn't deemed AGP capable, then those files weren't used. I have a couple more computers that I can try it on, but it won't be today.
|
|
Top
|
|
|
|
|
#2820182 - 07/16/09 04:41 PM
Re: .3 Files
[Re: HomeFries]
|
SimHQ Member
Registered: 06/27/06
Posts: 591
|
What I would really like to see is if swapping sky2200 with skynvg (or just all black since skynvg is unlocated) will help alleviate this issue. I'm not as concerned with dropping skynvg into moonpal/nomopal (in the mod NVGs look fine without a nighttime gradient) as I am about dropping sky2200 into the skynvg position.
If you can send me the files, I'll be happy to test it myself.
I'll send you the files and you can go from there. Just an FYI about your swapping files, the .raw files and the .col files are not interchangable. There is a flag for file size which generates an error message regarding the issue of the 'file size does not match expectated size'.
|
|
Top
|
|
|
|
|
#2820201 - 07/16/09 05:14 PM
Re: .3 Files
[Re: DrKevDog]
|
F22 Air Dominance Project
SimHQ Member
Registered: 01/01/01
Posts: 714
Loc: Greater Washington DC Area
|
Understood. just intend to pair the raw with the col files.
_________________________
-Home Fries The average Naval Aviator, despite the sometimes swaggering exterior, is very much capable of such feelings as love, affection, intimacy, and caring. These feelings just don't involve anyone else. F-22 Air Dominance Project
|
|
Top
|
|
|
|
|
#2821105 - 07/17/09 05:42 PM
Re: .3 Files
[Re: HomeFries]
|
F22 Air Dominance Project
SimHQ Member
Registered: 01/01/01
Posts: 714
Loc: Greater Washington DC Area
|
Well, I had no luck with my experiment.
I copied sky2200.raw to skynvg.raw, then unremmed the skynvg line in redmoon and rednomo.ini. Got the infamous "unexpected file size" error. Strange, considering all the other gradient raw files are 384k.
Now I'm interested to see how big the noname1317 file is.
_________________________
-Home Fries The average Naval Aviator, despite the sometimes swaggering exterior, is very much capable of such feelings as love, affection, intimacy, and caring. These feelings just don't involve anyone else. F-22 Air Dominance Project
|
|
Top
|
|
|
|
|
#2821390 - 07/18/09 07:39 AM
Re: .3 Files
[Re: DrKevDog]
|
F22 Air Dominance Project
SimHQ Member
Registered: 01/01/01
Posts: 714
Loc: Greater Washington DC Area
|
no prob.
_________________________
-Home Fries The average Naval Aviator, despite the sometimes swaggering exterior, is very much capable of such feelings as love, affection, intimacy, and caring. These feelings just don't involve anyone else. F-22 Air Dominance Project
|
|
Top
|
|
|
|
|
#2822317 - 07/19/09 03:20 PM
Re: .3 Files
[Re: mikew]
|
SimHQ Member
Registered: 06/27/06
Posts: 591
|
The AGP capability is read from Windows, so a flag will be be set when the game starts.
Just a quick note on the 00 A3 Opcode. If you look at the file dust.3 you will find the following: header;FFFC3E80000000007FFF00000000000000000000 header;0002000300030000000000000083000700040005 header;000600000000000000200000002000000020000000040030001E 0000;007B0004 0001;0000 0002;00080008 0003;0008056A 0004;0000 0005; 00A30D160006;002700320334 0007;00480000 >>>>> 0238;0000 0239;0001000200030000 0240; 00A303380241;004B00030004 0242;0000 Could this be a jump to the second 00 A3 opcode? I also noticed that the Header for dust.3 is different on the AGP PC than on the PCI/Glide PC: header;FFFC 05DC000000007FFF00000000000000000000 header;0002000300030000000000000083000700040005 header;000600000000000000200000002000000020000000040030001E ie, 8000 vs 16000, maximum visible distance? D3D half that in 3DFx/Glide ? There are some interesting findings in this file. 0372;00A700A200910075 0373;0047 0101000400000000008000000080008000000080 0374;008800040000000100020003 0375; 00A80376;0000 Considering the opcodes 00 A3, 00 A7 and 00 A8, it appears as if their is a seperate set of Opcodes for specific AGP file system. I modified the dust.3 files code related to the 00 A7 opcodes: 00A700A200910075 Simply changing the color determinant from 00A2 to 0103 changed the texture color for dust.raw from gold/brown to bright green. In TAW the dust plumes from ground vehicles are now visible as green dust, this is the same code in the .3 files responsible for the colored missile trails, explosions, etc.. I ported the modified dust.3 file to my 3DFx-Glide/PCI PC and the AGP opcodes are not recognized, the dust plumes appear as white 3d objects complete with ground shadows which are not present with the AGP/.raw textures system implementation. It is not yet clear what the 008A opcode does however it could be the AGP system equivalent of 00 00 used to terminate the AGP related blocks of code. The AGP flag determines which block is utilized? 00470101... calls 257h + 1; 258=dust (.raw)
Edited by DrKevDog (08/01/09 10:00 AM)
Edit Reason: calculation error
|
|
Top
|
|
|
|
|
#2822556 - 07/20/09 01:17 AM
Re: .3 Files
[Re: DrKevDog]
|
SimHQ Member
Registered: 02/26/01
Posts: 1694
Loc: UK
|
If you look at the file dust.3 you will find the following: Typical! you pick one of the most complicated files. The dust and smoke files were some of the hardest to make sense of when trying to find out how to split them up into opcode lines, and they haven't necessarily been converted correctly. Line 0239 is a bit suspicious: 0239;0001000200030000 This is the opcode for drawing a line, but seems out of place here, particularly with its following parameters. So, the chances are I've misinterpreted something a few lines earlier. I'll try and look at this later and update the Parse_3 program if necessary. I also noticed that the Header for dust.3 is different on the AGP PC than on the PCI/Glide PC: Did you run run Krus's extractor on both machines? This is worrying if different 3 files are produced on different machines. The AGP flag determines which block is utilized? Seems to be for 00A3. If you go into TAW options, there are buttons for a whole bunch of things like building textures, aircraft shadows etc. It would seem logical that there are opcode combinations to handle these settings. 00470101... calls 257h + 1; 258=dust (.raw) At least that stacks up. The colour stuff is interesting, but 0102 is not a palette colour since the size of the palette is only 00FF bytes. It may wrap round to 0002 though. Maybe those lines could be interpreted instead as: 00A7 00A200910075 . . 00A8 Anyway, a thought provoking post, DKD.
|
|
Top
|
|
|
|
|
#2822557 - 07/20/09 01:33 AM
Re: .3 Files
[Re: DrKevDog]
|
SimHQ Member
Registered: 02/26/01
Posts: 1694
Loc: UK
|
I also noticed that the Header for dust.3 is different on the AGP PC than on the PCI/Glide PC Now, this is really bugging me. I think we need to find a copy of Krus's first version of the extractor, ie the one where you had to play the game, in order to ensure (or otherwise) that the .3 files output are the same if different graphics options are selected in 'TAW Options'.
|
|
Top
|
|
|
|
|
#2822851 - 07/20/09 09:30 AM
Re: .3 Files
[Re: mikew]
|
SimHQ Member
Registered: 06/27/06
Posts: 591
|
Typical! you pick one of the most complicated files. That's what friends are for sue me  Did you run run Krus's extractor on both machines? This is worrying if different 3 files are produced on different machines. It's been a couple years since I did the most recent extractions and I had to reconstruct my entire Glide/PCI system after a recent meltdown. IIRC the program files on the Glide/PCI PC were ported over from the same extraction used on the D3D/AGP PC, but I'll have to confirm that.
|
|
Top
|
|
|
|
|
#2823139 - 07/20/09 04:24 PM
Re: .3 Files
[Re: mikew]
|
SimHQ Member
Registered: 06/27/06
Posts: 591
|
The colour stuff is interesting, but 0102 is not a palette colour since the size of the palette is only 00FF bytes. It may wrap round to 0002 though.
Maybe those lines could be interpreted instead as:
00A7
00A200910075
.
.
00A8
I have identified basic colors, green and what I would consider 2 shades of red, could the .raw textures palette be limited to 4bit color?
|
|
Top
|
|
|
|
|
#2824620 - 07/22/09 11:44 AM
Re: .3 Files
[Re: DrKevDog]
|
SimHQ Member
Registered: 02/26/01
Posts: 1694
Loc: UK
|
If we take the 00A7 line eg: 00A700FB009700FF and then treat the 3 numbers after the 00A7 as RGB colours, so R=00FB, G=0097 and B=00FF, then repeat for all 17 of the examples above......we get this:  Apart from the 4th to last, the colours come out pretty much as DKD describes. ....and you can also see that I can't count.
|
|
Top
|
|
|
|
|
#2825000 - 07/22/09 11:35 PM
Re: .3 Files
[Re: DrKevDog]
|
SimHQ Member
Registered: 02/26/01
Posts: 1694
Loc: UK
|
Okay, very good. So, if I contrast this with the sea.3 files process of color acquisition, is it correct to say the sea.3 calls the Tex4.tm texture map which contains an index to the first 16 positions in the palette (.col) file which determine the color of the .TM texture by using the TAW 6 bit RGB hex codes contained within the .col palette file? Basically correct, except that it's the 16 positions of the palette starting at position 129. In contrast, the dust.3 file, on an AGP activated PC, will determine the color of its (dust).RAW texture using the TAW 6 bit RGB hex codes directly from the .3 file itself? I haven't had time to go into the dust file in any detail, but those 00A7 lines seem to give a direct reference to full 8 bit colour, although stored as 16 bit numbers. Note also that the skyXXXX.raw files seem to contain 8 bit colour information directly, rather than refer to a palette. These are some great findings that you are coming up with. Just wish I had more time to help.
|
|
Top
|
|
|
|
|
#2826569 - 07/25/09 07:17 AM
Re: .3 Files
[Re: mikew]
|
SimHQ Member
Registered: 06/27/06
Posts: 591
|
Mikew, Thanks for clearing up those misconceptions for me,...me having misconceptions...that has never ever happened before Well, I can certainly say I am enjoying these new findings and I have a few ideas about how we will parlay these little niblets into a "LOMAC-ON-STEROIDS" look for TAW  The fact that the sky raws are handled differently than the palette colored sky has got me thinking... perhaps this is a portal of opprtunity that could pay some weather dividends. One of my initial thoughts was the possible use of the NVDOT.raw and/or NVNOISE.raw, which create light dot "artifacts" in the NVG environment, features to create a rain-like effect in the environment. So far I'm starting to be convinced that the NVDOT and NVNOISE files use is hardcoded in the game, so I'll continue investigating this
|
|
Top
|
|
|
|
|
#2826749 - 07/25/09 12:57 PM
Re: .3 Files
[Re: DrKevDog]
|
F22 Air Dominance Project
SimHQ Member
Registered: 01/01/01
Posts: 714
Loc: Greater Washington DC Area
|
DKD,
A little off topic from 3 files, but since you're discussing weather, I discovered the following the other night.
In the different time of day text files (\lev\redxxxx.txt), the section that calls the palettes also assigns an altitude range to the palettes. This allows for separate palettes for different altitude bands. Any overlap in altitude bands results in transitional merging of the palettes. I haven't played around with this much in D3D, but done correctly it looks amazing in Glide.
For proof of concept, we could use the greyscale palette in TAW for low altitudes (say up to 5000), followed by the palettes for that time of day (perhaps starting at 1500 up to whatever) to create the impression of a fog/cloud layer that you finally burn through at 5000ft. Only problem is that you would be able to see the ground plain as day above 5k, but that's a topic for another pursuit.
Just throwing my $.02 into the mix.
_________________________
-Home Fries The average Naval Aviator, despite the sometimes swaggering exterior, is very much capable of such feelings as love, affection, intimacy, and caring. These feelings just don't involve anyone else. F-22 Air Dominance Project
|
|
Top
|
|
|
|
|
#2826778 - 07/25/09 02:13 PM
Re: .3 Files
[Re: HomeFries]
|
SimHQ Member
Registered: 02/26/01
Posts: 1694
Loc: UK
|
Just throwing my $.02 into the mix. ...Interesting idea. Just going back to dust.3 for a moment, and these lines: 0372;00A700A200910075 0373;00470101000400000000008000000080008000000080 0374;008800040000000100020003 0375;00A8 There are only 4 vertices in the dust.3 file, so the dust effect must always be somehow billboarded towards the viewer. Line 0372 gives the dust colour. Line 0373 calls the 128x128 'texture' dust.raw which, since line 0374 starts with 0088, is used as a transparency mask. 
|
|
Top
|
|
|
|
|
#2826822 - 07/25/09 03:43 PM
Re: .3 Files
[Re: HomeFries]
|
SimHQ Member
Registered: 06/27/06
Posts: 591
|
to create the impression of a fog/cloud layer that you finally burn through at 5000ft. Only problem is that you would be able to see the ground plain as day above 5k, but that's a topic for another pursuit.
HF, I think it would be worth a look see, if you have the time. IIRC I worked on a similar approach before (Glide) and I couldn't get the altitude transitions to work smoothly enough (read: convincingly enough) with the Palettes I had at the time (and I was also concurrently using the East-West Palette system). I remember Polak had some success with creating or modifying palettes so perhaps that is the way to go.
|
|
Top
|
|
|
|
|
#2826837 - 07/25/09 04:15 PM
Re: .3 Files
[Re: DrKevDog]
|
F22 Air Dominance Project
SimHQ Member
Registered: 01/01/01
Posts: 714
Loc: Greater Washington DC Area
|
DKD,
Apologies for my ignorance, but what is the East-West palette system? I am not familiar with that nomenclature.
So far as modifying palettes, I have some (albeit limited) experience with this. However, I have taken existing palettes (such as my "new" NVG palette) and adjusted the color/brightness on a consistent basis among rows to make the transition look normal. I will post a video of the transition with NVGs shortly (i.e. once I make it).
Like I said previously, the downside of manufacturing cloud cover like this is that you will be able to see the ground as normal once you clear the grey. However, it should be doable if you make a hybrid palette (i.e. mix greyscale ground textures with normal sky textures as a medium layer), then have the hybrid palette go to a solid grey or more lower contrast grey palette for higher altitudes.
Not as easy as it sounds, but very doable.
Edit: well, maybe it could be easier. Are there utilities that can make global changes (i.e. to luminosity or color) to indexed palettes, and is there a utility that can convert an indexed palette in a graphics file to a .col file? If so, this would really open things up (and not just for weather mods).
Edited by HomeFries (07/25/09 04:20 PM)
Edit Reason: Maybe there is an easier way
_________________________
-Home Fries The average Naval Aviator, despite the sometimes swaggering exterior, is very much capable of such feelings as love, affection, intimacy, and caring. These feelings just don't involve anyone else. F-22 Air Dominance Project
|
|
Top
|
|
|
|
|
#2826845 - 07/25/09 04:30 PM
Re: .3 Files
[Re: mikew]
|
SimHQ Member
Registered: 06/27/06
Posts: 591
|
Just going back to dust.3 for a moment, and these lines:
0372;00A700A200910075
0373;00470101000400000000008000000080008000000080
0374;008800040000000100020003
0375;00A8
There are only 4 vertices in the dust.3 file, so the dust effect must always be somehow billboarded towards the viewer. Line 0372 gives the dust colour. Line 0373 calls the 128x128 'texture' dust.raw which, since line 0374 starts with 0088, is used as a transparency mask.
You know, it is so fascinating to learn about this process. I am amazed at the images of dust.3 created in AC3D with, if I understand this correctly, two standard TAW texture maps used, one for the XY(exp_6) plane and another for the XZ(exp_1). I was unable to find a AC3D .raw plugin, is there a way to get AC3D to use the raw textures? Okay I'm trying to understand why when I converted line 0372;00A700A200910075 by changing it to 0372;00A7000000000000 the ground vehicle is seen with a series of progressively enlarging rectangular plates of the exact raw image you posted, without color and trailing the ground vehicle. Almost as if I had lost the dust image and had only the mask, does that seem logical? Not sure the billboarding orientation is related to this but perhaps the orientation of the 3D image can also be modified by the SSD files using the parameters in the smoke.dat file , eg: DEFSMOKE "MEDIUMDUST8" ; dust trail VIS 1000 VEL 0,0,0 ; initial velocity (m/sec) SPUTTER 0.2,0,0.2 ; random sputtering (m/sec) LIFE 1.5 ; particle life expectancy (secs) LIFERAND 0.2 ; random life variation (secs) RATE 0.3 ; delay between particle emissions (secs) RATERAND 0.01 ; random emmision variation (secs) BETWEENS 0 ; How many particles to insert for each particle emitted VARIABLEBETWEENS 1 UNTIL 1.6 "DT1" UNTIL 1.2 "DT3" UNTIL 0.8 "DT5" UNTIL 0.4 "DT7" UNTIL 0.0 "DT9" ROTATE 0 ENDSMOKE ???
Edited by DrKevDog (07/26/09 11:42 AM)
Edit Reason: correction of fx_ian 2 to exp_6
|
|
Top
|
|
|
|
|
#2826857 - 07/25/09 04:49 PM
Re: .3 Files
[Re: HomeFries]
|
SimHQ Member
Registered: 06/27/06
Posts: 591
|
Apologies for my ignorance, but what is the East-West palette system? I am not familiar with that nomenclature.
The East-West Palette feature was, we believe, a DID method of simulating real world differences in solar influence on sunrise and sunset in TAW although it was never implemented within the game. I was only able to get it functioning in Glide and not D3D. It is fairly easy to set up and the SimHQ thread reference which explains it all is below: http://simhq.com/forum/ubbthreads.php/topics/2525857/1.htmlAs to the utility for making global changes to indexed palettes, I'll have to defer to someone more experienced than me 
|
|
Top
|
|
|
|
|
#2827327 - 07/26/09 11:40 AM
Re: .3 Files
[Re: mikew]
|
SimHQ Member
Registered: 06/27/06
Posts: 591
|
There are only 4 vertices in the dust.3 file, so the dust effect must always be somehow billboarded towards the viewer. Line 0372 gives the dust colour. Line 0373 calls the 128x128 'texture' dust.raw which, since line 0374 starts with 0088, is used as a transparency mask.
Okay, trying to keep up here... When you say only 4 vertices: *00620000FFC700000039 *00640072 *0066FF8E *0064FF8E 006100040000 0098FFEC Did you figure out how 0061 functions? Your visual explanation of the use of the .raw file as a transparency mask is very well done. I noticed the file was 128 x 128 RGB with the alpha channel utilized. It reminds me of the TAW_OPTS.cfg file which has "ALPHA" settings, I just have not been able to figure that file out yet. My earlier comment about the two TM files used in the AD3C rendering of the dust.3 file, is one related to software mode (exp_1) and the other D3D hardware mode(exp_6)? 0047 002A0004005E002F008D002F008D005E005E005E008800040000000100020003...exp_1 at position 43 0047 00380004005E008D008D008D008D00BC005E00BC008800040000000100020003...exp_6 at position 57 0047 0101000400000000008000000080008000000080008800040000000100020003...dust.raw at position 258 ?
|
|
Top
|
|
|
|
|
#2827355 - 07/26/09 12:14 PM
Re: .3 Files
[Re: DrKevDog]
|
SimHQ Member
Registered: 02/26/01
Posts: 1694
Loc: UK
|
Yes, there are any 4 vertices describing a rectangle. That I'm totally sure of.
00620000FFC700000039
00640072
0066FF8E
0064FF8E
006100040000
A block of vertex descriptions always starts with a 0062 line, which fixes the start vertex.
Immediately following the 0062 is 0000 which is the start vertex index. At the end, the 0061 line contains the number of vertices in the block, in this case 0004. I don't know the exact purpose of the 0061 line in the game, but it probably helps set up the vertex buffer in some way.
Note that all the vertex blocks start at 0 and contain 4 vertices.
There are many such blocks, although only one will be used at any time. Which one is selected depends on the decision lines:
0027 Based on distance
00480000 A loop number (I think). This produces 11 rectangles at slightly different places, giving the dust trail.
00A3 Based on AGP capability.
I haven't followed the branches through the file, but maybe exp_1 and exp_6 are used in non-AGP mode, with the choice between exp_1 and exp_6 based on distance.
dust.raw is only used in AGP mode.
In the picture above, I tried to simulate the effect in the game by producing a 128x128 .bmp file with the RGB hex values A2,91,75 respectively taken from the 00A7 line. I used the values from dust.raw for the alpha (A) channel.
Note that dust.raw has an alpha value for each colour, meaning that it is theoretically possible to have different levels of transparency for R,G and B. In dust.raw though, the 3 values are always the same.
What is interesting here, is that it is possible to set the colour that becomes transparent. In dust.3 it's that sand colour. Where transparacy masks are used elsewhere, eg clouds, I can't see any way to set the colour meaning that the clouds will always be white.
|
|
Top
|
|
|
|
|
#2827360 - 07/26/09 12:17 PM
Re: .3 Files
[Re: HomeFries]
|
SimHQ Member
Registered: 02/26/01
Posts: 1694
Loc: UK
|
....and is there a utility that can convert an indexed palette in a graphics file to a .col file? If so, this would really open things up (and not just for weather mods). I think MGonzales' texture manager will do that when converting from .bmp.
|
|
Top
|
|
|
|
|
#2827471 - 07/26/09 03:40 PM
Re: .3 Files
[Re: mikew]
|
SimHQ Member
Registered: 06/27/06
Posts: 591
|
00A3 Based on AGP capability.
I haven't followed the branches through the file, but maybe exp_1 and exp_6 are used in non-AGP mode, with the choice between exp_1 and exp_6 based on distance.
dust.raw is only used in AGP mode.
As I look back at the actual game images I am inclined to reconsider the "software mode" statement I made earlier regarding the utilization of exp_1, and consider a somewhat different explanantion involving shadows. The exp_1 is used in the Horizontal/Top-down XZ plane as seen in AC3D, which would suggest that a more logical explanation is that it is used for the dust shadow on the ground under the dust objects in the game. It is curious, however, to note that the shadows are not present in AGP mode. If I understand you correctly, (and I'm not certain that I do because I'm getting the Alpha Channel transparency issue mixed in with the transparency mask issue, but I'm sure I'll sort it all out in time) you are saying that the dust.3 is read, pretty much the same, in AGP as it is in Non-AGP except that AGP uses, in addition, dust.raw as a transparency mask over exp_6. Is that correct? 0025;0047002A0004005E002F008D002F008D005E005E005E 0026; 008800040000000100020003 0260;004700380004005E002F008D002F008D005E005E005E 0261;00 8800040000000100020003 Both exp_1 (shadow?) and exp_6 (dust) use transparency masks, so why is there no dust ground shadow seen in the AGP mode?
...What is interesting here, is that it is possible to set the colour that becomes transparent. In dust.3 it's that sand colour. Where transparacy masks are used elsewhere, eg clouds, I can't see any way to set the colour meaning that the clouds will always be white.
OUCH!
|
|
Top
|
|
|
|
|
#2827712 - 07/27/09 01:10 AM
Re: .3 Files
[Re: DrKevDog]
|
SimHQ Member
Registered: 02/26/01
Posts: 1694
Loc: UK
|
As I look back at the actual game images I am inclined to reconsider the "software mode" statement I made earlier regarding the utilization of exp_1, and consider a somewhat different explanantion involving shadows. The exp_1 is used in the Horizontal/Top-down XZ plane as seen in AC3D, which would suggest that a more logical explanation is that it is used for the dust shadow on the ground under the dust objects in the game. It is curious, however, to note that the shadows are not present in AGP mode. I didn't realise the dust had shadows, in which case exp_1/exp_6 could be used for the dust/shadows. Need to go the dust.3 file line by line to sort it out. Just because only X and Z coordinates are specified doesn't necessarily mean that the object will be horizontal in the game though. If I understand you correctly, (and I'm not certain that I do because I'm getting the Alpha Channel transparency issue mixed in with the transparency mask issue, but I'm sure I'll sort it all out in time) you are saying that the dust.3 is read, pretty much the same, in AGP as it is in Non-AGP except that AGP uses, in addition, dust.raw as a transparency mask over exp_6. Is that correct? I don't think that's right. It looks like at the start of the file that there is a 00A3 line which hops over the exp_1/exp_6 stuff if AGP is used. So it seems like it's exp_1/exp_6 for non-AGP and dust.raw for AGP. Both exp_1 (shadow?) and exp_6 (dust) use transparency masks, so why is there no dust ground shadow seen in the AGP mode? Fits in with previous comment. OUCH! Maybe not. With this new information we could replace the 002E... polygon descriptors in the cloud files with 0047... descriptors. We just need to place a 00A7 line before the 0047 lines to give the cloud colour, then probably a 00A8 at the end.
|
|
Top
|
|
|
|
|
#2828324 - 07/27/09 05:19 PM
Re: .3 Files
[Re: mikew]
|
SimHQ Member
Registered: 06/27/06
Posts: 591
|
I didn't realise the dust had shadows, in which case exp_1/exp_6 could be used for the dust/shadows. Need to go the dust.3 file line by line to sort it out.
Just because only X and Z coordinates are specified doesn't necessarily mean that the object will be horizontal in the game though. Okay, noted. I'll look further. I don't think that's right. It looks like at the start of the file that there is a 00A3 line which hops over the exp_1/exp_6 stuff if AGP is used. So it seems like it's exp_1/exp_6 for non-AGP and dust.raw for AGP. That was my original understanding. The issue of how the transparency mask is applied, or to what it is applied, made me a bit daft I suppose  Maybe not. With this new information we could replace the 002E... polygon descriptors in the cloud files with 0047... descriptors. We just need to place a 00A7 line before the 0047 lines to give the cloud colour, then probably a 00A8 at the end. Now you're talkin...and hope maketh not ashamed
|
|
Top
|
|
|
|
|
#2832659 - 08/01/09 12:38 PM
Re: .3 Files
[Re: DrKevDog]
|
SimHQ Member
Registered: 02/26/01
Posts: 1694
Loc: UK
|
DKD, I've got another unfinished user-unfriendly tool for you to look at .3 stuff. If you can be bothered, it's here: http://rapidshare.com/files/262612680/taw_viewerdx8.zipIt comes with all TAW related support files so you just need to unzip the file to a new directory. Clicking on the .exe should show a screen like this:  ..which is an extract from the file 'drums.3.txt' The general idea is that you paste any vertex/polygon info that you're interested in into the file input.txt (which must exist) and it will attempt to render it.
|
|
Top
|
|
|
|
|
#2836949 - 08/07/09 08:54 PM
Re: .3 Files
[Re: mikew]
|
SimHQ Member
Registered: 06/27/06
Posts: 591
|
As soon as I get some time I'll look into the AGP cloud code modifications and post what I find. Trying to follow your logic on the 0015 rendering order in sea.3. Sounds like a perfectly good theory to me Are you still OK with 0015 GOTO and 0008 GOSUB? Have you expanded and modified your TAW opcode table? I may need your help,at some point, in modifying your parser algorithm for some of the more complex files I previously found. Really like the 3file viewer, havn't had much time with it yet but, as always, very impressed with your skills and creativity.
|
|
Top
|
|
|
|
|
#2840147 - 08/12/09 04:51 PM
Re: .3 Files
[Re: mikew]
|
SimHQ Member
Registered: 06/27/06
Posts: 591
|
I can explain the 3rd and 4th byte discrepancy though. At some point I made a script which changes those bytes in all .3 files to 3E80 (16000) which increases the viewing range.....and I must have used those files to produce that big zip file.
Thanks for the explanation, I suspected that was the reason. One of my goals is to find a way to introduce some of the noname, non-krus files, which are not conventionally used, into TAW. I am hoping sections of the header information, such as viewing distance, will allow me to group objects in such a way as to determine relationships and, perhaps, function.
|
|
Top
|
|
|
|
|
#2846170 - 08/22/09 10:02 AM
Re: .3 Files
[Re: DrKevDog]
|
SimHQ Member
Registered: 06/27/06
Posts: 591
|
Slightly OT: Eurofighter 3D-object extraction success: not yet Eurofighter Textures and Sound files extraction success: Have been successful in extracting a large cache of, what I believe is, the complete set of textures (including DDS files of DXT-1 and DXT-3 compression format textures). TGA, BMP, DDS formats. They are irfanview and photoshop (with plugin) viewable. Also a large collection of .wav and other SFX/MUSIC files. Am quite hopeful many will provide TAW portability Although it seems a little more challenging, looking forward to moving on to extracting the 3D-object and other files 
|
|
Top
|
|
|
|
|
#2846259 - 08/22/09 12:33 PM
Re: .3 Files
[Re: DrKevDog]
|
F22 Air Dominance Project
SimHQ Member
Registered: 01/01/01
Posts: 714
Loc: Greater Washington DC Area
|
Slightly OT: Eurofighter 3D-object extraction success: not yet Eurofighter Textures and Sound files extraction success: Have been successful in extracting a large cache of, what I believe is, the complete set of textures (including DDS files of DXT-1 and DXT-3 compression format textures). TGA, BMP, DDS formats. They are irfanview and photoshop (with plugin) viewable. Also a large collection of .wav and other SFX/MUSIC files. Am quite hopeful many will provide TAW portability Although it seems a little more challenging, looking forward to moving on to extracting the 3D-object and other files Bet OT reply in a while!
_________________________
-Home Fries The average Naval Aviator, despite the sometimes swaggering exterior, is very much capable of such feelings as love, affection, intimacy, and caring. These feelings just don't involve anyone else. F-22 Air Dominance Project
|
|
Top
|
|
|
|
|
#2878799 - 10/12/09 11:57 PM
Re: .3 Files
[Re: HomeFries]
|
F22 Air Dominance Project
SimHQ Member
Registered: 01/01/01
Posts: 714
Loc: Greater Washington DC Area
|
|
|
Top
|
|
|
|
|
#2879045 - 10/13/09 11:25 AM
Re: .3 Files
[Re: HomeFries]
|
SimHQ Member
Registered: 04/16/03
Posts: 1039
|
I'll admit I do not keep up on this particular glossary of technobabble......
Is there a possibility that you can fit EF2000 with a Glide or D3D capability??
_________________________
The Colonel
"They're not toys. They're collectables."
|
|
Top
|
|
|
|
|
#2879384 - 10/13/09 08:42 PM
Re: .3 Files
[Re: Colonel Kern]
|
F22 Air Dominance Project
SimHQ Member
Registered: 01/01/01
Posts: 714
Loc: Greater Washington DC Area
|
Doubtful. The more likely route would be to convert the EF2000 objects (and thus the Scandinavia theater) to the TAW engine. Bringing over the EF2000 would require source code edits.
_________________________
-Home Fries The average Naval Aviator, despite the sometimes swaggering exterior, is very much capable of such feelings as love, affection, intimacy, and caring. These feelings just don't involve anyone else. F-22 Air Dominance Project
|
|
Top
|
|
|
|
|
#2897053 - 11/08/09 12:44 PM
Re: .3 Files
[Re: HomeFries]
|
SimHQ Member
Registered: 02/26/01
Posts: 1694
Loc: UK
|
A new piece of information, the '0007' operator does not appear to be a GOTO statement after all, but a GOSUB based on one of the 'Options' settings. Probably 'Airfield Detail'. As mentioned in anther thread, I'm doing some experiments with the Python language instead of VB. The first thing I've done is try and interpret the jumps through the 3 file to provide the vertex and polygon information in a particular set of circumstances. For example, taking the simple 'tent_3' file and setting the damage level to 1 and viewed from close range only uses the following lines of code which is what is actually rendered: 0065FFFD
0061000A0000
006200000001FFFFFFF1
006E000700010006
006BFFF00005
006D001E0008
006B00100007
006EFFF7FFFF0001
00750000
00750006
00750005
00750008
00750007
00750001
0062000AFFDD00000023
00640046
0066FFBA
0064FFBA
00640023
00660046
0066FFDD
0064FFDD
00640046
00610009000A
00470009000400010001002000010020002000010020
008E0004000A000F00100011
00470009000400200001003F0001003F002000200020
008E0004000F000B00120010
00470009000400200020003F0020003F003F0020003F
008E000400100012000C000E
00470009000400010020002000200020003F0001003F
008E000400110010000E000D
009F000E0074040100B700B700BC00BC009E0005000800010000
009F000E0070040100B700B700BC00BC009E0000000100070006
009F000C0072030100B800BA00B7009D000500000006
009F000C006E030100B900B600BB009D000800070001
This can be pasted into the 'input.txt' file of the 3D viewer I posted a couple of pages back to see what it looks like:  The whole parsed tent_3 file is here: 0000 00300003
0001 006200000000FFFBFFF1
0002 0066001E
0003 006700080002
0004 0066FFE2
0005 0064FFF0
0006 00650003
0007 00640010
0008 0066001E
0009 0064FFF0
0010 0065FFFD
0011 0061000A0000
0012 002700A50184 If Distance >165 then jump to line 43
0013 00480007
0014 0022000000D0 If Parameter 0007 > 0 then jump to line 25
0015 0008035A Jump to Sub at line 99
0016 009F000E0035040100D000D000CD00CD009E0001000000040009
0017 009F000E0033040100CE00CE00CF00CF009E0000000100020003
0018 009F000C0036030100CA00CB00C9009D000400000003
0019 009F000C0032030100CA00C900CB009D000900020001
0020 009F000E0036040100CA00C900C800C9009E0004000300060005
0021 009F000E0032040100C900CA00C900C8009E0002000900080007
0022 009F000E0038040100CC00CC00CA00CA009E0009000400050008
0023 009F000E0034040100C800C800C600C6009E0003000200070006
0024 0000
0025 006200000001FFFFFFF1
0026 006E000700010006
0027 006BFFF00005
0028 006D001E0008
0029 006B00100007
0030 006EFFF7FFFF0001
0031 00750000
0032 00750006
0033 00750005
0034 00750008
0035 00750007
0036 00750001
0037 00080188 Jump to Sub at line 79
0038 009F000E0074040100B700B700BC00BC009E0005000800010000
0039 009F000E0070040100B700B700BC00BC009E0000000100070006
0040 009F000C0072030100B800BA00B7009D000500000006
0041 009F000C006E030100B900B600BB009D000800070001
0042 0000
0043 002700FA00E0 If Distance >250 then jump to line 71
0044 00480007
0045 0022000000BC If Parameter 0007 > 0 then jump to line 68
0046 006200030008FFFDFFF1
0047 006C00030006
0048 006BFFF00005
0049 006CFFFD0004
0050 006D001E0009
0051 006C00030008
0052 006B00100007
0053 006CFFFD0002
0054 00750003
0055 00750006
0056 00750005
0057 00750004
0058 00750009
0059 00750008
0060 00750007
0061 00750002
0062 009F00080038010300CC009E0009000400050008
0063 009F00080036010300CA009E0004000300060005
0064 009F00080032010300CA009E0002000900080007
0065 009F00080034010300C8009E0003000200070006
0066 009F00080035010300CE009E0004000900020003
0067 0000
0068 00080058 Jump to Sub at line 79
0069 009F00080077010300B9009E0005000800070006
0070 0000
0071 002703840456 If Distance >900 then jump to line 244
0072 00480007
0073 002200000018 If Parameter 0007 > 0 then jump to line 76
0074 009F00080035010300CA009E0006000500080007
0075 0000
0076 00080018 Jump to Sub at line 79
0077 009F00080077010300B9009E0006000500080007
0078 0000
0079 002703840416 If Distance >900 then jump to line 244
0080 0062000AFFDD00000023
0081 00640046
0082 0066FFBA
0083 0064FFBA
0084 00640023
0085 00660046
0086 0066FFDD
0087 0064FFDD
0088 00640046
0089 00610009000A
0090 00470009000400010001002000010020002000010020
0091 008E0004000A000F00100011
0092 00470009000400200001003F0001003F002000200020
0093 008E0004000F000B00120010
0094 00470009000400200020003F0020003F003F0020003F
0095 008E000400100012000C000E
0096 00470009000400010020002000200020003F0001003F
0097 008E000400110010000E000D
0098 0000
0099 002700960356 If Distance >150 then jump to line 244
0100 002700930138 If Distance >147 then jump to line 179
0101 002700900128 If Distance >144 then jump to line 176
0102 0027008D0118 If Distance >141 then jump to line 173
0103 0027008A0108 If Distance >138 then jump to line 170
0104 0027008700F8 If Distance >135 then jump to line 167
0105 0027008400E8 If Distance >132 then jump to line 164
0106 0027008100D8 If Distance >129 then jump to line 161
0107 0027007E00C8 If Distance >126 then jump to line 158
0108 0027007B00B8 If Distance >123 then jump to line 155
0109 0027007800A8 If Distance >120 then jump to line 152
0110 002700750098 If Distance >117 then jump to line 149
0111 002700720088 If Distance >114 then jump to line 146
0112 0027006F0078 If Distance >111 then jump to line 143
0113 0027006C0068 If Distance >108 then jump to line 140
0114 002700690058 If Distance >105 then jump to line 137
0115 002700660048 If Distance >102 then jump to line 134
0116 002700630038 If Distance >99 then jump to line 131
0117 002700600028 If Distance >96 then jump to line 128
0118 0027005D0018 If Distance >93 then jump to line 125
0119 0027005A0008 If Distance >90 then jump to line 122
0120 000700CC Jump to line 182
0121 0000
0122 0098FFFF
0123 000700C2 Jump to line 182
0124 0000
0125 0098FFFE
0126 000700B8 Jump to line 182
0127 0000
0128 0098FFFD
0129 000700AE Jump to line 182
0130 0000
0131 0098FFFC
0132 000700A4 Jump to line 182
0133 0000
0134 0098FFFB
0135 0007009A Jump to line 182
0136 0000
0137 0098FFFA
0138 00070090 Jump to line 182
0139 0000
0140 0098FFF9
0141 00070086 Jump to line 182
0142 0000
0143 0098FFF8
0144 0007007C Jump to line 182
0145 0000
0146 0098FFF7
0147 00070072 Jump to line 182
0148 0000
0149 0098FFF6
0150 00070068 Jump to line 182
0151 0000
0152 0098FFF5
0153 0007005E Jump to line 182
0154 0000
0155 0098FFF4
0156 00070054 Jump to line 182
0157 0000
0158 0098FFF3
0159 0007004A Jump to line 182
0160 0000
0161 0098FFF2
0162 00070040 Jump to line 182
0163 0000
0164 0098FFF1
0165 00070036 Jump to line 182
0166 0000
0167 0098FFF0
0168 0007002C Jump to line 182
0169 0000
0170 0098FFEF
0171 00070022 Jump to line 182
0172 0000
0173 0098FFEE
0174 00070018 Jump to line 182
0175 0000
0176 0098FFED
0177 0007000E Jump to line 182
0178 0000
0179 0098FFEC
0180 00070004 Jump to line 182
0181 0000
0182 0062001300080000000F
0183 0066FFE2
0184 0064FFF0
0185 0066001E
0186 006100040013
0187 004301FF002E If Time of Day = 511 then jump to line 196
0188 004301FF0028 If Time of Day = 511 then jump to line 196
0189 0043003F0172 If Time of Day = 63 then jump to line 232
0190 0043001F0134 If Time of Day = 31 then jump to line 226
0191 0043000F00F6 If Time of Day = 15 then jump to line 220
0192 0043000700B8 If Time of Day = 7 then jump to line 214
0193 00430003007A If Time of Day = 3 then jump to line 208
0194 00430001003C If Time of Day = 1 then jump to line 202
0195 0000
0196 00620017FFED0000FFF1
0197 0066001E
0198 006100020017
0199 00470006000400000040003F0040003F007F0000007F
0200 008800040017001800160015
0201 0000
0202 00620017FFF30000FFF1
0203 0066001E
0204 006100020017
0205 00470006000400000040003F0040003F007F0000007F
0206 008800040017001800160015
0207 0000
0208 00620017FFF50000FFF1
0209 0066001E
0210 006100020017
0211 00470006000400000040003F0040003F007F0000007F
0212 008800040017001800160015
0213 0000
0214 00620017FFF70000FFF1
0215 0066001E
0216 006100020017
0217 00470006000400000040003F0040003F007F0000007F
0218 008800040017001800160015
0219 0000
0220 0062001700090000000F
0221 0066FFE2
0222 006100020017
0223 00470006000400000040003F0040003F007F0000007F
0224 008800040017001800140013
0225 0000
0226 00620017000B0000000F
0227 0066FFE2
0228 006100020017
0229 00470006000400000040003F0040003F007F0000007F
0230 008800040017001800140013
0231 0000
0232 00620017000D0000000F
0233 0066FFE2
0234 006100020017
0235 00470006000400000040003F0040003F007F0000007F
0236 008800040017001800140013
0237 0000
0238 0062001700130000000F
0239 0066FFE2
0240 006100020017
0241 00470006000400000040003F0040003F007F0000007F
0242 008800040017001800140013
0243 0000
0244 0000
0245 FFFF
0246 002000200020
For what it's worth, the Python script used to do this is here:
f = open("C:\eclipse\workspace\\taw_3\\tent_3.3.TXT")
index=[]
data=[]
branch=[]
total=0
xx=0
active48=""
active15=0
hand8=0
after15=0
try:
for line in f:
index.append("%04d"%total)
data.append(line[0:len(line)-1])
total+=1
# print opcode
finally:
f.close()
total-=1
count=0
nest=1
active7=1
param0007=1
distance=10
tod=31
jumpbase=[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]
branchind=0
active8=0
curr15=0
while nest>0:
temp=data[count]
opcode= temp[0:4]
if opcode=="0000":
nest-=1
if nest>0:
count=jumpbase[nest]+1
elif opcode=="0007":
jump=int(temp[4:8],16)
hopcount=2
hopline=1
while hopcount<jump:
temp=data[count+hopline]
linlen=len(temp)/2
hopcount+=linlen
hopline+=1
if active7==1:
jumpbase[nest]=count
count+=hopline
print 7,count
nest+=1
else:
count+=1
# print index[count]+" "+data[count]+" "+comment[count]
elif opcode=="0008":
jump=int(temp[4:8],16)
hopcount=2
hopline=1
while hopcount<jump:
temp=data[count+hopline]
linlen=len(temp)/2
hopcount+=linlen
hopline+=1
if active15==0:
jumpbase[nest]=count
oldcount=count
count+=hopline
print oldcount,8,count
nest+=1
else:
hand8+=1
trycount=count+hopline
temp=data[trycount]
if temp[0:4]=="0015":
count+=1
else:
jumpbase[nest]=count
oldcount=count
count+=hopline
print oldcount,8,count
nest+=1
if hand8==2:
active15=0
hand8=0
count=after15
# print index[count]+" "+data[count]+" "+comment[count]
elif opcode=="0015":
after15=count+7
active15=1
print count,15
count+=1
elif opcode=="0021":
param=int(temp[4:8],16)
jump=int(temp[8:12],16)
hopcount=2
hopline=1
while hopcount<jump:
temp=data[count+hopline]
linlen=len(temp)/2
hopcount+=linlen
hopline+=1
if param0007==param:
count+=hopline
print 21,count
else:
count+=1
# print index[count]+" "+data[count]+" "+comment[count]
elif opcode=="0022":
param=int(temp[4:8],16)
jump=int(temp[8:12],16)
hopcount=2
hopline=1
while hopcount<jump:
temp=data[count+hopline]
linlen=len(temp)/2
hopcount+=linlen
hopline+=1
if param0007>param:
count+=hopline
print 22,count
else:
count+=1
# print index[count]+" "+data[count]+" "+comment[count]
elif opcode=="0027":
dist=int(temp[4:8],16)
jump=int(temp[8:12],16)
hopcount=2
hopline=1
while hopcount<jump:
temp=data[count+hopline]
linlen=len(temp)/2
hopcount+=linlen
hopline+=1
if distance>dist:
count+=hopline
print 27,count
else:
count+=1
# print index[count]+" "+data[count]+" "+comment[count]
elif opcode=="0043":
tim=int(temp[4:8],16)
jump=int(temp[8:12],16)
hopcount=2
hopline=1
while hopcount<jump:
temp=data[count+hopline]
linlen=len(temp)/2
hopcount+=linlen
hopline+=1
if tod==tim:
jumpbase[nest]=count
count+=hopline
print 43,count
nest+=1
else:
count+=1
# print index[count]+" "+data[count]+" "+comment[count]
elif opcode=="0048":
active48=temp[4:8]
count+=1
else:
branch.append(data[count])
branchind+=1
count+=1
f = file("C:\eclipse\workspace\\taw_3\\tent_3branch.TXT","w")
while xx<branchind:
print >> f, branch[xx]
xx+=1
f.close()
It looks better in a proper editor with context highlighting.
|
|
Top
|
|
|
|
|
#2897240 - 11/08/09 07:59 PM
Re: .3 Files
[Re: mikew]
|
SimHQ Member
Registered: 06/27/06
Posts: 591
|
|
|
Top
|
|
|
|
|
#2901334 - 11/15/09 10:30 AM
Re: .3 Files
[Re: mikew]
|
SimHQ Member
Registered: 06/27/06
Posts: 591
|
Anything that can be done with Python can also be done with Visual Basic. But after a few hours of Python I'm still in awe of how easy it is to do quite complicated tasks. This may be the 'new mistress' effect though. All the control surfaces from TAW's F22, and presumably the EF2000's canards etc, have their own .3 files. These are not referenced from the .ssd file, but direct from the game .exe. I don't know the exact mechanism for this though...... Thanks for jogging my memory on the control surfaces issue. I know you're probably just sitting around home playing with your Python...but perhaps you could look at this project for me. Trying to improve the surface object textures and am interested in how to implement Triangle Texture Mapping with Gouraud Light Rendering. There is a source code for script in C++ here: www.yov408.com/html/codespot.php?gg=39How could this be adapted, using Python, for use in TAW?
|
|
Top
|
|
|
|
|
#2901371 - 11/15/09 11:58 AM
Re: .3 Files
[Re: DrKevDog]
|
SimHQ Member
Registered: 02/26/01
Posts: 1694
Loc: UK
|
I know you're probably just sitting around home playing with your Python... I've been a bit busy this week, but I've been bashing away when I've had the chance. I suggest you take a look at this: http://fly.cc.fer.hr/~unreal/theredbook/ ...particularly chapter 5. As far as I know, TAW uses index colour mode for everything although your AGP work does suggest that 24 bit RGB colour is used as well. I didn't think it was possible to mix the 2 modes, but DID possibly knew more about it than I do. The following line from 'tent_3.3' contains both texture and gouroud shading for a triangle: 009F000C0072030100B800BA00B7009D000500000006 If textured buildings are enabled, the tent is rendered with a texture (in this case 'MATERIAL DEAD') otherwise it is shaded with the colours of the 3 vertices being at palette positions B8,BA and B7. The triangle is then rendered with a linear interpolation between these colours.
|
|
Top
|
|
|
|
|
|
|
| |
Calendar
Downloads
FAQ
Multiplayer
News
Release Dates
SimHQ TV
Previous Topic
Index