[Models] Alpha Skins - Needs GPL'd "Triangle Depth Sort

[Tormentor667]

Okay, I just talked to Torr Samaho and he said, that he might implement that, but there is one condition that must be fulfilled before he start:

As I mentioned earlier, full alpha support requires depth sorting of the triangles. At least at the moment I can't be bothered to write an algorithm for this from scratch, because it's like reinventing the wheel. Countless implementations already have to exist. If somebody can point me to a ready to use C++ implementation, I'll have a look at it.

So what we actually need to have this implemented is the C++ based and GPL'ed implementation of a depth sort algorithm for triangles.

Anyone? Or does anyone know where to get that? Any open sorce or GPL'd 3d game or demo that we can get the code from?

[Graf Zahl]

How can GPL code be used here? Even if I got rid of FMOD that'd still prohibit it from being used in Skulltag.

[Chris]

Wouldn't the proper way to handle this be to split up a model into sections (left hand, left forearm, left upper-arm, torso, etc), then construct some way for GZDoom merge them? It'd be far simpler to sort by section instead of individual triangles.

IIRC, newer model formats, like MD5 (no hint there..) can even have multiple meshes in a single model, allowing them to be sorted according to their centers.

[Torr Samaho]

Graf is right, GPL code won't help, and just for the record, I never asked for GPL code.

Wouldn't the proper way to handle this be to split up a model into sections (left hand, left forearm, left upper-arm, torso, etc), then construct some way for GZDoom merge them? It'd be far simpler to sort by section instead of individual triangles.

No, proper transparency requires full on-the-fly sorting of all transparent triangles.

[Chris]

No, proper transparency requires full on-the-fly sorting of all transparent triangles.

Only for concave shapes (or if back-face culling is disabled, but I believe GZDoom has that on anyway). If you split a model into roughly convex shapes, there's no way any two visible triangles from the same section can overlap.

[DaniJ]

Naturally. However, successfully fragmenting an animated model into n convex polytopes is definitely not an 'easy' problem and requires quite a substantial implementation which (I might add) is not a straight-forward thing to write.

I can fully understand why neither Graf nor Torr want to bother with it. Heck, we don't even bother with doing that in Doomsday.

[Chris]

However, successfully fragmenting an animated model into n convex polytopes is definitely not an 'easy' problem and requires quite a substantial implementation which (I might add) is not a straight-forward thing to write.

It wouldn't be done pragmatically, of course. That's a bit too much. The model should be made for it in the first place, and for that it would need a model format that can support separations (like MD5). The main problem would be that the vertices are weighted, so a convex section in one pose may not be convex in another.. I'm not sure that would be a huge deal, though, if the model is made properly.

[DaniJ]

Most of the so-called "modellers" in the DOOM community can barely cope with simple format conversions. Do you seriously expect them to be able to do such a task manually, successfully?

Something like that would have to be done programatically if only to safeguard peoples sanity.

[Chris]

Most of the so-called "modellers" in the DOOM community can barely cope with simple format conversions. Do you seriously expect them to be able to do such a task manually, successfully?

Is it any better to shoehorn a feature in with an inefficient implementation that can cause more headaches as the engine matures further? I mean, I don't know what Graf's going to do, so consider this what-if argument, but if it's implemented in this way (per-triangle sorting), and somewhere down the line MD5 or some other modern format is implemented, people are going to want the same feature there. But considering newer formats can have models with literally thousands of polys or more each, any per-triangle sorting method would not be worth it.

At that point, people are going to have to learn to do it properly anyway, or lose the feature. And I just think it's better to do it the right way the first time, instead of throwing in a lower quality method that's only going to cause problems down the line. As it is, simple masking (doing an alpha test and discarding anything that's not 100% opaque) should work fine. Even additive/multiply blending should work, as long as the objects themselves are properly sorted, since those don't need per-poly sorting to blend properly.

[DaniJ]

I appreciate your argument but I think that doing it manually is probably beyond what most modellers in this community will be prepared to do. I agree that implementing a substandard algorithm to do it automatically is not a good idea. Its a case of do it properly or don't do it at all imo.

So long as the models themselves are sorted correctly then yes, most blends and indeed alpha tests will work just fine but obviously there will be no self-occlusion et al. Depending on Grafs plans for the engine this may be sufficient and this is currently as far as we go with Doomsday's implementation.

[Torr Samaho]

So long as the models themselves are sorted correctly then yes, most blends and indeed alpha tests will work just fine but obviously there will be no self-occlusion et al. Depending on Grafs plans for the engine this may be sufficient and this is currently as far as we go with Doomsday's implementation.

Can you elaborate a little what Doomsday exactly does? Even a model as simple as a sphere has self occlusions.

[DaniJ]

In Doomsday we sort all models by depth from the viewer, currently by the position of the mobjs they are associated to (note that in Doomsday there can be multiple models representing a given mobj and any number of which may be visible at once. Each (sub)model has it's own origin, relative offset (from mobj center) etc, etc...).

Drawing is done in reverse depth order (furthest to nearest to the viewer) drawing all visible submodels for a visible mobj. We do nothing about the case where a model from one mobj intersects a model from another mobj as this is extremely rare given the bounding boxes used in the playsim collision system . When drawing the submodels of a mobj we do not worry about occlusions between them, it is up to the mod author to define them in "inner-most" to "outer-most" order (for example, a skull spinning inside a sphere would be defined so that the skull submodel is first with the sphere next in the definition itself). Each submodel has a set of flags which allow various effects to be achieved, for example, disabling depth writes, flipping faces and disabling back-face culling. Depending upon which effects are used we then draw the model using multiple passes as necessary, for example, if environmental texturing is used.

Thats basically it. We don't bother doing any splitting at all, as 99% of the time there is no need to (won't be noticed) and in the instance where parts of a model need to occlude with others the model can be split into submodels and ordered appropriately in the model definition, by the model author.

So if I understand correctly, "all" GZDoom is missing from the above is the submodel feature.

However. The Doomsday model renderer is scheduled for an overhaul in 1.9.1 so all this will be changing quite considerably (we want to leverage modern hardware more effectively).