[REL|Tool] RW Analyze

[DexX]

 

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?

Edited October 18, 2006 by DexX

[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]

 

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]

 

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.

Edited November 6, 2006 by teun.steenbekkers

[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]

 

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]

 

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.

 

 

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

 

 

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!

Edited May 21, 2007 by Aschratt

[DexX]

 

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]

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.

[ShitpostSuckDickMyShit]

nice

Edited December 18, 2017 by ShitpostSuckDickMyShit

[The Hero]

This is not the right topic to bump, especially after 8 years. But anyway, here you go: http://www41.zippyshare.com/v/16LfNTXd/file.html

Edited December 18, 2017 by The Hero

[ShitpostSuckDickMyShit]

ok

 

thanks for unlock my dff

Edited December 22, 2017 by Crokey

[Leinad]

How can I fix this?

 

[Nmax7]

Solution for Locked DFF's and it works

[AXIS Motion Studio]

On 2/12/2019 at 5:45 PM, Leinad said:

How can I fix this?

 

Did you find any way to convert the model

[AXIS Motion Studio]

 

i have a bunch of dff file now i want to convert into any RW version which is possible to import in 3Ds Max or blender...

 

 

Somebody know anything about it please reply

 

sorry for my bad english

[The Hero]

It's not a valid renderware stream file. Could be compressed or something.

[Muzzarino]

Certain sections need to be viewable as it makes it harder for sections to be identifiable and edited such as the 2d scene.