[REL|Tool] RW Analyze

[jcab42 0]

I'm catching on now. Just so you you know why I was confused, the pre-lighting that I ws using was the "pre-lighting" checkbox, not the "vertex color prelighting" checkbox. (see pic)

 

http://www.mods4us.net/jcab42/pics/max1.gif

 

And when I open the resulting DFF with RW Analyze and go to the "stuct" section under "geometry" then this is what I see:

 

http://www.mods4us.net/jcab42/pics/rwanalyze1.gif

 

Now I realize that the simple pre-light actually turns on vertex pre-light on full bright white for every single vertex (schroll down - color info). So now that I'm a bit more in the loop, here's my revised request: could you give us the ability to alter those entries? Like allow us to change the yes's to no's (and vise-versa) and even the ability to add, take away, and change the color info for each vertex? Hope it's not too much of a PITA. Thanks.

 

And getting rid of extras like normals, extensions, material effects (espectial alphas which are of no use in GTA since alphas are controlled by the TXD), and all other data that is useless to GTA, if you could make it so RW Anylize strips it all off then that would be stupendous.

[Opius 9]

But... wait. Aren't normals how Vice figures out how to do back-of-face culling?

 

That is all.

[jcab42 0]

are you talking about 2-sided faces? You know illspirit has a nice tut on his webpage that shows you how to get two sided faces in VC, and I can say from experience that it doesn't matter whether you have the normals checked or not.

 

I just made a 2-sided face fix for an LC (landSW) fence and to test the theory I made a DFF with normals checked and another without normals. So far my testing indicates no difference. Here's the two files and the location of the fence if anyone wants to help me test it:

 

indsub_gate03(WithNormals).zip

indsub_gate03(WithoutNormals).zip

 

http://www.kostelecky.com/craig/jcab5.jpg

 

edit: oh wait, back-of-face culling is when you don't see back of a 1-sided face? Guess it would help if I knew all the terminology. Well as Steve said in the following post, normals don't matter for 1-sided faces either.

Edited August 9, 2004 by jcab42

[steve-m 24]

 

But... wait. Aren't normals how Vice figures out how to do back-of-face culling?

Apparently not, since NONE of VC's model files except peds and vehicles have normals! Backface culling is quite simple, you don't need normals for that. A triangle has 3 vertices, and the order in which these 3 vertices (or their indices) are listed defines what is it's front.

 

 

could you give us the ability to alter those entries? Like allow us to change the yes's to no's (and vise-versa) and even the ability to add, take away, and change the color info for each vertex? Hope it's not too much of a PITA. Thanks.

You could change all that using a hex editor (double click on the section), if you know what you're doing.

The flags (yes and nos) just tell the parsing program what is contained in that section. If you set prelit to no, you also have to remove all the vertex colors; if you set normals to no, you have to remove the normals, or it will crash.

And believe me, you don't want to edit the vertex color of hundreds of vertices manually, especially since you don't know which vertex is which...

 

 

And getting rid of extras like normals, extensions, material effects (espectial alphas which are of no use in GTA since alphas are controlled by the TXD), and all other data that is useless to GTA, if you could make it so RW Anylize strips it all off then that would be stupendous.

Getting rid of normals - yes. But try deleting those (even empty) extensions and stuff - you will see VC crashes without them. The engine is not very tolerant. If you find something that can be deleted without problems, let me know.

 

 

are you talking about 2-sided faces? You know illspirit has a nice tut on his webpage that shows you how to get two sided faces in VC, and I can say from experience that it doesn't matter whether you have the normals checked or not.

To get 2-sided faces you either set a flag for that material (like explained in Illy's tut) or you select the faces, copy them, and flip them around. Of course the latter one eats up more space and performance, but you'll need it e.g. for characters, since there the 2-sided flag doesn't work.

[jcab42 0]

I've done alot of testing, and now I know what is causing my buggy DFF's. It's the reflection texture. Somehow if you add the reflections yourself it works fine, but sometimes Zmod spontaniously adds chrome.bmp as the reflection texture, and that causes all kinds of problems. I don't know what the difference is. The problems include not openable in Zmod, texture loss in Zmod, texture loss in moomapper, and the more buggy dff's you have, the quicker you can hit the gta3.img crash. Fortuanatly the fix is super easy. All you have to do is uncheck the reflection texture in either Zmod or 3ds Max. No need to feed it through RW Analyze, although RW Analyze is very handy for identifying buggy DFF's: the buggy parts will show up as red dot entries.

 

Steve: I still would love to at least have the ability to turn pre-light on and turn on all vertices to full 255's, just like 3ds Max does with the pre-light checkbox. Not such a great use of vertex pre-light, but at least it saves people from having to feed the DFF trough Zmod and Max to turn it on. Besides, zlot of modders out there don't have Max. You could make it a simple "pre-light" command instead of making every vertex editable.

 

Also, and this is more important to me, I would love it if you could figure out a way to upgrade 3.3 files to 3.4 as I think I found a use for it. I did try the function in it's current state and as I'm sure you already know, it looks alot like the 3.4 DFF's looked in kcow's old mapper, faces all out of place.

 

Other than that I've been finding this program to be totally awesome. When I get some free time I'll have to write a tut on how to use RW Analyze to bring unopenable DFF's back from the dead.

[DexX 47]

My apologies for being so late jcab,

 

Also, and this is more important to me, I would love it if you could figure out a way to upgrade 3.3 files to 3.4 as I think I found a use for it. I did try the function in it's current state and as I'm sure you already know, it looks alot like the 3.4 DFF's looked in kcow's old mapper, faces all out of place.

What use would that be?

 

The reflections change format several times, it differs for sure between 3.0 (max 3), 3.3, 3.4 (zmodeler export) and 3.6-3.7 (max 5, 6). Vice will recognize reflections from 3.0 and 3.3-3.4, but not 3.6-3.7 RWA, will not properly resave the reflections for 3.0. Check that, it is properly saving it, but there some funky stuff happening with reflections in that version anyway, the header size for the reflection maps is f*cked or something. steve can explain it better than i can.

 

Other news, and the actual reason im posting here - i dont think you can use reflection maps on characters / actors / players. Why would i anyway? I wanted to make a robot or cyborg-like creature, that had shiny metal limbs. I added the reflection map to the dff as perfectly as i can tell, and gta still wont use it. ive gotten white characters, but thats it.

 

Also, there might be other uses for vertex illumination, if they *could* become editable - they work on cars, so you could add prelighting to vehicles, in a non-textured way. Ive done this via exporting from max 6 (see the max r3 dff exporter topic, and do some searches, for max 6 dff availability) and i do beleive it may have a practical application.

[jcab42 0]

It's not so important to me any more but the reason I wanted to be able to upgrade from 3.3 to 3.4 is because 3.4 handles transparencies better. I was trying to figure out a way to fix the GTA:LC Easy Credit Auto glitch without having to create a second revision model. As it is now you either get culling from the breakable glass or culling from the non-breakable glass. I could have made the non-breakable glass a new model but that would be yet a second revision for a conversion mod that's already loaded with 'em. I was hoping to find a solution that could possible eliminate all revision models. Of course the append feature would have to work right too.

[DexX 47]

dunno if you got my pm steve, so i'll post these here, since they dont really have any other place anyway..

 

RwLight Struct Definition (type id 0x12), 24 bytes:

float radius/attenuation

float (0-1.0) light color red

float (0-1.0) light color green

float (0-1.0) light color blue

float(?) spotlight falloff (dont know how its calculated)

word always "3"

word light type, 02 is Skylight, 03 is Directional light, 80(hex) is an Omni light, 81(hex) is Spotlight

 

0253F2FC (SA RefMat) Definition;

float (0-1.0) reflection map image intensity red (the refmap this refers to, is defined in the material its a part of)

float (0-1.0) refmap intensity green

float (0-1.0) refmap intensity blue

float (0-1.0) refmap intensity alpha

float refmap image multiplier. set to 100, and the refmap is at full power WITH the spec

dword always 00

 

0253F2F6 (SA SpecMat) Definition;

float (o-1.0) specular reflection level

string "vehiclespecdot64" - i dont know if this can be changed, in every material that uses it, its the same though.

dword string terminator, always 00

dword unknown, always 00

 

and alter your re_secs.ini, miscellaneous section to this, so they dont read as "unknown"

0253F2F6=SA SpecMat

0253F2FA=SA Appended COL

0253F2FC=SA RefMat

[steve-m 24]

Yep, I got them, thanks a lot. Will update ASAP.

[DexX 47]

w00t! gta:sa 2dfx lights are stored per model now. heres the pertinent info-

 

 

section type: 0x0253f2f8 (GTA Light)size: 68(hex) bytes total for the first light, counting the 4 bytes at the begining as the count. each additional light is 64h.int lightcountfloat x pos (position relative to parent!)float y posfloat z posdword unknowndword unknownbyte color rbyte color gbyte color bbyte unknown always C8 (200d)dword unknownfloat light radius (area it actually illuminates)dword unknownfloat corona 1 image sizefloat corona 2 image sizestring corona image 1 nameunknown datastring corona image 2 nameint light type ? (flashing, night, day, etc - exact parameters unknown atm)dword unknown

 

 

updated rw_secs.ini

 

# Miscellaneous: ----------------------F21E=ZModeler Lock0253F2F6=SA SpecMat0253F2F8=GTA Light0253F2F9=GTA Unknown0253F2FA=SA Appended COL0253F2FC=SA RefMat0253F2FD=BinMesh Ext0253F2FE=Frame

 

 

still don't know what GTA Unknown (0x0253f2f9) is exactly, but it appears to have one dword entry for every face on the corresponding geomtry, preceded a by an unkown int for the first 4 bytes of the section.

 

BinMesh Ext (0x0253f2fd) seems to just be a 00 integer. it adds 4 bytes to the size, but thats it as far as i know atm.

 

GTA lights can be found in some map objects, most of the Helicopters, the baggage car. theres probably a lot more, but those are the only ones i've checked so far.

[steve-m 24]

Just been looking at the 2dfx section (0x0253F2F8) and found some interesting stuff.

 

The section starts with a 4 byte int, which is the number of 2dfx entries. Each entry begins like this:

 

12b - 3*float - Position Vector (xyz)4b  - int     - Entry Type4b  - int     - Data Size

 

"Entry Type" defines the type of the 2dfx entry, and "Data Size" the number of bytes that follow the first 20, until the next entry starts.

 

Entry Type 0 - Light (80 bytes)

 

4b  - 4*byte - RGBX, where X = 200d4b  - float  - draw distance4b  - float  - outer range4b  - float  - size4b  - float  - inner range4b  - 4*byte - parameters (unknown)1b  - ?      - padding???24b - string - corona texture name24b - string - shadow texture name3b  - ?      - padding???4b  - float  - unknown

 

 

Entry Type 1 - Particle Effects (24 bytes)

 

24b - string - particle effect name (entry in effects.fxp)

 

 

Entry Type 7 - Street Signs (88 bytes)

 

20b - 5*float - various unknown coordinates2b  - word    - number of lines used64  - string  - sign text, 16 byte per line2b  - ?       - padding

 

The lines can start with arrows, such as '<', '^' and '>'; also '_' is used instead of a whitespace. Example from c*nteroads_58.dff:

 

^_Martin_Bridge_^_B/Berry_Acres_<_Panopticon____________________

 

 

- - - - -

 

My own updates to RW_Secs.ini:

 

# Miscellaneous: ----------------------F21E=ZModeler Lock# R*^ Custom Defs: --------------------0253F2F0=Unknown 1 [R*]0253F2F1=Unknown 2 [R*]0253F2F2=Unknown 3 [R*]0253F2F3=Unknown 4 [R*]0253F2F4=Unknown 5 [R*]0253F2F5=Unknown 6 [R*]0253F2F6=Specular Material [R*]0253F2F7=Unknown 8 [R*]0253F2F8=2dfx [R*]0253F2F9=Night Vertex Colors [R*]0253F2FA=Collision Model [R*]0253F2FB=Unknown 12 [R*]0253F2FC=Reflection Material [R*]0253F2FD=Mesh Extension [R*]0253F2FE=Frame [R*]0253F2FF=Unknown 16 [R*]

 

Dunno if any of the unknowns are used.

0253F2F9 are the vertex colors used by SA at night, this is implemented in my Map Viewer since version 0.5 alpha 3. The first value seems to be a float, not sure about that yet.

0253F2FD looks like an extra mesh, with lots of different data, still have to look into that.

Edited June 17, 2006 by steve-m

[DexX 47]

 

Entry Type 7 - Street Signs (88 bytes)

CODE

20b - 5*float - various unknown coordinates

2b  - word    - number of lines used

64  - string  - sign text, 16 byte per line

2b  - ?      - padding

ho ho ho! the light 2dfx work on vehicles, maybe the signs can be adapted too (delivery trucks?)

i looked at a few DFF's for the 2dfx text (that i just quoted) and didnt find any. what files specificly have you run across that have it?

[steve-m 24]

I'm not sure, I couldn't even get the texts to work on static map objects, no matter what I tried. Dunno if it's somehow hardcoded to project only on the default signs. It's quite hard to test, since all of them are placed via binipl files.

 

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? I copied the data of a streetlamp, but need it to be on the whole day. And any idea why the texture names are shifted one byte?

[tonywob 1]

Although this may be incorrect, the first unknown parameter in the lighting list is always 7 for traffic lights, and normally 0 for other objects.

 

 

[Suction Testicle Man 38]

I am unpinning this to help resolve the clutter in this forum. It is listed here (a topic left pinned), so we shouldn't have trouble finding it again.

 

 

[BMWPower 0]

Can i unlock dff with this tool?

[GT-1 2]

Yes, though no-one is going to tell you how... thats just edging towards mod theft, which we don't support.

[AleXXX 2]

Yes, though no-one is going to tell you how... thats just edging towards mod theft, which we don't support.

I don't think so, because this tool indentificate Zmodeller Lock.

[oCain 2]

Bla!

I was wonderin about the 'cigar.dff', 'cause there is an ParticleFX included.

So, it's an 2DFX section, too. But much shorter...

 

int = Fx-Count

3*Float = Coords

int = Number (1)

int = Number (24)

String = Fx-Name

 

...i've tryed to re-export the cigar.dff with KAMS and include the 'SmokeFX-Section' into it.

But now it's ain't showin' up inGame.

There actually more difference between my dff and the original one, some Flags etc.

But the main thing is the 'Facetype'...

-Original='Triangle Strip'

-Export='TriangleList'

...I don't know, if this does any matter.

Is there anyone out there, who knows more about this thing or maybe did it successfully?

 

Thanx'n'Peace!

 

 

[DexX 47]

 

But now it's ain't showin' up inGame.

well, what isn't showing up ingame, the particle fx, or the cigar model itself? Facetype doesn't matter, its just a different way of storing the geometry data but it still works.

 

If the model isn't showing up, i'm not sure what would cause that right off hand. If its the particle effect that isn't showing up, its because Kam's export script doesn't export SA 2dfx sections at the moment.

[steve-m 24]

Added it to my post above. Maybe I should write something to scan all files for more of those 2dfx types some day. Or is there a list somewhere else already?

[xmen 3]

hi buddies some peoples telling that you can add lights by RW Analyze but i dont how to do that. so some one tell about it , im new in RW Analyze

[oCain 2]

 

But now it's ain't showin' up inGame.

well, what isn't showing up ingame, the particle fx, or the cigar model itself? Facetype doesn't matter, its just a different way of storing the geometry data but it still works.

 

If the model isn't showing up, i'm not sure what would cause that right off hand. If its the particle effect that isn't showing up, its because Kam's export script doesn't export SA 2dfx sections at the moment.

Oh...the model isn't showing up and the particle FX, too.

I've export it without any Dummy, Light or something like that and include the 2DFX-Section with the RW-Analyzer/Hex-Editor...maybe I did something wrong, so I will try it again...tomorrow.

Thanx!

 

 

[dustcrazy 1]

Ingore me if I'm wrong, but on VC theres a billboard type text above clothes that say what they are.

[steve-m 24]

Did anyone ever start on a SA 2dfx editor (for lights, signs and such)?

[steve-m 24]

Apparently not...

 

Anyway, I've let a tool do some research for me to find the missing 2dfx types. It seems the game only uses 0, 1, 3, 7, 8 and 9.

 

Type 3, 56 bytes, example: blck_jack.dff

Has to do with black jack cards, contains the object(?) name "PEDCARD".

 

Type 8, 4 bytes, example: kb_bandit_u.dff

Position & index of slot machine wheels (scripted objects?).

 

Type 9, 12 bytes, example: carter-column02.dff

No idea. Used quite often and in large ammounts per file (stadium_sfse.dff uses 192 of them!).

Maybe simple lights that use the default corona/shadow textures?

 

(all examples are files from gta_int.img)

 

The full list can be found here: 2dfx.txt

Lists ammount and types of 2dfx entries in correct order per file. Only gta3.img and gta_int.img; those in player.img don't use the 2dfx section.

[DexX 47]

The full list can be found here: 2dfx.txt

Lists ammount and types of 2dfx entries in correct order per file. Only gta3.img and gta_int.img; those in player.img don't use the 2dfx section.

very handy list, but what type of text formatting did you use? its only readable in firefox, not notepad

 

I know you asked that same question in Paradox's street sign topic - imo, you should incorporate 2dfx stuff into rwanalyze, as opposed to a standalone program. regardless, there definetily needs to be some way to get this stuff onto objects, short of the current cumbersome methods.

 

As for lights, i think we have most of it down, with the exception of the light type, and i've got a bit of insight into that, which i'll post once i confirm it.

[Chris_topher 0]

WTH???!!?!??!?! I CANT DOWNLOAD IT?? Please give any alternate link..

[Ryder35 0]

so cool that prog i unlock all dff with that SA to just fine the text line

 

 

steve-m.com you can download the program

 

see ya

Edited October 11, 2006 by ryder 35

[steve-m 24]

WTH???!!?!??!?! I CANT DOWNLOAD IT?? Please give any alternate link..

http://www.steve-m.com/?page=2&ID=21&act=details