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.

I'm not sure that much progress has been made, but it's been useful for me to try and document things. Maybe we should investigate Home Fries's suggestion of a wiki. Certainly this guy's efforts for F15SE3 put me to shame:
http://simhq.com/forum/ubbthreads.php/topics/2740370/F_15_Strike_Eagle_III_editing_.html#Post2740370

Anyway, off to the arctic for a few days. No internet, but will try to work on TAW, since with perpetual daylight I won't be getting much sleep.

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.zip

Unzip 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.

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;000200B40001001E001F

to

0258;000200090001001E001F

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?

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.

HomeFries,

Thanks for the input. I believe you probably know much about the NVG Palettes so that info is helpful. I don't, however, think it was green masking and so I'm looking to get a brief update on how transparencies are rendered, especially WRT code identifications. I'm going to be away from the computer for a few days but I'll follow-up on my return.



Thanks,

DKD

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.

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;00A30090
0492;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.html

I 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. (?)

I agree, it's a very curious finding, perhaps we can explore it further?

Interesting! That 00A3 opcode is quite rare and I haven't yet tried to guess what it does, but your theory seems sound. So, we can say for the 0491;00A30090 line:
"If AGP (or something else) is enabled then jump 90 bytes"

I'm not sure the 00A3 in the headers is linked to the 00A3 opcode, but will keep it in mind.

As to the textured polygons, I suggest you make some changes and see what happens. The AC3D converter is still very crude and will not try and decode things it doesn't understand.

In your example of a 0047 line, you've got texture coordinates for a rectangle of size 512x2. This doesn't fit in with 'normal' textures, which can be maximum of 256x192, but of course the textures in the agp folder can be handled differently. I haven't looked into this before.

The textures 'sky0800' etc, I assume you've found among the nonames?