Alpha Sorting Almost Makes Me Weep

So I just spent the last month off and on making a building that has alphas in most of the walls using hollowed megaprims. Now when I place objects inside it that have alpha channels, they of course appear to be outside the walls. (should have thought of that) Had I not a spine of steel I'd weep. I'm thinking of rebuilding it with separate walls to try to ameliorate the problem.

Has anyone had luck with that approach?

Is there any hope that things will get better some day?

The use of alpha channels in textures is what makes the sorting glitch. The only way to remedy it is to use textures with alpha channels sparingly. And when you do use them place in such a way that any other texture with an alpha channel will not be viewed in line with any other other texture having an alpha channel. Nearly impossible but it can be minimunized with some planning and thought.

And I doubt "things will get better" any time soon. It's the nature of graphics rendering engines. Both OpenGL and DirectX have the glitch.

Megaprims can really magnify alpha sort order problems, I think it tries to decide which prims are rendered as "in front" based on each object's center, so with a large megaprim it's center is much further off - not sure if this is technically it, but that's the impression I've gotten.

re : hope things will get better, I wouldn't hold my breath, since it's not exclusive to SL and something that even game designers have to work around.

Things could be made a lot better. Windlight has significantly more alpha sorting problems than the Classic SL rendering engine did. It looks like Windlight works on the object center, while the classic rendering engine used the face center.

For all the complaints about the alpha sorting glitch in SL, the fact remains that SL actually handles alpha sorting FAR better than most other 3D apps do, including the majority of video games. As I said earlier, the only reason you don't see it in games is because professional game artists go to whatever lengths are necessary to build around it.

That said, yes, it COULD be made better, as Argent said. But to do so would, in all likelihood, carry some serious drawbacks:

First, the more sophisticated you make the system that figures out the draw order, the slower it will operate. There's no way around that under the current standards for how graphics pipelines work.

For example, Maya has an option for advanced transparency sorting, which generally does a really good job of making sure things are drawn in the right order. But when it's enabled in any but the simplest of scenes, frame rates drop considerably. Consider the already low frame rates SL operates at on most computers, factor in that the average scene in SL tends to be far more complex than a typical working scene in a traditional 3D modeling program like Maya, and any attempt at employing a similar system in SL would be a recipe for disaster. It just wouldn't be able to operate at any semblance of speed.

Once real-time raytracing starts to be come the norm, as opposed to traditional rasterization techniques, a lot of things will change, including transparency sorting. But we're still several years away from that. Significant changes to hardware standards need to be adopted first, and that's going to take time.

Second, the glitch has been such an inherent part of 3D graphics for so long, techniques have evolved to take advantage of it, rather than simply hide from it. Certain objects and effects like trees, plants, fire, chandeliers, etc., are commonly created to capitalize on the glitch, to the benefit of geometric simplicity. Were the glitch to be "fixed" tomorrow, a lot of existing content would break.

That's not to say that we should hold on to old techniques forever, of course. Certainly as technology evolves, we do need to evolve ourselves along with it. But all perspectives (no pun intended) should be fully understood and fully considered before deciding what's a "fix" and what's not. To solve one problem by creating another is not necessarily a good decision (or a bad one).

Bottom line, alpha sorting is a minor annoyance in SL, and will continue to be for the foreseeable future. Even if you do all the right things to work around it, just like the pros do, your neighbor might not, and then your build will be screwed up anyway. All we can do is deal with situations as they arise, and employ the best solutions we can. Sometimes that means we can't design things quite the way we want them. Frustrating as that may be, it's just part of the SL experience. It is what it is.

Bodhisatva, I'm not quite sure what you meant by "separate walls", but it sounds like you're on the right track. If your current design isn't workable, redesign. It's often a good idea to make a 24-bit version of every 32-bit texture, and then break a wall into sections. Keep as much of it opaque as you possibly can by using the 24-bit version, and then use the 32-bit version only for the section(s) that absolutely need transparency. That could mean making a wall out of two or three prims instead of just one, but generally it's worth the investment.

Another option is to "insulate" a wall by hiding opaque prims inside partially transparent ones.

There are lots of possibilities. Employ a little creative problem solving, and I'm sure you'll be able to glitch-proof your build just fine.





By the way, Argent, how certain are you that a change actually was made with Windlight? I never noticed any difference, myself, between how Windilight and pre-Windlight viewers handle alpha sorting. Perhaps I'm just not observant enough, but as far as I could tell, nothing changed in that regard.

I've always just chalked up the claims of "alpha sorting is worse with Windlight" to the rantings of the small but vocal "everything's worse with Windlight" crowd. As you're not a member of that group, I'd love to hear more about your assessment of what actually did change, and what didn't.

I can't swear to WHAT the change was, but it was definitely real. I tested both versions looking at the same prims from the same point and the difference was startling. It was particularly obvious with cross-prim trees, which is what made me think it was a switch from per-face to per-prim sorting.

And we could have real-time ray-tracing now, hardware real-time raytracing was demoed at SIGGRAPH 2005 using FPGA hardware that was comparable in gate-count, speed, and memory bandwidth to a late-'90s entry level GPU like a Rage Pro, and poly counts in the millions. The problem is an "Open Raytracing" API suitable for games doesn't exist. There's one called OpenRT but it's proprietary.

Thanks, Argent. I'm tempted to install a non-Windlight client, and do some testing.

I was unaware that current common hardware could support real-time raytracing, so thanks for the info on that.

Assuming it is possible with today's hardware, here's an interesting puzzle. During the the whole Intel/nVidia public fight that went on for several months late last year through early this year, one of the things both sides were claiming was that a major benefit of proposed cGPU's over current GPU's would be the realization of real-time raytracing. Intel started that particular discussion, if I remember correctly, by implying that their cGPU's would surpass nVida's GPU's in every conceivably way, with raytracing as the flagship example. nVidia initially responded with cries of "it's not fair for a big guy like Intel to pick on a little guy like us", but then seemed to jump on the cGPU bandwagon themselves, again touting raytracing as one of the chief benefits.

Perhaps all this was just posturing or creative advanced marketing for future devices, but it did seem to suggest that neither Intel nor nVidia believed real-time raytracing would ever happen in earnest, or possibly at all, without major architectural changes to hardware. Thoughts?

I'm pretty sure it's a conflict between their business plans and what they see as a niche market.

Intel is in the business of selling CPUs. CPUs are bad at raytracing compared with custom hardware.

nVidia is more complex. They have a long term plan which involves using the GPU as a general purpose CPU. Their GPGPU is also not super-good at raytracing.

So, yes, it would take architectural changes, but:

The changes are not a research project, that's been done. You do need custom hardware that nVidia and Intel don't currently make, but the technology is sound. It would also be something that would be useful as a relatively small (hence cheap) subsystem... if there was an open API to make use of it.

So, it's not a matter of "we don't know how to do this", it's a matter of "we don't think we can make money doing this, but we don't want to put things wuite that baldly".

That all seems to make sense. Thanks, Argent.

What I meant was that instead of hollowing, say, a 20x25m box to make four walls with one prim, and thus putting the center of the prim smack in the center of the build and in front of everything, I'll try making the walls all with separate prims. It will be some time before I can test it extensively. It's a glass conservatory so there's not a hole (*snicker*) lot of opportunity for inserting alpha-textured windows in opaque walls but I do know the technique and use it when I can.

I must say that in spite of the frustrations, learning the technical side of building and texturing is actually intellectually stimulating. Thank you, all for your comments.

Yes, making the walls 4 separate prims will help, a LOT. With a single hollowed prim, of ANY size, you have several issues.

As you found out, when you put an alpha object inside another alpha textured prim, it does not always realize which is "in front". Essentially, any prim in the closer half of the hollowed space is almost certain to think it should be rendered before the "walls". because the center of the enclosed object is closer to you than the center of the large hollowed object.

Add to that the fact that cameras NEVER focus properly when aimed at the inside of a hollowed prim, of any size or shape. If there is an exterior face of the enclosing prim on the line of sight going *backwards* from the line of sight between the camera and the hollowed interior wall, the camera is forced outside the prim, to point at the exterior at point blank range.

So yes, you'll be much happier with separate wall prims.