Does Alpha Blend work on rigged objects?

[Faith Suki]

I'm currently working on a fur attachment for a top I made. I've been running into an issue where every time I import the same object with the same texture set, the textures on the rigged version tends to fight. I'm not to sure if this is just how it is! Or is anyone aware of a way in which I can fix it?

[Salt Peppermint]

the alpha sorting is different on rigged and unrigged items. the only "workaround" I know of is when creating the mesh, make sure all alpha layers are named alphabetically and combine them from low to high. I usually just use plain numbers. 

 

[arton Rotaru]

I don't know if it would be of any help with the issue at hand (probably not), but here is an article about alpha blend attachments sorting in general.
Kudos to @Beq Janus for sharing this important information.

https://beqsother.blogspot.com/2022/11/alpha-blend-issues-get-them-sorted.html

[Beq Janus]

Thanks @arton Rotaru

Put simply the whole thing is a bit of a lottery. It has been interesting over the last month or so. I came back from having been waylaid by RL and the need to earn money 🙂 over the summer to find that there were a number of different alpha rendering issues that emerged after the performance updates. I fixed some in FS and the Lab fixed the same ones and more in their Maint-N update, this in turn broke other things. So I've spent a while dancing circles around this stuff and playing bug whack-a-mole because the "correct behaviour" has never been defined; thus people find a thing that they think is a cool hack to make sure that their pet creation renders as they want, but then we innocently change some code and the house of cards comes crashing down.

There are a range of hacks such as the use of materials (blank or otherwise) to change the apparent render priority, the use of full bright for the same, even the use of alpha mask cutoff, when alpha blend is in use, all being treated as cast-iron rules, when in reality they are pure happenstance, a side-effect of the order in which the code runs. This "order"  may be arbitrary and thus can change because we alter the way we store something, or just change the algorithm to make things faster, who knows simply changing the compiler could affect some of these nuances.

The attachment point agreement is step one of the route out of the dark ages. I hope by the end of the weekend to have a concrete solution as a proof of concept that will go a lot further and I will seek support from the Lab to make that a documented and stable feature for the foreseeable future. By this I mean that if your content follows the rules and breaks then we will fix the viewer, if you don't follow the rules then you'll need to fix the content. Moreover, if and when the day comes that rendering upgrades and tech changes mean that some part of the rules can no longer be supported, we viewer devs (or more correctly for such changes, LL) will at least be able to broadcast this fact and make a breaking change in the full knowledge of what it is breaking.

As with the attachment points, the plan is to get a working proof of concept, test it out and work out what the impact is on current content and then ask LL to adopt it; "Beq says so" should never be acceptable (or trusted)🙂 but "LL says so" is something you should be able to hang your hat on.

TL;DR at the moment, the ordering within a linkset and within the faces of a mesh/prim is not fully guaranteed, and even where an ordering exists or can be deduced, it is not underwritten to stay that way. I hope to get that resolved soon(tm)