QUOTE |
It seems the game only uses 0, 1, 3, 7, 8 and 9. |
and 6 (barrio3b_lae.dff), and 10 (escl_la.dff). 10 is only used on 2 objects, both are escalator-related.
Heres what i've got on the light info so far:
parameter 1, parameter 2, parameter 3
0x07010028, 0x42, 0x02000400 - traffic (traffic)
0x07010028, 0x42, 0x67000400 - traffic (trafficredlight - yes the redlight is slightly different)
0x00000028, 0x40, 0x5400109C - maverick (flashes - will NOT flash without parameter 3!)
0x00000028, 0x40, 0x0200109C - tug (flashes - will NOT flash without parameter 3!)
0x00000028, 0x46, 0x6400109C - mine
0x03000028, 0x60, 0xB0000000 - bb_pickup
0x03000028, 0x60, 0x70000000 - basejumplight
0x00010050, 0x42, 0x50000400 - mlampost
0x00010028, 0x42, 0x70000400 - lampost_coast
0x08000028, 0x60, 0xC0000000 - traincross (traincrossing light)
it appears as though all 3 parameters need to be set, for the light to function correctly. only parameter 2 seems "optional" in the least, as long as its not 0. however making it 0 disables the light so it IS used.
parameter 1, is the "parameters" dword mentioned before. parameter 2, is the 1-byte "padding??" we thought of, and parameter 3 is actually the dword, 8 bytes before the section ends.
UV Animation breakdown, as near as i can tell:
Section Type - 0x2b, Uv Animation Dictionary
size
rwversion
Section Type - 01, Struct
size
rwversion
dword - 01
Section Type - 0x1b, Anim Animation
size
rwversion
dword - 256d
dword - 449d
0x30 - dword - (number of keyframes)
0x34 - dword - 0
0x38 - word - unknown
0x3A - word - end frame position?
0x3c - dword - 0
0x40 - string - material name (null terminated)
unknown, padding? length, 0x37 bytes, after null terminator
//begining of animation data?
0x84 - dword - 0x00000080
0x88 - float - 1.0
0x8c - float - 1.0
0x90 - dword - 0
0x94 - dword - 0
0x98 - dword - 0
0x9C - byte - (offset U)
0x9D - byte - (offset V)
0x9E - word - unknown
0xA0 - float - 1.666667e+1
0xA4 - float - -3.141593e+0
0xA8 - float - (Tile U multiplier?(when tile U is 1.0 in max, so it this. when its .5, this is 2.0))
0xAC - float - (Tile V multiplier?)
0xB0 - float - 8.742278e-8
0xB4 - float - (Tile U, inverted (if .5 in max, it will be -.5 here)
0xB8 - float - (Tile V, inverted (if .5 in max, it will be -.5 here)
0xBC - dword - 0
The float numbers i have listed are from my own files for testing.
The UV coordinates type (UV/VW/WU) in the 3dsmax bitmap rollout IS respected by the exporter. All tests done using "UV" coordinates, however different coordinate types (VW, WU), will export different data. There is no flag in the anim animation data, to signify which coordinates are being read however.
Likewise, the "Angle" data is respected on export, and will alter the uv coordinates appropriately.
A keyframe at frame 0, is assumed.
Material effect Breakdown
(this data is part of material effects PLG struct)
dword - mat type
dword - mat type2
float - multiplier for bump/envmap (if mat type is dual, then src blend type (integer as well, not float))
dword - 0 (if mat type is dual, then dest blend type(integer))
dword - 1 (always 1?)
Section type 06, texture
Section size
Renderware Version
Section type 01, struct
Section size
Renderware Version
dword - texture flags
section type 02, string
section size
renderware version
string - texture name (null terminated, byte aligned? theres an extra "00" appended)
section type 02, string2 (if appllicable)
section size
renderware version
string - texture name (dword 0 if no texture)
section type 03, extension
section size
renderware version
dword 0
//end material*
*if the material type is BumpEnv, then all the data above is repeated, with the variables (tex name, multiplier, etc) set as necessary, EXCEPT, mat type 2; only mat type 1 is listed for this section, which i call type 3. Read below for a detailed explanation.
mat type key: type1, type2:
BumpMap:01,01
EnvMap:02,02
BumpEnvmap:03,01
DualPass:04,04
UVTransform:05,05
DualUvTransform:06,05
Type one, seems to be the material "Superclass", going incrementally from 1-6, wheras type 2 is some sort of of "sub-class". Note on "BumpEnvMap", the superclass, is 3, as its the 3rd main material type; type2 is 01, which corresponds to "Bumpmap" (and the subsequent multiplier tha follows, matches the bumpmap setting). On the second set of material data that gets appeded ONLY on BumpEnvMap, one type is gone, and "type 3" is set to 02, which corresponds to EnvMap.
/goes for a nap.
No replies at all? What, too much info all at once?
