Jump to content
Sign in to follow this  
USSRsniper

ArmA 2 Glass .rvmat

Recommended Posts

Was trying to import my addon from ArmA 1, everything works fine, except the materials for mirrors and glass.

Got the rvmats from ArmA 2, used kegetys tools to unRap them and then applied them to my model, BINPbo reports the following errors.

Error in statement: ar.SerializeEnum(RSB(pixelShaderID),_lod[0]._pixelShaderID,0,PSNormal)
Error while loading material ussr_zaz968m\data\mirror.rvmat
Error in statement: ar.SerializeEnum(RSB(pixelShaderID),_lod[0]._pixelShaderID,0,PSNormal)
Error while loading material ussr_zaz968m\data\auta_skla.rvmat

Share this post


Link to post
Share on other sites

Don't rebinarize the RVMATs.

Just use unbinarized ones (so add *.rvmat to the exceptions in BinPBO)

Share this post


Link to post
Share on other sites

I'm getting a similar error. I get it regardless of whether I except *.rvmat in BinPBO. The materials will not show up in ArmA 2 unless I use the addon unbinarized.

Here's my binbpo log file:

Parse: 0 ms
cwr_xm177e2\data\xm177e2_co.paa->C:\Users\Theo\AppData\Local\Temp\ARMAaddons\cwr_xm177e2\data\xm177e2_co.paa
Parse: 0 ms
Convert model p:\cwr_xm177e2\cwr_xm177e2.p3d -> C:\Users\Theo\AppData\Local\Temp\ARMAaddons\cwr_xm177e2\cwr_xm177e2.p3d
Error in statement: ar.SerializeEnum(RSB(pixelShaderID),_lod[0]._pixelShaderID,0,PSNormal)
Error while loading material cwr_xm177e2\data\2.rvmat
Warning: Degenerated faces found in model p:\cwr_xm177e2\cwr_xm177e2.p3d:10000 

Share this post


Link to post
Share on other sites

fo shizzle.

ambient[]={1.000000,1.000000,1.000000,1.000000};
diffuse[]={1.000000,1.000000,1.000000,1.000000};
forcedDiffuse[]={0.000000,0.000000,0.000000,0.000000};
emmisive[]={0.000000,0.000000,0.000000,1.000000};
specular[]={0.600000,0.600000,0.600000,1.000000};
specularPower=50.000000;
PixelShaderID="Super";
VertexShaderID="Super";
class Stage0
{
texture="cwr_xm177e2\data\xm177e2_co.tga";
uvSource="tex";
};
class Stage1
{
texture="cwr_xm177e2\data\xm177e2_nohq.tga";
uvSource="tex";
class uvTransform
{
	aside[]={1.000000,0.000000,0.000000};
	up[]={0.000000,1.000000,0.000000};
	dir[]={0.000000,0.000000,0.000000};
	pos[]={0.000000,0.000000,0.000000};
};
};
class Stage2
{
texture="#(argb,8,8,3)color(0.5,0.5,0.5,0,DT)";
uvSource="tex";
class uvTransform
{
	aside[]={1.000000,0.000000,0.000000};
	up[]={0.000000,1.000000,0.000000};
	dir[]={0.000000,0.000000,0.000000};
	pos[]={0.000000,0.000000,0.000000};
};
};
class Stage3
{
texture="#(argb,8,8,3)color(0,0,0,0,MC)";
uvSource="tex";
class uvTransform
{
	aside[]={1.000000,0.000000,0.000000};
	up[]={0.000000,1.000000,0.000000};
	dir[]={0.000000,0.000000,0.000000};
	pos[]={0.000000,0.000000,0.000000};
};
};
class Stage4
{
texture="cwr_xm177e2\data\xm177e2_as.tga";
uvSource="tex";
class uvTransform
{
	aside[]={1.000000,0.000000,0.000000};
	up[]={0.000000,1.000000,0.000000};
	dir[]={0.000000,0.000000,0.000000};
	pos[]={0.000000,0.000000,0.000000};
};
};
class Stage5
{
texture="cwr_xm177e2\data\xm177e2_smdi.tga";
uvSource="tex";
class uvTransform
{
	aside[]={1.000000,0.000000,0.000000};
	up[]={0.000000,1.000000,0.000000};
	dir[]={0.000000,0.000000,0.000000};
	pos[]={0.000000,0.000000,0.000000};
};
};
class Stage6
{
texture="#(ai,64,64,1)fresnel(1.36,7)";
uvSource="none";
};
class Stage7
{
texture="CA\Data\env_co.paa";
uvSource="tex";
class uvTransform
{
	aside[]={1.000000,0.000000,0.000000};
	up[]={0.000000,1.000000,0.000000};
	dir[]={0.000000,0.000000,0.000000};
	pos[]={0.000000,0.000000,0.000000};
};
};

Edited by Max Power
:)

Share this post


Link to post
Share on other sites

Most don't usually specify a stage zero, although it's quite fine to do so, at least so I'm told, but as I never make use of the feature I can't comment whether there's a bug with processing them in some circumstances with the A2 tools suite.

It'll just get mixed with your 'primary' texture (if you have one specified for these faces) like a macro texture. You probably already know this.

The only other thing I noticed was your '_dt' texture had '0' for the alpha channel, when most use '1'.

You're not using A1 tools are you? Some tricky setup with A1/A2 tools on the same system?

Share this post


Link to post
Share on other sites

As far as I know I'm using all ArmA 2 tools.

Those changes to the RVMAT had no effect. I've tried reinstalling binmake and binbpo a couple of times. Maybe I need to completely reinstall all of the tools?

Adding RVMAT to the exception list in binpbo (files to copy directly) or not makes no difference.

Share this post


Link to post
Share on other sites

I've never had rvmat issues with glass, but then again i've never copied the arma2 vanilla rvmats, I always made my own... I would like to be able to answer this though, so I might have a look when i get home

Share this post


Link to post
Share on other sites

Well, here's the latest one. I pared it down a bit... no effect on the binarizer, though.

ambient[]={1.000000,1.000000,1.000000,1.000000};
diffuse[]={1.000000,1.000000,1.000000,1.000000};
forcedDiffuse[]={0.000000,0.000000,0.000000,0.000000};
emmisive[]={0.000000,0.000000,0.000000,1.000000};
specular[]={0.600000,0.600000,0.600000,1.000000};
specularPower=50.000000;
PixelShaderID="Super";
VertexShaderID="Super";
class Stage1
{
texture="cwr_xm177e2\data\xm177e2_nohq.tga";
uvSource="tex";
};
class Stage2
{
texture="#(argb,8,8,3)color(0.5,0.5,0.5,1,DT)";
uvSource="tex";
};
class Stage3
{
texture="#(argb,8,8,3)color(0,0,0,0,MC)";
uvSource="tex";
};
class Stage4
{
texture="cwr_xm177e2\data\xm177e2_as.tga";
uvSource="tex";
};
class Stage5
{
texture="cwr_xm177e2\data\xm177e2_smdi.tga";
uvSource="tex";
};
class Stage6
{
texture="#(ai,64,64,1)fresnel(4.08,7.04)";
uvSource="tex";
};
class Stage7
{
texture="CA\Data\env_co.paa";
uvSource="tex";
};

Share this post


Link to post
Share on other sites

Planck has been helping me get to the bottom of this. He is able to binarize my addon and have the materials show, but I am not. I decided to try to note the differences between the two packed PBOs and their contents and then replace components of each pbo, rePBO them, then run the addon in the game. The results of my experiment are as follows:

Planck's pbo.

PBO size = 3,183 KB

P3d size = 683 KB

RVMAT size = 1 KB

Notes: Packed with CWR packing scripts written by T_D. paa textures are 1/3 the size of mine. No exceptions listed in BinPBO. Unpacked and repacked for experiment using cPBO by Kegetys.

Test Results

No alterations => Material displayed

My p3d => No material displayed

PBO Size = 3,549 KB

My RVMAT => Material displayed

PBO Size => 3,183 KB

My pbo

PBO size = 14,707 KB

P3d size = 1,049 KB

RVMAT size = 1 KB

Notes: Packed with Binpbo. paa textures are 3 times larger than Planck's. Default exceptions in BinPBO + *.RVMAT

Test Results

No alterations => No material displayed

Planck`s p3d => Material displayed

PBO Size = 14,341 KB

Planck`s RVMAT => No material displayed

PBO Size =14,707 KB

I must then conclude that the problem lies in the binarized p3d.

edit: I got Planck to binarize with BinPBO. It works, same results as the packing tools for CWR. We've found that our BinPBO files are different sizes. This is odd because I installed the new tools a couple of times to reconfirm it wasn't my tools. I will now uninstall my tool suite, blank those directories, and reinstall them.

edit: There was something wrong with my tools install. I completely reinstalled it and it works like a charm now. Thanks for your interest and replies.

Edited by Max Power

Share this post


Link to post
Share on other sites

ah, well there's the giveaway... your .paa's being 3 times the size of Planck's versions means that your tools install was using A1 pal2pace.exe & it's accompanying .cfg to convert your .tga's to .paa.

The .paa format changed from A1 to A2.

A1 used LZSS compression and A2 uses LZO compression and thereby produces smaller compressed .paa's. A2's binarize expects LZO'd .paa's not LZSS'd .paa's.

So, there was some tricky setup with your tools suite after all and you were partially using A1 tools with A2 tools, just not aware of it.

Annoyingly time consuming isn't it.

Share this post


Link to post
Share on other sites

Yes, it was a simple problem that was complicated to narrow down. It was aggravated by the fact that another addon developer I was sharing files with also had the same problem, so the logical conclusion was that Planck's work environment was magic, and there was something wrong with my files.

Share this post


Link to post
Share on other sites

How would it take to fix this issue on another addon? I came across the same thing (I think. Your talking about the glass being a milky white instead of clear right?) on an addon I tried to convert from ArmA1 to ArmA2.

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  

×