Alpha over Alpha

I think this question is asked a million times. Is LL going to fix the alpha over alpha problem? (2 alpha channeled textures will cancel each other out) I am building right now a replica of a motorbike, and was thinking about the motor texture and the "alluminium cap" covering the motor texture. I applied the texture i worked on a while on a prim that was supposed to be the cap, but as you guess so, it canceled the cap out and the motor was seen through it (the shape of the cap required an alpha channel)

I guess now i need to build the cap in prims instead of using 1 prim and texture them without alpha channels.

So I keep questioning, are they gonna fix that bug or not

The alpha sorting glitch is not just an SL thing. It's a quirk of OpenGL. It affects everything from video games to high end 3D modeling applications that cost thousands of dollars.

Even if it could be "fixed", the question of whether it should is perhaps more important. While the glitch makes building certain things (like the way you wanted to do your motor) impossible, certain other things are only possible because of it. The common methods for modeling things like trees, plants, fire, and many other items depend on the glitch. Eliminate it, and you break all those items.

The best solution would be if there were some way to alter the behavior on a per-object basis. I don't know if that's technically possible or not.

As for what to do in there here and now, my usual response is this. If you ask professional game artists how they deal with alpha sorting, the most common answer you'll get is "we avoid it all costs".

For your specific project, I'm wondering why the motor and the cap can't all be one object, one texture.

For all practical purposes, it is not possible. What I mean is that it technically can be done, but it would cause such a hit on framerate that the solution is worse than the problem. Glossing over the technical details, basically the system the computer uses to tell which pixels to draw is currently very simple (ie. it only works completely correctly with completely opaque polygons) in order to be fast. Making things any more accurate would be entirely too taxing on the computer. Probably some day when graphics cards get more powerful there won't be sorting issues with alpha transparency, but right now it's a limitation we have to accept.

Incidentally, while there are programming tricks that can help alpha sorting in many games, as with many graphics shortcuts these tricks depend on geometry that is carefully prepared ahead of time by the people making the game. That doesn't help any in a system like SL where any random person can make any random thing at any random time.

They've already said it...

It's not an SL thing...it's an OpenGl thing. It will never be fixed until they completely overhaul OpenGl itself.

For now, you have to be creative in your design to accommodate.

Cheers.

It's such a shame, so many things in SL would look so much better with the alpha textures sorted correctly.

One thing I don't understand is what things it makes possible or better? Chosen Few, you mention fire, plants and trees. All the plants and trees I have look a bit odd because the 'far' textures appear over the top of the 'near' ones. How does that make them look better? Maybe some sort of optical illusion cube might be possible, but plants are one of the main reasons I'd like to see it fixed.

A lot of cases of alpha sorting problems would be solved immediately by support for decal textures and/or multiple textures per face. A lot of of what is currently hacked in with prims (shadows, baked lighting effects, etc) could be done cleanly and efficiently by multitexturing which avoids geometry sort issues altogether.

Add it to the giant SL wish list

I for one hope your wish never comes true... one more layer of textures for makers to overload my poor bandwidth and video card with? uhm thanks, I'll pass.... granted it would be pretty

I don't know if it helps or hurts, but I've found layering alpha textures from the inside seems to avoid the bug in most cases...

how I do this is to have 2prims that touch have a texture facing the other, and the outsides can also be alpha'd textures, or pure alpha...

obviously this increases prim use, but it can be used to simulate complex flat shapes accurately and without running afoul of the sorting glitch, which can occasionally reduce prim use.... for instance box in a hollow box used to create realistic table/chair legs

IM me inworld and I'll demo the idea for you if you want

Void, people are already doing it, just on seperate prims.

Reducing the need for extra prims might add texture streaming overhead, but if that is a concern, but secondary textures could have a very low streaming priority. The combined texture for a face could even be cached similar to the baked textures on avatars.

They ALL look that way? They shouldn't. Typically, simple plants and trees are made by putting a picture of the plant on a flat plane (squashed cube), copying the plane a couple of times. and then rotating the two copies in place by 60 degrees and 120 degrees. The result is that since the 3 planes share the same center point, there's no such thing as "far" or "near". Whichever one is most facing the camera will be drawn as "in front", the other two "behind". As you rotate your view around the object, the plant will appear to face the camera almost at all times.

I have noticed that some people who make plants don't understand how the process works, and they attempt to have the planes intersect at the tree-trunk centers instead of the prim centers. If the trunks are off-center in the imagery, people end placing the prims off center to match, and then the illusion fails horribly, just as you're describing. People need to understand that it's not any particular detail of the textures that makes it work (all pixels on all textures are always treated equally by computers); it's all about where the prims are.


I never said that at it makes anything look "better". That wasn't the point. Nothing in real-time 3D is ever just about any one thing, including looks. It is ALWAYS about finding the optimum balance between visual quality, resource consumption, and computer performance. Any building technique that does not seek to balance all three factors has no business being employed in a real-time engine.

If having things look their absolute best is your chief concern, then please don't take this the wrong way, but your best bet is to get out of real-time altogether and to start working on CGI films. If you want to be working in real-time, then balance is paramount.

To elaborate, obviously, what would absolutely look best would be to model geometrically every single branch, every leaf, every flower. But that just would never be practical in SL, as it would take thousands of prims just to make a single tree. The gains in visual quality, however spectacular, could never be enough to outweigh the tremendous performance drawbacks.

The picture-on-planes method, on the other hand, while far from visually ideal, is convincing enough that people can tell what it's supposed to be, while requiring just 3 lil' prims (or when the same technique is used in video games, which it often is, 6 polygons) to make an entire tree. It obviously looks nowhere near as good under scrutiny as the "model every last detail" method would, but the resource savings are so radically huge, they outweigh visual drawbacks by a thousand fold.

Between "looks great but makes system choke" or "looks OK but system runs just fine with it", I'll take the latter any day. Were we talking CGI film, then looks would be everything, but in any real time application, whether it be SL, video games, or anything else, balance is what makes the world go 'round. Make sense?


Yeah, Daniel, that would be awesome. LL's been talking for years now about a "coming soon" material shader system to replace the current texture system. Presumably, it would make some degree of layering possible, which would solve all kinds of problems. When we'll get to see it is anyone's guess.

Sorry if i`m going over what has already been said............

I noticed that some textures have alpha channels when they dont need to, such as floors or walls with no windows or any need for them. I think some paint progs automatically set a tga with alphas when you only actually need them for certain things

Well, thats my penny`s worth...... just gotta make sure i remove alpha channels on my floors!!!

That's possible, but more likely it's user error. It's a common mistake when people are new to texturing to assume that "more bits" must somehow be better than "less bits", so they save everything as 32-bit at first.

My targas have more bits than your targas.

PSP (from about 7+ I think) ONLY saves as 24bit, and then internally bumps it up to to 32 if you have any alpha channels specified (IIRC it drops all those after #1)

this is usually good for beginers, because they rarely use the alpa channel, so don't end up with alpha channels in non alpha textures

it can be bad if they save masks there that have nothing to do with the pictures transparency though...

PSP users you've been warned =)

Well as my starting post said, i am building a motorbike (trying to script it now since the prim limit on vehicles are 35 prims, learned something, since my bike is over 150) anyway, when I make textures, I never apply a alpha in it unless needed, first of it takes less space in the picture size and rezz time, second off, like i state, alpha on alpha cancels out, suddenly parts of your work dissapear when you angle your cam.

With my bike, the motorblock, i decided to do it different. I build it out of lose prims and textured them with handmade textures, non alpha, and the cap that protects the engine, i made that one alpha. The idea of making textures on each other (dunno who said it) didn't work to well, since there was no depth, something i really wanted in it.