Why alpha cuts are bad for your health

[Beq Janus]

I've been meaning to get this all written up for a while now. Here is a two part blog on why we need to ditch alpha cuts and start making alpha layers again. 

The first part should be consumable by most. The second is more of a deep dive into the numbers and probably less interesting to most.

part 1 - https://beqsother.blogspot.com/2021/09/why-crowds-cause-lag-why-you-are-to.html

part 2 - https://beqsother.blogspot.com/2021/09/find-me-some-body-to-lovebenchmarking.html

 

[WineOtter]

2 hours ago, Beq Janus said:

most if not all viewers now have an optimization in place that prevents the rendering of fully transparent meshes

What makes a material "fully transparent"? 100% in the transparency field? If so, will that artificially inflate Complexity by forcing that face into blended alpha mode?

[Beq Janus]

The viewers test the "texture entry" attribute's colour transparency value. That is essentially the "Transparency" box on the build/edit floater or the texture face alpha property in lsl terms.

llSetAlpha(0.0, face);

So in that regard it won't affect the complexity. 

Complexity itself is a worse than useless value and while I realise that (too) many people still consider it the arbiter of good quality products it is ever so badly flawed so don't place too much stock in what complexity says. 

 

[WineOtter]

12 hours ago, Beq Janus said:

llSetAlpha(0.0, face);

So in that regard it won't affect the complexity. 

It might cut out the draw call for that face (which, according to your blog, is a big performance win) but I don't see it affecting avatar Complexity in live tests. In fact, setting a face's whole Transparency to anything besides 0% knocks the face out of emission or alpha mask mode. I've been making faces invisible by assigning a clear default texture and using alpha mask mode instead of alpha blend, to avoid the 4x Complexity rating hit. That's not compatible with this. Seems I now have to choose between what is effective or what everyone else thinks is effective.

Quote

Complexity itself is a worse than useless value

I've read that before, but it's the only one the viewer uses to determine whether to jellydoll you.

[Beq Janus]

8 minutes ago, WineOtter said:

I've read that before, but it's the only one the viewer uses to determine whether to jellydoll you.

Indeed, for now that is the case. That does not make it right. The reason I say it is worse than useless is that it quite literally makes people do the wrong thing on many occasions. 

There is a separate thread in the viewer forums where I shared a snapshot of the the so-called worst offenders based on their ARC alongside their actual render time on the machine I was running on. There was next to no correlation between the two. 

Here it is. 

 

The above image shows the Beq-hacked version of a new tool inside the viewer that the lab are planning to release. In my one I have altered the white line graphs to show the actual rendering time, but it remains (in this image) sorted by ARC, you can very clearly see that ARC has no bearing on actual FPS performance. 

Here is the Lab's original, same UI just that the white line is indicating the ARC instead.

 

Sorry for the blur I cropped it from a video clip I made. Notice here how by sliding the uhm slider we are "causing the top of the list people to be jelly dolled"?

Great idea, in theory, but when you look at the image from my version where the white lines are the true render cost. you can see that by jellydolling the top ARC people you are 1) de-rendering the innocents and 2) not really achieving the intended result.

In fact, in my example at the top just removing that one FPS hog person would have saved more FPS than jellydolling the top 6 or maybe 7 using ARC, and with the ARC option you'd still be left with the worst offender. You might as well just pick avatars based on their hair colour.

I want to be clear here though. The tool itself is reasonably well-formed, the intention is great. I like the UI shown above, I am now lobbying and asking LL at every opportunity not to release it until there is something better than ARC in place. I will be updating my blog with my progress on what I hope will be an improved version of this tool. The trouble is that ARC is not just for the jellydolls it is used elsewhere, people such as yourself use it to decide if their products are good (which is a really great thing, we need to take care over such things) but giving people the wrong advice is depressing and coutner productive.  

We desperately need tools. What we don't need is more badly misleading tools.

 

 

 

[ChinRey]

9 hours ago, Beq Janus said:

We desperately need tools. What we don't need is more badly misleading tools.

Mandatory question: has anybody heard any news about Project ArcTan recently?

[Beq Janus]

58 minutes ago, ChinRey said:

Mandatory question: has anybody heard any news about Project ArcTan recently?

It's sole manifestation at present is the performance floater project viewer.  I would recommend having a look and giving feedback on the UI. That's what project viewers are for. 

I hate a couple of aspects o the UI and really like some others. The content of it, so very flawed, I've covered, let's not go there I can feel my blood pressure rising 😉

[Extrude Ragu]

That was an interesting read. This graph was quite fascinating to me

The drop is quite dramatic at first, although it is interesting how it seems to have less effect beyond a point.

As someone who creates a couple of Chest Mods for the Kemono Body, this is interesting to me.

My mods aim to reduce lag by reducing the amount of mesh used, and they do this by taking advantage of the Alpha Slices of the Kemono Body.

But what you're saying here at least as I understand it is that 100% transparent mesh has little to no performance impact on the viewer unlike visible mesh, so trying to reduce the amount of invisible mesh does not really make much of a difference at all. In fact, things that I assumed created a lot of unnecessary lag on the Kemono Body (Such as having two sets of legs, one human, one animal hidden) would really make no perceivable difference to performance, and we can actually keep invisible meshes worn without much guilt.

Instead if I really wanted to make a difference, I would provide my Chest Mod without alpha slices to reduce the number of draw calls. Of course as a creator that is a tough call, as Kemono is not BOM. The best I could do is provide a 'low lag' version without alpha cuts in the future.

[Extrude Ragu]

@Beq JanusHear me out on this and tell me if it is a smart or dumb idea, I am just going based on my understanding of what you have wrote:

Perhaps I could even have two of my Chests in one linkset, one with many materials, one with just one. When the user wants the chest fully visible, I'd just have the link with a single material shown, and otherwise I'd show the link with many materials.

Counter intuitively, even though the user is now wearing twice as much mesh, the lag would be reduced when the user has the Chest fully visible, because only a single material is visible and thus a single draw call instead of 8. Invisible mesh does not make a perceivable impact on performance and thus the 2nd link even though it has all those alpha slices would have a negligible impact on performance because it's all 100% transparent.

Am I understanding this right? Although I am one of the smaller creators, it'll still hit a lot of people if I rolled out changes like this so I want to be sure.

[Jenna Huntsman]

On 9/14/2021 at 9:49 AM, Beq Janus said:

The viewers test the "texture entry" attribute's colour transparency value. That is essentially the "Transparency" box on the build/edit floater or the texture face alpha property in lsl terms.

llSetAlpha(0.0, face);

So in that regard it won't affect the complexity. 

Complexity itself is a worse than useless value and while I realise that (too) many people still consider it the arbiter of good quality products it is ever so badly flawed so don't place too much stock in what complexity says. 

 

Does having a texture in Mask mode with the cutoff of 255 also trigger this?

[Extrude Ragu]

Continuing on that train of thought, does that mean that the amount of mesh being rendered before and after CTRL+ALT+T changes? presumably 100% transparent mesh must be being skipped from rendering if it has a negligible impact on performance, but such meshes are visible in CTRL+ALT+T. So the viewer is rendering more then?

The Devils Advocate in me wonders if someone could make a CTRL+ALT+T lag bomb, where a whole bunch of 100% invisible complex meshes are worn, and because they are transparent they don't have a noticable impact until someone CTRL+ALT+T's at which point it could overwhelm the viewer.

(Sorry for writing so much )

[Beq Janus]

6 hours ago, Extrude Ragu said:

The Devils Advocate in me wonders if someone could make a CTRL+ALT+T lag bomb, where a whole bunch of 100% invisible complex meshes are worn, and because they are transparent they don't have a noticable impact until someone CTRL+ALT+T's at which point it could overwhelm the viewer.

It would be a pretty lame grief if it were, but no, the example you give would not work in the way you describe because the optimisation works for rigged mesh and transparency overlay does not work on rigged meshes anyway. 

7 hours ago, Extrude Ragu said:

@Beq JanusHear me out on this and tell me if it is a smart or dumb idea, I am just going based on my understanding of what you have wrote:

Perhaps I could even have two of my Chests in one linkset, one with many materials, one with just one. When the user wants the chest fully visible, I'd just have the link with a single material shown, and otherwise I'd show the link with many materials.

Counter intuitively, even though the user is now wearing twice as much mesh, the lag would be reduced when the user has the Chest fully visible, because only a single material is visible and thus a single draw call instead of 8. Invisible mesh does not make a perceivable impact on performance and thus the 2nd link even though it has all those alpha slices would have a negligible impact on performance because it's all 100% transparent.

Am I understanding this right? Although I am one of the smaller creators, it'll still hit a lot of people if I rolled out changes like this so I want to be sure.

I think when you say material, you mean mesh/submesh (i.e. a parcel of stuff for the GPU). In all cases, if you are drawing less, then the frametime will drop, absolutely. Look at the exmaple I showed of the multipose mesh feet, look at the trend in the last year or so towards multistyle hair. These are not the massive disaster that you would expect, purely because we side step the issue with the "transparency trick". Would I advise going down that route...? It depends. In most cases there are more efficient means to achieve a result. I would look into how you can achieve the same without that, be inventive. In the long term, once we've all got rid of the 1000lb gorilla's on our backs, I may well be whining about how unnecessary transparent meshes are causing cache churn and thus slowing things down. Everything has an impact somewhere.

Keep in mind that frametime lag, is not the same as lag in the broadest sense. As I noted in the blogs, I am measuring only the outright render cost, the most direct impact on the FPS. If you want to consider the time it takes to download, to cache, to unpack, then that extraneous mesh will have an impact (the files is bigger after all). Those aspect do not however directly impact FPS because they are not conducted by the main thread. And I want to be clear on this. Just because I showed that the triangle cost is not a driver of the CPU render time, that is not a green light to slam things full of triangles. Far from it.

Triangles do have an impact (especially on the low end machines, as my graphs indicate) they are just not detectable because the drawcall load is such a heinous thing. Once we remove those overheads then the smaller costs will show up more clearly and may well nuance "efficient" from "very efficient".

And while I know that this is now talking about something else entirely. Please keep in mind that the drawcall burden is a large part of why almost everyone is CPU bound in SecondLife (that is to say that for a typical scene with avatrars in your GPU is not working as hard as it could because the CPU is too choked up with pushing boxes of body parts around to keep it busy. Once we get rid of that bottle neck then we're likely to see more people constrained by GPU limits, and one of the worst offenders there is "overdraw" (painting the same pixel more than once) which is caused by many factors and which tiny thin triangles are a big source of.

We are getting deep into "future problems", and they'll be nicer problems to have in that regards as we should (hopefully) be in a generally happier place. 😄

 

7 hours ago, Jenna Huntsman said:

Does having a texture in Mask mode with the cutoff of 255 also trigger this?

 No. Not in anything like the same way. The reason that the submesh diffuse colour transparency test works so well is that no matter how large or small the mesh, it is a single value test. "Is the face alpha set to 0.0". You cannot make the same assertion for arbitrary textures, we would have to check whether every pixel was transparent to draw the same conclusion. What we could do is test a known UUID such as the default transparent texture (somewhere in a thread over the last week or so we examined a Jira that spoke of this). We could...but why pollute things, if we have one perfectly good "off switch" we'd need to have a strong use case to want to start adding more variants. Never say never, but a compelling reason why the existing method is not adequate and proof that a new method has no unexpected gotchas (always a worry) is needed.

 

Finally, and I use this as a summary of all the above.

8 hours ago, Extrude Ragu said:

In fact, things that I assumed created a lot of unnecessary lag on the Kemono Body (Such as having two sets of legs, one human, one animal hidden) would really make no perceivable difference to performance, and we can actually keep invisible meshes worn without much guilt.

Instead if I really wanted to make a difference, I would provide my Chest Mod without alpha slices to reduce the number of draw calls. Of course as a creator that is a tough call, as Kemono is not BOM. The best I could do is provide a 'low lag' version without alpha cuts in the future.

Yes and yes. The key term here is "without much guilt" I honestly do not feel comfortable suggesting that having invisible meshes around is a god thing. In the end it is not, if you can find a better way please please please do. However, they are not leading to anything like the kind of problems the slices cause.

In the end, it would be better all round if we didn't have invisible floaty stuff being worn, it'll bite us on the bum in the long run no doubt. But if you need to pick one then it is by far the lesser of two evils.

Also, all things in moderation. A few slices here and there to enable some cool feature is fine. hundreds of them for no real benefit is (I am arguing) very much not fine.

[Stephanie Misfit]

I'm in the Slink group and I have seen a few people absolutely losing it in group chat over the fact that Redux does not offer alpha cuts. Siddean has said repeatedly that Slink will not make this feature available and that alpha layers are the way to go, for all the reasons that you have said. I've rarely needed them for Redux anyway, or for Kupra for that matter (and it seems it is only since the introduction of Kupra that some designers have started offering them with their clothes). If people are looking for alpha layers for their clothing for these bodies, Slink has a ton available for free at their store, and Little Black Dress does too. Alternatively, Slink has YouTube videos on making them. It would be awesome if creators offered cut free versions of their bodies as you have suggested and alpha layers became a thing again, they aren't that hard to make, they are just a lost skill.

.

[Anna Nova]

10 hours ago, Stephanie Misfit said:

.... It would be awesome if creators offered cut free versions of their bodies as you have suggested and alpha layers became a thing again, they aren't that hard to make, they are just a lost skill.....

I suggested (on Discord) to Maitreya that they include a cut-free version of the body in the next release, so far it's been ignored.  However, I did get a Red-Heart Emoji for a link to this thread - so maybe there is hope...  I think it's important for transition that people get the choice, <expletive deleted> can have their alpha-cuts, and the intelligentsia can use alpha layers to sort lag.

Making alpha layers is fun too.