[info]SWBF MSH Forensics
Here is a fun one. I'm revising the code for the SWBF_MSH_INFO tool and have developed a method of selectively or recursivly editing or scanning all files in a directory and sub-directories. This thread will contain the results of scanning the collective assets for SWBF and SWBF2. As a bonus, I will also be looking into the "The Clone Wars" assets, as they share the same MSH format with different conventions.
The intent behind releasing this information is promote research on this format. A lot has been done already, but there are still big gaps in information. I can only uncover one piece at a time and hope that if anyone else is exploring it, that this info will help.
Other reports may follow. If you have an idea of what may be usefull, let me know.
SWBF MSH Materials
This first report(in the zip attached to the end of this post) is simply a list of every material used in every msh that shipped with the mod tools distributions for BF1 and 2.
I intend to use this information to identify render type indexes and further requirements for those render types. I though it might come in handy for others that may be researching these materials.
The report is an OpenOffice spreadsheet, and I will be happy to export it to a cvs, or html file if needed, though I recomend keeping it in spereadsheet format so the columns and rows can be manipulated for analysis.
Each row is a full material.
Every material in every msh is listed, even the animations, so there is a ton of irrelevant and redundant data. It's all included for completeness.
The columns are:
[spoiler]
filename - the name of the file containing the material
NAME - the materials name as it appears in the MSH
-material colors-
-I may have the specular and ambient swapped. Only way to know is to test.
-the color values are derived by multiplying the floating point in the
-msh by 255.
diffuse_red - the red component of the diffuse color
diffuse_blue - the blue component of the diffuse color
diffuse_green - the green component of the diffuse color
unk_1 - used to think this was diffuse alpha, but it's
either "1" or "107374176", so an BF2 has some
diferent values more suited to actually be alpha,
so I don't know.
specular_red - the red component of the specular color
specular_blue - the blue component of the specular color
specular_green - the green component of the specular color
unk_2 - this may be specular alpha, but have not found out
for sure.
ambient_red - the red component of the ambient color
ambient_blue - the blue component of the ambient color
ambient_green - the green component of the ambient color
unk_3 - this may be ambient alpha, but have not found out
for sure.
specular_decay - specular decay value
-render flags-
-These are encoded into the first byte of the ATRB field. simply having a value
-in this column indicate that it's flag is set.
Emissive -
Glow -
Singlesided Transparency -
Doublesided Transparency -
Hardedged Transparency -
Per-Pixel Lighting -
Additive Transparency -
Specular -
-render type-
-this is what I am currently trying to figure out. The indexes are diferent
-from BF1 to BF2.
Render Type - Method used to render the material indicated by an index.
data1 - the data fields contain extra information as required
data2 - by the render type
-textures-
-Not every material has a texture.
TX0D - primary, 'diffuse' texture
TX1D - special purpose texture
TX2D - special purpose texture
TX3D - special purpose texture
Here is a short sample of data:
[spoiler]
[0] 6519 NAME diffuse_red diffuse_blue diffuse_green unk_1 specular_red specular_blue specular_green unk_2 ambient_red ambient_blue ambient_green unk_3 specular_decay Emissive Glow Singlesided Transparency Doublesided Transparency Hardedged Transparency Per-Pixel Lighting Additive Transparency Specular Render Type data1 data2 TX0D TX1D TX2D TX3D
[1] wok_1st_weap_inf_bowcaster.msh Material0 178 178 178 1 255 255 255 1 76 76 76 1 50 0 0 0 wok_1st_weap_inf_bowcaster.tga
[2] wok_inf_wookie.msh _1Shirt0 178 178 178 1 255 255 255 1 76 76 76 1 50 0 0 0
[3] wok_inf_wookie.msh _1Shirt1 178 178 178 107374176 0 0 0 1 76 76 76 1 50 0 0 0 wookie.tga
[4] wok_inf_wookie.msh _1Shirt2 178 178 178 107374176 0 0 0 1 76 76 76 1 50 Doublesided Transparency 0 0 0 wookie.tga
[5] wok_inf_wookie.msh Material0 178 178 178 1 0 0 0 1 178 178 178 1 50 0 0 0 wookieface02.tga
[6] wok_inf_wookie_low1.msh _1Shirt0 178 178 178 1 255 255 255 1 76 76 76 1 50 0 0 0
[7] wok_inf_wookie_low1.msh Material0 178 178 178 1 0 0 0 1 178 178 178 1 50 0 0 0 wookieface.tga
[8] wok_inf_wookie_low1.msh _1Shirt1 178 178 178 107374176 255 255 255 1 76 76 76 1 50 0 0 0 wookie.tga
[9] wok_weap_inf_bowcaster.msh Material0 178 178 178 1 255 255 255 1 76 76 76 1 50 0 0 0 wok_weap_inf_bowcaster.tga
[10] wok_weap_inf_bowcaster.msh Material12 178 178 178 1 255 255 255 1 76 76 76 1 50 0 0 0 all_1st_weap_inf_bowcaster.tga
[11] wok_weap_inf_bowcaster.msh _1Shirt0 178 178 178 1 255 255 255 1 76 76 76 1 50 0 0 0 noIcon.pic
[12] wok_weap_inf_fusioncutter.msh Material0 178 178 178 1 255 255 255 1 76 76 76 1 50 0 0 0 all_weap_inf_fusioncutter.tga
[13] wok_weap_inf_fusioncutter.msh Scene_Material0 178 178 178 1 255 255 255 1 76 76 76 1 50 0 0 0
[14] wok_weap_inf_launcher.msh Material0 178 178 178 1 255 255 255 1 76 76 76 1 50 0 0 0 all_weap_inf_launcher.tga
[15] wok_weap_inf_pistol.msh Material0 178 178 178 1 0 0 0 1 76 76 76 1 50 0 0 0 all_weap_inf_pistol.tga
[16] wok_weap_inf_pistol.msh _1Shirt0 178 178 178 1 255 255 255 1 178 178 178 1 50 0 0 0 noIcon.pic
[17] wok_weap_inf_thermaldetonator.msh _1Shirt0 178 178 178 1 255 255 255 1 178 178 178 1 50 0 0 0 noIcon.pic
[18] wok_weap_inf_thermaldetonator.msh Material1 178 178 178 1 0 0 0 1 76 76 76 1 50 Emissive 0 0 0 all_weap_inf_thermaldetonator.tga
[19] wok_weap_inf_thermaldetonator.msh Material3 178 178 178 1 0 0 0 1 76 76 76 1 50 Emissive 0 0 0 com_weap_inf_grenadethermal.tga
The columns get a little wonky on the flags part. That's a byproduct of the way OOo saves fixed width files. The spreadsheet and cvs have it more clearly seperated.[/spoiler]
This is all part of further research and some is speculative. As always, all my work is geared toward SWBF 1 compatability.
If you have insight, speak up and we'll see how the data likes it.
-edit
The report, in excel xls format is attatched to this post (http://www.swbfgamers.com/index.php?topic=6091.msg63543#msg63543), several posts down.
Data on Materials? SWBF1? *DOWNLOADS*. Wait I don't have OpenOffice, *DOWNLOADS THAT AS WELL*.
Quote from: SleepKiller on February 17, 2013, 03:35:08 PM
Data on Materials? SWBF1? *DOWNLOADS*. Wait I don't have OpenOffice, *DOWNLOADS THAT AS WELL*.
heh
OpenOffice a worth-while download. Big, but worth it.
It's just a flat, 3-sheet, no-formula, no-macro spreadsheet, so I can save it in another format if you like.
Nice, looks like I need to download open office as well.
Could you save it as excel spreadsheet?
Wait OpenOffice is a big download? lol I didn't even notice I just it the download button and waited a couple minutes. I only bothered to look at the size after you said that.
Now onto the lovely data, looking good. But it is incomplete, you know the byte that transparency goes into? It hold. I'm wondering if we could get that's value added in. Here's an example of why I would like it. It's marked as emissive due to the byte 01 in the slot before renderer type.
1650 bes2_bldg_mall.msh Material15 178 178 178 1 0 0 0 1 76 76 76 1 50 Emissive 0 0 0 bes2_bldg_interior03.tga
Well that can't be right http://dictionary.reference.com/browse/Emissive?s=t (http://dictionary.reference.com/browse/Emissive?s=t). Have you ever seen the main hallway on cloud city emitting anything? What it does appear to do though is force the material to be render without shadows or ambient light/sun light effecting it. Hence why I am interested in what else can go there in SWBF1.
Save in Excel format?, You bet.
Excel xls format attatched to the end of this post.
The render flags are wierd.
I interpereted the flags from Ande's table (http://www.ande.pytalhost.eu/flags.jpg).
[spoiler]The constants I have set up for them are thus:Global Const $cATRB_RENDER_FLAG_none = 0
Global Const $cATRB_RENDER_FLAG_Emissive = 1
Global Const $cATRB_RENDER_FLAG_Glow = 2
Global Const $cATRB_RENDER_FLAG_SinglesidedTransparency = 4
Global Const $cATRB_RENDER_FLAG_DoublesidedTransparency = 8
Global Const $cATRB_RENDER_FLAG_HardedgedTransparency = 16
Global Const $cATRB_RENDER_FLAG_PerPixelLighting = 32
Global Const $cATRB_RENDER_FLAG_AdditiveTransparency = 64
Global Const $cATRB_RENDER_FLAG_Specular = 128
and the ugly code I use to break the byte up:
Local $iFlag = _hex_to_byte(BinaryMid($bData, 1, 1))
If BitAND($iFlag, 1) = 1 Then $aTagData[1] = "Emissive"
If BitAND($iFlag, 2) = 2 Then $aTagData[2] = "Glow"
If BitAND($iFlag, 4) = 4 Then $aTagData[3] = "Singlesided Transparency"
If BitAND($iFlag, 8) = 8 Then $aTagData[4] = "Doublesided Transparency"
If BitAND($iFlag, 16) = 16 Then $aTagData[5] = "Hardedged Transparency"
If BitAND($iFlag, 32) = 32 Then $aTagData[6] = "Per-Pixel Lighting"
If BitAND($iFlag, 64) = 64 Then $aTagData[7] = "Additive Transparency"
If BitAND($iFlag, 128) = 128 Then $aTagData[8] = "Specular"
Yeah, I actually had to write a "hex to byte" function :/
And I'm just now discovering the usefulness of constants, thats why they arent in the "if BitAnd" lines yet.
[/spoiler]
The way that first byte is supposed to work is you add the value of all the desired flags together. The values are aranged so that the value cannot be more than 255.
So, for instance, if both emmisive and glow wer turned on, the value of the first ATRB byte would be 3 (emmissive[1] + glow[2]).
So the flag is there, but since each mesh has many pieces, there may be a small piece somewhere that has the emissive feature.
Or... (theory power, activate) the dev's made an emmisive part of the model to avoid adding a light?
There is a possibility that the flags for bf2 and bf1 are different, but the sequence of the string appearance in the mod tool exe's is consistant across both games.
Hm this calls for testing. I shall report back later.
It's worth noting, that even though specular is listed in the flags, most all the models that have specular have the render type 04 and a TX0D with an alpha channel.
So when it comes down to use a flag, or use a render type, I'm flat lost.
-edit
I thought that the render flag might be depreciated, but since transperancy works that can't be.
Perhaps some of the flags themselves are unused by the engine? (yay, more theories..)
And this is why we should not take tables designed for SWBFII into account in SWBF1.
These models are exactly the same save the texture and another important difference. One has the 01 flag the other does not. The one on the left doesn't in the first image and the one on the right does. Then in the second image both of them have the flag. Which now begs the question what other flags does SWBF1 have?
I agree.
It's worse with the render types as the munger throws "invalid render type" errors on many bf2 types.
The images seem like what emmisive would do. Sort of brighten it up without casting huge amounts of light. I'm going to guess the emmisive power is controlled by either an alpha channel in the texture and/or the ambient color and the unk_* value after it. (I still think I have ambient and specular switched.)
I suspect the list of types and thier order is accurate. The main argument for this is the presence of this list in the same sequence in the ModelMunge.exe. (It's where I took the names from after consulting Ande's page.)
In order for there to be more flags, there would need to be another byte somewhere to store it.
This calls for even more testing. Adding an Alpha channel resulted in no change. Edited the Ambient Colour in the msh no change. Edited the Diffuse Colour no change. So none of those control it.
Ok. I'm down with super testing.
We need a baseline msh to test on. Preferably with only one material to eliminate possible interfering effects.
Then we need to establish a base set of values for each of the fields.
I'd say set all the colors and unk_* fields to zero and go from there.
Of course the render type would need to be set to zero as well as the data1 and data2.
I would replace the texture with a solid white or at least very non detailed image.
Then, the test area. How about the default map created by selecting "new" in bfbuilder.
That would eliminate crazy lighting and possible bleed over from ambiant or emmisive features in the environment.
The texture may need to be varied through testing as some flags may require the alpha channel... (Alphas in Paint.net always give me siezures.) And I suppose a range of alpha would be needed. Perhaps if a grey scale of a zebra print could be used as the alpha channel the pattern would illuminate itself so we could see what high, low and mid settings do.
Also, some effects may be easier to see with no texture applied.
Once everything is zeroed (heh.. Zeroed...) then procedure.
Probably best to do this with all video settings on and set to high as low video settings might block some of the effects.
I'd make several copies of the msh, then edit each in different ways. Place them in zero in a recognizable pattern, munge and screenshot away.
Get out of the game, and organize the screenshots, record findings, and move on to the next test.
...
A potential gotcha.. not all video cards are equal. Some may simply not render the effect, and some may render incorrectly. I think we've seen this before in maps where certain things show up black.
Ok.. I'm gonna play around with this. I needed to do the same to line up the list of render types anyway, but this gets a good test arena set up for it.
-edit
I'm going with yav_bldg_column.msh.
It has 3 materials and a bump map, but I will hex the crazy stuff out, only use one material and not use the .option files.
(I've been playing on Yavin temple lately and have a new appreciation for the obelisks.)
revised tests and method.
Here are my render flag tests. (v2)
There are lots of settings in the msh that can affect how it looks in-game. I'll get to them all eventually, for now, I need to nail down just how much influence the DATA chunk has on the render flag. After that, I need to identify the order and number of render types, then I'll do a small amount of testing on the extents and properties of those types. Then I'll need to know how the DATA chunk affects the render types. By doing this, I'll know how to make my program handle materials instead of guessing or ignoring the DATA colors, like we've been doing for years.
Previously this spot was occupied by some tests where I was comparing the color values in the msh material's DATA chunk. I had encoded the color values incorrectly so I'm re-doing the tests with correct values.
Befor getting to the results, I ran a bunch through with the varied colors with the same results as before in that Zero saw the colors, but the game didn't. Perhaps there is more to it, but since this particular battery is about render flags, I'll design the tests to ignore DATA color values for the now.
I also ommited the sets of models with no alpha channel. They weren't doing anything before and I don't expect then to now.
For each test the columns each have identical settings, except for the render flag.
The color settings are all a nice neutral 128,128,128.
All tests are done with a texture that does have an alpha channel.
Any changes will be indicated.
flag_testing_v2_a baseline
[spoiler]Material Settings:Diffuse Color = 128,128,128
unk_1 = 1
Ambient Color = 128,128,128
unk_2 = 1
Specular Color = 128,128,128
unk_3 = 1
Specular Decay = 50
(https://www.swbfgamers.com/proxy.php?request=http%3A%2F%2Fdl.dropbox.com%2Fu%2F58361588%2FSWBFG%2FProjects%2FFLAG_TESTING%2Fflag_testing_v2_a.png&hash=4b2f9841097e1f6b9310d426921b09de8fd27764)
level - flag_testing_v2_a.rar
src folder - flag_testing_v2_a_src.rar[/spoiler]
notes:
- nothing spectacular. Emissive is emissing, glow isn't doing anything, and specular is very un-specular.
- Shadows don't appear on the surface of the emmisive column. That's interesting. ::)
flag_testing_v2_b unk_1 field
There are 6 discrete values for unk_1 across all the msh materials. (0.4929999709, 0.5419999957, 0.6159999967, 0.6579999924, 1, and 107374176)
Since 4 of them are simularly small and 1 is already in the baseline, I'll do 2 tests (0.4929999709 and 107374176) against all the flags to see what they do.
flag_testing_v2_b1 unk_1 field = 0.4929999709
[spoiler]Material Settings:Diffuse Color = 128,128,128
unk_1 = 0.4929999709
Ambient Color = 128,128,128
unk_2 = 1
Specular Color = 128,128,128
unk_3 = 1
Specular Decay = 50
(https://www.swbfgamers.com/proxy.php?request=http%3A%2F%2Fdl.dropbox.com%2Fu%2F58361588%2FSWBFG%2FProjects%2FFLAG_TESTING%2Fflag_testing_v2_b1.png&hash=6f79ddeec38109d027c51488f9a7992be5df1df7)
level - flag_testing_v2_b1.rar
src folder - flag_testing_v2_b1_src.rar[/spoiler]
flag_testing_v2_b2 unk_1 field = 107374176
[spoiler]Material Settings:Diffuse Color = 128,128,128
unk_1 = 107374176
Ambient Color = 128,128,128
unk_2 = 1
Specular Color = 128,128,128
unk_3 = 1
Specular Decay = 50
(https://www.swbfgamers.com/proxy.php?request=http%3A%2F%2Fdl.dropbox.com%2Fu%2F58361588%2FSWBFG%2FProjects%2FFLAG_TESTING%2Fflag_testing_v2_b1.png&hash=6f79ddeec38109d027c51488f9a7992be5df1df7)
level - flag_testing_v2_b1.rar
src folder - flag_testing_v2_b1_src.rar[/spoiler]
notes:
- well.. identical to nothing at all being changed.
flag_testing_v2_c unk_3 field
unk_2 contains a value of 1 in every msh. It's getting skipped.
unk_3 has 3 different values (0, 0.1000000015, and 1) I'll do the 2 smaller values. 1 is covered in the baseline.
flag_testing_v2_c1 unk_3 field = 0
[spoiler]Material Settings:Diffuse Color = 128,128,128
unk_1 = 1
Ambient Color = 128,128,128
unk_2 = 1
Specular Color = 128,128,128
unk_3 = 0
Specular Decay = 50
(https://www.swbfgamers.com/proxy.php?request=http%3A%2F%2Fdl.dropbox.com%2Fu%2F58361588%2FSWBFG%2FProjects%2FFLAG_TESTING%2Fflag_testing_v2_c1.png&hash=8c05a8117b9b12e20b664e50de1ede1ee53a7d65)
level - flag_testing_v2_c1.rar
src folder - flag_testing_v2_c1_src.rar[/spoiler]
flag_testing_v2_c2 unk_3 field = 0.1000000015
[spoiler]Material Settings:Diffuse Color = 128,128,128
unk_1 = 1
Ambient Color = 128,128,128
unk_2 = 1
Specular Color = 128,128,128
unk_3 = 0.1000000015
Specular Decay = 50
(https://www.swbfgamers.com/proxy.php?request=http%3A%2F%2Fdl.dropbox.com%2Fu%2F58361588%2FSWBFG%2FProjects%2FFLAG_TESTING%2Fflag_testing_v2_c2.png&hash=456a9e90b7fab4e13e55fbca457958a2e907dbe6)
level - flag_testing_v2_c2.rar
src folder - flag_testing_v2_c2_src.rar[/spoiler]
notes:
- more no effect.
flag_testing_v2_d specular decay
I hope this one gets interesting. The field contains a range of numbers from 0 to 300, with the most common one being 50. I'll do 3 test of low, mid and high (0, 150, and 300.)
flag_testing_v2_d1 specular decay = 0
[spoiler]Material Settings:Diffuse Color = 128,128,128
unk_1 = 1
Ambient Color = 128,128,128
unk_2 = 1
Specular Color = 128,128,128
unk_3 = 1
Specular Decay = 0
(https://www.swbfgamers.com/proxy.php?request=http%3A%2F%2Fdl.dropbox.com%2Fu%2F58361588%2FSWBFG%2FProjects%2FFLAG_TESTING%2Fflag_testing_v2_d1.png&hash=453beeffa39b3361ff39151e38284b1dfeeae1df)
level - flag_testing_v2_d1.rar
src folder - flag_testing_v2_d1_src.rar[/spoiler]
flag_testing_v2_d2 specular decay = 150
[spoiler]Material Settings:Diffuse Color = 128,128,128
unk_1 = 1
Ambient Color = 128,128,128
unk_2 = 1
Specular Color = 128,128,128
unk_3 = 150
Specular Decay = 150
(https://www.swbfgamers.com/proxy.php?request=http%3A%2F%2Fdl.dropbox.com%2Fu%2F58361588%2FSWBFG%2FProjects%2FFLAG_TESTING%2Fflag_testing_v2_d2.png&hash=9e1b5fa4ac7004f875fa66af8a50ebeb0935fbce)
level - flag_testing_v2_d2.rar
src folder - flag_testing_v2_d2_src.rar[/spoiler]
flag_testing_v2_d3 specular decay = 300
[spoiler]Material Settings:Diffuse Color = 128,128,128
unk_1 = 1
Ambient Color = 128,128,128
unk_2 = 1
Specular Color = 128,128,128
unk_3 = 1
Specular Decay = 300
(https://www.swbfgamers.com/proxy.php?request=http%3A%2F%2Fdl.dropbox.com%2Fu%2F58361588%2FSWBFG%2FProjects%2FFLAG_TESTING%2Fflag_testing_v2_d3.png&hash=006179a369a15b1215da135594a6d59a417e8491)
level - flag_testing_v2_d3.rar
src folder - flag_testing_v2_d3_src.rar[/spoiler]
notes:
- Nothing. I am dissapointed.
flag_testing_v2_e TX1D (additional textures)
I know that some of the render types require an additional texture to work right. Like bumpmap, environmentmap, ect. Perhaps some of the flags have a simular requirement.
The format of the additional texture is a guess right now. I'll just add a duplicate entry to the already present TX0D. If anything makes a slight change, I'll dig deeper.
There are 4 texture slots used by all 3 games. From the way the render types use them, I know that their 'meaning' is dependant on what requires them, so I will test all 3 of the TX?Ds besides TX0D.
I hope this will affect glow and specular, but I will be happily surprised if it affects per-pixel-lighting.
flag_testing_v2_e1 TX1D
[spoiler]Material Settings:Diffuse Color = 128,128,128
unk_1 = 1
Ambient Color = 128,128,128
unk_2 = 1
Specular Color = 128,128,128
unk_3 = 1
Specular Decay = 50
Added TX1D chunk
(https://www.swbfgamers.com/proxy.php?request=http%3A%2F%2Fdl.dropbox.com%2Fu%2F58361588%2FSWBFG%2FProjects%2FFLAG_TESTING%2Fflag_testing_v2_e1.png&hash=6554f9e9cdd2f427e9ace2d597f44096a4d55189)
level - flag_testing_v2_e1.rar
src folder - flag_testing_v2_e1_src.rar[/spoiler]
flag_testing_v2_e2 TX2D
[spoiler]Material Settings:Diffuse Color = 128,128,128
unk_1 = 1
Ambient Color = 128,128,128
unk_2 = 1
Specular Color = 128,128,128
unk_3 = 1
Specular Decay = 50
Added TX2D chunk
(https://www.swbfgamers.com/proxy.php?request=http%3A%2F%2Fdl.dropbox.com%2Fu%2F58361588%2FSWBFG%2FProjects%2FFLAG_TESTING%2Fflag_testing_v2_e2.png&hash=40fa7d9bdf5544def318455d741b145421f0c703)
level - flag_testing_v2_e2.rar
src folder - flag_testing_v2_e2_src.rar[/spoiler]
flag_testing_v2_e3 TX3D
[spoiler]Material Settings:Diffuse Color = 128,128,128
unk_1 = 1
Ambient Color = 128,128,128
unk_2 = 1
Specular Color = 128,128,128
unk_3 = 1
Specular Decay = 50
Added TX3D chunk
(https://www.swbfgamers.com/proxy.php?request=http%3A%2F%2Fdl.dropbox.com%2Fu%2F58361588%2FSWBFG%2FProjects%2FFLAG_TESTING%2Fflag_testing_v2_e3.png&hash=9e2c577419566c8892a4b5d622dacf1b88d37a95)
level - flag_testing_v2_e3.rar
src folder - flag_testing_v2_e3_src.rar[/spoiler]
notes:
- Big effort for nothing.
This is where I will stop with the general flag testing.
There are 3 that need further investigation (glow, per-pixel lighting, and specular) and I will handle them by digging through existing files that use them.
From this battery of tests, I believe it safe to say the DATA chunk does not affect the render flags, and I will handle them in that way in my program untill something to the contrary pops up.
-edit Removed by tirpider due to inacurate test information
I may put more tests here if I need the space.
While I set up the models to dig deeper into emissive, here is a handy dandy (actually kinda useless) list of all 256 possible render flag settings.
Combined Render Flag Values (sample because the list is longer than the post would allow)
[spoiler]
value= hex = added flags = flag names
0= 0x00 = = no flags set
1= 0x01 = 1 = Emissive
2= 0x02 = 2 = Glow
3= 0x03 = 1 + 2 = Emissive + Glow
4= 0x04 = 4 = Singlesided Transparency
5= 0x05 = 1 + 4 = Emissive + Singlesided Transparency
6= 0x06 = 2 + 4 = Glow + Singlesided Transparency
7= 0x07 = 1 + 2 + 4 = Emissive + Glow + Singlesided Transparency
8= 0x08 = 8 = Doublesided Transparency
9= 0x09 = 1 + 8 = Emissive + Doublesided Transparency
10= 0x0A = 2 + 8 = Glow + Doublesided Transparency
11= 0x0B = 1 + 2 + 8 = Emissive + Glow + Doublesided Transparency
12= 0x0C = 4 + 8 = Singlesided Transparency + Doublesided Transparency
13= 0x0D = 1 + 4 + 8 = Emissive + Singlesided Transparency + Doublesided Transparency
14= 0x0E = 2 + 4 + 8 = Glow + Singlesided Transparency + Doublesided Transparency
15= 0x0F = 1 + 2 + 4 + 8 = Emissive + Glow + Singlesided Transparency + Doublesided Transparency
16= 0x10 = 16 = Hardedged Transparency
17= 0x11 = 1 + 16 = Emissive + Hardedged Transparency
18= 0x12 = 2 + 16 = Glow + Hardedged Transparency
19= 0x13 = 1 + 2 + 16 = Emissive + Glow + Hardedged Transparency
20= 0x14 = 4 + 16 = Singlesided Transparency + Hardedged Transparency
21= 0x15 = 1 + 4 + 16 = Emissive + Singlesided Transparency + Hardedged Transparency
22= 0x16 = 2 + 4 + 16 = Glow + Singlesided Transparency + Hardedged Transparency
23= 0x17 = 1 + 2 + 4 + 16 = Emissive + Glow + Singlesided Transparency + Hardedged Transparency
24= 0x18 = 8 + 16 = Doublesided Transparency + Hardedged Transparency
25= 0x19 = 1 + 8 + 16 = Emissive + Doublesided Transparency + Hardedged Transparency
26= 0x1A = 2 + 8 + 16 = Glow + Doublesided Transparency + Hardedged Transparency
27= 0x1B = 1 + 2 + 8 + 16 = Emissive + Glow + Doublesided Transparency + Hardedged Transparency
28= 0x1C = 4 + 8 + 16 = Singlesided Transparency + Doublesided Transparency + Hardedged Transparency
29= 0x1D = 1 + 4 + 8 + 16 = Emissive + Singlesided Transparency + Doublesided Transparency + Hardedged Transparency
30= 0x1E = 2 + 4 + 8 + 16 = Glow + Singlesided Transparency + Doublesided Transparency + Hardedged Transparency
31= 0x1F = 1 + 2 + 4 + 8 + 16 = Emissive + Glow + Singlesided Transparency + Doublesided Transparency + Hardedged Transparency
32= 0x20 = 32 = Per-Pixel Lighting
[/spoiler]
Someone else on GT already made a list like this, but thats there and this is here. Enjoy the instant replay of novel data.
Attached is the whole list in Open Office and Excel format.
-edit found the GT post.
It was AceMastermind (link (http://www.gametoast.com/forums/viewtopic.php?p=480836#p480836)) in the "inside the edit flags" thread.
For Science!!
Funny, I try your "64" code (04 00 00 00 64), but all, what it can do, is simple transparent... and actualy, how you put triple number code "128" in to binare code lines, or you just rip it apart, like this: 04 00 00 00 12 80 ?...
Wow, that's realy long code list, but... I did not try it yet, but I am almost sure, most of those numbers do nothing, or repeat the same thing, again and again...
The list is every permutation of the factors 0, 1, 2, 4, 8, 16, 32, 64, and 128.
Those factors are the flags that all combine to make the render flag byte in the ATRB section of the msh.
[spoiler] A T R B
41 54 52 42 04 00 00 00 00 00 00 00
| | | | | |
| | | | | |
size field----+--------+ | | | |
| | | |
render flag----------------+ | | |
| | |
render type-------------------+ | |
| |
data1----------------------------+ |
|
data2-------------------------------+
(data1 and data2 provide extra information for
the type and flag fields as needed so their
meaning is flexible.)
Render flags:
dec hex desc
0 = 00 = none
1 = 01 = Emissive
2 = 02 = Glow
4 = 04 = SinglesidedTransparency
8 = 08 = DoublesidedTransparency
16 = 10 = HardedgedTransparency
32 = 20 = PerPixelLighting
64 = 40 = AdditiveTransparency
128 = 80 = Specular
[/spoiler]
Each one is a discrete number and does not repeat any more than the integers from 0 to 255 repeat.
The way to get them into a format usable for hex editing, change the decimal number to a hexadecimal number. (see also, base10 to base16, or decimal to hex)
I use built-in functions to convert the numbers, so I forget the actual method.. I think it uses a lot of division.. but it's been years, so I forget.
128 in hex would be "80", and in the file it would look like:
41 54 52 42 04 00 00 00 80 00 00 00
That 64 flag (addative transperancy) really suprised me. The only thing special about the test files is the tga. It has an alpha channel with a full range of values. the lower values were the invisible parts. I think it must be interacting with the rest of the colors in the other channels as well. I plan on digging into it more after I get emmisive working without specifying a render type.
Oh, that's explain a lot. So, if I have to convert 64, it will be 40... So, the code, after ATRB, should look's like this: 04 00 00 00 40 ?... I am afraid, to got your effect, it will be far not enough... Seems, more bigger part of code, that you use, also have some certain RGB parameters, just like my "super shiny" code.
Quote from: Sereja on February 21, 2013, 03:23:46 PM
Oh, that's explain a lot. So, if I have to convert 64, it will be 40... So, the code, after ATRB, should look's like this: 04 00 00 00 40 ?
Yes.
Quote from: Sereja on February 21, 2013, 03:23:46 PMI am afraid, to got your effect, it will be far not enough... Seems, more bigger part of code, that you use, also have some certain RGB parameters, just like my "super shiny" code.
The test I ran on the 64 flag used a wide spread of values for the colors. ZeroEdit noticed that the diffuse color was different, but after munging, the game did not notice the difference in the color values at all.
It had the same effect on all the models, regardless of how the colors were set in the msh file.
I am not certain, but I believe the fiery yellow was caused by the rgb channels interacting with the alpha channel in the tga. The way to test would be to set the 64 flag, and try different texture combinations.
It has to have an alpha in the tga, else the effect will not show up.
If the alpha is entirely blank, then it would probably just make the model invisible.
If the alpha is completely opaque, then it should still have some remnant of the fiery look to it.
An example of the hex in the format of your shiney code:
[spoiler]
44 41 54 41 34 00 00 00 00 00 00 43 00 00 00 43 00 00 00 43 00 00 80 3F 00 00 00 43 00 00 00 43 00 00 00 43 00 00 80 3F 00 00 00 43 00 00 00 43 00 00 00 43 00 00 80 3F 00 00 48 42 41 54 52 42 04 00 00 00 64 00 00 00[/spoiler]
That starts at the DATA tag and ends just before TX0D. I copied it staight out of one of the test files.
It has every color set to 128,128,128 and the specular decay set to 50. (this shouldn't effect anything.)
-editoh my god.....
You know what? thank you for asking about this... I have to redo those tests . I was reviewing the numbers in the DATA fields, and instead of making them into percents before encoding as a float, I just encoded the raw color numbers as foating points. .....
So you are right about it needing something more... the numbers in that test code are exactly
128% 255% larger than the numbers Zero, the munger, and the game expected.....
I'll redo the tests, it shouldn't take long since I already have the files made and named. Perhaps things like specular will behave this time around and emisive might emiss.
The test code above is what I used the incorrect tests, so it should give you the glowy-yellowy-transperant look that I got before.
(Note that the numbers for DATA and the numbers for ATRB are encoded differently regardless of my mistake.)
Seems, I found "code" line, responsible, for color regulation:
[spoiler](https://www.swbfgamers.com/proxy.php?request=http%3A%2F%2Fi53.fastpic.ru%2Fbig%2F2013%2F0222%2Ff0%2F2d8ccb860947e2736a654d617f3fbff0.jpg&hash=9ce13a5fae031d0dd915c10e8a6245abd0670eb9)[/spoiler]
Explanation:
Additive, means, it uses added color palette. In this case, it uses ambient colors, from your .SKY file. So, to change colors, you need to change this line:
AmbientColor(40, 36, 76);
That's it! :)
Quote from: Sereja on February 22, 2013, 12:18:21 AM
Seems, I found "code" line, responsible, for color regulation:
[spoiler](https://www.swbfgamers.com/proxy.php?request=http%3A%2F%2Fi53.fastpic.ru%2Fbig%2F2013%2F0222%2Ff0%2F2d8ccb860947e2736a654d617f3fbff0.jpg&hash=9ce13a5fae031d0dd915c10e8a6245abd0670eb9)[/spoiler]
Explanation:
Additive, means, it uses added color palette. In this case, it uses ambient colors, from your .SKY file. So, to change colors, you need to change this line:
AmbientColor(40, 36, 76);
That's it! :)
Excuse me if I'm wrong, but does that mean we can finally change the CP colour?
Oh, I am afraid, CP's hologramm, has totaly different nature...
Quote from: Sereja on February 22, 2013, 02:20:06 AM
Oh, I am afraid, CP's hologramm, has totaly different nature...
Oh well.
However this stuff is all great anyhow.. uh carry on.
Bad thing about changing SKY file ambient color, is that it applies the color to all of the objects in the map..
It would be cool to have some slightly transparent crystals like the model above, with some beautiful glow in a night time setting.
While we are talking about light, I cannot seem to get whitelight.ODF to work, and is crashing my map.
Any ideas? (It is unmodified)
Quote from: -RepublicCommando- on February 22, 2013, 10:32:04 AM
Bad thing about changing SKY file ambient color, is that it applies the color to all of the objects in the map..
It would be cool to have some slightly transparent crystals like the model above, with some beautiful glow in a night time setting.
Well, I guess, that easy can be done, with some other hex codes, like simple "Glow Soft Edged Transparent" code:
04 00 00 00 09Quote from: -RepublicCommando- on February 22, 2013, 10:32:04 AM
While we are talking about light, I cannot seem to get whitelight.ODF to work, and is crashing my map.
Any ideas? (It is unmodified)
Hope, you didn't try add whitelight.ODF, just with ZE? It is for some prop odf attach only. If msh, has some hp firepoint, you may attach whitelight.ODF, by open prop odf, and add this lines:
AttachOdf = "whitelight"
AttachToHardPoint = "hp_light"
Oh yes.. I should have known this (https://www.swbfgamers.com/Smileys/macx/slap.gif)
I looked at tusken fire pit and it had those lines in it, so theoretically, I could use tat2_barge_turret (since it has hp node) and use it as a light "host" ?
Will it read any node as long as it's in the MSH?
Yes, but it works only for prop, but not for turret, vehicles, units etc.
I revised the render flag tests in my previous post (http://www.swbfgamers.com/index.php?topic=6091.msg63594#msg63594) and double checked the way the numbers were encoded.
Basicly it reveals little more than yes, there are render flags, and no, the data chunk has nothing to do with how they render.
There are still a few more to go through, but they may require more than just the data color values to work, so they are a different array of tests.
Comming soon: Glow, why doesn't it?
any idea what this would do when called on?
-- set sun light for the model
ScriptCB_SetSunlight( this )
It is strange, but for me, 04 00 00 00 01, hase shadow :confused:...
Also, 04 00 00 00 02, has different look's.
But, here, few more interesting codes, I found:
[spoiler](https://www.swbfgamers.com/proxy.php?request=http%3A%2F%2Fi53.fastpic.ru%2Fbig%2F2013%2F0223%2F56%2Fd0bf67be9e07525a22b973e659b8e856.jpg&hash=8f2a7a3b2924ca3bfd4e933b8c3b3615c1f737a8)[/spoiler]
04 00 00 00 00 0A - "Misterious Code".
It's totaly ignore any texture, and, under different view angles, become totaly black, white, or transparent.
04 00 00 00 00 0B - "Secondary Texture Switcher".
Become super glow, if you come too close. Actualy works only with -vertexlighting, in msh.options, and wraped secondary texture. Without it, become totaly black, in close look's.
04 00 00 00 16 00 - "Blur Code".
Make dissapear any lights, or lighted objects behind of it.
04 00 00 00 40 04 - "Glass Code".
Stopping use alpha channel, for transparence.
I have no idea what that script would do, Phobos.
Quote from: Sereja on February 23, 2013, 04:11:38 AM
It is strange, but for me, 04 00 00 00 01, hase shadow :confused:...
Also, 04 00 00 00 02, has different look's.
But, here, few more interesting codes, I found:
<pic>
04 00 00 00 00 0A - "Misterious Code".
It's totaly ignore any texture, and, under different view angles, become totaly black, white, or transparent.
04 00 00 00 00 0B - "Secondary Texture Switcher".
Become super glow, if you come too close. Actualy works only with -vertexlighting, in msh.options, and wraped secondary texture. Without it, become totaly black, in close look's.
04 00 00 00 16 00 - "Blur Code".
Make dissapear any lights, or lighted objects behind of it.
04 00 00 00 40 04 - "Glass Code".
Stopping use alpha channel, for transparence.
04 00 00 00 01
- emissive render flag, yours has a shadow because you have altered something. I removed all shadows from the test model. When I mentioned that emissive couldn't accept a shadow, I was talking about shodows falling on it, not it's own shadow.
04 00 00 00 02
- Cool. I can't seem to get it to do anything without altering the world some how. (I'm trying to see what these types and flags do without altering the world. once thats established, then they can be customized to fit in all the different sky files folks come up with.)
04 00 00 00 00 0A
- thats the water render type. it's look will change as you view it from diferent angles.
04 00 00 00 00 0B
- groovy. thanks for the info. I suspect others only work with certain .option settings as well.
04 00 00 00 16 00
- The munger calls that flag HardedgedTransparency in the modelmunge.exe.... I think you swapped the values here..
04 00 00 00 16 00 = HardedgedTransparency flag
04 00 00 00 00 16 = ICE_REFRACTION type, which behaves exacly as you describe it.
04 00 00 00 40 04
- AdditiveTransparency flag and the Specmap render type.
And...
Heres a list of the render types and their names, as pulled from the modelmunge.exe for bf1... (remember all that noise about the types being different? Well they aren't as different as expected.)
Most all fail unless you have them set up with other settings correctly, I will go in to lining up correct settings later, using the assets and bf2 info as a guide...
[spoiler]
render type index hex
nothing 0 00
Glow 1 01
Lightmap 2 02
Scroll 3 03
Specmap 4 04
Glossmap 5 05
Chrome 6 06
Animate 7 07
Ice 8 08
Sky 9 09
Water 10 0A
DETAIL 11 0B
SCROLL2V 12 0C
ROTATE 13 0D
GLOW_ROTATE 14 0E
PLANAR_REFLECTION 15 0F
GLOW_SCROLL 16 10
GLOW_SCROLL2V 17 11
CURVED_REFLECTION 18 12
NORMALMAP_FADE 19 13
NORMALMAP_INVFADE 20 14
ICE_REFLECTION 21 15
ICE_REFRACTION 22 16
EMBOSS 23 17
WIREFRAME 24 18
ENERGY 25 19
AFTERBURNER 26 1A
BUMPMAP 27 1B
BUMPMAP_GLOSSMAP 28 1C
TELEPORTAL 29 1D
MULTISTATE 30 1E
SHIELD 31 1F [/spoiler]
The render types can be used with flags, and many other settings, but you can only specify one render type at a time, per material. Some require additional textures, some require settings in the data1, and data2 spots. Some require specific data colors, some don't... haven't tested them yet, other than to determine the above list is, in-fact, all the types the munger looks for regarding render types.
Here is the fun part about all this.. the texture could cause a flag or type to render in such a way that it's effect might not be noticable. Also, different video cards may ignore certain flags or types for technical reasons. (memory? under powered gpu? low dx or ogl version compatabiity? idk..) I have a low end video card, so some of these may fail on my machine for that reason.
-edit afterthought
At first, I thought there was a totally different set of render types for bf1 and bf2. I checked inside the exe's for lists of things that looked like render types and came up dry for bf2, but in the bf1 munger, I found a slightly longer list that was backwards. [spoiler]SHIELD
MULTISTATE
TELEPORTAL
BUMPMAP_GLOSSMAP
BUMPMAP
AFTERBURNER
ENERGY
WIREFRAME
EMBOSS
ICE_REFRACTION
ICE_REFLECTION
NORMALMAP_INVFADE
NORMALMAP_FADE
CURVED_REFLECTION
GLOW_SCROLL2V
GLOW_SCROLL
PLANAR_REFLECTION
GLOW_ROTATE
ROTATE
SCROLL2V
DETAIL
Water
Sky
Ice
Animate
Chrome
Glossmap
Specmap
Scroll
Lightmap
Glow
nothing
Bump
Camouflage
Refraction
Detail
Reflection
*
glow
[/spoiler]
The numbers did not match and only last night did I confirm the previous list through the error codes the munger throws when a type is called but not set up correctly.
So for the types, It is just a matter of figuring out what is required to get them to work, and I bet they work just like the documentation and
Ande's site (http://www.ande.pytalhost.eu/rendertypes.htm) describes.
I cant explain why some bf2 assets render incorrectly anymore, because the reason I came up with before (that BF2 has more and different types) is invalid. It may be that the types are referenced, but the munger wasn't set up to build them untill BF2 was developed.
A lot of folks have put efforts into describing the behavior of these types, and as demonstrated by Sereja's glass, there is an almost unlimited potential for material effects when combining flags, types, and world settings. When I do test them, it won't be as straight forward as the flag tests since each type has wierd requirements. It will take a while to plan the tests and build the materials for them. I'll just chase down one type at a time and leave combined effects to the experts and artists.