It is a "tough" problem, but not a "hard" problem. Give it some time and someone who has a clue about real time graphics and re-tessellation of prims and it can be fixed.

I think this should rather be high priority, though. It's a biggie with regards to graphics integrity.

This sounds like Z-fighting? (If so, I see it @ my place in Grasmere because I'm very fond of transparencies.

The screenshot "Z-Order bug example" shows what at first glance may seem to be a normal screenshot. It is a view from my dining room through the partition doors across the Salon to the rear doors. As the screenshot shows, the rear door texture which is actaully on the back wall of my house appears to be in front of the partition doors and "in" my dining room. A representation worthy of M.C. Escher I think. The Salon is at least 5metres square, the textures both have transparencies and despite their disitnt separation in coordinate space all recent viewers have this problem. The only solution I have found is to waste precious prims on constructing prim doors and windows to avoid transparency, and that assumes you are happy not to have glazingin your doors and windows. Any workarounds that do not involve additional prim usage are most welcome.

I had a book case with afreebie books texture and a wallpaper texture. Placed the book case in front of the wall with the wallpaper on and then changed the angle of view and the wallpaper was see instead of the books.

I chanege one of the textures and it stopped happening. So I Iooked at the textures in Gimp and they both have alpha channels even though it isnt neccessary for them to have. So I dont think its due to transparency itself but due to the alpha channel data overriding the other channels data in some way.

I dont know how occlusion works technicallly so I am stuck at this point but I hope this information helps in some way for those who do know.

[ Show » ] bob wellman - 02/Aug/07 05:01 AM I have noticed that this also occurs with 2 textures that do not appear transparent at all. I had a book case with afreebie books texture and a wallpaper texture. Placed the book case in front of the wall with the wallpaper on and then changed the angle of view and the wallpaper was see instead of the books. I chanege one of the textures and it stopped happening. So I Iooked at the textures in Gimp and they both have alpha channels even though it isnt neccessary for them to have. So I dont think its due to transparency itself but due to the alpha channel data overriding the other channels data in some way. I dont know how occlusion works technicallly so I am stuck at this point but I hope this information helps in some way for those who do know.

Correct, the renderer sees a texture has an alpha channel and from then the object is treated differently. When a texture has no need for an alpha, people should know how to not use it, it only takes up disk space and causes such problems.

I acknowledge that intersecting objects require complex solutions, but objects which are obviously seperated should work fine. Ive yet to see a game with similar issues, to be honest.

Alternatively just an on/off option, either you play without alpha sorting issues and take the performance hit, or you play with them at greater speeds. Could be a good option for snapshots as well, meaning snapshots will always come out perfect even if the game itself looks a bit iffy.

7 years ago people used mask transparency usually, not partial alpha transparency. It's a crapload simpler to sort mask transparency right.

The key thing to note is that most games from the last 7 years use pre-rendered scenes, and as a result are able to identify areas where these bugs may happen, and generates information which allows the game-engine to reduce or eliminate the issue when you come to play the game.

In SL the load from trying to do this would be HUGE, either on the simulator side or on the client side. All it takes is a single object to switch from opaque, to 50% transparency and your performance is fucked.

Thinking specifically of "Issue - Transparency-render-1.jpg", if the cylinder was turned into 4 equal curves, I'm fairly certain that from every angle alpha sorting should work correctly.

It's not a complete solution, but should work well until we can get real time raytracing clients!

So, best algorithm idea I've had so far:

1. Find furthest and nearest point of all on screen semi-transparent objects (fairly expensive, but shouldn't be too bad as long as there aren't too many semi-transparent objects on screen).
2. Look for objects which are between the near/far point of those objects. Any objects found are a problem case.
3. For each problem case create a plane orthogonal to the camera, centered on the mid-point of each contained object.
4. Break down the containing objects such that they do not intersect any plane from an object within them.

First 3 steps are fairly well straight forward, AFAIK. Last one's still not terribly easy, alas, but I think shouldn't be impossible for someone with a better grasp on geometry than me...

Or am I talking nonsense?

Using: Second Life 1.18.6 (76116) Dec 19 2007 09:54:25 (Second Life WindLight)

CPU: AMD (Unknown model) (2009 MHz)
Memory: 2560 MB
OS Version: Microsoft Windows XP Service Pack 2 (Build 2600)
Graphics Card Vendor: ATI Technologies Inc.
Graphics Card: Radeon X1600/X1650 Series x86/MMX/3DNow!/SSE2
OpenGL Version: 2.0.7058 WinXP Release
LLMozLib Version: 1.1.0 (Mozilla GRE:1.8.0.12_0000000000)
Viewer Digest: 6b35fccc-b104-8755-e4b8-145f94ebc10d

The most annoying thing for it to happen regularly to is hair... Hair goes invisible if you stand infront of a texture with an alpha channel, which is very common with walls with windows in.

Also plants! I have plants by my walls, but they don't even appear because the wall has a transparent section of window in it. It's not even like the plant is overlapping the window section itself, but because it's the same texture, the plant completely disappears. This is utterly ridiculous... This happens even when the window part of it isn't visible! I used the texture that had the window in it, resized it down so that the window wasn't even visible (so the wall section was there only) and the plant still disappears.

This severely needs to be fixed soon...

• • • Do it right before you do it fast. ***

Read why this is a problem on http://www.opengl.org/wiki/index.php/Alpha_Blending

If the solution would cause rendering lag, then just have it be a selectable option for people who have graphics cards capable of dealing with this?... oh wait, I see Crash just said that a second ago.

For the record, yes, I'm using the Windlight First Look viewer. The bug is as persistent as ever from what I've seen. I'll try to take some screencaps soon.

This bug is MORE THAN ONE YEAR OLD and the only thing you have to tell us is that ?
Moreover, this bug REALLY affect graphics of Second Life, and make it UGLY (when you see your skull through your hair, you can panic...)

I never seen a game with that transparency problem, I never heard anything about it (and I went to a 3D school and had many friends in Game Design section) and it's a BASE to create "3D" objects with transparency map in video games (cause poly are too heavy to calculate), moreover, it's an OBLIGATION in a game like SL where you HAVE TO build objects with least prims as possible !!! So we HAVE TO build object with bugs ? I don't like to build bugged stuff....

So maybe you can close this topic instead of replying that kind of message ? It would be more clear for all players posting here for ... nothing.

Thanks for your (non)work.

People from the SL community can't do anything to help Linden Labs to solve this problem at this step.

Now, we all need to see this bug Assigned. (or closed)

=== Act now ! ====

The SL builders community (and moreover, the SL residents community) can't believe there is no solution...

At least - thanks to Linden team to communicate on this JIRA VWR issue with people waiting for this bug to be solved for a long time now

@Shaka, even if this problem isn't assigned, even if it isn't immediately actionable, it still ought to remain open for discussion and to maintain visibility so long as the problem itself persists.

I can perfectly well understand that it's a "hard problem" in a computational sense; I can understand that it may even be a specific problem insofar as SL is yoked to OpenGL for its 3D rendering. However, it's also possible that the current handling of alpha stacking is not optimal and can be improved, even if not perfected-- perhaps with a performance tradeoff, perhaps with better algorithmic methods the Lindens haven't explored yet.

It HAS been discussed – see https://wiki.secondlife.com/wiki/Bug_triage/2007-07-16/Transcript among others.

Let's keep this visible, even if it's frustrating not to have a deus ex machina solve it for us right away

A fix for this would go a long way towards improving how clothing looks in SL. I would trade a performance hit for a fix.

Switching to Ray-Tracing would ease this, I think - but considering Intel just demonstrated it on 8-way CPUs in realtime in much simpler environments - and significant parts of how SL works would have to be rebuilt - probably not this year or next.

One thing I've noticed is that the usual explanations for the intractability of the alpha-stacking problem using a Z- buffer approach revolve around partial overlaps, or varying nearness, of un-subdivided, or partially sub-divided, objects. Yet we see alpha-stacking problems with prims that clearly don't exhibit this ambiguous distance relationship – where the something entirely "far away" appears in front of something entirely "close". (Understanding here that there are undoubtedly multiple issues, mathematical and implementational!)

Anyhow, point is, like a lot of things in SL – a partial improvement would be welcome even when a perfect result can't be achieved. Even a major performance hit might be acceptable in certain cases – e.g.due to additional subdivision time to build a 'correct-er' snapshot image.

For those interested in some Linden discussion of the issue, it's been brought up in a few bug triages: around 15:18 in https://wiki.secondlife.com/wiki/Bug_triage/2007-07-16/Transcript and mentioned in at least two others that don't seem to have transcripts (2007-05-07 and 2007-09-26).

I am a computer science major, my current field of study however isn't graphics but artificial intelligence, I might have a look into it though. I realize that sl's graphics are not the same as most other games, via the fact it a bunch of primative's instead of meshes and the like.

However I recall that a nurbs modeller exists which handles the rendering of them in real-time preview rather well, it was called... Rhinoceros. But that is of no real help really.

Agreed. My old house had a horrid problem with its mostly windowed exterior walls. I'd put a semi-transparent prim plant or bush inside and it would look like it was outside even though the windows were a good 3m away from the prim. I finally gave up and bought a house that wasn't so see through. At least you can now tell what's inside and what's out.

One thing that I was thinking about for clothing – it would be cool if you could link a flexi transparent and non-transparent prim together to have them act as one prim. That way you could design a prim skirt that had transparency where you needed it and solid panels where you didn't. I am no computer graphics expert so I have no idea if this is feasible.

Now I am working with sculpties... First project was a lantern. It seems the use of transparents in the windows affects the way the sculptie rezzes... or maybe it is a plane ordering issue as above, that just exacerbates in sculpties. FURTHER I notice that is the window is 'frosted,' say a 50% transparent in PhotoShop, The problem is not as drastic. Is there a percentage of transparency that seems to be a tipping point?

Same problems as everyone else, being new i was trying to design something which has 4 prims with transparent sections all aligned and with a few cm's in between., hoping to create a nice 3D aspect to the whole thing. it looks great and works well..until you move - the whole magical moving layers trick is very weird to say the least and completely random as to which layer is in front first.. very confusing to a noob who then thinks he has positioned it all wrong and starts trying to adjust it.. 8-(

I hope this can be fixed, its the kiss of death to designers and has certainly thrown a spanner in the works for me, so it certainly has my vote and yes keep the issue open.

So this is not a matter of Z-buffer (the thing which tells which texture is closer or behind another). If so, all the texture type would be affected in the same way. So it is not an "impossible problem" as it is solved in some cases. I rather think that it is some gross bug that the library designers were lazy to solve, and escaped their responsabilities in saying that, as usual, it is a "security feature", or that "it is bad coding to use textures with transparency, which should be forbidden".

This is a serious bug, which brings constant inconvenience for users.
It is also one of these old (8 years old!) bugs which gives a bad image of the 3D technology, and induce into thinking that virtual worlds are not serious.

Linden labs cannot solve the bug itself, but I think it now has enough weight to enforce the library designers to solve this bug, or to change library.
Creating our own library is however difficult, as it must work with different systems and graphic cards.

The way I've done it is that when you render the scene you render two images, or in my case simple arrays. One has the colour/alpha data for all pixels rendered so far, and the other has depth information for each pixel. When you write new pixels, if the depth of the new pixel is less (closer) than the existing one in the image so-far, then you add the new data over the top, if it is greater (further away) then you write it in behind the existing pixel (if it has transparency). Obviously if you're able to render the scene in a particular order, you don't need the full-sized 'depth' image, only the part needed for the area you're working on, so long as you're able to do that bit in one-pass it's okay.

It is worth noting that a game like Oblivion has a 10 times better rendering than SL (like realistically walking through grass and bushes), a 10-30 times better fps, it never gets stuck for 10 seconds when lanching a menu, I never seen it filling the memory with memory leak, and making windows swap (a time consuming operation where Windows scrape the hard drive and stops the game for 30 secs) and above all there is not this texture muddling like the one we are speaking about in SL. Of course SL relies on the Internet (and has land management functions), so that it is doomed to be slower than a CD game like Oblivion. But the example of Oblivion shows us that many things (texture muddling, memory leaks) could be fixed without major trouble in SL, especially there is no "problem generally considered as impossible to fix".

I think your ideas about rendering are interesting. The main difficulty about rendering a scene is that the workload increases exponetially with the number of faces to render, if we all the time have to check which face is before/behind another. Such exponential problems are considered difficult to impossible to solve otherwise than with heavy exponential calculation time. But your idea should, I think, overpass this problem and make it a more linear problem, so that we could render a 10 times more complex scene with only 10 times more calculations, not 1000 times more.

By the way OpenGL is not a software, it is a specification for a set of functions. There is a standard licensed openGl, but also a free implementation called mesa (google: openGL + wiki). Same for other renderers. So in the worse case, if the library creators are unable or lazy to fix their work correctly, it would be possible to create another implementation. Only little problem, this is a work for an engineer team, not for geeks writing code with their feet. Also getting the requested infos will not be easy.

Haravikk, have you taken into account the edge surfaces of rounded objects where more then one part of an object may be contained in the same pixel? Not to mention the haze effect on transparent surfaces based on distance to the viewer. IIRC sl renders on a object level not a pixel based one... as such really this is a complex issue and there are few ways around it beyond a much slower trace solution, as I mentioned the object base, thus sl parses the entire transparent texture, not just the transparent part of the transparent texture.

As a side note:
I have noticed a few rare number of non-transparent textures that do this aswell, I may upload an example of this, once I get on later today.

But this don't explain all the difference between oblivion and SL. The way objects are described (primitives, meshes, nodes, kind of texture, etc) influences only the parsing of the scene, when the viewer is building the scene into the memory, before actually rendering it. Rendering only comes later, and only at this moment directx or OpenGL make a difference. Of course there could be some simplifications, for instance only one layer of transparency allowed (althought I did not noticed that in Oblivion). but then such simplifications should appear in the same way, whatever we are in Oblivion or in SL.

Also I still have the old cortona installed, and it allows to choose openGl or DirectX (but I am not sure it actually switch from the one to the other). I tried, but I did not noticed any difference, the texture muddling problem appears in both case. But with Cortona, the bug appears, not with transparent textures, but with PNG textures, even if they don't have transparency.

All this point at a bug in the libraries themselves. After what you say, openGl would not have the bug, and openGL would have it.

@Aeron:
With the per-pixel "shader" type drawing I mentioned, you can fix the majority of common cases. Basically when you render pixels with depth information you get three cases:

• New pixel is closer than existing pixel
• - Draw new pixel over the top, existing pixel is blended based on transparency of new pixel (if any)
• New pixel is same depth as existing pixel
• - Rare case. Either blend the two equally, or (more likely) just use overwrite by assuming the new pixel is slightly closer.
• New pixel is further away than existing pixel
• - Draw new pixel behind the existing one if the existing one has transparency

Now, this system only tracks the depth of the nearest pixel, as a result, items behind can still fight for priority. However, it solves the majority of cases since the fighting usually only occurs between two items. Incredibly complex objects/scenes will still suffer as normal, but it is rare for a scene to contain such large amounts of transparency without other objects blocking them (and thus preventing the issue as they will take priority).

The only way to solve the issue perfectly is to use per-polygon render ordering as mentioned, but the cost of calculating a BSP tree on-the-fly is huge. I've been investigating was to do a simplified BSP tree on-the-fly, and while so far it's good for physics, it doesn't help much with rendering.

If simulators had more powerful processors, or sets of simulators had a shared processor they could use, then it could be possible to break sims up into areas and compile BSP trees for static objects within those areas periodically, but I shudder to think of the complexity and potential to introduce even more bugs in such a system. They wouldn't be true BSP trees, but approximations of an object's shape to provide hints to the viewer.

But you can also have in Oblivion very realistic landscapes, and travel though them at high speed and on large distance: prerendering should then be calculated for millions of places. I don't know how these landscapes are made, they are probably sprites alway presenting their face to the user (like particules do in SL). These sprites mandatorily have transparency, so that you see through leaves or grass blades. Then, not only oblivion keeps a very good FPS, but also I never saw this texture muddling problem we are speaking in this thread.

anyway you are speaking about the rendering order (in which order faces must be drawn) a complex problem certainly, but which is basically independent of what kind of face it is, a coloured face, an opaque face, a gif or png face (pngs are buggy in Cortona), or a transparent face (wich are buggy in SL, although all faces are jpg). If rendering order was faulty, all the faces whould be affected in the same way, with or without transparency.
So that bettering the rendering order like in Oblivion will not fix the texture muddling problem.

This texture muddling problem probably arises from a wrong method for applying transparencies, at a stage where the viewer however knows very well which texture is behind the other. Probably the library designers (less likely LL. Cortona engineers told me that the library was faulty) assumed that transparent textures would be rare (we were in the beginning of 3D), and, to avoid the cost of computing the correct mixing of the two textures, they just made the trade-off of rendering only one of them at random. (and, as you know in this case, the random order is nearby alway the wrong order). But today transparent textures are a common and indispensible feature, and such a trade-off is no longer acceptable, and people complain, like in this thread.

The only 'easy' semi-solution may not even be possible, as it would require hooking two unrelated sections, in which one may not even be part of the viewer. Basically if two objects do not intersect determine whichever is closer for rendering purposes as you would a non transparent object. If they do intersect do what you do now till realtime raytracing becomes possible. By intersect I mean the bounding boxes, so many problems would still exist, but many of the 'totally' unrelated surfaces that overlap strangely would be eliminated.

The page is really ugly and poorly made, but I also found this, which refers how to fix this problem in OpenGL.
http://onyx2ced.frascati.enea.it/grafica/Corsi/.opengl/12blending_014.html

Here is a custom css sheet to make the site more readable if you want to delve further into it.
http://pastebin.com/pastebin.php?dl=f94b137d

An approach I find attractive is VWR-6713 - it doesn't solve the alpha sorting problem per se, but it does allow an enormous amount of content to totally avoid being actually affected by it, when used appropriately by content creators.

If only there was a way to feed levels of semi-transparency into the z-buffer in a way simular to the 1-bit textures but still have thier level of transparency overlap, abiet this won't work for intersecting objects like the cylinder through the hole of a torus or tube, but it would solve some of the problems. But I do think some residents are at a point where they would choose working a little better now over say, delayed until we can find a way to competely fix it.

While thats is some hypocrisy on my part I cannot deny I would perfer some of the stranger overlaps to be gone sooner then later.

I tried the 1 bit transparency for a foliage, and obtained a good result, provided that we use a large enough texture so that the edges don't appear jagged. At least this is a lesser evil than the texture muddling problem.

Is there a detailed explanation somewhere why it hasn't been fixed yet?

i usually stop to see my hair while i walk on a fur (transparent on transparent, but now i see correctly all transparent item with the right layer. Vendor rezzed on glass object too.

I know it's a really tough problem to solve robustly, though - but that doesn't make it less important.

Bizarrely, the Linux client on my Intel GMA-X3100-based laptop seems to struggle less with this than my GeForce 6600 main machine! It's dog slow, and can't even render my avvie's name correctly - but it does seem to get the z-order right more consistently. Maybe because it's doing more in software? Very odd.

Anyhow, a robust, perfect fix is very probably too much to hope for - but this issue is annoying enough that even a partial fix would be better than nothing.

The truth is, a lot of users may be willing to take a performance hit to get more correct rendering in these cases. I mean I'm an advocator of performance, but correctness is important too, and if it gets to be too much of a cost, you just switch it off for a while.

Regarding my earlier comment about the laptop - I'll try and get some snapshots to back that up - I'm not sure yet whether the difference I'm seeing is a Windows client vs. Linux client or an nVidia vs. Intel thing.

I had a problem with a particle flame not being displayed over a floor that was solid white marble. After reading this issue's comments I removed the alpha channel from the floor texture and that solved it.

Does not do anything for helping with situations where alpha is required tho, and I have another situation where a particle fountain wants to get displayed behind low prim tress that are 10 meters behind it!

I voted for this issue, needs to be fixed if at all possible!

It is to be noticed that the problem don't appear with particules: particules superimposed to each other merge correctly. Even different types of particules don't muddle together.

Probably particules are processed a bit differently than objects (they are one face alway facing the user). But I never saw the muddling problem. So the problem may appear at a later stage in the rendering. And it is not so bad to solve, then.

Waiting for this, a building workaround useable in some cases would be to use only one texture for several prims, so that these prims, at least, would not muddle together. However this is a known tip to optimise the rendering (less lag).

Also linden trees seems to heavily rely on alpha channels. They seem to be true meshes, not the LL "prims". I never saw a Linden Tree disappearing behind another, alway their transparencies merge correctly.

So the problem is specific to rendering LL prims (cube, sphere, etc)

This segregation tells us that the problem is not "some fundamental difficulty of 3D rendering" or "a rendering library problem". If it was so, all the objects would be affected in the same way. The problem is specific to the LL prims: at a moment, some parameter may be passed wrongly, when dealing wih transparencies. Probably somebody made a "simplification", decreeing that "people don't want to use multiple alpha channels". And correcting this minor mistake will need to rehearse the whole rendering pipeline, a costy task. I don't want to be naughty, but probably the best way to find the bug would be to check who says that the users are faulty, and look at which part of the development they were responsible.

Daedalus, okie for Linden Trees to have a 1 bit transparency, although I am not sure of this. But particules are indeed 3D objects, in the meaning they are rendered as other 3D objects, even if they happen to have only one face alway facing the user. they are not like a chat window superinmposed to the scene. This can be checked easily, if you look at particules going through objects or ground: they correctly intersect these objects, or disappear behind them.
The only way, though, to sort between our two statements, would be some tests, with particules, Linden trees and alpha transparency objects intersecting together in conditions which usually produce the texture muddling. Especially with linden trees in the process of downloading, when they still appear blurred, that is in a situation where the texture actually in the memory must have a true alpha channel. If it had a one bit transparency, it would appear simplified, not blurred.

Yichard,
particles are 2D faces in a 3D environment. Once they intersect with 3D objects, they act according to their location in the 3D environment, but as they are all facing you, they cannot intersect with eachother (because in order to intersect, they would need to have volume in your depth-field (not to be confused with DOF); particles have no depth), therefor they don't cause sorting issues (amongst other particles) which arise when objects intersect.
(that said, particles might intersect when they're huge and you have a very wide angle 'lens' viewport. When one particle is on your left and one on your right, due to image distortion because of the wide lens, they are in the 3D environment not parallel to eachother and thus can probably intersect)
Most likely particles will produce the error when you have them going through partially transparent prims. It should be pretty easy to set such an experiment up with relatively few and large particles and small 3D objects.

In the center, I applied 1% transparency to show the bug. Obviously faces are now rendered in an arbitrary order....

On the left, a SculptCrafter made animated texture robot; as you can see the transparent part of the texture makes only one set of arms visible, frame 3 of its walking cycle to be precise.

But the same bug happens in the same way, making nontransparent faces look rendered out of order!

I guess the viewer code works like this:

if (any transparency at all)

else

I'm showing that "code" thing to point out that the incredibly annoying flickering when faces overlap perfectly (as the arms of the robots do from the side) is not present when the transparency bug is active, so please look it over while you fix the transparency bug, you might fix the annoying random-like flickering too within 5 minutes if you just look the code over while you're at it.

http://graphics.cs.uni-sb.de/Publications/2005/Ecosystems/Ecosystems_Teaser00.jpg
http://www.mpi-inf.mpg.de/~guenther/carpaint/img/teaser3.jpg

Moore's Law works in favor of Ray-Tracing, because it assures us that computers will get faster - much faster - while monitor resolutions will grow at a much slower pace. As computational capabilities outgrow computational requirements, the quality of rendering Ray-Tracing in real time will improve, and developers will have an opportunity to do more than ever before.

However its application is still not ready for secondlife, not everyone has the hardware to back this type of thing, even my high-end system would rattle under its load.

But I did like the solution suggested in VWR-6713, as seen here: http://www.humus.name/?page=3D&ID=61

Anyway this is not a Linden lab problem, it is in the rendering library, which is probably already several years old, and is not likely to be upgraded. the famous "openGL" and the like, which, by the way, all more or less exhibit the same bug.

Yichard, afaik, z-fighting also occurs with opaque textures. I'll see if I can test that.

Z-ORDER INPUT SOLUTION

Say ABCD are totally identical faces except the color.

Frame 1: Sorting gets ABCD as imput, and outputs ADBC. Which is correct sorting.
Frame 2: sorting gets DCBA as input, and outputs DACB. Which is correct sorting, but unfortunately different.

(the changing order is a side-effect of some queueing or buffering mechanisms, which themselves may or may not be adapted to produce fixed order)

The fix would be to present the textures in exactly the same order each time. With knowledge of the exact sorting algorithm used (or using a sorting algorithm that makes it easier), you could present the textures as always ABCD, ABCD, ABCD and if something is blinking, have a fixed way to re-add it to the mix.

ABCD would output ADBC (on equal values, many sorting algorithms will move things around in a totally predictable way, which we will count on)

ABCD would output ADBC again, no flickering

B blinks off (rotating of a transparent texture, or whatever)

ACD would output ADC

B blinks on

input may now be ACDB if not for the fix!

We need input to be ABCD again, and since every texture is stripped of any ID in a texture pipeline, sort it according to an arbitrary fixed test (i.e. reddest upperleft pixel first, on ties bluest first, on ties greenest first, on ties tolerate leftover flickering).
input is ABCD again, so output is ADBC again.

Obstacles to Z-ORDER INPUT SOLUTION:
-Some of that sorting may be OS-specific, hardware-specific, or other problems forcing the programmers to rewrite it over and over again for various system combo.
-Maybe the sorting algorithm is in the hardware, and can't be known or sort in an easily predictable order (i.e. nice trick, but it kills performance).
-One example of failure to pre-sort the faces would be a hardware buffer fluctuating in size, or order unpredictably due to factors like the CPU load, making the pre-sort irrelevant or impossible.

ALTERNATE SOLUTION: offer a 500$ to whoever reduces flickering by at least 95%. It's much, much better than waiting for the next openGL library to come out and hoping they fixed it! Or put a Linden coder on it - some days I wish there was a garanteed Linden coder attached to whatever graphic issue has most votes.

And once Z-fighting is fixed, or mostly fixed, I have a feeling that fix will contain code useful in fixing the transparency non-Z-sorting bug... I have a feeling the flickering bug is what causes Linden Labs to turn Z-sorting off for transparency as the result of Z-fighting within a complex transparent sculptie may be one of the worst eye sores known to residentkind.

I don't wish to be a nay-sayer but generaly speaking, z-fighting between objects near each other in the z-buffer will flicker, it is to be expected, this happens in transparent and non-transparent surfaces equally. Surfaces that are along the same spacial plane and overlap will z-fight, there is little avoiding this. The best LL could do is increase the precision of the depth buffer and that will lower flicker on non-transparent, non coplanar overlapping surfaces. Generally it is up to the content creator to resolve this issue rather then delve into lazy and costly practices.

Also it is not ABCD that needs sorting but A,B,C,D,E,F,.....,KXZ,KYA,KTB,....,NVO, and keeping track of every set of overlapping textures that can occur in a dynamic 3d environment is very costly. It is niave to think that if this could be solved so simply that it hasn't been done.

I will re-quote as stated in an ealier comment by Daedalus Young.
"Torley, it's not really Z-fighting, that occurs when 2 surfaces are on the same spot in 3D space (see http://en.wikipedia.org/wiki/Z-fighting).
This happens because the Z-buffer (which you can see if you go to Snapshot > Capture > Depth) doesn't allow transparent texturing. You can make it work in a lot of situations, but it breaks when several objects are both behind and in front of eachother (like a ring around a pole, the ring is behind the pole, but the pole is behind the ring). As Thygrrr said, it requires geometry subdivisions, divide the ring in 2 pieces, one piece behind the pole and one piece in front of it."

Subdividing can get complex, and multipies out of control as objects intersect each other. The page I linked was to help solve it for flat surfaces so they do no flip over each other as much when they are not overlapping and they are not intersecting. (some is better then none in my opinion).

Another way to reduce this problem would be just to alphablend them based on the objects distance, objects of equal distance, even if they intersect like a ring around a pole would get the same blend value. This has inherent problems of its own.

The last way I will consider mentioning is ray tracing (rather ray casting) the scene, the rays could stop when they hit opaque objects or opaque parts of transparent textures but otherwise will collect the extra overlapping textures. This method is very handware intensive and not currently within SL's scope of users.

(forgive me if I don't make sense i'm tired)

-If we get to consistently pick the same overlap pattern for the same position, z-fighting will not cause flickering in nontransparent objects. By no means we care if that pattern is any more correct than any other frame in the flicker cycle, we just stick to one and only one. Pre-ordering the prims (not the face) and having a consistent face sorting algorithm would be enough.

-Once that's done, the flickering problem is not so bad as to make complex, overlapping things like my robot's arms from the side be dizzyingly superflickering, and Z-sorting for partly transparent objects like my bot will be an option - or at least it will be much, much easier to make a "close enough" or "woohoo clean" fix.

P.S.: what is the issue or meta-issue for Z-fighting? I have a quick trick to reduce it a lot.

However the problem in this thread is about very non-coplanar faces being muddled. It is different of the problem which occurs with coplanar faces. And I think that there is no theoretical limitation creating the texture muddling, when there is one for rendering coplanar faces.

Contagious, the "useful code" would be to ELIMINATE THE RANDOM RENDERING ORDER. A still scene should alway render its faces in the same order, to avoid flicker in any situation.

The solution to the texture muddling should be to allow for SEVERAL VALUES FOR EACH PIXEL IN THE Z-BUFFER, each with its own alpha coefficient and distance. This theoretically allows for the correct mixing of an infinite number of superimposed alphatextured faces, however at the cost of a memory load proportionnal to the number of values allowed, and a calculation time less than proportionnal. Today a tradeoff would be to allow 2 or 3 values. This would only little impact the frame rate, while solving the issue into most situations. Until further increase in computers power still allows for more values...

But the main problem I see is that these parts of the viewer are not written by Linden Labs, but they are provided as libraries (the famous openGL, etc) that Linden Labs cannot modify (because they are copyrighted, not open source, and I guess very complicated). The library creators will not admit that there is a bug, and probably Linden labs has not enough strength for writing their own library. So the hope relies probably on the capacities of IBM, allied with the experience of the Second Life team.

...which is the case unfortunately, but then my pre-sorting trick might still work at getting the code non-random.

Since I have not succeeded in opening an issue, here is the quick fix:

Camera smoothing and related settings cranked up to the max produce for me up to 9 seconds of heavy flickering; even for movements which during that whole 9 seconds were less than a pixel.

The quick fix is to crank the camera smoothing and related sliders all the way down, making the flicker 90% less. Until someone bothers to make the camera smoothing (which IS LL owned code) stop caring about less than half a pixel of movement left in leftover camera smoothing - rerendering extremely small differences like that stretches the problem to several seconds after user stopped moving.

And back to the transparency problem - is it a problem in proprietary code, or a Linden Labs code problem?

So it is difficult to conclude. My best guess is an uncomplete library, unable to handle the multi-transparency situation (for instance because it has only one value in the z-buffer, or perhaps more trite problems). A second guess is a correct but ill documented library, that LL was not able to make it work properly.

Well, we have only guesses, not infos. It would be fair to see somebody of the development team explaining us a bit how it works, and where the problem come from. Otherwise, even if we find a solution here, all this discussion is a bit useless.

The desired and intended behavior is that the sections of the texture that are transparent, be rendered as such, and the opaque sections are likewise rendered as such. The opaque section, are rendered as opaque when an opaque object is in the background (the floor in this case). But are rendered as semi-transparent when a transparent object is in the background (the sphere/wall in this case).

aaron

I can't believe this problem has been recognised for almost 2 years and not yet resolved when SL manages to do so many amazingly clever things.

Thanks LL for what you have enabled for us and please fix this one soon

So, watch and learn.

-Ilyara

Greetings,
sal

I happened to see the problem on ONE prim, on itself. It was a quarter of a torus. When looking from a certain angle, the inner side was visible through the outer side (on certain angles of viewing, part of the inner side faces the viewer, but are normally hidden).

So i don't think that there are "tips" to avoid the problem.

But there certainly are SOLUTIONS, as Linden trees don't show this texture muddling, and no more bushes and grasses in Oblivion. And oblivion scenes have a much higher frame rate, despites running on the same machine and being sometimes complex. (many characters, etc).

Ilyara, it's actually to do with objects being both in front of and behind eachother at the same time. The reason your 4-prim bush works is because the planes are either in front of or behind another plane, the 2-prim bush fails because they are in front of and behind eachother at the same time.

Yichard, the Linden trees work because they are 1-bit transparency images. That makes them compatible with the z-buffer, as the pixels are either opaque or transparent. Full transparent images may have pixels that are partially transparent, that makes them incompatible with the z-buffer and therefor need a crude fix to work. It's an engine problem, not SL specific. A single prim indeed can show the problem, now it's not one object in front of and behind the other, it's one face of the prim. The possible solutions are to subdivide the prim (see the 4-prim bush in Ilyara's video, because they're subdivided, there are no prims intersecting in a way the engine gets confused). This of course costs you more prims and may be hard to achieve with twisted and mangled prims. Another solution is to use 1-bit transparency, but that can cause jagged edges. However, for a square window for example it is a perfectly fine option. If you enable antialiasing in the client the jagged edge will be smoothed a bit. General rule though is, use what is minimally required for the texture. A full opaque texture should never have an alpha channel; even though it's empty, it still causes problems (I've seen it a lot). A texture with square bits cut out in transparency or at least not needing half transparent parts should never have a full alpha channel, 1 bit is usually fine for this. This already should take care of quite some issues. For plants and flowers and grass you could actually use particles. These always directly face the camera and therefor decrease the chance of this happening. It can also save you on prims, as you only need 1 prim for dozens of plants. Also, in my experience it seems flexiprims can be buggy even though they're not visibly intersecting other prims. See if you really need a plant or tree to be flexi and sway in the wind. If it also looks good as non-flexi, try to see if that fixes the issue.

I can't give you more tips, evaluate each situation and see if there's absolutely no other way of doing it like it is. It's a matter of kill-your-darlings. Recently in a game level design I came across this issue too, where one object really needing transparency intersected with one that had transparency for eye-candy purposes. Although I'd loved to keep it, I could only really solve it by not using the eye-candy transparency. So just a tiny bit less win, but it solved a huge deal of fail.

That's what the bush example is illustrating. If you read the text you see it says 'Same Coordinates'.

As for the Red/Blue example the pillars represent the center of the prims in both cases. Clearly not on the same spot. In the second example the blue prim is big enough so the red prim is inside the blue one. But the alpha problem show is that when the center of the red prim is infront of the blue prim center, the whole red prim is drawn infront of the blue one, despite it being inside it. And when you turn the camera around the center of the blue prim becomes closer to the camera, and thus the entire blue prim is drawn infront of the red one.

http://www.opengl.org/wiki/index.php/Alpha_Blending

in short, SL uses OpenGL as a rendering library (set of ready made functions).

A good image of its working is that each face is painted in turn in the z buffer, a memory space that we can figure as a succession of painted layers. Save that once a layer is covered, it is discarded, and in fact only the uppermost layer (last painted) is memorized. Faces are painted in any order, and when a new face has to be painted in a position where it is already covered, it is not painted (this would be useless).
This works fine as long as we have opaque faces. It works fine too when an alpha transparent face is painted on top of an opaque face. But when an alpha transparent face must have to be painted BEHIND another, it cannot be, as the information for this is lost. So in this case, the transparent face is not drawn, and the bug appears.

there are other limitations to openGL, such as the very small number of lights (8, less in SL the sun and the moon) which also make some glitches like lights appearing or disappearing when there are more than 6.

So we understand where this bug comes from, but also that it is not near of being solved: the last attempt to rewrite openGL properly was abandonned by lack of funds. Today the whole thing is managed by a consortium named the Khronos Group, which is made of 3Dlabs, Apple, ATI, Dell, Evans & Sutherland, Hewlett-Packard, IBM, Intel, Matrox, nVidia, SGI and Sun Microsystems. So it is these people that we must badger, not Linden labs. (although Linden Labs could become a part of it)

However there are several versions of open GL, and some may correct the bug.
or other libraries...

(added)
in front of a problem caused by the order in which faces are "painted" in the z-buffer, the ideal solution would be to paint them from the farthest to the closest. Alas this is not practically possible, because this just takes far too much calculation time, and in the case of a folded face hiding itself in needs other tips. However, to draw faces in the correct order is easy in at least one case: particules, which are a well identified set of faces. This tip was probably used in the SL viewer, and this explains why particules don't display the texture muddling bug with each other, even when some are far and hidden with other faces, and others are close.

Also the 1 bit alpha channel brings back the problem to non-transparent faces (when it is opaque) and a non-existent face (when it is transparent). This explains why 1 bit alpha textures don't show the bug.

So it would be unfair to say that it is a Linden labs problem, it is a difficult limitation to 3D rendering, which was not overcome by openGL and the largest companies workinf for it.

Only a new version of OpenGL implementing several layers of transparency in the z-buffer will stop this. Implementing 2, or 3... transparency layers in the z-buffer would multiply its memory requirements by 2, 3... etc. This was a severe limitation 10 years ago, but should not be today.

On the other hand, Oblivion also uses openGL, and it displays an outstanding better quality and frame rate than SL. This is partly due to "optimisations", such as one bit alpha channel textures (for grass, bushes) (unless they are rendered with 3D textures) and a much limited set of textures per scene. But this doesn't explains all, and I strongly suspect that the SL viewer code would require some optimisations also.

Actually, oblivion uses DX 9, it only uses opengl if you apply a patch that is shoddy at best, or run it under wine. I've taken the liberty of uploading screenshots illustrating the performance difference between the two.

DX 9 (135 fps):
http://farm4.static.flickr.com/3247/3024664809_53fcf870a5_o.png

OpenGL Patch (45 fps):

http://farm4.static.flickr.com/3140/3024664821_f93f0c3bf6_o.png

__________________________________

Oblivion Minimum System Requirements:

Windows XP, Windows 2000, Windows XP 64-bit
512MB System RAM
2 Ghz Intel Pentium 4 or equivalent processor
128MB Direct3D compatible video card
and DirectX 9.0 compatible driver;
8x DVD-ROM drive
4.6 GB free hard disk space
DirectX 9.0c (included)
DirectX 8.1 compatible sound card
Keyboard, Mouse

It also lags in the extreme when compared to DX 10 versions of games like Crysis, which gets 80fps on medium-high graphics on my 800 USD machine featuring a modest geforce 8800 GTS. Direct X games generally do not suffer from the alpha blending bug.

In addition to this, direct x 11 will also support gpu and/or software realtime raytracing, and will be firmware updatable on most geforce cards that current support DX10.

By contrast games like Kotor II and Neverwinter Nights II are limited, sluggish, and suffer numerous VBO related issues (both are extremely choppy until you disable them, and still not fantastic for what they are, running at 25fps or less or less on the same machine).

Neverwinter Nights II, opengl, low settings (43 fps):

http://farm4.static.flickr.com/3043/3024664813_35a30fbefa_o.png

Crysis, DX 10, same machine (88 fps):

http://farm4.static.flickr.com/3037/3025491840_2e7303178d_b.jpg

You'll note in the second screenshot, there are no alpha blending issues, despire thousands of plants with alpha textures.

So, it seems to me that rewriting SL to support direct x would solve any number of problems, but, no one wants to hear that; it's too much work, it would leave out mac and linux users without LL going to the expense of writing an API to support gpu based direct X, and it's evil + loaded with trans fat on top of that, so, I won't suggest it. However, proof is in the pudding as it were.

*All screenshots taken on the following machine:

2.4 ghz 64-bit Intel dual core processor
4gb DDR2
1 500gb sata II drive
Geforce 8800 GTS (old model)
Windows Vista Ultimate
Onboard sound only

Someone also mentioned something about a nobel prize and raytracing. DX 11 will support both software and onboard GPU realtime raytracing.

Can anyone explain why this issue isn't "major", or more importantly, why it's not assigned to anyone after almost two years? It's not like this is some minor, isolated issue that only affects a few specific builds, or only manifests on certain hardware configurations. This occurs on PCs and Macs (possibly Linux but I don't have a box to test with at the moment), and on a wide array of video cards.

Oh yeah, and it looks nasty.

Ray tracing would fix this by calculating the exact path that light takes to get to the camera. The other suggestion has been to have the client break prims down into smaller prims for rendering, to avoid this, but that woud take time and I'm unaware of any way of calculating the exact breakdown required in order to solve this, without essentially ending up back at ray tracing.

A few people have point out it doesn't happen on this object, or that object, or in some other 3D application. The issue is not present in all cases where transparency is used, only (AFAIK) in cases where one object is both infront and behind another, from the camera's POV, such as a transparent cylinder containing another object.

Some days ago, I did a built which used about ten superimposed full alpha transparency prims, which did not showed the bug. Is this because they all used the same texture? Not sure, because one month ago I had the bug with one prim hiding another part of itself. So my idea is that the bug is not in the library, but in the viewer.

My ten prims yesterday were hollow cylinders, that is one face showing through another one. Both faces were rendred properly, and others cylonders showing through also showed properly. Probably because there was only one texture for all, and in this case they are all renderd in one step, like particules. But one month ago the prims had only one face, and a face showing through itself did not worked.

A very unpleasant effect for an art gallery, to be sure

1. Nobody has been assigned to it, and some months ago someone arbitrarily flagged this issue resolved, when of course it wasn't.

2. It can't be fixed, due either to flaws in OpenGL or current graphics drivers.

3. Linden Lab doesn't care, because although this is the fourth most reported error, and unresolved, they haven't even
bothered to assign someone to the case.

If the answer is #2, then builders will have to do what other game manufacturers do – plan their builds accordingly. However, it's more likely #3. Linden Lab only cares about flashy effects they can show off to reporters. Serious flaws, such as the inability to teleport, lost inventory, etc aren't newsworthy and get no attention.

There is no easy workaround to solve this problem and is related to any range within Second Life.

So the method used is the z buffer, which is a copy of the screen, pixel per pixel. Each face is rendered in any order, and its value for a given pixel placed in the corresponding memory of the z buffer. Then an information on distance is added. When another face is calculated, and the distance of the pixel is higher, then the pixel is not calculated. If it is closer, the pixel replaces the previous, with the new shorter distance.

This works perfectly well with all opaque faces. But when transparencies appear, we must have several layers in the z buffer, which increases memory use (3 times, if there are 3 layers) and somewhat also calculation time. Probably in SL there are two layers. So, when all th faces with a given texture are calculated together, their transparencies merge properly. But if a second texture is calculated later, it replaces the previous in the second layer. This makes that one of the texture replaces the other, depending on which is calculated first (the order can be different from a frame to the other, making the textures flicker). Even if a texture is applied for instance to a torus, then the bug appears with only one texture, on itself.

Probably this sytem with one transparent layer in the z buffer was implemented for transparent faces without textures. In this case it works well. But with several textures one layer is not enough, we should have at least 2 transparency layers (3 in total). This would consume some megaooctets only.

At least this is what I guess, because we discuss in the vacuum, without any return or whatsoever...

http://imprudenceviewer.org/

Whatever they did with this viewer, they seem to have greatly reduced this problem. I thought it had been resolved, until panning my camera back and forth to shift perspectives caused it to recur.

I haven't had much of a chance to use this viewer, just having found it last night, but it's pretty quck. Only issue that would keep me from using it full time is it has no sound support (yet).

But I remember a time when this bug did not exist. So how was it done back then? (Approximately before April 2007.)

Ideally, you would want to draw each transparent pixel in order from far away in the scene to the camera's position (in the inverse order of distance). Unfortunately doing so in real-time is simply not possible on modern hardware. We're thus forced to do very coarse depth sorting which will always have corner case bugs which are simply unavoidable. Videogames avoid this by having professional artists that create geometry that specifically minimizes or avoids this inherent limitation of current graphics technology.

Unfortunately, the only option is to NOT create transparent objects and geometry that overlap or are closely adjacent. For objects that you don't want partial transparency, you can instead vote for the following jira, which deals with the adding of support to treat alpha textures as masks (every pixel is either opaque or invisible, with no partial transparency and thus no blending), which allows us to use the depth buffer and would thus not suffer from alpha sorting errors:

http://jira.secondlife.com/browse/VWR-6713

The truth is very probably that Oblivion uses up to date rendering libraries, or a system they developped themselves, when SL uses 12 years old rendering libraries or worse. Pity I no more have the game, I would post screen shots which would REALLY close this discussion.

I agree there are some shortcoming in Oblivion, which mark the real limits of the 2006 technology. But where are the "special optimisation methods" used in game building? Why these methods would not be known and used into SL??

oh, ok, thank to you to make us understand at last that this is not the roleplay here to have civilized discussions. Enjoy your roleplay then. if you want, I still have several other JIRAs open. As I said, I shall not reopen a JIRA closed by a Linden. But now there will be other roleplays to deal with.

I no more have the game, but we have now many Oblivion videos on Youtube. I selected some among the many available:

-for photorealistic vegetation in a huge scene: http://www.youtube.com/watch?v=6esRjBvU9nc&feature=related
Note the gently moving photorealistic grass, tree trunks which ridiculize the Linden trees, beautiful walk, behaving animal, deep 3D effects in bushes. Check info on the page, for high graphics parametres

-For the number of objects: http://www.youtube.com/watch?v=UyHiIeBsc9E

-for the number of characters: (not nice video) http://www.youtube.com/watch?v=w3FOMfLHS_8&feature=related note that we have some visible fps here, this PC may be much older than the previous. Note that the menu appears instantly, not needing to scrape the hard drive for a minute. This PC is much slower than the previous, as FPS is visible even with the nonely character.

-This one gives all the PC characteristics, and max graphic settings, for a fair comparizon (many other videos do) http://www.youtube.com/watch?v=pTofa9ehovU&feature=related Note that FPs is never noticeable, although there are never more than 2 characters (don't look at the trailer, this is not a good comparizon). The only thing which is better in SL than in this video is that we have a better roleplay than stupidly killing all the animals we meet.

and this is only Youtube quality, imagine the same, full screen, and sharp.

Theses videos are a shame for SL.
We can do MUCH BETTER than SL.

Yes, we can.

Yes, Oblivion and other modern games have more advanced materials systems (which we've previously mentioned as something we're looking to add when when we have the development resources to do so. Everything else you mentioned is a perfect example of the things that you can do when you have professional artists working in a structured environment on art. We have an open system where close to all of our content is created by amateurs in the public at large and where we don't place many limits on the efficiency of the content they create. So yes, of course a modern AAA videogame looks better than the average SL scene. Professional game artists (which Bethesda's most certainly are) are simply that good and their engine has been created to perform well and look beautiful, not to allow anyone to dynamically create any content that they want with few limits.

Like I said before, for objects that you don't want partial transparency, you can instead vote for the following jira, which deals with the adding of support to treat alpha textures as masks (every pixel is either opaque or invisible, with no partial transparency and thus no blending), which allows us to use the depth buffer and would thus not suffer from alpha sorting errors:

http://jira.secondlife.com/browse/VWR-6713

There are ways around it with increased primcount and other solutions. It's like most things about finding the right balance.

Though, this "bug" has been improved over the years. There was a time where all alpha textures where brightly visible through the water surface. Back then two plane trees would flicker like crazy all the time, nowadays you don't see that flickering nearly as much.

I do hope that the future will bring a solution that will end this behaviour if a more advanced version of OpenGL or something comes out....

So, avoid making bad stuff.

-Set it as "Won't fix" if it's truly unfixable at LL's programming skill level, and other constraints. It may be a placeholder for "won't fix NOW".

-Assign it to some Linden.

Either choice is good enough from the classification point of view, "Closed" is not because it's misleading.

As to your demand that they make a choice I think it's clear per the above comments by BigPapi and others that it's not a choice they can make because there's no way for them to "fix" this problem.

what I would like to see from Linden labs is not vague generalities or opinions, but a precise TECHNICAL STUDY on what blocks the resolution of this issue:
-The list of existing rendering libraries, with those which have the bug, and which have not
-what may make difficult to change to a better library. It can be that a better library is more expensive
-it can be that another library may add other bugs
-I even heard a nasty rumour as what the viewer would not be modularized, a very serious fault which would need to be corrected in utmost priority, everything else stopped. By the way such a rewriting would be only a marginal cost in today SL, quickly counterbalanced by a flow of new content creators and happy residents.

Bigdady Linden:

Most video games, including oblivion, also have user created content. These are the wellknown "mods". I remember one in Oblivion, which property was to make all the female character topless! What is relevant here is that the result of these amateur mods is as good as the professionnal content. This is because the mod-ers use the same rendering system, and also that they can import 3D files created with gmax (a free version of the pro soft 3DSmax, limited to only a special file format for mods). What makes 3DSmax so superior to SL's prim system, or to an old VRML rendering soft like ISB? For instance when we create an object, and use several textures, 3DS calculates in one click a texture map and unique texture for it, thus greatly enhancing the rendering cost of the whole object. In the old ISB this map must be calculated by hand, which may need several days and cannot easily be modified. So VRML worlds, and SL too, have one texture per prim, thus strongly slowing the rendering. There are many other problems like this, which can be solved if someone decides to become part of the solution instead of looking for excuses. Especially there are several JIRAs about importing real 3D file formats. Just ask.

http://www.opengl.org/wiki/Alpha_Blending

PLEASE DO NOT REOPEN THIS ISSUE. Especially if you haven't read or understand the above linked wiki page!

Alpha sorting problems can ONLY be solved in one of three ways:
1) Having artists not create geometry that is susceptible to alpha sorting issues (aka don't create the issue).
2) Cutting up semi-transparent polygons (breaking them into smaller polygons) per viewer frame (camera dependant) and sorting each and every new transparent face perfectly from back to front based on "coverage".
3) Draw the entire scene using ray-tracing.

I've been recommending #1 all this time, because #2 & #3 are currently impossible to do in real time for the geometry that our residents create in world. Yes, impossible. No, not because we "don't get it." If we were to implement #2 or #3, the viewer framerate would quickly approach 0, which would make it very hard to move around.

Like I said a couple of times already, for objects that you don't want partial transparency, you can instead vote for the following jira, which deals with the adding of support to treat alpha textures as masks (every pixel is either opaque or invisible, with no partial transparency and thus no blending), which allows us to use the depth buffer and would thus not suffer from alpha sorting errors:

http://jira.secondlife.com/browse/VWR-6713

For example, what if we had a system that allowed builders to assign priorities to faces of an object relative to others in the same linked-set? The Myth: The Fallen Lords and Myth 2: Soulblighter engine (11 years old now) allowed map-makers to import 3dmf models and assign priorities in this way so that complex/interesting geometry can be created and yet avoid the clashes that could be caused by faces that are too close to one-another. Let us (the builders) provide these hints to the Second Life graphics engine, and we could probably resolve a ton of common-cases.

I mean, a lot of cases are unavoidable. Do you expect us to drop a one-prim fence that uses a texture in favour of using tens or hundreds of prims for a much laggier and resource-hogging effect? What if I have a house with an alpha-window and someone puts up a tree outside within view of my window? What about the random grass in some sims?

I have a simple fix, at the viewer level, which is likely to work with the today graphic library and allow full freedom to content creator.

But re-open first this feature request...

Please also post somewhere the shedule for the modularization of the viewer. All other fixes are in dependence of this one.

When several prims are present, prim A would still be either completely in front or completely behind prim B, but at least object A would not overlap itself strangely and object B would not overlap itself strangely.

A prim sorting only itself is not so ressource intensive. Do I need to open a separate issue to get that done?

P.S.: with prims sorting their own faces artists could now position prims so that the issue would not be so annoying.

P.P.S.: if you're thinking case study, think of a single-prim sculptie spider with 2 walk frames being shown in succession with llTextureAnim while making the other one invisible (an easy output of my tool). If you make the self-sort fix, you are getting very MMORPG server worthy with one fix.

We can overlay many alpha-textured prims with no problem if they are all the same texture. This works even if each prim's texture is offset to show a different portion of the texture, or if repeats are altered to show different percentages of the texture. Is this maybe a clue to where the solution lies?

Please keeping working on this. "Expected behavior"...laughing ruefully....I think you must have really been in a lot of pain as you gave that resolution. Nope, no matter how accustomed we get to things being borked, we expect better things from you. You are very clever people. Close it with a "Won't fix" if you must, but "expected behavior" is just too sad.....

Complaining people; if it's simple, write it and submit it as a patch. If you can't, please PLEASE accept that perhaps your understanding of 3D rendering isn't as complete as you think it is, and maybe that actually it's a lot harder than you think.

harleen Gretsky, did you read my comment 07/Mar/09 12:20 AM before quoting BigPapi Linden???

There IS a simple fix which may solve at 100% the problem, without adding constrains to the content creators, without changing for a better library and rewriting all. It is probably the "optimisation" used by other games like Oblivion, where this ridiculous problem is never seen. But this would require a reorganization of the rendering module of the viewer, so a patch will not do. And such a task would require professionnal equipment, with all the simulators and test benches and quality assessment.

But before describing this solution, I want to see High level Linden Labs people asking me officially. You understand why.

ROFL

If it is just what you expect of SL, then it is fine...

note: I shall be offline for a while, due to RL issues. Useless to post again and again just to repeat the same thing. I shall reply later if LL asks for the simple solution.
not reopening, because it was first closed by a Linden, so I assume it is the official LL position.

PS: 180.55 nvidia driver "seem" not suffer about alpha overlap... (PNB 1.23.0)

Oblivion on XBox 360 (and I suspect a lot of modern graphics cards in the PC version) can do the 1-bit alpha quite nicely, by interpolating the 1-bit alpha at higher zooms to create "smooth" (i.e - curved) edges for a nice effect. If used right it's a great way to handle alpha, but isn't some magical fix that will solve everything for everyone.

I still thing being able to identify relative sort-orders may be something worth investigating, I'll post an issue if I find time; basically these allow you to specify which faces render over others, with greater complexity this can become very powerful.

1) Try your test with sets of shapes more complicated than a couple of planes (for example, the center of one object inside another, looking through). Straight-up planes usually work fine even in the current browser.

2) Claiming you have a solution that you plan to hold hostage is not particularly productive.

If someone comes up to you and says "I know how to build a perpetual motion machine" or "I know how to travel faster than light" - you don't say "Oh, cool, here's a big wad of cash!" or "Of course, you're obviously smarter than everyone else on the planet!" You say "Where's the machine?" or "Got close-up photos of Alpha Centauri?"

Scientists do NOT just ignore people with un-obvious claims on a whim - see the history of the Alcubierre drive for proof.

@Yichard - you want exact information on what libraries have this "bug". It's not a bug - it's a matter of computational difficulty. Do you have any clue what O notation is, or P vs NP problems? There is one rather nice solution to the problem, but ... it requires new hardware, as it means ripping out the current rendering system and replacing it with ray-tracing. Fortunately, ray-tracing is embarrassingly parallel, and that's something the new computational GPUs are going to excel at. That'll fix the alpha blending problem - it'll also give us reflections, reflections of reflections, refraction, distance fogging, and a whole host of nice new features. Pop for one of these http://www.physorg.com/news177617175.html in your new computer, and you can start work on that new generation rendering engine today!

I'm not saying it can't be done, I am going to say however that I'm not aware of any way of doing it, nor of any examples of someone fixing this problem through changing the engine (as others have pointed out, Oblivion & co. do it in the content creation stage - they have FAR more powerful tools for content creation though).

Subdividing as a matter of course would probably help (and has been suggested by various people starting from comment #2), but is not a fix. I suspect a few people are thinking "subdivide the object until the problem goes away", however detecting the problem basically takes us back to raytracing (so not currently considered practical for realtime rendering).

Anyone with a technical background who thinks they have a solution, the Unreal Engine recently became free for non-commercial use ( http://www.unrealtechnology.com/ ), grab yourself a copy and see if you can sketch out your solution in that, perhaps?

Yes I've read all the comments here. First, I never agreed with LL CLOSING this topic as Resolved / Expected behavior. The problem still exists. It's NOT expected behavior as far as the end user is concerned. A fix may not be technically feasible given today's hardware and software but that doesn't mean this isn't a bug. It is. Closing it as NOT GOING TO FIX is more appropriate.

Next, my comment was directed at Harleen for re-closing a topic on behalf of the Lindens. That was presumptive. I was not saying that Yichard HAS a fix. Only that if he did, reclosing the topic takes away any opportunity to provide it.

Finally, LL has exhibited on many occasions that they are capable of screwing up and/or not knowing how to fix something and/or IGNORING fixes provided by the community. The entire development of Nicholaz' viewer was centered around him fixing things that LL wouldn't and in some cases, wouldn't even acknowledge. Yet, later, they got fixed.

So let's not be presumptive that LL consists of "scientists" who know exactly what can and can't be done. K?

2) Reclosing a JIRA report on behalf of the Lindens is NOT presumptive, it's an expected part of how the public JIRA is expected to work - with many eyes making the problem shallow, the Lindens hope that users with some experience will go through and close bugs that are duplicates, that are actually what's expected, and other semi-obvious possibilities, to allow them to focus on the things that actually ARE problems, or perhaps features that can be added. In addition, Yichard is quite capable of re-re-opening the issue, and posting the fix. He's said that he won't provide the solution until certain conditions are met. In the mean time, if Yichard wishes to get the solution out there, he's welcome to A) download the source code, code up a replacement rendering engine which fixes the problem, and make said client available to users, or B) sell the solution to any one of a number of other companies who can pay him a LOT more for it (I'm sure most major game makers and movie graphics rendering farms would dearly LOVE to have the algorithm that does this in a reasonable time, as it would speed up THEIR work incredibly, while allowing them to do really nice effects they haven't been able to so far...)

3) While Linden Labs is in fact not omniscient, when a large group of people BESIDES the Lindens acknowledge the issue, explain the issue in much the same manner, and agree that it is HARD - then anyone wanting to make claims that it is really easy, and that everyone who doesn't see that is totally mistaken, can expect to want to see proof that they are wrong. This is a KNOWN issue in Computer Science in general, there is quite a bit of study that goes on around graphics rendering, and a number of the people here are tired of people saying "I don't care if you can't do it , do it anyway! I want it! I want it! I WANT IT!"

Explanations have been made - that those explanations mean that what someone wants, they can't have - that's not MY problem. I'm not qualified in psychiatry.