Jump to content
kenoxite

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

Recommended Posts

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:
OqOoWMYl.jpg

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):
BUqv6Qal.jpg

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

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

@ 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.

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites

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).

Share this post


Link to post
Share on other sites

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............. :)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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).

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

×