Materials & BinPBO/Binarize...

[Synide]

firstly, sometimes i can be about as much use as tit's on a bull... oh well, ya live & learn eh?! having said that, you could read rest of the post's in this thread but they'd be just a laugh for you. essentially, Binarize.exe does process rvmat's fine when you are producing binarized outputed models.

here's the summarized version.

i was trying to build pbo's based around a 'mod' structure, just like BIS's.
that is, BIS's mod is 'ca' and there are 'subfolders' to this 'mod' like 'ca\weapons', 'ca\air', 'ca\blah,blah' etc.

i wanted our structure to be the same, that is, the mod is 'AAW' and the subfolders are things like 'AAW\aawWpns', 'AAW\aawBodies' etc.
i wanted the resultant output to be a mod folder in the ArmA installation folder called 'AAW' with a 'AddOns' subfolder with the pbo's 'aawWpns.pbo', 'aawBodies.pbo' etc, etc.
all standard stuff, the problem was the frik'n odol'd models materials weren't working... hence this stupid amount of wasted time figuring out why...

so, my directory/folder structure on the P:\ drive is just as above.

the problem is, i was using BinPBO with settings like I was trying to make a standalone 'addon'.

that is, i had the following settings...

http://i198.photobucket.com/albums/aa15/sbeetham/BinPBO1.jpg

and...

http://i198.photobucket.com/albums/aa15/sbeetham/BinPBO2.jpg

So, binarize.exe was expecting my aawWpns folder to be sitting in the ROOT folder of my P:\ drive, where as i had it sitting in a sub-folder called 'AAW'. which is the structure i want, just like BIS's 'ca' mod.

What i should have had set in the options was this...

http://i198.photobucket.com/albums/aa15/sbeetham/BinPBO3.jpg

So...

If you are building a pbo that is part of a mod, you should set the 'Path to Project Folder' in options as the pathname of your mod on the P:\ drive, not as 'use source path'.

If you are building a 'standalone' pbo then you have 'Use Source Path' checked. the folder you are trying to pbo can be anywhere though... but make sure in your model the pathname to the rvmat (and any textures mentioned inside the rvmat) starts in the same folder.


I'm sorry i've wasted your time (and more importantly mine&#33http://forums.bistudio.com/oldsmileys/wink_o.gif with the rubbish in the rest of this thread.

cheers, sy.

============================================================================================



i posted the following in another thread but thought it of significance to merit it's own... as it annoyed me for a day...

ok, i've had to do a bit more around this area myself the last week so this is what i have found... probably already some of you know this anyway... but, for those that don't...

There a 2 (two) methods by which materials work on models...

a. by specifying all relevant information for 'CfgTextureToMaterial' and 'CfgMaterials' in a config.cpp - this is the old/transition method.

 OR

b. by pointing faces in your model (using O2PE only) to not only the main texture for that face but also a .rvmat material file.

currently, method (b) will only work if you do not binarize your model. if you choose to leave your model as a P3DM you can successfully utilize the new ArmA method.

if you want to binarize your model (to make it smaller for one thing...) currently i believe you cannot use method (b) and here's why...


1. when Binarize comes across a .rvmat reference in your lovelly P3DM mlod model it currently cannot include this rvmat in the binarized version it tries to produce.
(this is of course written in the readme... which i failed to read for a very long time... lol)

so, if you utilize the new method and want to binarize your models then the materials won't work...

Solutions

1. release your model as p3dm and you can use the new method.

2. if you want to binarize...
while working on your model and using Buldozer you can of course make use of the new method...
but when you go to produce your pbo (for use in game) you should remove all reference to .rvmat's in your model.
you should copy and paste all the information from your working rvmat files into a config.cpp and utilize the old/transition method of making CfgTextureToMaterial and CfgMaterials classes.

now when you produce your pbo using BinPBO/Binarize the model will be binarized and it will read the material information from the config.cpp and include this in the model.p3d.

you do not need the rvmat files to be included in the pbo. you should of course include damage rvmat's.

warning: if you specify the materials in a config.cpp AND still have references to the rvmat's on faces in the model you will probably find your materials will not work in game. they do in Buldozer but not in game... this is because Binarize will try to include the rvmat information found on the face in the model over what it reads from the .cpp, and of course it fails to do this...

This will, become irrelevant when BIS fix the Binarize.exe tool to correctly process rvmat's.

i think the above is pretty accurate...

[KKB]

Quote[/b] ]
Current version of binarize doesn't support rvmat files and these must be copied manually.
If you add *.rvmat to BinPBOs list of files to copy directly and it should work IMO.

[Synide]

Quote[/b] ]
Current version of binarize doesn't support rvmat files and these must be copied manually.
If you add *.rvmat to BinPBOs list of files to copy directly and it should work IMO.
that's true, but that is not what i talking about. obviously you didn't read the post very well.

adding *.rvmat to the list of files to copy does nothing but that. it tells BinPbo to copy them to the temporary working folder in preparation for inclusion by the Binarize tool into the model. and then ultimately Filebank to squash them into a pbo. the current version of Binarize is not capable of including the rvmat file into the model.
Binarize is capable (at this time) in reading the relevant material settings/parameters if you use the 'transition' method.
and, as i mentioned, if you choose not to binarize your model into odolv40 then you can use the 'new' method of specifying materials through O2PE directly on 1 or more faces.

[KKB]

Since all the BIS pbos have the rvmat files besides ODOL p3ds I thought that material info gets always read from the rvmat file. I don't understand then why the rvmats are in the BIS pbos at all if the info is in the p3ds itself? Not suggesting you're wrong, just wondering.

[Synide]

Since all the BIS pbos have the rvmat files besides ODOL p3ds I thought that material info gets always read from the rvmat file. I don't understand then why the rvmats are in the BIS pbos at all if the info is in the p3ds itself? Not suggesting you're wrong, just wondering.
indeed, it is a question that i have pondered for a long time.
i have often wondered why have the rvmat info. for a model sitting in the folder and have it duplicated inside the p3d.

my theory is this... some of the rvmat files are required in the pbo's, namely for damage materials and islands.

and because, they are small, for BIS making the distinction of not including the unecessary ones is really sort of an overhead that they have decided to live with...

it's like the duplication of many texture files... they are there because to organize them out or have a process/procedure or tool to clean the content base before delivery is just another overhead. (that's another reason i like the xna framework btw)...

anyhoo, i digress... the info. above is quite accurate i believe and will hopefully be rectified with a 'final release' version of Binarize or it's next RC incarnation. if/when that occurs.
in the meantime, there is the above info. to get some of you through this little glitch... as it gave me a headache for a day.

[KKB]

Thank you, I didn't know that (as you might have guessed http://forums.bistudio.com/oldsmileys/wink_o.gif )

[JB™]

Thanks Sy, this explains some of the troubles I have been having http://forums.bistudio.com/oldsmileys/smile_o.gif

[Planck]

Textures that are used in a model are listed there in the same way rvmats that each face needs (or not) is listed also.

The information in a rvmat file is not stored in the model file, only the fact it is used and which faces use it is stored.

rvmat files are not incorporated into anything as far as my understanding goes.
The only thing that happens to rvmat files is they get rapified when the addon or whatever gets binarized and packed, much like a config.cpp gets rapified.

More than likely you can also just pack them directly into a pbo without rapifying them, again much like a config.cpp.


Planck

[Synide]

Textures that are used in a model are listed there in the same way rvmats that each face needs (or not) is listed also.

The information in a rvmat file is not stored in the model file, only the fact it is used and which faces use it is stored.

rvmat files are not incorporated into anything as far as my understanding goes.
The only thing that happens to rvmat files is they get rapified when the addon or whatever gets binarized and packed, much like a config.cpp gets rapified.

More than likely you can also just pack them directly into a pbo without rapifying them, again much like a config.cpp.


Planck
Planck,

good assertions, but unfortunately incorrect.

rvmat's do indeed get incorporated into the odol'd p3d. this is not a point of debate - they just do - believe me.
they also, as you point out do get binarized - but atm not by the Binarize tool - unless you guys at CWR are using an unreleased version of the tool from BIS. this tool in it's current form is incapable at this time of peforming this task.
it is clearly written as such it's readme... and i am very, very familiar with the structure of a 'well formed' odolv40.p3d.
after binarization the contents of the material file that is referenced in the 'Face Properties' O2PE dialog for a given set of faces is supposed to be duplicated into the p3d.
only the rvmat mentioned in this dialog should get incorporated, not it's cousin rvmat's for damage textures - they are referenced by the .cpp.

do you follow me?

[KKB]

I just tested with a piece of custom road i made, and the sound environment only worked correctly for the mlod object, in odol it didn't change (object placed with visitor). I guess the cfgsurface part is linked to the rvmat?

[Scars09]

Quote[/b] ]rvmat's do indeed get incorporated into the odol'd p3d. this is not a point of debate - they just do - believe me.
they also, as you point out do get binarized - but atm not by the Binarize tool - unless you guys at CWR are using an unreleased version of the tool from BIS. this tool in it's current form is incapable at this time of peforming this task.
it is clearly written as such it's readme... and i am very, very familiar with the structure of a 'well formed' odolv40.p3d.
after binarization the contents of the material file that is referenced in the 'Face Properties' O2PE dialog for a given set of faces is supposed to be duplicated into the p3d.
only the rvmat mentioned in this dialog should get incorporated, not it's cousin rvmat's for damage textures - they are referenced by the .cpp.


sorry i dont get it. what you mean with incoorporate in the p3d? and why should the rvmat config solution can get that handled? the next thing i dont understand is the argument that cleaning the data folders of double existing files would be so hard to do. the addonmaker script from o2 does it in seconds, it wasnt functional in the initial release of the public version but since the script itself doesnt changed i think bis was able to use it when arma was created. rvmat enable a "selection" to handle engine triggered event based texture swapping, like hidden selection in ofp, just with more textures or better spoken materials. and not eventhandler or script triggered. thats how i understand it.
for example was the reason not getting any blood textures for me that i didnt had the selections for the injuries named in config. after naming them accordingly i can binarize the addon and everything is fully functional.

[Synide]

sorry i dont get it. what you mean with incoorporate in the p3d?

here's the dictionary.com definition of the word incorporated (http://dictionary.reference.com/browse/incorporated) - means the rvmat referenced on the face properties dialog in O2PE, when you are attempting to binarize your p3dm mlod into a odolv40 the values contained in the rvmat are meant to be placed inside of the odolv40 model. however, at this time binarize cannot do this, but it is meant too.

-if anyone disagrees with this, well there it not much i can do about that except point out they'd be wrong.



and why should the rvmat config solution can get that handled? - i do not know - ask BIS.



the next thing i dont understand is the argument that cleaning the data folders of double existing files would be so hard to do.
the addonmaker script from o2 does it in seconds, it wasnt functional in the initial release of the public version but since the script itself doesnt changed i think bis was able to use it when arma was created.

- i'm tired of repeating myself - so i won't.



rvmat enable a "selection" to handle engine triggered event based texture swapping, like hidden selection in ofp, just with more textures or better spoken materials. and not eventhandler or script triggered. thats how i understand it.
for example was the reason not getting any blood textures for me that i didnt had the selections for the injuries named in config. after naming them accordingly i can binarize the addon and everything is fully functional.

- i'm not talking about damage textures. damage textures  are indeed specified in the .cpp (again - i repeat myself) - these rvmat's do not get incorporated into the binarized version of the model. i did not indicate that they did.

is there anything else you are unclear about?

PS. sorry if i sound grouchy, but i've not had much sleep in the last 24hrs. my apologies.

[RN Malboeuf]

One question (may be it will clear the thing for me ) - what problems do we get with this issue ? i.e after i binarized well configured model (rvmats set in the model) what will not work or work incorrectly ?

[Scars09]

second layer of faces with material applied as far i understand it.

[Synide]

hopefully, this will resolve the misunderstanding... although, for the life of me i cannot understand why it is so difficult for the information in the previous posts to be understood - it is quite plain and simple.

oh, and the links are temporary... i'll leave them here for a week.

    synTest.rar (ftp://203.97.251.53/synTest.rar)

    synTestBox.Intro.pbo (ftp://203.97.251.53/synTestBox.Intro.pbo)


Daylight shot...

http://i198.photobucket.com/albums/aa15/sbeetham/synTest_Day.jpg


Night shot...

http://i198.photobucket.com/albums/aa15/sbeetham/synTest_Night.jpg

I made the material very emissive so it is quite plain and noticeable if it is working or not...

if you are still not convinced... then i could possibly do hex dumps of the odolv40 versions of the models so as to dispell all possible doubt for you...

By the way, No.2 is the method by which BIS intend for this process to work... however, currently it does not.

No.3 is the temporary solution... No.1 represents a p3dm mlod and is included for reference purposes only.

open the config.bin and have a look at that... also, here is the 'source' versions of the files above...

    synTest_Source.rar (ftp://203.97.251.53/synTest_Source.rar)

cheers, Sy.

Edit:

"Synide Test Box 1" is a p3dm mlod model. It has textures and materials specified on faces in the model through the O2PE Face Properties dialog. This model will work in Buldozer and in game just fine and will have rendered textures and materials. P3DM mlods are not the issue in this thread.

"Synide Test Box 2" is a binarized model in ODOLv40 format. It is exactly the same as the above model except the texture has a no. 2 on it. You will note that in game this box does NOT have a working material on it. Also, you will note that the .rvmat that is referenced by this model is present in the pbo. (i have tried it in both text format and rapified format to be thorough)
The reason this box doesn't have a working material on it has been clearly detailed above. It is because when attempting to binarized the model the Binarize.exe tool cannot process the rvmat to include it's contents in the outputed odol model.
When BIS are able to release a version of Binarize to the ArmA community that can process the rvmat files, this will be the preferred method of detailing materials for faces.
The temporary 'work around' for this problem is exhibited as...

"Synide Test Box 3" is a binarized model. It has only the main textures specified on the Face Properties dialog. The materials are specified through detailing 'CfgTextureToMaterial' and 'CfgMaterials' entries as appropriate.
Even though this model is binarized it displays materials in game because when the Binarize.exe tool is processing the model it can successfully integrate the values for the material from the config.cpp entries into the outputed Odolv40 model.

Cheers, Sy

[Scars09]

thx alot for the example. no further questions from my side.
sorry that i costed you that much time

[Synide]

cool, so someone understands...

however, i've become aware through discussions with others that this problem IS NOT one that everyone has.

it appears that the use of binarize is just like the old days - fickle to say the least.

3 quite reputable people have indicated to me that they have this problem, and a couple of others have indicated that they do not.

the guys that do have it working have spent some time with me trying different things to replicate why there setups work and why others do not.

and, just to be a pain i've even sent them content to binarize and it's come back exhibiting the above issues with materials... and yet they have sent content to me that they have successfully binarized and it is 'well formed'...

the variety of results is quite remarkable...

[RN Malboeuf]

Have yuo tried not to use pbo prefix ?
Path in your model - synide\syntest\synide1.tga
though i always used smth like syntest\synide1.tga - without any prefolder. and i got no problems with binarization of my models. Maybe this is the trouble ?

[Synide]

i found the problem... it's late so i'll detail it tomorrow...

you'll all laugh at how simple it is... it's always the simple things that are little devils in disguise!

[Scars09]

dude, you really know how to make things thrilling.
stating to know the reason and keep it for yourself another day.
http://forums.bistudio.com/oldsmileys/pistols.gif
i did some boats, wich first had config materials. as material tool came out i noticed the difference of the look of the effect. it was clear to me that the config materials were faulty, cause the material tool generated looked so much better. http://forums.bistudio.com/oldsmileys/whistle.gif

[Synide]

I edited the first post in this thread with the appropriate information.

[[APS]Gnat]

lol ... thanks for clarifying http://forums.bistudio.com/oldsmileys/smile_o.gif