72 replies to this topic

[DexX]

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?

[DexX]

omg double post feedmetothelions! Sorted out 1 of the Sa data types, and revised another:

Street Sign Text: type 7 (exclbrsign01_lvs)
float - position x in world coordinates
float - position y in world coordinates
float - position z in world coordinates
type - 7
Size - 0x58 (varies..)
float - scale X (horizontal)
float- scale Y (vertical)
float - rotation X
float - rotation Y
float - rotation Z
byte - 0x32, 0x33 (may vary per sign text, but changing has no noticeable effect ingame...)
byte - 0
string - sign text
byte - 0 (may vary per sign text, but changing has no noticeable effect ingame...)
byte - 0 (may vary per sign text, but changing has no noticeable effect ingame...)

For the life of me, i cannot find any position data for the street sign text. i've checked everything in the IPL, IDE, binary ipl, cull info, collision info, the models' dff and txd, nada. I doubt it is scripted, but it wouldnt hurt to confirm that. last stop is the exe. that seems unlikely, considering every other facet of the sign text is stored externally, but i'm not sure what else is left to check.
sorted. see following posts for details.

Escalators type 10 (0xA)
size - 0x28
float3 - bottom of escalator (xyz)
float3 - top of escalator (xyz)
float3 - escalator end (Z pos, matches top Z if escalator goes up, bottom Z if it goes down)
long - direction 0/1 (down/up)

Edit: Unknown type 9
size 0x0C
float unknown (usually 0 on samples i checked)
float unknown (usually 1.0 on samples i checked)
dword unknown (usually 0, 1 or 2 on samples i checked)

[steve-m]

QUOTE (DexX @ Nov 3 2006, 22:24)

For the life of me, i cannot find any position data for the street sign text. i've checked everything in the IPL, IDE, binary ipl, cull info, collision info, the models' dff and txd, nada. I doubt it is scripted, but it wouldnt hurt to confirm that. last stop is the exe. that seems unlikely, considering every other facet of the sign text is stored externally, but i'm not sure what else is left to check.

Erm, what about the 12 byte position data before the entry type ID?

I've created several articles for the wiki, notably RenderWare binary stream file, List of RW section IDs and 2dfx and started moving some of the RW file info over. Would be great to get some help with this, just use the existing articles as templates.

[DexX]

QUOTE (steve-m @ Nov 4 2006, 18:08)

Erm, what about the 12 byte position data before the entry type ID? I've created several articles for the wiki, notably RenderWare binary stream file, List of RW section IDs and 2dfx and started moving some of the RW file info over. Would be great to get some help with this, just use the existing articles as templates.

thats what happens when i get too involved in what i'm doing, and stop paying attention to basic details. Yes, those coords work just fine, thank you
On that note however, the coords are world coordinates, and are NOT relative to the object! here i've resized the text, and moved it from -1907 (X axis) to -1900.


i'll try adding text to a new object, and edit this post with results. I'll look into the wiki as well.
Edit: Here you go; new map, new object, new text, everything. 2d text is no longer an issue.

[steve-m]

Hehe, yea, sometimes the solution is so easy that you can't see it. Good work.

Since it uses absolute coords one could as well just create one dummy object holding the texts for a whole map. Oh, and did you play with the rotation yet? Since this uses Euler angles, it would be interesting to know in which order they are applied. And are there any other special characters except the arrows?

[Quadropheniac90]

I'm not sure if this is ontopic, but why when I import a VC DFF in Max, do most of the roads have their nighttime vertex colors instead of daytime. The same for the Police Dept. with the interior on the first island.

I ask here because maybe RW Analyze would show me info on that. Is this true? If not, why does this happen? It's annoying as I would have to have a go at manually fixing all road DFFs.

EDIT: I forgot to say I'm converting those DFFs to SA. I already converted everything to SA, but the colors of those roads are just not good.

[steve-m]

What do you mean? VC DFFs only have one set of vertex colors. Might be a problem with the exporter.

[Quadropheniac90]

I'll try to explain better:

I import a VC IPL, I select them all and add the Vertex Paint modifier to it. I select the shaded option on the modifier. Now I see their vertex colors. But the ones of the roads look like they're the colors they have at night. It might be something the VC engine handles differently, since it's just the roads and 1 building that are so dark.

If you still don't get me, I'll post a pic.

[DexX]

CODE

0253F2F3=Unknown 4 [R*]

I actually found this section used; c*nthouse.dff (u, not *), its under the extension of the atomic. No idea what the data does, but it is actually used at least once..

[steve-m]

QUOTE (DexX @ Dec 11 2006, 11:52)

CODE 0253F2F3=Unknown 4 [R*] I actually found this section used; c*nthouse.dff (u, not *), its under the extension of the atomic. No idea what the data does, but it is actually used at least once..

unknown != unused But indeed, 0x253F2F3 is the only one of the unknown sections that's actually used by SA. It's size is always 4 byte, and the content is 0x53F2009A for all the vehicle parts, but can also be 0x53F20098 or 0x53F2009C (see below).

Here's a list of files that use this section, content in brackets if not 0x53F2009A.

QUOTE (gta3.img)

bbb_lr_slv1.dff, bbb_lr_slv2.dff, bnt_b_sc_l.dff, bnt_b_sc_m.dff, bnt_b_sc_p_l.dff, bnt_b_sc_p_m.dff, bnt_lr_slv1.dff, bnt_lr_slv2.dff, bntl_b_ov.dff, bntl_b_sq.dff, bntr_b_ov.dff, bntr_b_ov.dff, bntr_b_sq.dff, casroyale01_lvs.dff (0x53F2009C), casroyale02_lvs.dff (0x53F2009C), casroyale03_lvs.dff (0x53F2009C), casroyale04_lvs.dff (0x53F2009C), c*nte_roads81.dff (0x53F20098), exh_a_f.dff, exh_a_j.dff, exh_a_l.dff, exh_a_s.dff, exh_a_st.dff, exh_a_u.dff, exh_b_l.dff, exh_b_m.dff, exh_b_s.dff, exh_b_t.dff, exh_b_ts.dff, exh_c_f.dff, exh_c_j.dff, exh_c_l.dff, exh_c_s.dff, exh_c_st.dff, exh_c_u.dff, exh_lr_bl1.dff, exh_lr_bl2.dff, exh_lr_br1.dff, exh_lr_br2.dff, exh_lr_rem1.dff, exh_lr_rem2.dff, exh_lr_slv1.dff, exh_lr_slv2.dff, exh_lr_sv1.dff, exh_lr_sv2.dff, exh_lr_t1.dff, exh_lr_t2.dff, fbb_lr_slv1.dff, fbb_lr_slv2.dff, fbmp_a_f.dff, fbmp_a_j.dff, fbmp_a_l.dff, fbmp_a_s.dff, fbmp_a_st.dff, fbmp_a_u.dff, fbmp_c_f.dff, fbmp_c_j.dff, fbmp_c_l.dff, fbmp_c_s.dff, fbmp_c_st.dff, fbmp_c_u.dff, fbmp_lr_bl1.dff, fbmp_lr_bl2.dff, fbmp_lr_br1.dff, fbmp_lr_br2.dff, fbmp_lr_rem1.dff, fbmp_lr_rem2.dff, fbmp_lr_slv1.dff, fbmp_lr_sv1.dff, fbmp_lr_sv2.dff, fbmp_lr_t1.dff, fbmp_lr_t2.dff, flamingo04_lvs.dff (0x53F2009C), flamingo05_lvs.dff (0x53F2009C), hydralics.dff, lawroads_law04.dff (0x53F20098), lgt_b_rspt.dff, lgt_b_sspt.dff, lod_vbg_fir_co.dff (0x53F20098), lodalibur03_lvs.dff (0x53F2009C), misc_c_lr_rem1.dff, misc_c_lr_rem2.dff, misc_c_lr_rem3.dff, nto_b_l.dff, nto_b_s.dff, nto_b_tw.dff, rbmp_a_f.dff, rbmp_a_j.dff, rbmp_a_l.dff, rbmp_a_s.dff, rbmp_a_st.dff, rbmp_a_u.dff, rbmp_c_f.dff, rbmp_c_j.dff, rbmp_c_l.dff, rbmp_c_s.dff, rbmp_c_st.dff, rbmp_c_u.dff, rbmp_lr_bl1.dff, rbmp_lr_bl2.dff, rbmp_lr_br1.dff, rbmp_lr_br2.dff, rbmp_lr_rem1.dff, rbmp_lr_rem2.dff, rbmp_lr_sv1.dff, rbmp_lr_sv2.dff, rbmp_lr_t1.dff, rbmp_lr_t2.dff, rf_a_f.dff, rf_a_j.dff, rf_a_l.dff, rf_a_s.dff, rf_a_st.dff, rf_a_u.dff, rf_b_sc_r.dff, rf_c_f.dff, rf_c_j.dff, rf_c_l.dff, rf_c_s.dff, rf_c_st.dff, rf_c_u.dff, rf_lr_bl1.dff, rf_lr_bl2.dff, rf_lr_sv1.dff, rf_lr_sv2.dff, sm_fir_copse1.dff (0x53F20098), sm_fir_tallgroup.dff (0x53F20098), spl_a_f_r.dff, spl_a_j_b.dff, spl_a_l_b.dff, spl_a_s_b.dff, spl_a_st_r.dff, spl_a_u_b.dff, spl_b_bab_m.dff, spl_b_bar_l.dff, spl_b_bar_m.dff, spl_b_bbb_m.dff, spl_b_bbr_l.dff, spl_b_bbr_m.dff, spl_b_mab_m.dff, spl_b_mar_m.dff, spl_c_f_r.dff, spl_c_j_b.dff, spl_c_l_b.dff, spl_c_s_b.dff, spl_c_st_r.dff, spl_c_u_b.dff, stereo.dff, vbg_fir_copse.dff (0x53F20098), vgnlowbuild236.dff (0x53F2009C), wg_l_a_f.dff, wg_l_a_j.dff, wg_l_a_l.dff, wg_l_a_s.dff, wg_l_a_st.dff, wg_l_a_u.dff, wg_l_b_ssk.dff, wg_l_c_f.dff, wg_l_c_j.dff, wg_l_c_l.dff, wg_l_c_s.dff, wg_l_c_st.dff, wg_l_c_u.dff, wg_l_lr_bl1.dff, wg_l_lr_br1.dff, wg_l_lr_rem1.dff, wg_l_lr_rem2.dff, wg_l_lr_slv1.dff, wg_l_lr_slv2.dff, wg_l_lr_sv.dff, wg_l_lr_t1.dff, wg_r_a_f.dff, wg_r_a_j.dff, wg_r_a_l.dff, wg_r_a_s.dff, wg_r_a_st.dff, wg_r_a_u.dff, wg_r_b_ssk.dff, wg_r_c_f.dff, wg_r_c_j.dff, wg_r_c_l.dff, wg_r_c_s.dff, wg_r_c_st.dff, wg_r_c_u.dff, wg_r_lr_bl1.dff, wg_r_lr_br1.dff, wg_r_lr_rem1.dff, wg_r_lr_rem2.dff, wg_r_lr_slv1.dff, wg_r_lr_slv2.dff, wg_r_lr_sv.dff, wg_r_lr_t1.dff, wheel_gn1.dff, wheel_gn2.dff, wheel_gn3.dff, wheel_gn4.dff, wheel_gn5.dff, wheel_lr1.dff, wheel_lr2.dff, wheel_lr3.dff, wheel_lr4.dff, wheel_lr5.dff, wheel_or1.dff, wheel_sr1.dff, wheel_sr2.dff, wheel_sr3.dff, wheel_sr4.dff, wheel_sr5.dff, wheel_sr6.dff

QUOTE (gta_int.img)

biglashadow.dff (0x53F20098), bigniceveghotel.dff (0x53F20098), bihotelshad.dff (0x53F20098), chinafurn1.dff (0x53F20098), chinafurn2.dff (0x53F2009C), countrysavehouse.dff (0x53F20098), c*ntbits.dff (0x53F20098), c*nthouse.dff (0x53F20098), genmotel2_sv.dff (0x53F20098), genmotel2sh_sv.dff (0x53F20098), genmotel_sv.dff (0x53F20098), genmotelfurn_sv.dff (0x53F20098), hotelgen_sv.dff (0x53F20098), immy_clothes_sv.dff (0x53F20098), imy_roomfurn12_sv.dff (0x53F20098), kb_bed_test2_sv.dff (0x53F20098), kit_cab_washin_sv.dff (0x53F20098), labigsavehouse.dff (0x53F20098), labihalfhouse.dff (0x53F20098), lamidshadfloor.dff (0x53F20098), lamidshadflr.dff (0x53F2009C), lasmall1_sv.dff (0x53F20098), lasmallfurn_sv.dff (0x53F20098), med_dinning_2_sv.dff (0x53F20098), midvegsavehouse.dff (0x53F20098), mrk_bed02_sv.dff (0x53F20098), newhouse1.dff (0x53F20098), plant_pot_3_sv.dff (0x53F20098), savelamid.dff (0x53F20098), svc*ntflorday.dff (0x53F20098), svlabigbits.dff (0x53F20098), svlabigkitchshad.dff (0x53F2009C), svlamidshad.dff (0x53F2009C), svlasmshad.dff (0x53F20098), svmidsavebits.dff (0x53F20098), svrails.dff (0x53F20098), svsfmdshadflr1.dff (0x53F2009C), svsfsmshad.dff (0x53F20098), svsfsmshadfloor2.dff (0x53F2009C), svvgmdshadfloor.dff (0x53F20098), svvgmedhoose.dff (0x53F20098), tr_man_glass.dff (0x53F20098), tr_man_main.dff (0x53F20098), tr_man_main_tr.dff (0x53F20098), tr_man_pillar.dff (0x53F20098), vegashotel_sv.dff (0x53F20098)

And btw, the documentation for the Texture Native Struct section (used in TXDs) is pretty much complete now, including tons of flags.

[Aschratt]

(IMPORTANT... I think xD)

The Last Flag for Type 0 (Lights) in 2dfx section only consists of 2 Bytes and seems to be Of Type UInt16 or Int16 (But I Think UInt13).

I found 3 Values for it till now: 0, 100, 25600.
It seems to be some kind of additional Flags.
Maybe it also can be some Index to an address in Mesh Extension Section. Dunno. My decoding skills are not very high ^^.

Greetz!

[DexX]

QUOTE (steve-m @ Dec 11 2006, 14:01)

QUOTE (DexX @ Dec 11 2006, 11:52) CODE 0253F2F3=Unknown 4 [R*] I actually found this section used; c*nthouse.dff (u, not *), its under the extension of the atomic. No idea what the data does, but it is actually used at least once.. unknown != unused But indeed, 0x253F2F3 is the only one of the unknown sections that's actually used by SA. It's size is always 4 byte, and the content is 0x53F2009A for all the vehicle parts, but can also be 0x53F20098 or 0x53F2009C (see below). Here's a list of files that use this section, content in brackets if not 0x53F2009A. <snip>

figured out more of what this does.

Unknown Effect: 0x53F20098
vehicle upgrades and cutscene objects: 0x53F2009A
buildings with reflection map somewhere, but not always: 0x53F2009C

After looking in the exe, these seem to be the only 3 types defined. the use seems to be to determine which of the custom R*-made rendering pipelines to use, instead of the default Rw ones. So for example, by putting the section 0x53F2009A section in, we can have specular lighting on map objects, and not just vehicles. For vehicles and vehicle upgrade pieces there are actually 2 pipelines, that are very similar, but not exactly the same. But it explains the reflection differences on upgrade objects that have materials with a non-uv2 reflection map.

Anyway, Kam's script actually adds this section, if you export you the object as an upgrade piece, but i don't think there was ever a thorough documentation of what the section did. until now

Example of spec lighting on a static map object:


i'm still trying stuff, will edit post if i find anything else interesting.

Edit; Just like the vehicles, spec is only cast from one light, which is not updated, ever. it's a light that is used only for spec, is and is not linked to anything in the game, even the sun. So headlights for example, will not produce a specular hilight...

Note also, the reflection map on the sphere is screwed. This is almost amusing, because on types 0x53F20098 and 0x53F2009C, the reflections are projected almost perfectly..


The material that i did all testing with use a cubic reflection map, both material extensions (on Kam's material, in max) and a specular level of 50. No asi files or any 3rd party hacks were in use although after looking at these results, that should probably change

Edit 2;
same as above, but with spec lighting asi (included my cubemap mod) installed, producing specular hilights from every light around the object;


edit 3;
A correction; 0x53F2009A forces the use of the vehicle material/pipeline
(not a simliar pipeline, but the exact same one, although very similar code does still exist elsewhere, for unknown reasons...). case in point, fixing the reflections on one, fixes the other (truck and sphere);

[Labiloute]

QUOTE (steve-m @ Sep 3 2005, 02:23)

Also, do you have more information about the 2dfx light, such as what parameter defines whether they are only on at night, or whole day?

Sorry for the big bump,

I work on a mod with dexx tool, all my added lights work perfectly but only the night. I tried to use a d3d9.dll let me turn on off engine nos and lights but, the thing is only original lights are on. Any of my new 2dfx lights added work on the day with that hook, only the night :s

Is there a byte allow me to change the value to let me turn on new 2dfx lights and original lights the whole day when i use the d3d9.dll mod ?

Thanks and sorry for my poor english.