Alpha blend issues? Get them sorted.

OK, so I'll accept that the title is a little clickbaity, but bear with me, what I am going to explain here will make managing your rigged mesh alpha a lot more predictable.

Making it easier to avoid alpha-clashes with Second Life and OpenSim outfits

No doubt we've all stumbled across the issue of alpha blend items clashing with one another. Most of us just accept the shortcoming with grumbles, but creators have tried with varying levels of success to navigate their way through this to minimise the alpha issues.

Recent updates have enabled us to use a more deliberate and robust way to achieve this. 

The aim is to move away from the left-hand "Before" image and achieve the right-hand "After" image more reliably.

What's the big deal, Beq?

In the past, there was an implied ordering that was somewhat inconsistent or, at the very least, undocumented and thus fragile, meaning it could well break in the future.

When Linden Lab was developing the recent performance improvement updates to the viewer that were recently delivered, there came a point where a choice had to be made in order to enable alpha-blend rigged meshes to be batched under more circumstances. This choice basically boiled down to ensuring that rigged mesh items were sorted, like everything else. The problem was that sorting them caused numerous things to break. Ultimately, what was deemed to be the "least damaging" sort order was settled upon. This sort-order was effectively setting in stone the implicit ordering that we had before, but it does have some gotchas that we'll come to. 

What does the ordering mean?

In the "before image" above and at the top of the blog, we can see that the alpha of the hair is not correctly interacting with the dresses underneath it. This is because the ordering is incorrect. when the hair is being drawn the dress has not yet been drawn, and as a result, only my bare skin shows as being "underneath". 

By ordering the attachments explicitly, we can ensure that the hair always appears to be on top and thus that any items worn closer to the skin will "render as if under" the hair.

OK, so how does this new thing work?

An excellent summary of the new sort order posted "anonymously" can be found on Tumblr. This summary was initially put together by a well-known hair creator who then discussed this with another creator and me; they have decided to remain anonymous as they don't want to become the focus of all the questions that will ultimately come of this and, of course, the anger if it should ever stop being true.

Before publicising the new rules too widely, I suggested that we wait until I could confirm that Linden Lab (specifically Runitai Linden, the rendering team lead) were happy that what we were publishing was indeed something they (and thus we, i.e. Firestorm) would look to maintain going forward. 

I specifically want us to be able to move on from creating items that rely on folklore towards robust rules that are guaranteed at least to the point where any future breaking changes would be obvious to LL and allow them to give us fair warning. 

Here is the link to the Tumblr post itself. It is a great concise read and includes a great example of fragile folklore that has been depended upon in the past.

You used to be able to fix this by using bump and specular maps to assign priorities

While the above quote may be true, it was not something that was deliberately defined by anyone and thus is not something anyone should be relying upon. when such things break, we often have to duck and dive through all kinds of weird paths in the code to help fix someone's favourite little hack. The result is bloated, slower code that is extremely prone to breakage (fragile) and may well impose severe limitations on future development. This is not good for anyone.

So let's have a quick look at the post and the list.

"There are two things that decide the priority: the attachment point, and the root prim transparency.

Let me explain. LL recently added priority to each attachment point, here is a breakdown of what priority each bone has. Please note that the lower the number, the higher the priority:"

This ordering is actually defined in the avatar_lad.xml file that is distributed with the viewer. Each attachment point entry has a numeric ID specified, and it is this that defines the sort order. 

The list above includes all the attachment points for completeness. Keep in mind though that the HUD points don't really count as nobody else will see the attachments on those.

If you would like this as a notecard then I have placed it in a box in my "factory/shop" 

SLURL to Alpha Rigged Attachment Order List

As the blog notes, this means that a rigged mesh hair attached to the skull will render as if it is on top of a mesh head that is attached to the chin attachment point. Creators can now use this ordering to give the most logical layering of alpha items, whilst end-users can tweak their outfits to avoid clashes by changing the attachment point. 

Caveats

There are a couple of issues that need to be highlighted here. 

1) Make sure your root prim is at least partially transparent.

This first point is important at the moment and one of the primary sources of "content breaks" on the latest viewers. It alludes to the fact that the above ordering is enforced only for items that share the same root prim state of alpha-blend. Rigged items with a semi- or fully-transparent root prim will prioritise with one another as above; meanwhile, items with a solid root prim will similarly sort amongst themselves. However, those with a solid root prim will always draw as a lower priority (render as if behind/underneath) those items with transparency on the root prim. 

The reason behind this anomaly is deep down in the technicalities of the rendering pipeline, and while it would be preferable for all of us to have a consistent behaviour that did not get impacted by this weird and arbitrary anomaly, changing this behaviour is not easily achieved without risking many other breakages and thus for the time being creators are advised to use transparency on their root prim (which is frequently a block). Because, at the present time, the majority of items seem to have transparency, and moreover, there are cases where the item cannot work without it (because the root prim cannot be buried inside the body/head, for example), the strong recommendation is that creators converge on the standard of ensuring that the root prim is at least partially transparent. 

Important: While the attachment point priority changes have been confirmed as an intentional change and should stick around going forward, the root prim transparency part is not confirmed. This means that it might not remain true in the future. 

There is a hidden performance trick in here too.

Further to making your products behave nicely with others, I would advise anyone using a hidden/buried root prim to make that prim fully transparent; doing so will remove that prim from the rendering overhead and reduce the overall cost of rendering the attachment. Another performance win. It will also ensure that should a user want to attach to a non-standard attachment point, they won't have your logo box poking out of their face.

2) Make a copy if you need an item to be worn in different places with different outfits.

The final caveat is perhaps more subtle as it only applies if you have an item that is worn with many different outfits and might have a different priority within those. You may have noticed in the past that when you attach an item to a specific attachment point, it will remember that change, so every time you wear it, it will return to the same point. 

This means that if you have saved 5 outfits with "My little black dress" at priority 17,  but for some reason, you need to change it to priority 20 for a new outfit. The next time you wear one of the original outfits, the dress will have moved to the most recent priority. The simplest way to avoid this is to make a copy and consider renaming it with the priority number.