Transparency Sorting Issue

[AGP]

Obviously, the right side one is the jpct-rendered one. The object is being set to a transparency value of 252. The texture has alpha channel, and is being initialized with true set in its constructor. For scale, I placed a cube as created by Primitives.getCube(5f). The sorting is less than desirable. Please advise how to address this. I've noticed that there's a setSortOffset method, but it (jpct docs lack this too often, in my opinion) gives us no idea of scale. Thanks in advance.

[EgonOlsen]

setSortOffset() has no scale by itself. The scale depends on the scale of the scene. Anyway, it won't help here. In fact, nothing does. You have on influence on the order in which polygons are being drawn in an object. You can only sort between objects, not inside of objects. For transparent objects, this will have the effect that you can witness here. There are only three solutions:

• Don't use such objects
• Split the objects so that transparent and opaque parts end up in different objects
• For the Android version: There's no other way. For the desktop version: Don't compile the objects. That will make the engine revert to per polygon sorting. That might help in some cases, but not in all.

[AGP]

The only sort of reasonable option of the three you mentioned is number 2, but that may prove to be a nightmare if I have to re-rig the character. Is there really no way around this? If you wanted to, could you change the accuracy of the sorting (and, if so, isn't that worth adding to Object3D?)? I really need this character, and its hair is what defines it.

[EgonOlsen]

No, unfortunately there's no way around this. The order in the mesh data defines the rendering order and there's no way to change that at runtime unless you render each polygon on it's own, which happens if you don't compile the object.

[AGP]

I see. Here's how it looks decompiled:



Still some z-fighting, but the fur looks nice. Could I do something about the z-fighting?

[EgonOlsen]

Other than seperating these parts some more...no, i'm afraid not. You can try to decrease the far plane to increase zbuffer accuracy, but i've never actually seen a case where this really helped.

[AGP]

I know little about the problem, but isn't this a per-pixel/per-polygon thing? As in, isn't jpct doing per-polygon sorting whereas it could be doing per-pixel? Or am I completely off?

[EgonOlsen]

No, it can't do per pixel sorting, because the pixel information is available to the GPU only. If the parts in question are opaque, it's a depth buffer precision issue. If it's all transparent, it's a sorting issue. In both cases, there's nothing you can do about it. Polygon sorting is never 100% correct unless you are using some very complex algorithms that finally include polygon splitting and such. That is much to complex for a real time engine. If it weren't, no hardware would have to use a zbuffer instead.

[AGP]

I see.

The reason I'm being reluctant about separating the fur from the face is the fact I wouldn't just lose its rig. It's got a morpher with several expressions which will go completely to waste. And although I haven't tested this model in another engine, I think that other engines would display it properly. If I were to test it in, say, Unity, and I showed you it worked (I can do this tomorrow at the office), what could you say it was doing differently? The reason I'm suggesting this is the fact that I can't imagine that fur is that tough a subject to crack for a character (and it's already so hard to put characters in jpct as it is...).

[EgonOlsen]

No, they won't. At least not when using the same render mode, i.e. alpha transparency. There are solutions for order independent transparency but they work only on the latest hardware and are far away from the scope of this engine: http://en.wikipedia.org/wiki/Order-independent_transparency

It might be possible to do it by using alpha testing instead of alpha blending, but that will lead to sharp edges around the textures, is not advised to be used on mobile devices for performance reasons and isn't supported by jPCT anyway (and it's not going to either).

[EgonOlsen]

Some more information about it: http://www.java-gaming.org/topics/ordering-draw-calls-for-alpha-blending/33772/msg/317774/view.html#msg317774

[AGP]

What a nightmare. Thanks. Back to rigging and making new morphs it is...

[AGP]

By the way, I did have it tested on Marmoset and by using a process that I'm told is called dithering (I'm not sure that I'm told correctly but it's only about some data in the texture) it worked perfectly. Sentences like "and it's not going to, either" sound like you feel that I'm shoving something down your throat. But don't you think that fur is important enough a thing to at least be considered for a while?

EDIT: "Alpha to Coverage" appears to be what Marmoset's "Dithering" is typically called.

[EgonOlsen]

Yes, that dithering is a solution to the problem, albeit a very ugly one. Seeing dithering of that kind in 2014 is kind of retro to me and the only games that i know of that use this do it in the distance to fade out entities. Not for close ups. The thing is, that a solution to this problem (even an ugly one like the dithering) can't be added without shaders. So i would have to limit this to OpenGL 3.0+ plus i would have to write a dozen of shaders (or one slow Über-Shader) to mimic everything that OpenGL 2.0 does. That's just not worth it to me. 

[AGP]

I see your point about the shaders. For the record, in my opinion, it looks great in Marmoset: