SMDI, AS, paa compression, artifacts

[scotg 204]

I'm getting some major pixel clustering when I convert tga files into paa, but it seems to be only with the _SMDI and _AS textures. Here's my process:

1. Create a 2048x2048 .psd file for my object with folders dividing diffuse, specular, normals, and ambient shadows.

2. Diffuse is always grayscale, and AS usually starts off with an inverted colors (negatives) version of the combined specular image.

3. Save out the Specular layers to a .tga file ending with _smdi, eg: myObject_ext_smdi.tga

4. Open that new .tga in TexViewer2, and save it as myObject_ext_smdi.paa

5. The new .paa file has lost a lot of information, forming large blocks (clusters) in the image. This has happened to EACH. AND. EVERY. *_smdi.paa and *_as.paa texture I've created.

 

For diffuse it seems I can sometimes trick the compression to avoid clustering; I sometimes add what I call a "noise overlay" to the final diffuse image. This trick doesn't work for the textures smdi and as.

 

Is it some kind of overactive compression? LOL But seriously, other people have non-blocky, "hi-res" DXT1 files out there, so why does it create these ugly ones for me?

 

 

[Jackal326 1158]

When you save as TGA are you saving as 24bit or 32bit? I think 32bit is only necessary if you are saving an Alpha Channel (which, considering you're creating the SMDI/AS you probably wont have), but just make a 100% white Alpha Channel and then try saving as a 32bit TGA. If that doesn't work, right click the TGAs and hit 'Send To' then Pal2PacE (a hang-over from the old tools I think) OR 'Open With'and then 'Image2PAA.exe (you may need to navigate to the program which should be somewhere like C:\SteamLibrary\SteamApps\common\Arma 3 Tools\ImageToPAA').

[scotg 204]

I've tried the solid white alpha thing on 32 bitdepth thing, but it's no-go. For not knowing exactly what I'm doing, I also tried saving the file as a _nohq instead of _smdi. This created a blank DXT5 file with an error. The only thing I haven't tried so far is the Pal2pacE. I've come across it being mentioned here and there, but I never saw anything about how to use it.

 

Here's an interesting result I had from experimenting: I created a contrasty "white noise" layer (like an old TV without signal). It's similar to the noise overlay I sometimes use for diffuse, so I gave it another try. There were no clusters. Although the noise ruined the desired specular image, it helped me realize that maybe my specular map has too many subtle changes.

 

I'll try using pal2pacE, but if that doesn't work then I'll have to make my specular maps more contrasty.

[PuFu 4591]

1. try converting PNGs to PAAs

2. try having OB convert TGAs to PAAs for you.

 

NEVER have a CO texture in 32BIT. I never bother with compression details TBH, texview should do that for you automatically, and so should O2/OB  

[scotg 204]

Incidentally, here's a visual of what I'm getting in game: http://images.akamai.steamusercontent.com/ugc/395546970948402844/9FD2719B6646B9628EBAF75F68F4F29154A711B7/

 

I've tried starting from PNGs, but they also get blocky. How does one convert using OB, on model import?

 

Actually, I've been having some issues with OB and other tools - that may be another topic, or could be part of a bigger issue causing all this.
- First, OB doesn't always order all the alpha faces to the top, even though I specify it. The result is that some of the faces have a light-blue ghosting effect.

- Second, I can't see PAA files on the model in OB, even though I can see TGA textures.

- Third, I cannot run Buldozer at all. It begins start up, then produces two simultaneous dialogs one that says "Starting External Viewer, Please wait." and the other that says "Arma 3 has stopped working." When I escape out of these, there's a third dialog that says "External Viewer: Attach Failed. No viewer found." -- It might be of interest to note: Buldozer used to work w/o showing textures, then it worked with textures, then w/o again, and now not at all.

- Fourth, some alpha-enabled _CA textures will allow shadows cast upon them in game, and some won't even be dark when a shadow completely covers them.

- Last (for now), I've recently discovered that pal2pacE does nothing. I mean it produces no files. This could be a result not knowing how to use it, but I've tried "send to" and drag & drop. Not sure if I need to set up parameters, but when I look that up, I get info on making a homebrew .bat file that I don't know how to make it work for my files.
 

Besides the fact that I'm learning as I go, I wonder if all these things, including my pixel clustering issues, have something in common?
 

Back to the texture clumping problem...
I had submitted a ticket quite a while back on the Feedback Tracker site, but they asked me to produce a mission replicating the issue. I'm not sure how that would help, considering it was happening without a mission in the first place. Instead, I just created a new vehicle with new textures which was suffering the same texture issues, and put it up for download. So far in 6 months I haven't heard anything back. I can't believe that I'm the only one having these issues.

[PuFu 4591]

1. OB never orders the alpha textured faces by itself on top. You need to do it yourself - faces-move top

2. That is intended. i never used any other type of texture but TGAs. I know you can use PNGs as well, but i got so accustomed to TGA that i never really bothered working with PNGs. (also PNGs are 1 layer image, by definition PNGs have an plpha channel). I always work with TGAs, and let Buldozer convert it when i start it (that way in the same folder with textures i have both PAAs and TGAs.). To allow buldozer to convert files, go to options - Autoconvert GIF and TGA texture - on. It converts on buldozer start

3. That means you P drive is not setup correctly. I would use mikeros P drive instead of BIS. There are wiki pages on the subject

4. Shadows are based on the shadow volume lods. It also depends on the intensity of the alpha (transparency)

5. never used pal2pacE by itself as a individual software, so i can't help here

 

Remember that PAA is a compressed file, and TGAs aren't. PNGs compression is also lower (if active) than PAAs. That has an effect on the end result. It shouldn't, however, be as drastic as shown.

 

Can you provide the clean TGA and PAA to me, so i can have a look and try to build a PAA myself from the TGA?

[x3kj 1247]

if i want to manually convert a tga i drag&drop the file onto the imageToPAA.exe in the tools folder

[scotg 204]

"Manual" is a loose term, I suppose. Drag&Drop gives no other control options. Starting ImageToPAA, and then opening files within its interface seems more manual, because you can specify which files, types of files, folder source, and folder destination. It isn't manual enough because you can't control the compression; that is unfortunately determined by the filename_ending.paa.

[x3kj 1247]

 

you can't control the compression

you dont need to, at least i never had to. As long as you follow the naming convention all should be fine. Do you use the appropriate channels designed for AS and SMDI? means R for smdi+as = white ;  B =white for _as, G= spec and B= gloss for smdi ? just in case...

[scotg 204]

you dont need to, at least i never had to. As long as you follow the naming convention all should be fine. Do you use the appropriate channels designed for AS and SMDI? means R for smdi+as = white ;  B =white for _as, G= spec and B= gloss for smdi ? just in case...

I don't know if I use the appropriate channels. I must be missing some vital information about the RBGB channels, which you mentioned in that order. It's a bit confusing with RGB, so I'm getting the feeling like it's a different thing. What I do is: I just save my specular layers image as a B&W tga - something I had been doing in several other game engines in the past. After that, I invert the image and save that for the AS. Then, I save the TGAs as PAAs in either TexView2 or ImageToPAA; while this automatically converts it to Red for SMDI and White for AS, it also is where the main topic - pixel clustering - occurs. I have tried to work within my .psd files, in the RGB channel, with a solid Red (#FF0000) top layer on Linear Dodge. It's very hard for me to see the details in monochromatic red unless I zoom in very close, but they are there and in tact. If I save it as a TGA with the red filter on, and then examine the TGA in Photoshop, it is still in tact. The over-compression definitely occurs during the conversion to PAA, which is why I wanted more control over the compression process. This is more of a need expressed in frustration - not that it's a valid solution.

 

Side note: Recently, ImageToPAA is no longer working for me since I attempted to create a Mikero P: drive. I can use OB, AB, and TV2, but not ITPAA or BD - pardon the acronyms.Since I'm having such issues with getting my P drive working correctly, could it be that I am running all my Arma, Steam, and Arma Tools from a secondary HDD? I'm not convinces, because it had been working once upon a time... I'm just not sure what happened. I think I read something somewhere, at one point, that claimed we don't even need a P drive - in which case I may have attempted to remove it. I had to take a break from Mod'ing for a bit to focus on work, life, etc, and when I came back it was kind of like starting over again.

[x3kj 1247]

_AS and _SMDI are both RGB color maps, not greyscale. They contain the information you try to put in, you just have to do it in a special fashion that's not necessarily "industry standard" (because arma is weird ;))

 

For AS maps the color channels are supposed to be used like this:

Red = white color

Green = Ambient occlusion texture (greyscale obviously)

Blue = white color

 

For SMDI:

Red = white color

Green = Specular map

Blue = Specular Power map (also known as Gloss map)

 

Inverting the specular map is the "quick&dirty" way to get values for a gloss map. An ambient occlusion map is for shadows and you can't get that from specular. Of course you could use it that way if you desire... I assume you modelled this vehicle yourself? You can bake ambient occlusion models with blender, 3dsmax. There are also standalone renderers that can do it. This will make your vehicle look alot better (once you have a properly set up shadow LOD).

 

Also, i assume you are new to texturing? You could try dDo (legacy), it is a free Photoshop plugin but can give you some very nice results even without much efford (not perfect but incredible for a few button clicks). Example The only thing i did was making a normalmap with rivets, baking an Ambient occlusion and painting the camo base colors.

[scotg 204]

So judging by your quick charts and imagining a full RGB of each texture, then the _AS will look mostly white, with a purple-magenta details. Meanwhile, the _SMDI will  be mostly red, where highlights will appear yellow and reflectivity will appear purplish... That right?

"New to texturing" in the Arma methods, yes - even though I've been working with it now and then since its beta release. Aside from A3, I've actually been using Photoshop for web design, logo design, GUI design, photo retouching, and 3D model textures for 17 years... I'm not unfamiliar with how to use channels, etc... it's just understanding how to make textures work properly in Arma that trips me up, compared to CryEngine, Unreal Engine, and Refractor Engine. So, those engines are a lot more straight-forward. Overall, I'm an old dog, but I can certainly learn to do new tricks.

Yes these are my own models. If I ever needed a shadow in a crevice, I would have just hand-painted it or just dealt with how it looked. Baking AO has somehow escaped my grasp. I have gotten by with successfully using NVidia's polybump for normals baking, and later learned to do this in 3DS Max, which I had already been using all along for modeling and animations (Unfortunately, A3 doesn't really like full-on normal maps made for objects with broader smoothing groups. I've had to un-detail some of my normal maps, and up-poly the objects instead, in many cases). When it comes to using Max's Projection modifier, I have a hard time getting favorable results with lighting, which is why my AO suffers and not my normal maps.

 

Max is such a powerful tool, that one could get a lot accomplished on his part even sticking to one simple aspect of it. Some people do JUST lighting, some do JUST modeling, and some may do JUST animation, etc. I am the modeler-animator type and I can rig models with semi-complex IK (such as airplane landing gear with all the bells and whistles). I lay out my own UVs and do my own textures, but I'm not so great with lighting or baking.

 

Here are some models I have made over the years, using only diffuse, specular, and normal bump, with ~meh~ lighting, and then given some post-render touches in PS:
http://rooster3d.deviantart.com/gallery/32775893/3D-Showcase.

[x3kj 1247]

 

So judging by your quick charts and imagining a full RGB of each texture, then the _AS will look mostly white, with a purple-magenta details. Meanwhile, the _SMDI will  be mostly red, where highlights will appear yellow and reflectivity will appear purplish... That right?

indeed

 

it's just understanding how to make textures work properly in Arma

we know ;) arma handles many things the unusual way...

 

 

Baking AO has somehow escaped my grasp

It's super easy to do a "selfbake" for a lowpoly modell - means baking just the information the low poly has itself. You dont need a projection modifier or cage for this. First setup your renderer for scanline - lighttracer rendering. Follow this (admittedly crappy but short and to the point) video

Once you have completed this (the render setup), select your UV'ed low poly model. Apply a completely white material to it.  Press "0" to open render-to-texture dialog. Scroll down to "output" and click add, add a "CompleteMap". Set the size to the desired output (either by button press or by inputting manually in Width and Heigth). Under Filename and Type you can specify the output format and path. When finished, scroll down and click on the render button. This should complete fairly quickly for a 2K map.

 

Now if you want better quality (antialiasing) in your baked texture, go into your render settings again (press "F10"), go to renderer tab. Under "Global Supersampler" click "enable global supersampling" and choose  Hammersley with a setting of ~0,5 . This takes a while longer to bake, but is worth the quality.

 

If you want to bake from high to low poly you would use standard projection method with cage (or use another tool such as xnormal) and otherwise do it the same for the Ambient occlusion as above, but instead of applying white material to the low poly you apply it to the highpoly.

[scotg 204]

Has been an easy set up, but I can't figure out how to separate the different map channels. Eg: in my tank model, the exterior, interior, turret, parts, glass, and tracks maps are overlapping.

BTW, x3kj, PuFu, and Jackal326 - really big THANKS! for all you guys helping me through this. I'm humbled and very encouraged by your dedication to helping less-experienced Arma moders like me. The original problem still persists, but I have learned a lot nonetheless. At least I no longer feel like I'm flailing in the dark.

[x3kj 1247]

 

Has been an easy set up, but I can't figure out how to separate the different map channels. Eg: in my tank model, the exterior, interior, turret, parts, glass, and tracks maps are overlapping.

Just select everything of a certain map channel (e.g. turret) and detach it temporarily from the rest. If you have multiple objects for the turret, you need to combine them all into one, for the purpose of baking (otherwise it bakes maps for each object individually). Then do the render to texture procedure, do the same with the pieces of another map channel like interior,  rince and repeat.

[scotg 204]

That was going to be my work-around solution, but I guess it's the actual solution. Thanks!

[x3kj 1247]

that's the only solution i know would work. Maybe there are other/better options and solutions to this (wouldnt surprise) - i just dont know it^^

[scotg 204]

I think I may have unearthed a solution for the artifact problem. After doing some research on DXT conversions, I learned that it actually uses two colors, decided by an average, for every 4x4 block of pixels, called texels - or something along those lines. I remember going through this back in the old days with UT2004, but for whatever reason I only suffered strange colors back then, and not blockiness. The color issue was minor, because they were consistent enough to get the point across visually. I was also only using 1024x1024 images back then.

Many of my Arma3 objects use 2048^2, but even the ones with 1024^2 and 512^2 resolution are suffering because of the texelling. What has had a huge improvement is to upscale the image to the next size (eg 2048 > 4096), save it, convert to .paa, save THAT back to .tga, downscale back to 2048 and save, then reconvert to .pga. It's like being a one-legged man at a butt-kicking contest, but it seems to be the best solution so far. It doesn't completely solve the issue, but the textures look a heckuva lot better.

The ultimate solution, aside from making the need for compression obsolete, would be something that does all this within photoshop, or defining a palette of safe colors to work with.

[ianbanks 30]

I think I may have unearthed a solution for the artifact problem. After doing some research on DXT conversions, I learned that it actually uses two colors, decided by an average, for every 4x4 block of pixels, called texels - or something along those lines. I remember going through this back in the old days with UT2004, but for whatever reason I only suffered strange colors back then, and not blockiness. The color issue was minor, because they were consistent enough to get the point across visually. I was also only using 1024x1024 images back then.

 

DXT1 is used on SMDI which gives you 4 colours, which are equidistant linear mixes of the two colours you mentioned. DXT1 picks those two "endpoint" colours and then the extra two colours are 1/3rd and 2/3rds between them.

One issue might be is that the two "endpoint" colours are only encoded with 6 bits (for specular) and 5 bits (for specular power). If your maps have a low dynamic range (for example, a channel only uses values 0-20 instead of 0-255) you could try scaling the channels up and then reducing the specular or specular power in the RVMAT. The specular power (B channel) in an SMDI file simply multiplies the specular power and the specular (G channel) (almost) simply multiplies the specular value.

 

Also, TexView2 can show you the compression error while you are trying to tune things. You change the pulldowns that are under the menu to (for example):

RGBA    RGB Difference

DXT1     ARGB8888

[scotg 204]

DXT1 is used on SMDI which gives you 4 colours, which are equidistant linear mixes of the two colours you mentioned. DXT1 picks those two "endpoint" colours and then the extra two colours are 1/3rd and 2/3rds between them.

One issue might be is that the two "endpoint" colours are only encoded with 6 bits (for specular) and 5 bits (for specular power). If your maps have a low dynamic range (for example, a channel only uses values 0-20 instead of 0-255) you could try scaling the channels up and then reducing the specular or specular power in the RVMAT. The specular power (B channel) in an SMDI file simply multiplies the specular power and the specular (G channel) (almost) simply multiplies the specular value.

 

Also, TexView2 can show you the compression error while you are trying to tune things. You change the pulldowns that are under the menu to (for example):

RGBA    RGB Difference

DXT1     ARGB8888

What you're saying, essentially, is that if my specular power is too subtle, then it can look blocky. Is that correct? 0-20 isn't much compared to 0-255, but it seems appropriate for nearly-flat, anti-gloss/glare military surfaces. I almost think the original image might have too many colors within an even smaller color range than 0-20. EG, instead of using 4 different colors over a 21 color range, it could be due to my using 8 colors over an 8 color range, like 9-16. Admittedly, this theory is based on possibly an incomplete understanding. It may or may not be worth mentioning that not every portion of the image has such a limited range; there are surfaces that require more dynamic specularity. It's just that the majority of these issues occur on large areas of subtly different pixels of low-specularity, intended to represent the broad sides of vehicles with low-glare paint. I think the best thing to do at this point is to open up a BIS *_smdi.paa and convert it to TGA, then analyze that in photoshop to get the range needed.

 

RVMATS: For simplicity's sake, I'm trying to stick with the ones that are already in use. EG if there is a BIS object with similar surface properties that I desire for my objects (mostly vehicles), then I will incorporate its settings into my own rvmat.

 

<rant> //not directed towards anyone - just a general rant expressing general frustration

I look back at how long it has taken me so far to try and figure this out, compared to previous projects. I've been a graphic artist since 1999, and I'm having these issues that seem so elementary. I've dealt with many forms of color optimization in my career, working on 2D and 3D projects. I look around and see that nobody else is suffering the texel blocks in their textures. Either I'm unintentionally making it harder than it has to be, or there is some other setting I'm overlooking. Should I be looking at color settings, profiles, etc. in photoshop? I've already tried adding noise with moderate (but not full) success. I've been upsizing 2048 images to 4096, and then converting to paa, then downsizing it back to 2048 - with even more success, but still not quite fully there. Moreover, it's a huge hassle! To make matters worse, I can't use imagetopaa for batch conversions because my P: drive is not working properly. It's all just downright frustrating. If I didn't feel like I have such a great project and if I wasn't so dedicated, I'd have given up on all this long ago.

</rant>

[ianbanks 30]

To sum it up, you want your SMDI maps to use the full range of each channel. The channels should be used to modulate the values (specular and specular power) that are in the RVMAT, not to try to "turn them down" everywhere.

 

Also, have you tried adding small amounts of noise to the normal map?
 

I look around and see that nobody else is suffering the texel blocks in their textures. Either I'm unintentionally making it harder than it has to be, or there is some other setting I'm overlooking. Should I be looking at color settings, profiles, etc. in photoshop?

 

I see DXT1/DXT5/related artefacts in game all the time (even in satmaps), but I think I'm a bit special that way.

[scotg 204]

To sum it up, you want your SMDI maps to use the full range of each channel. The channels should be used to modulate the values (specular and specular power) that are in the RVMAT, not to try to "turn them down" everywhere.

So maybe it would help the overall map if empty space (non-UV mapped) had full range... i.e: add highlights where they are not needed for the sake of image integrity -- is that right?

 

Also, have you tried adding small amounts of noise to the normal map?

Strangely enough, I'm not having issues with texel blocks clustering in my normal maps. It could be due to the DXT5 format, or that the typical colors in a normal map are diverse enough to prevent the blocks. Since you said "small amount," I'm wondering if you could be more specific. On a related side note: adding noise to the diffuse (_co/_ca) map does indeed help prevent the clusters forming.

[p1nga 23]

Just to chime in on this,

 

Ive noticed that if you are having issue with blocky artifacts after conversion, you can try exporting the texture from photoshop using the 'Export for Web' options which compresses the image before you turn it into a PAA.  If you open the compressed image and compare it to a uncompressed one, it will be hard to see the difference,  if you then convert both of them to PAA, you will notice the one you 'Saved For Web' will be substantially cleaner.  In the end, photoshop does a better job of compressing the image and then when you convert it to PAA it hardly has to change anything.   I typically only have to do that on textures that have lots of black or very dark colors.

[scotg 204]

Just to chime in on this,

 

Ive noticed that if you are having issue with blocky artifacts after conversion, you can try exporting the texture from photoshop using the 'Export for Web' options which compresses the image before you turn it into a PAA.  If you open the compressed image and compare it to a uncompressed one, it will be hard to see the difference,  if you then convert both of them to PAA, you will notice the one you 'Saved For Web' will be substantially cleaner.  In the end, photoshop does a better job of compressing the image and then when you convert it to PAA it hardly has to change anything.   I typically only have to do that on textures that have lots of black or very dark colors.

I had a similar thought, but I wonder what your settings are, specifically? I've tried PNG-24, and the blocks were still there. PNG-8 creates a file unreadable to TexView2, and JPG seems to enhance the blocks. My textures are rather dark as well, especially the _smdi channels, but also the _co and _ca.

 

It appears that contrasty is working the best. I played around with legacy brightness and contrast in the green channel of my _smdi image until it was not making blocks. Some parts got a little too bright as a result, but at least it gives me a new starting point to work with. This is all subject to theory for me at this point, because the method I used to quickly discover if it was blocky was to screen-cap TexView2 with my newly contrasted file open, paste it into a new .psd document, desatch, and again adjust the brightness. I figure if it can go through that much conversion and still remain unblocky, then it must be working.