[FIX] Workaround for faulty texture sorting (units visible through smoke, etc)

[kenoxite 156]

I thought I'd share this little workaround I've come up with regarding wrong texture sorting.

As per title, it refers to the cases where units aren't hidden by particles, usually smoke. Like here:


This has been discussed before, and even some solutions were provided by a dev. Unfortunately, none of those worked for me for this particular texture.

For some reason, the texture used for the equipment of the units shown in the screenshot above was causing all this problem with sorting. Nothing mentioned in that thread worked for me. Neither changing the name of the texture, copy pasting in a new file, exporting from the blood version (with blood hidden), exporting to tga through Irfanview (instead of GIMP), etc.

There were some oddities regarding the texture, though. Its size, once conveted to .paa, was particularly big (about 300kb when the rest were 170). Also, checking the texture in TexView2 (as it provides more feedback than TexView) showed that the texture was in AI88 format and not DXT1, as it should. Why this was the case, I don't know.

The workaround
Seeing that nothing I was trying worked, and that the exported tga seemed to be the root of all the problems, I decided to export to jpg instead, and created the paa from version. This solved it.

So, if you ever happen to be in this same situation, consider exporting as jpg instead of tga. No idea how to work around this when using textures with alpha channels, though. Not sure the jpg can preserve the alpha information.

The same units with fixed textures (they are properly hidden now):


And here's a zip file with the faulty texture and both the bugged and fixed paas, just in case you're curious or come up with another workaround: https://www.mediafire.com/download/3sd6bm2z9klsvph/bugged_texture_example.zip

[krzychuzokecia 717]

Strange bug indeed, actually I don't recall if it ever happened to me. But I use mostly .png to make a .paa file, so maybe that's it?

[kenoxite 156]

I'll export as png any future textures then. Not that the higher output quality of png over jpg matters in OFP, but the support for alpha channels will definitely come handy.

And it was a weird bug, idd. From all the EXT textures I've revised that was the only faulty one. For no apparent reason whatsoever.

[Lenyoga 326]

Awesome, thanks! I encountered this bug now and then, but usually went with smaller drop effect sizes. I'll see if this also helps with other texture/alpha related problems one I encounter them again.

[kenoxite 156]

@ krzy: What settings are you using to export to png? I don't seem to found the correct ones. My pngs don't load in TexView.

[vektorboson 8]

There were some oddities regarding the texture, though. Its size, once conveted to .paa, was particularly big (about 300kb when the rest were 170). Also, checking the texture in TexView2 (as it provides more feedback than TexView) showed that the texture was in AI88 format and not DXT1, as it should. Why this was the case, I don't know.

If an image contains only black/grey/white, the converter decides to use IA88, because it gives 8 bits to greyscale; unfortunately it also gives 8 bits to alpha and even if the alpha channel is completely opaque, the engine will recognize the texture as being a texture with alpha channel.

Now comes the hairy part: Since the IA88-texture covers a lot of area of the model, the P3D or LOD gets flagged as being "transparent", and then gets drawn in a bad order. Therefore, avoid texture file formats with alpha channel, especially for the larger parts of your model.

[kenoxite 156]

Amazing explanation, vektorboson. Mistery solved, then. This will surely help others.

So, it seems jpg is indeed the only way to bypass this problem. Png wouldn't have worked in this case (as it preserves alpha information).

[Macser 776]

Hey guys.I don't think jpg is the best choice for game textures.I've had this discussion with Vektor and others before.

Although the jpg is relatively small on disk it apparently can't be used in the same way as dxt textures with video memory.

Despite both being compressed formats.

Do you get the same issue with 24bit tgas(no alpha)?

Also keep alpha textures separate.Rather than incorporating them into the main images.

In your models try selecting all the faces that are causing an issue,and "move to bottom",or "move to top" in O2.

Although if it works,and there's no complaints............. :)

[kenoxite 156]

Hey Mac.

Don't worry, textures are still in paa format. So, instead of the usual:

GIMP -> export tga texture -> Tex View -> final paa texture

to fix this particular problem you should:

GIMP -> export jpg texture -> Tex View -> final paa texture

This is to avoid Tex View messing things up with textures heavy on black and whites (or greys). Using a jpg instead of a tga to create the TexView texture fixes the alpha sorting in the final model. And the texture used will still be paa.

[Macser 776]

Aah.Right.I haven't used Texview in quite a while.I didn't realise it accepted JPGs. :)

The other info about moving to top or bottom and separating textures should still be valid.

[kenoxite 156]

Yes, I tried changing the order before trying to export as jpg. Didn't try the bit about separating textures, though. I don't think it would have worked in this case, anyway, as the texture itself didn't have any alpha channel. It was just TV believing the texture had one (or, more likely, believing it _was_ one).

[faguss 65]

TexView automatically selects texture format when you save .paa. TexView 1.1 for grey TGA files will pick IA 8:8 (as Vektorboson said above). TexView 2 doesn't do this but it has a similar issue where it will prefer DXT5 for transparent textures and then you won't be able to use them in OFP.

 

To avoid autoselect, save file with .pac extension and the program will convert it to DXT1.

 

Also I recommend to mostly avoid TexView 1.1 because it produces artifacts and leaks memory. Use TexView 2 for ArmA 1 or PAATool or PANTool. In PAATool you can manually select format. In TexView 2 you can do the same by following naming convention. For example _co.paa will result in DXT1. You can add your own suffixes in TexConvert.cfg.

Edited June 4, 2021 by faguss
added extra info about tv2; updated texview2 link

[krzychuzokecia 717]

15 hours ago, faguss said:

In TexView 2 you can do the same by following naming convention.

Oh noes... Now my OFP textures will have the same suffixes as Arma textures. How I'll recognize which is which!? 

[hitman1987 69]

PAAtool, DXT1/RGBA5551with no alpha filtering might to help with the bugged edges.