Possible work around for alpha sorting problem

[Kavorka]

I spent hours today trying to create a plant that used several curved planes with alphas aplied.  This creaeed the alpha sorting glitch.  After a lot of trial and error, I have something that mostly works.

 

I am trying to create a mesh plant.  Using a curved plane, I duplicate it and flip the normals so it has the same mesh for the top and bottom.  I do not join the meshes.  I import the mesh into second life.  When I apply the texture,I apply it to the bottom mesh first, then the top.  This gives me a nice leaf with no alpha sorting glitch.  If I duplicate this object, the original now has the glitch, but the new one doesnt (weird).  To get around this, I just rez another and repeat.  When placing them together, there is still no alpha sorting glitch.  But, if I take a copy and rez the copy i took, it now has the problem.

 

So, this mostly works for me, but then, if you want a copy of it, you have to recreate it again and thats just a pain.  I am trying to create a dense rain forest and need lots of ground cover.  I want to use mesh because I have much more control over how many polys and also each level of LOD.  If I use sculpties for it, I'm affraid it wont look as good and also run slower on some omputers.

Anyone else have a better solution?

[Chosen Few]

You're wasting your time on this.  Alpha sorting is alpha sorting, is alpha sorting.  There's no way to make it behave differently, without fundamentally altering the principles behind how modern graphics works.

Most likely the reason you're seeing different effects with existing objects than with newly rezzed ones is because of certain tricks SL employs to save on processing overhead.  It tries not to re-sort things that haven't changed from frame to frame.  With that in mind, here's what might be going on. When you construct an item in the order of oprations you described, you are, in effect, manually supplying the renderer with information about which surface texture to draw first. In that situation, it might decide not to bother re-sorting if it doesn't think it has to.  But when you you bring a new copy of the object into existence, both of its surface textures are generated at the same time, so they have to be sorted.  Hence the copy displays the glitch.

You said that when you duplicate the model, the new copy does not display the glitch, but the original does.  How did you do the duplication?  Was it by shift-dragging?  I can think of a few reasons why this might be:

1.  You might have gotten the two copies backwards.  When you shift-drag to produce a new copy, the original is the one that moves, and the new copy is the one that remains behind.  Not everyone realizes this.  If the one that stays behind was the one that displayed the glitch, then the behavior is consistent with what I described above.

2.  If the one that moves is the one that displays the glitch, the fact that you moved it is most likely the reason.  Movement is a change which can trigger a re-sort.  The fact that the other one appears to be sorting the way you want might just be dumb luck.

3.  The mere fact that a new object has been added to the scene might trigger a re-sort of the entire scene, in which case all bets are off.  Either or both of the models could then appear to sort correctly or incorrectly.

 

I'd be willing to bet that the leaves you're seeing as non-glitchy would look perfectly normal (glitchy) to anyone newly arriving upon the scene. 

I'm also not certain that all computers would even produce the result you described in the first place.  It might be something unique to your particular hardware and software configuration.

[Kavorka]

It was the one that moved, so as you said, the original.  I did come back with another viewer (Firestorm) and the previous non glitchy leaves were glitchy.

As a side note, I applied the alpha channeled texture to the model in blender (using the regular real time viewport renderer) and with lots of overlap, got no glitches.  Well, I did get a very slight transparency issue around the leaf, but it was barely noticable.

That leads me to believe that the way SL handels its mesh rendering is causing more problems then we want to admit, even if it is inherently an OpenGl problem.

 

But it looks like I will be going back to using those aweful sculpties for my alpha needing plants.

[leliel Mirihi]

---

Kavorka wrote:

As a side note, I applied the alpha channeled texture to the model in blender (using the regular real time viewport renderer) and with lots of overlap, got no glitches.  Well, I did get a very slight transparency issue around the leaf, but it was barely noticable.

That leads me to believe that the way SL handels its mesh rendering is causing more problems then we want to admit, even if it is inherently an OpenGl problem.

---

Blender is probably doing per triangle depth sorting where as sl is doing per object or per material depth sorting (just a guess). Doesn't matter tho because neither way is perfect, the only perfect solution is per fragment depth sorting.

And I know nobody ever listens when I say this but saying alpha sorting is an OpenGL problem is like saying running out of gas is a Toyota problem.

 

[Kavorka]

I was thinking that maybe my temporary work around could actually become a feature.  You could manually set the sorting yourself and it saves it per object.  Not a great solution, but if I could do that and have it keep after I copied it, I would be happy.

[Kavorka]

I totally agree.  Every other game has a work around to make it mostly non existant.  The fact that this has gone on this long without being addressed is a little embarrassing.

It is a flaw in openGl, but everyone knows this and plans accordingly.  This isnt something that just came up and they dont know what's causing it or how to deal with it.

[Kwakkelde Kwak]

I must be slow, but how is setting a fixed number on the sorting ever going to fix a whole lot? it will fix things from one angle, but it will make it worse from all others..always showing the wrong one instead of sometimes..am I missing something?

[Chosen Few]

For examples like the curled leaf described, it suppose it could be useful (if there weren't a million other reasons why it probably couldn't work), since if I understand the description correctly, the underside of the leaf is the inner surface of the curve.

[Kwakkelde Kwak]

Still slow I guess... looking from the "top", as you would see the leaf most of the time, the outer one wouldn't be affected by the inner one, ok. But the different leaves would still affect eachother right? or is the sorting always correct if all outer leaves have one shared texture ID (SL face)?

[Drongle McMahon]

I racalled someone saying, early in the beta, that the faces you added to a mesh last (at least in Blender 2.49) would always appear in front (be rendered last) where an alpha texture overlayed itself. I checked this at the time and it appeared to be correct. Biut I guess it could depend on all sorts of intermediate processing which could change the order. So I made some objects with two planes and textured then to test this again. 

It is appears to be still true. As long as they are on the same SLface (material), the last added mesh faces appear in fron even when that contradicts their physical location. However, whe the two planes were different materials this no nonger applied. The one in from always appeared in front independently of which had which material/face index (that is, looking at them from the front).

It would be interesting to know if the effect of face addition is the same or different for the single material case with different software.

[Chosen Few]

---

Kavorka wrote:

Every other game has a work around to make it mostly non existant.

---

 

That's true, but it's not an entirely fair statement, in regard to comparison with SL. I'll explain.

The reasons you don't tend to see sorting problems in games are manifold, but most have nothing to do with anything under the hood, technologically.  It's primarily an issue of level design, and asset design, and camera control.  Professional game artists are well aware of the issue, and go to pains not to design in such a way that might be expose it.  We simply don't overlap 32-bit textured surfaces.  Here are four very common tricks of the trade in game art:

1.  Redesign.  Concept artists aren't always aware of practicality concerns, so sometimes the only way to avoid sorting issues (among other problems) is just to bite the bullet and redesign an entire level.  CA's are never happy when that happens, of course, but I've never have any problem telling a client they should hired a concept artist who understood how 3D worked in the first place.  (I remember one project in particular in which almost every single setting in the entire game had to be redesigned, since the concept artist was a the client's on-staff Web designer or something, and either he talked his way into the gig, or maybe the company just thought they could save a few bucks over hiring a qualified CA.  I ended up having to write out many page of bullet points every day listing exactly what aspects of each level were unworkable.  It was the project from hell.)

2.  Camera control.  In games, we can restrict the player's angle of view, so that it's impossible to maneuver the camera to any point from which the glitch would be visbile.

3.  One-bit alpha.  In cases where we truly have no other choice but overlap, a one-bit alpha is often the best solution.  There's no anti-aliasing on those, so they look pretty ugly up close, but they always sort perfectly, since there's no blending involved.  With a one bit alpha, transparency is either full on or full off, no in between.

4.  Use it to advantage.  Next time you play World of Warcraft, take a good look at the vegetation.  Most of it is just intersecting planes.  Most people never notice that, because (A) they're too busy actually playing the game to stop to look critically at the artwork, and (B) they're not 3D artists, so even if they did stop to look, they wouldn't understand what they were looking at anyway.

 

In SL, the first two points are impossible.  Designing around the problem is hopeless, because even if you do all the right things to avoid overlap, your neighbor might not, and then you're back to square one.  And even if you're on your own private island, so you have no neighbors to interfere with you, there can be no accounting for every potential avatar attachment.  As soon as someone shows up sporting a nice pair of butterfly wings, say goodbye to any benefit from all that careful design work you did.

Further, everyone in SL has complete freedom of camera movement.  So, even if you make a build look right from all the most typical viewing angles, it's pretty tough to ensure it will look right from ALL possible angles.

The third point could be made possible, but it never has been.  I'd certainly like to see it implemented (although I'm not completely sure I relish the thought of adding yet another thing to the already high-piled plate of what needs explaining for all the budding artists who don't yet understand it all).

The fourth point, we already do in SL.  Its effect isn't quite as convincing in SL as it is in games, because of the first two points.  But it does work.

 

---

Kavorka wrote:

The fact that this has gone on this long without being addressed is a little embarrassing.

 

---

I really don't think so.  Every freedom comes with a price, and SL, by its very nature, allows far more freedoms than any game in the world. 

What would you be wiling to give up, in order to never again see alpha sorting problems?  Freedom of design?  Freedom of movement?

I don't know about you, but I'd rather live with a slight bit of optical annoyance here there, than give up any of the things that make SL what it is.

 

---

Kavorka wrote:

 

It is a flaw in openGl, but everyone knows this and plans accordingly.  This isnt something that just came up and they dont know what's causing it or how to deal with it.

---

It's actually not an OpenGL issue.  DirectX has the same problem, as does every proprietary graphics engine I've ever seen. 

Leliel's analogy on this was perfect.  Every real-time renderer has alpha sorting issues, just as every car can run out of gas.

 

3D modeling programs like Blender, Maya, etc., can employ other technologies, like per-triangle sorting instead of per-object sorting, or any number of software-based solutions, because they don't have to operate at speed, and because they're typically dealing with relatively few assets at a time in any one scene.  Try loading up an entire scene from Battlefield 3 into Blender, and see what kind of frame rate you'd get.  It likely wouldn't be pretty.

 

Maya, by the way, allows you to turn, per-polygon transparency sorting on or off at any time, in any viewer pane.  If Blender has a similar option, I'd advise working with it turned off, to give you a better representation of how your meshes will look in SL.

As you can see, it works perfectly.  But needless to say, it can slow things down considerably, and it's not representative of what the model would look like in a game.

[Chosen Few]

---

Kwakkelde Kwak wrote:

But the different leaves would still affect eachother right?

---

They would still affect each other, I'm sure.  It would be pretty hard to get around that.

That's not necessarily a bad thing, though.  You can build a convincing tree with a lot less polygons in it, if the leaves do interfere with each other than if they don't.  Upon close scrutiny, you'd be able to obeserve each glitch, of course, if you're looking for it.  But the everyday end user would never notice it.

From any given poly count, I'd much rather invest details into the trunk of a tree, and let the leaves just be flat planes.

[Kavorka]

As far as what happened with my little temp fix.  As long as I rezed the mesh and applied the textures, I was able to get several large leaves into a group to make a plant and none of them caused glitches with each other or with other things with transparency in the area.  I witnessed 0 glitches.

Oh, and even from the underside, there were no glitches.

[Ashasekayi Ra]

I was the one that pointed out the last item joined had the highest alpha priority for objects exported from Blender. At that time, I was using Blender 2.49 and experimenting with hair models. I don't know if it is still true for the latest Blender or the latest SL uploader. I'll have to play with that again.

A few of us had a good discussion about workarounds for the alpha problem in these thread: 

 http://community.secondlife.com/t5/Mesh/Alpha-sorting-glitch-within-a-mesh/td-p/1109161/page/2

http://community.secondlife.com/t5/Mesh/Alpha-sorting/m-p/418761#M1741

[Kavorka]

I started doing some testing by getting rid of the underside and just making it low enough to the ground and angled so you would never see the underside.  In Blender, I dont join the meshes, so each plan is independant.  Now, if I have a lot of these over laping each other, there is almost no glitches and you would only notice it if you are really looking.  So, this will work for my ground cover, but not for anything about the size of the avatar and bigger.  At least it's something.

[Kagehi Kohn]

I keep hoping for a time when this becomes less of a problem. However, "sorting" is basically a short cut. While you can still get thingsl like coincident surfaces in full raytracing, you don't get alpha sorting problems. The reason being that you hold the "whole scene" in memory at once in those, and then trace back, based solely on where the surfaces are, compared to the camera, mathematically. With graphics cards, and other "real time" systems, you are sorting out things you can't see, and resorting every surface, before running the math. You are not really "tracing" anything, you are only picking out the bits that are "visible". Everything else is thrown out by the engine. Hense, if the method used to "sort" which bits are visible throws out the wrong things, or puts them in the wrong order, etc., things go wrong.

Unfortunately, despite all the advanced made, there are a) no cards that use true tracing, and b) nothing that can bypass this issue, in anything like real time, though the chip makers keep working towards a sort of compromise system that "kind of" does so. It just can't, yet, get the frame rate needed. Ironically, since SL rarely, if ever, runs at anything like the frame rate a normal game does, we could probably get by with it, if it was even available. lol

[Strawberry Lionheart]

I've answered the same topic on another site but here goes! :cattongue:

 

That's the well-known z-buffer issue in the gaming industries.:catembarrassed:

 

If you are in 3dsmax all you need is to setup the z-sort in the layers.

For blender it's best you resort the vertex(vertices) numbers from low to high (lower layers should have fewer numbers). That's how most game read the layers by vertex number. So say.. you have 3 semi-transparent layers close to each other and the camera doesn't know which one should be on top when it comes to render and it simply render from the smallest numbers to the largest. so if your top layer is 1-4 and 2nd layer is 5-8 and bottom layer is 9-12. you will definitely get an alpha blending bug with the z-buffer rendering in SL. so what you should do is, have your top layer's vertices sort to 9-12, 2nd layer 5-8 and bottom layer 1-4. This way when z-buffer render the mesh it will load the bottom mesh 1st then cover it with the 2nd layer and then the top layer thus eliminates the bug shown in the picture you post. :catwink:

 

Hope that helps! :catembarrassed: