The "treetop cube" MDL in the foreground contains an external texture. But when I import make the texture internal the problem doesn't happen.

Greetings!

OKAY, I have an update:

The crazy sorting / z-order / whatever bug happens when you use a 32 bit DDS texture, and have not turned the entity's 'transparent = on'. I have worked around it by simply turning the transparent flag to on, and the alpha to 99. Alternately I have also just converted the 32 bit dds files to 24 bit.

However this only happens when it's using an external texture. If the MDL has an internal texture it doesn't happen.

I hope this will be of some use, and that this will not happen in future versions. Unless it's one of those 'this is a feature, not a bug' situations that I just haven't grokked yet. Well, at any rate, it's weird that it's inconsistent when internal -vs- external textures are used.

Ok! Thanks!

Thanks, this is a very good hint. I'll check. As a workaround, until the next version comes out set the transparent flag for 32 bit external DDS textures.

Jetpack_monkey: I've tested it in the last days, but was not able to reproduce that problem with external or internal DDS textures.

If you still have a level where this problem happens, please send it to the support (support1(at)3dgamestudio(dot)com). We'll then look into the problem.

Z-sorting problems have puzzled me from the beginning. From time to time I see this issue discussed on the forums, but I feel the answers are somewhat confusing and diverse. I'd really like that a single page of the manual, or some website, or someone explained accurately and at once what are the problems about writing to the Z buffer, whatever that means, and why it's so complicated.


This is a question from http://www.conitec.net/beta/afaq.htm

Quote:

---

Q. I have problems with the sorting of transparent or TGA images. For instance, I'm trying to make a tree by crossing two sprite like a 'X. When using TGA sprites, the first sprite always draw before the second sprite. This doesn't happen when I use PCX or BMP sprites.
A. Transparent objects can not write into the z buffer, and thus are simply sorted according to the distance of their origins. This does look wrong when they overlap or are close...

---

This is probably the best answer I found about this. What it does not say is exactly what is a 'transparent object', other than an entity flagged as 'transparent'.

I think any entity that uses a 32-bit texture (meaning an extra 8-bit channel) is considered as having an Alpha channel, and thus, potentially transparent. Even if the alpha channel is not being used, its polygons won't show properly. Maybe the model polygons are sorted after the distance from the object origin, as this answer suggests?
Even objects with 24-bit TGA textures that I import in MED, end up as 32-bits. Once the model is in mdl7 format, I can change the texture to 24-bit and it will be fixed.

Below is an engine screenshot of a model textured with a TGA image. You can see the arms and legs completely out of order. When it happened first time, I spent several hours at the internet to discover that this is NOT a flipped normals problem.



AS far as I understand, you should use up to 24-bit textures. If you NEED to have an alpha channel (For instance, a car model whose windows are partially transparent, or plants that have smooth transparent edges) then you need to code a material that expressly enables writing on the Z buffer, which is slow to render. So, if making vegetation, the advice is to use a 16-bit texture with hard-looking color-cookie cut, or whatever it's called. Did I get that right this time?

|Emilio|

Not really. But I've added some more information to the FAQ explanation, which should clear up the issue a little:

Q. I have problems with the sorting of transparent entities or alpha channel textures. For instance, I'm trying to make a tree by crossing two sprite like a 'X. When using 32 bit TGA sprites, the first sprite is always drawn before the second sprite. This doesn't happen when I use PCX or BMP or 24 bit TGA sprites.

A. Transparent entities - meaning entities with TRANSPARENT flag or with an alpha channel texture - can not write into the z buffer. Thus the engine sorts them according to the distances of their origins. Neverteless, transparency causes visible errors when objects intersect or when a concave mesh consists of transparent polygons. You just have to think a little to avoid those mistakes. For instance, make your 'X' from 4 connected sprites rather than 2 intersectings sprites, and separate a transparent mesh into convex parts.

Hope this helps.

I thought there was a simple shader code to make such entities write into the Z-buffer. It had something with "ZWriteEnable = on" or the like, but don't recall exactly.

look the second post in this thread

That code doesn't fix anything ... just try it out.

Cheers

umm.. why not? it's just for zsorting, not for transparency.
plus, there is an alpha-testing mat which doesn't produce smooth edges along the transparent seams, but works anyway, which you should find in the wiki. btw, seems we had this several times ago already...

[edit] k here comes the proof, it works, at least for me:

my mat from the 2nd post, just with the alphablendenable-line commented out:


smooth...

now the alphatesting provided by the wiki...


a bit worse, i think.


both models are one of loopix' free trees, with either material z-sorting probs do not loger occur. just the quality is different.