polysail commented at 2016-03-23T17:55:07Z, updated at 2016-03-23T18:07:48Z

Edited for Clarity.

polysail commented at 2016-03-23T17:57:06Z, updated at 2016-03-23T18:08:02Z

Renamed photos so they were in the right order.

polysail commented at 2016-03-23T18:13:50Z

More edits for clarity.

Whirly Fizzle commented at 2016-03-23T22:59:07Z

Even if this change was implemented after the "serverside baker" it would break a lot of ordinary rigged mesh attachments.
As you said yourself, it's common practice to not even bother with any detail at all for lower LODs for rigged mesh attachments. Bear in mind the LL viewer has really low LOD settings by default too. Rigged attachments would disappear in a lot of cases when the camera was only 1-2m from the avatar.

This would happen constantly too: BUG-7239 & BUG-11309

It's a pity this wasn't done right from the start really but I presume there were reasons for the way it was implemented.
I always thought it was expected behaviour that rigged attachments used the avatar LOD.

Related: https://community.secondlife.com/t5/Mesh/level-of-detail-and-rigged-attachments/td-p/1594597
Last comment from Chosen Few is interesting.

polysail commented at 2016-03-24T07:31:08Z

Yes~ if it were changed to use object bounding box LOD a lot~ and I do mean a LOT of content would break, hence the suggestion to use something relating to render complexity to overall bounding box volume of the entire attachment in order to do LOD scaling. Because presently, if I make a rigged mesh shoe, and it has 125K polys, everyone in viewing distance of that shoe has to render either it's medium ( or more than likely HIGH ) LOD of that shoe. These distance tests were done on the Linden default ( bento ) viewer, so the LOD scaling is accurate to default settings. Like I stated, I was just as surprised as you were that this wasn't "intended behavior" as far as Oz was concerned.

polysail commented at 2016-04-06T16:18:46Z

NOW WITH GLOSSY PRINT AND CIRCLES AND ARROWS.

Whirly Fizzle commented at 2016-07-18T10:22:34Z

The fix for this issue is breaking pretty much all rigged mesh, it's especially bad on rigged mesh bodies & heads.
See comments on https://bitbucket.org/lindenlab/viewer-neko/commits/a1a0a055e892f811ee5fdfa770f76eaa0fc43196#comment-3418973

AndreyK ProductEngine commented at 2016-07-18T12:56:52Z, updated at 2016-07-18T15:48:36Z

Thanks for testing. Will work at alternative.

Upd: Backed out changeset, looking for alternate solution.
Looks like objects of different sizes attached to avatar need to be dependent onto something to keep their LOD switching in sync, otherwise it can cause issues. Also I suspect that mesh head you were testing simply lacks lower lods (looks like a demo head, please provide market link, can't repro), either way breaking things to this extent won't do...
It still should be possible to make smallest objects disappear/switch LOD at distances where they can't be seen good enough, but it doesn't look very advantageous.

P.S. If possible, please test http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/maint-neko/rev/317796/index.html
Meshes should get bigger 'offset' before breaking but I'm not sure if it will be sufficient.

Whirly Fizzle commented at 2016-07-18T15:47:39Z

A lot of rigged mesh lacks all lower LODs, because they were never needed before...
Hence the concerns above that this change could break a lot of rigged mesh content.

On the commit comments, the Trinity LAQ mesh head is not a demo & the Maitreya mesh body is not a demo.
The Catwa mesh head in the video is a demo but its fully functional & the non-demo version has the same problem.

You can get the Catwa mesh heads shown in my video here: http://maps.secondlife.com/secondlife/Catwa%20Clip/118/145/22

Whirly Fizzle commented at 2016-07-18T15:57:27Z

Catwa mesh heads on the marketplace: http://bit.ly/29Jz5C2

AndreyK ProductEngine commented at 2016-07-18T16:10:39Z

Thanks.

Whirly Fizzle commented at 2016-07-25T16:05:29Z

@andreyk

I'm still seeing problems after the latest changes at https://bitbucket.org/lindenlab/viewer-neko/pull-requests/9/maint-6259-rigged-items-lod-should-be-size/diff
I'm using the build linked on that commit: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/maint-neko/rev/318024/index.html

• If you use Ctrl+0 to zoom camera in (totally normal thing to do for close up portrait shots because it removes the fish eye effect when zoomed in close), rigged mesh will collapse really easily when RenderRiggedFactorMultiplier is set to default (now 8.00).
  Example: http://prnt.sc/bxbshr
  In above image I'm wearing a rigged mesh head (LAQ Trinity) and rigged mesh hair.
  This does not reproduce on default release with rigged mesh.

• After most teleports, rigged mesh is getting stuck at low LOD until you edit it or cam out & back.
  If the rigged mesh isnt getting stuck at low LOD, camming out & back is likely to cause the rigged mesh to get stuck at low LOD.
  It's the same problem as BUG-11309 but on this build it happens much more frequesntly.

Second Life 4.0.7.318024 (Second Life Test)
Release Notes

You are at 216.8, 134.3, 43.3 in Nuts Island located at sim9946.agni.lindenlab.com (216.82.46.88:13025)
SLURL: http://maps.secondlife.com/secondlife/Nuts%20Island/217/134/43
(global coordinates 256,217.0, 311,430.0, 43.3)
Second Life Server 16.07.06.317395
Error fetching server release notes URL.

CPU: Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz (3491.94 MHz)
Memory: 16268 MB
OS Version: Microsoft Windows 7 64-bit Service Pack 1 (Build 7601)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce GTX 750/PCIe/SSE2

Windows Graphics Driver Version: 10.18.0013.6881
OpenGL Version: 4.5.0 NVIDIA 368.81

J2C Decoder Version: KDU v7.2
Audio Driver Version: FMOD Ex 4.44.31
LLCEFLib/CEF Version: 1.5.3-(CEF-WIN-3.2526.1347-32)
Voice Server Version: Vivox 4.6.0017.22050

Packets Lost: 1/57,508 (0.0%)
July 25 2016 08:58:21

Whirly Fizzle commented at 2016-07-25T16:14:27Z

Is there a build available with your latest changes for this issue & also Ruslan's fixes for BUG-11309?
I think Ruslan finally had a fix for BUG-11309 but I can't find it.
What I'm seeing may just be BUG-11309 reproducing pretty much all the time after these changes because the rigged mesh loads at lower LOD much more frequently & remains stuck when cam is moved closer to the avatar.

Having said that though, editing the rigged mesh when it's broken isn't causing it to pop back into place since these changes: http://prnt.sc/bxby8p
Editing the broken mesh usually does fix the BUG-11309 case.

AndreyK ProductEngine commented at 2016-07-25T16:26:48Z, updated at 2016-07-25T18:17:56Z

It does look like BUG-11309.
Checked the ctrl+0 case and to me it looks more like distance calculation-camera issue. I will have to check it in more details and see what can be done (right now can't think of anything but checking for zoom factor which obviously isn't that good of a solution), but only once it is clear that BUG-11309 is fixed. If BUG-11309 still reproduces I will have no other choice but to mark this issue as blocked and revert the change.

Build with both changes: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/viewer-neko/rev/318044/index.html

Whirly Fizzle commented at 2016-07-26T01:46:59Z

That build seems fine!
The default setting for RenderRiggedFactorMultiplier has been lowered from 8 to 7.5. Unsure if this was an intended change.
7.5 seems to be ok on this build though.

At normal camera zoom (Ctrl+9), Im not seeing any of my rigged mesh collapse as I cam away.
At max camera zoom (using Ctrl+0), my rigged face doesn't collapse until camera is fairly far away: http://prnt.sc/bxizfx
At this max camera zoom, unrigged attachments would be collapsing anyway at this distance.

AndreyK ProductEngine commented at 2016-07-26T05:01:18Z, updated at 2016-07-26T05:12:36Z

Thanks for testing.
Change to 7.5 was intended, also I slightly adjusted ramp distance with It, but thought changes to be too insignificant to update build.

P.S. I still think that ctrl+0 might be bugged - distance passed to lod calculation is far bigger then visual distance, but this also might be intended behavior for lod testing.

polysail commented at 2016-07-28T17:03:31Z

Okay so. Little bit more info on how this issue impacts other things as well. ARC Costs are calculated based on LOD swapping data. However since rigged meshes are only functionally using HIGH and MEDIUM LOD's people are effectively cheating the system by uploading rigged mesh assets with 1 triangle MEDIUM LOW & MINIUM LOD's. So, for example the 3.7 Million polygon CatWa mesh head, because of it's 1 triangle MEDIUM, LOW and LOWEST LOD data comes up to approximately 5K ARC Cost. However, if you do the math on how it's effectively displayed ( due to how rigged LOD swapping is presently handled. If one tries to upload an mesh with the appropriate polycounts and LOD settings, correlating to how it's actually displayed. If my estimates are correct ~ the effective ARC cost should be roughly 23,494,000 ( no those aren't extra zeros , literally should be roughly 23.5 million ARC ) So the ARC cost vs the display cost is off by a factor of ~ uhm 4000+ ? Maybe I should create a separate JIRA for this discrepancy?

AndreyK ProductEngine commented at 2016-07-28T17:44:14Z, updated at 2016-07-28T17:44:53Z

That's a different kind of issue, so I would recommend new jiras, something like "LODs below HIGH have too little triangles, please limit ability to upload meshes with non-existent med-lowest LODs" (Since nobody is going to mess with existing models that's main option in my opinion) and "Cost of models with only high LOD set properly is too low" (but I suspect this one will be ignored or low priority)

polysail commented at 2016-07-28T18:16:16Z

The notion wasn't to limit uploads in any fashion but more change the ARC Calculation to reflect the actual expected display behavior. And correlate the ARC cost to the actual LOD swapping that takes place, rather than the numeric values defined by the raw triangle counts in the mesh asset file.

AndreyK ProductEngine commented at 2016-07-28T18:28:04Z

Then "ARC Calculation doesn't reflect actual expected display behavior due to all triangles being used in high LOD", it is still a separate issue.

Lucia Nightfire commented at 2016-07-28T20:07:44Z

"LODs below HIGH have too little triangles, please limit ability to upload meshes with non-existent med-lowest LODs" shouldn't be an option as many people, myself included, use low LoD levels below High for applications that are viewed explicitly at close range, such as HUDs or nearby objects in mouselook. People don't use it stictly to get low land impacts or low upload costs. Like with everything, use case can play a major part in settings choice. Limiting this now would cause future uploaded scenes to be more render intense as their LoD levels would persist from any average camera perspective due to higher tri counts per LoD level. It won't stop people from filling their land with scenery despite higher average land impacts either.

I would rather be in favor of an ARC calc change or an upload cost change even though we know it will cause screams, heh.

AndreyK ProductEngine commented at 2016-10-17T18:00:06Z, updated at 2016-10-17T19:26:20Z

Whirly, if possible please check this one again - there were slight changes to fix, now instead of object bounding box, drawable's dimensions are used.

Whirly Fizzle commented at 2016-10-17T18:50:27Z

@andreyk
Which repository? Neko?

AndreyK ProductEngine commented at 2016-10-17T19:05:23Z, updated at 2016-10-17T19:05:51Z

It already got to maintenance build.
http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/viewer-bear/rev/320723/index.html
Thanks.

Whirly Fizzle commented at 2016-10-17T19:16:10Z, updated at 2016-10-17T19:17:29Z

Ok thanks I'll try that one - build is still in progress.

Problem still reproduces on latest Neko build http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/viewer-neko/rev/320726/index.html
Gif showing the problem with rigged Catwa mesh head: https://gyazo.com/09d691098db634376dc5703162a6846b

Same problems as filed in BUG-40616

AndreyK ProductEngine commented at 2016-10-17T19:25:51Z, updated at 2016-10-17T21:31:59Z

There seems to be no reliable way to get real mesh size...
Do you think it is reasonable to use object's bounding box? It is limited by avatar size so users will be able to control visibility range of objects to some extent while not being able to go above what was seen previously. But it doesn't look like right solution to me. For now reverted to bounding box and looking for a better solution.

P.S. Build is completed but stuck in "in progress state" for some reason. Neko includes fix as well.

polysail commented at 2016-10-17T21:47:13Z, updated at 2016-10-17T22:12:30Z

Changing the bounding boxes is going to change how the LOD scales. Since CatWa heads have everything but the highest LOD completely zeroed (single triangles) I imagine they'd vanish? Or is this something different entirely? Is it possible that 40616 "full of holes" mesh is simply just displaying an auto-generated Medium LOD setting? I can't seem to comment directly on 40616 so I'm writing it here.

I'm referring specifically to this GIF : https://jira.secondlife.com/secure/attachment/95260/Fig%205%20-%20Head%20broken%20on%20Maint-RC.gif
That is a solid example of an LOD swap.

The whole entire goal of this was to hopefully make extremely high vertex count content LOD swap sooner than the avatar bounding box, ( possibly even dynamically based on it's vertex count? ) My original suggestion to use the "linkset" bound box would make things that are comprised of 100's of tiny sub meshes not so drastically affected ( like mesh bodies for example ).

Anything involving changing rigged mesh bounding box display behavior is dancing on eggshells of how much (absolutely terribly designed) content you're willing to change the viewing behavior of, for better viewer performance. The CatWa head has a sixth of an entire sim's worth of geometry inside it ( 3.7 mil poly~ appx?? ) I can show you rigged mesh shoes that are 1.5 Mil or so polys each.

AndreyK ProductEngine commented at 2016-10-17T22:12:56Z, updated at 2016-10-17T22:20:22Z

"full of holes" mesh is simply just displaying an auto-generated MEDIUM LOD setting
Unfortunately it is not only auto-generated, but autogenerated with lowest triangle count possible (or with something extremely simple) to save up lindens on upload/impact value... Model with no lower lods like "Catwa" causes a lot of issues with fixing this issue (for example it is forcing to amplify higher lod at higher distances to make them visible, which is far from right solution).

polysail commented at 2016-10-18T00:17:26Z

I would venture to say 4/5 ( 80% or so literally ) of popular rigged mesh items in SL have either single triangles or something on par with that for their Low and Minimum LODs. People figured out long ago that this was how things were displayed and designed accordingly. The issue just came into play when the incredibly high vertex count stuff got... popular~

Whirly Fizzle commented at 2016-10-18T07:56:17Z, updated at 2016-10-18T08:02:09Z

P.S. I still think that ctrl+0 might be bugged - distance passed to lod calculation is far bigger then visual distance, but this also might be intended behavior for lod testing.

Is it possible to fix this? So that when zoomed in using CTRL+0 and zooming camera out (by scrolling mouse wheel or alt+click zoom) the LODs behave the same as when not in CTRL+0 zoom?
If behaviour was changed here I don't think there would be any issue with these new LOD swapping changes.

Could add a debug setting to swap back to the old behaviour for LOD testing purposes.

Maybe this isn't worth the effort though because we can crank up RenderRiggedFactorMultiplier to fix the problem anyway.

AndreyK ProductEngine commented at 2016-10-18T09:59:47Z, updated at 2016-10-18T10:23:47Z

ctrl + 0 is not the only issue, riggend dimentions apparently are 0 for some meshes... still figuring out why.
RenderRiggedFactorMultiplier is more of a hack to compensate for missing lods and I don't think relying upon it to fix every problem with mesh size is correct.

My original suggestion to use the "linkset" bound box
In cases of meshes I don't see any childs (linksets), except for multiple drawable components, but those are accounted for. But it might help with things like Catwa (apparently has 90+ prims)
So far the problem is to get real size of a mesh which is not part of linkset to calculate distance we need to swap lod at.
P.S. Using linksets also isn't optimal solution since users might intentionally place something transparent/small afar from main item and get higher visibility range as result.

polysail commented at 2016-10-18T10:18:01Z, updated at 2016-10-18T10:23:43Z

The meshes that are turning up with zero volume, are they 3-4 material meshes? If so. There was another odd mesh bug Beq was trying to solve: relating to 3-4 material meshes having "prim type cylinder" which had no Z component to them. : http://beqsother.blogspot.co.uk/2016/10/bug-hunting-fixing-ancient-lod-issue.html Note the Code snippet :

...snip...        
    if (path_type == LL_PCODE_PATH_LINE && profile_type == LL_PCODE_PROFILE_CIRCLE)
    { //cylinders don't care about Z-Axis            <-- But seriously.. why? why is this?? 
        mLODScaleBias.setVec(0.6f, 0.6f, 0.0f);
    }
    else if (path_type == LL_PCODE_PATH_CIRCLE) 
    {    
        mLODScaleBias.setVec(0.6f, 0.6f, 0.6f);
    }

 ...

AndreyK ProductEngine commented at 2016-10-18T10:23:08Z, updated at 2016-10-19T07:03:48Z

That one should be fixed already (current maintenance build). Cylinders should be unaffected, but meshes' scale should no longer be treated as if meshes are cylinders.

Whirly Fizzle commented at 2016-10-18T10:57:15Z

Beq's bug Polysail mentions above is filed at STORM-2138

polysail commented at 2016-10-18T11:20:51Z, updated at 2016-10-18T12:15:35Z

How about this? All rigged mesh content has a ( dependent upon graphics settings ) 3-10 meter radius from the avatar it's worn on where it will be 100% guaranteed to have High LOD visible. After which it'll start falling off normally based on a numerical scalar based on it's volume divided by a factor based on it's total vertex/triangle count.

Keep the current system of behavior for the users avatar. ( that should be a special case for all the fashionistas and photo people ) So our own avatars don't LOD degrade on camera distance. In addition to this if a user selects "Always Render Fully" on an avatar, they too will "inherit" the special case of the user avatar LOD behavior. ( again useful for taking photos and fashion events )

Hopefully when ARC accounting catches up, Jelly AV's will unload more of the viewer clients stress by simply unloading massive quantities of vertex data from memory.

That would hopefully minimize the impact on the community, yet still make performance gains "on people you don't really care about."

The only downside to this is ~ up to a certain point, anything involving dealing with this bug is basically issuing a mandate on content in terms of numerical limits. It doesn't really matter what number is settled upon. Whether it's 50K triangles, 100K triangles, 300K triangles, 1mil or 3mil or 12mil. It comes down to picking a number and forcibly breaking the display behavior of anything over it. A line in the sand so to speak, which is something that people are going to have a hard time swallowing.

Kyle Linden commented at 2016-10-18T17:04:59Z

Set NMI for comments. Issue has been accepted.

AndreyK ProductEngine commented at 2016-10-18T19:43:53Z, updated at 2016-10-18T19:58:35Z

"Always Render Fully" not decreasing LODs sound like nice feature) But I suspect it might be challenging to implement.

I think that I found solution already (unfortunately it is related to linksets, but since it is still limited by avatars size it can't be abused too much), it works wonders at my side. http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/maint-neko/rev/320805/index.html

For now RenderRiggedFactorMultiplier is 1.0, but I suspect that it will have to rise at least to 1.2. If it works fine with 1.0 I might remove variable completely.
P.S. Whirly please take a look, sorry for burdening you, but I simply have no big enough outfit base and 'user' experience to test something like this, nor know how to give proper instructions to QA about this issue beyond simple "it should switch lods at some point". If this build 'fails', may be you can write a detailed "what to look for" manual so that I can do better testing myself and task our QA with testing changes for this issue?

Whirly Fizzle commented at 2016-10-18T21:25:39Z

Sure I don't mind. I like breaking thins ;)

Ok so on that new test build - good news and bad news.

My Catwa mesh head no longer disappears, however my Maitreya rigged mesh body has holes in it & lots of my rigged mesh clothing disappears.
The Maitreya body didn't have holes as badly as this on the previous Neko build.

Graphics on default High.
RenderRiggedFactorMultiplier on default (1.0)
Holes in rigged body & rigged dress disappearing: https://gyazo.com/0b1b7147dc61f165d469493826e6942b
https://gyazo.com/0d7ed8b21485efaa1530bf020131289f

Catwa head behaves better though: https://gyazo.com/9048fba63389a644ad693691e1030159

Kyle is going to give you a copy of the full outfit I'm wearing in those gifs.

Second Life 4.1.2.320805 (Second Life Test)
Release Notes

You are at 81.4, 239.2, 21.4 in Testylvania Sandbox located at sim10493.agni.lindenlab.com (216.82.51.199:12035)
SLURL: http://maps.secondlife.com/secondlife/Testylvania%20Sandbox/81/239/21
(global coordinates 332,625.0, 306,415.0, 21.4)
Second Life RC BlueSteel 16.10.07.320397
Release Notes

CPU: Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz (3491.94 MHz)
Memory: 16268 MB
OS Version: Microsoft Windows 7 64-bit Service Pack 1 (Build 7601)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce GTX 750/PCIe/SSE2

Windows Graphics Driver Version: 21.21.0013.7306
OpenGL Version: 4.5.0 NVIDIA 373.06

J2C Decoder Version: KDU v7.2
Audio Driver Version: FMOD Ex 4.44.31
LLCEFLib/CEF Version: 1.5.3-(CEF-WIN-3.2526.1347-32)
LibVLC Version: 2.2.4
Voice Server Version: Vivox 4.6.0017.22050

Packets Lost: 23/33,589 (0.1%)
October 18 2016 14:25:20

Whirly Fizzle commented at 2016-10-18T21:56:17Z

Kyle will pass you a box named "BUG-11627 repro outfit"
Unpack box to inventory and replace current outfit.

Beq Janus commented at 2016-10-18T22:28:07Z

I had a look at the fix MAINT-612. That does address the issue but it has (minor) side effects, I will add a comment to my JIRA STORM-2138 to detail this.

AndreyK ProductEngine commented at 2016-10-19T12:16:39Z, updated at 2016-10-19T13:32:23Z

Thanks for the testing and outfit.
I was expecting that there will be a bit of small meshes that might switch too early, but a large dress... Fortunately RenderRiggedFactorMultiplier being 1.0 means that missing Lods aren't compensated yet, so there is a room to work with.

Upd: I see the issue only with ctrl+0 and with RenderRiggedFactorMultiplier set to 1.6 it seems fine, but thanks to this outfit found a strange case where drawable's group is somehow smaller then single object in group, accounted for it in new changeset.
P.S. Ctrl+0 does seem bugged as zoom, unless it was made specifically to test LODs.

polysail commented at 2016-10-19T13:55:55Z, updated at 2016-10-19T14:01:54Z

Further refining my idea above.

Self avatar rendering is a special case of no LOD decay. This is extensible to other avatars via the "Always Render Fully" option.

For OTHER avatars (non special cases):

Items with bounding boxes that are 0.1 x 0.1 x 0.1 meters or LESS, decay at rate of (roughly) 6 x Standard LOD Decay based on BoundingBoxVolume / ( 3 + ( number of triangles / 10000 ) ) since a 10K triangle attachment is a pretty forgiving "decent" triangle allotment for a trinket that is worn ~ this seems appropriate. ( this is primarily targeting earrings and rings and hyper inefficient mesh eyeballs. Note: This bounding box volume will be small enough that shoes, mesh heads and hair won't be dragged in to this behavior. )

For items with bounding boxes GREATER than 0.1 x 0.1 x 0.1 We can assume that it will have a "visible impact from a distance".
All attachments that have a "visible impact from a distance" have a flat ( via graphics settings 3-7 meter ) radius from the avatar center, where they do not decay.
Beyond that things should decay at 6 x AvatarBounding Box LOD Decay / ( 3 + ( number of triangles / 50000 ) ) This should give a 150K triangle entity a rough equivalence in behavior to it's current behavior, but make a 1.5 million entity decay 2X faster and a 3 million entity decay 4X faster than current behavior.

This way everyone gets to look pretty for themselves, take photos with their friends and get a pretty good idea of what everyone else looks like barring them wearing some really fantastically awful stuff. It also rewards things that are under the target polycounts with extra viewing radius ~ encouraging designers to build efficiently.

Obviously the numerical values shouldn't be hard-coded in and are presently still rough estimates ~~ but I included them for an idea of how the behavior should work to minimize adverse social impact, yet still provide robust improvements over the present display behavior.

AndreyK ProductEngine commented at 2016-10-19T15:14:53Z, updated at 2016-10-19T17:00:08Z

It will be much simpler to include zoom's "field of view" into LOD calculation then to analyze mesh header for details.

Actually at max zoom (ctrl + 0) avatar has holes even at release, and if this feature is so frequently used I recommend creating a feature request that will account for zoom when rigged mesh's lod is calculated. It is extremely easy to implement and shouldn't affect performance (at least not without zoom).

AndreyK ProductEngine commented at 2016-10-19T17:26:58Z, updated at 2016-10-19T19:14:46Z

New build
http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/maint-bear/rev/320847/arch/CYGWIN/index.html
http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/maint-bear/rev/320847/arch/Darwin/index.html
Renamed RenderRiggedFactorMultiplier into RenderRiggedLodCompensation, simplified and excluded possibility to abuse it - it is now just a linear radius multiplier (as it was in first implementation, limited to be between 1..inf, radius still maxed by avatar), default value 2.5.
Any object that is of comparable size to avatar (and CATWA head as a whole are of comparable size with this build) will be performing same as in release, anything smaller will disappear faster then in release but at bigger distance then same mesh placed inworld to compensate for missing LODs.

P.S. So far it seems safest so returned to this simplest method.

Whirly Fizzle commented at 2016-10-21T00:41:36Z

I recommend creating a feature request that will account for zoom when rigged mesh's lod is calculated. It is extremely easy to implement and shouldn't affect performance (at least not without zoom).

Ok great! I'll do that :)

Second Life 4.1.2.320847 (Second Life Test edu) seems okay.
RenderRiggedLodCompensation doesn't seem to be working though - I see no difference with that setting on 0, 2.5 or 5.
When zoomed in with CTRL+0 the rigged mesh disappears at the same distance no matter what the RenderRiggedLodCompensation setting.
I can just crank RenderVolumeLODFactor up to 4 though to "fix" it.

I'll file that feature request though - if that change is added it will be perfect :)

AndreyK ProductEngine commented at 2016-10-21T08:45:28Z

Looks like I will have to allow lower values then 1 for RenderRiggedLodCompensation, just for debugging purposes and make it a bit more sensitive.
About feature request: there is a note in code "DON'T Compensate for field of view changing on FOV zoom" on lod calculation, no idea why so, I suspect this zoom was originally made for Lod testing.

Beq Janus commented at 2016-10-22T17:25:29Z

I presume the zoom could be dealt with similarly to the existing ramp that is given when very close. It would make sense to use this for non-rigged as well as rigged.

I would guess that they don't account for the FOV change as it reduces the clipping range for the scene.

Whirly Fizzle commented at 2016-10-23T12:51:42Z

I filed the feature request - BUG-40757 - Account for CTRL+0 zoom when mesh LOD is calculated

Whirly Fizzle commented at 2016-11-06T16:22:38Z

@andreyk

AndreyK ProductEngine added a comment - 25/Jul/16 5:26 PM - edited

It does look like BUG-11309.
Checked the ctrl+0 case and to me it looks more like distance calculation-camera issue. I will have to check it in more details and see what can be done (right now can't think of anything but checking for zoom factor which obviously isn't that good of a solution), but only once it is clear that BUG-11309 is fixed. If BUG-11309 still reproduces I will have no other choice but to mark this issue as blocked and revert the change.

Build with both changes: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/viewer-neko/rev/318044/index.html

You may want to look at the new issue at BUG-40845.
This bug only reproduces on the Maint-RC or any build which includes the fix for BUG-11309 / MAINT-6125 - Mesh avatar deforms constantly.
Backing out this one changeset fixes the BUG-40845 bug: https://bitbucket.org/lindenlab/viewer-bear/commits/fb2eb1a59be66d0c5d50bb3511bc5346a8078ff0

But with this changeset backed out on a Maint-RC build, I'm seeing BUG-40616 happen very badly again on the Maint-RC since the changes made here (for BUG-11627).

Passes cookies

AndreyK ProductEngine commented at 2016-11-06T17:49:59Z, updated at 2016-11-06T17:58:21Z

Thanks for the info.
Change in MAINT-6125 fixes worn mesh's bounding boxes jumping all over the place (looks like it affects distance - lod is counted for location of bounding box). And unfortunately BUG-11627 relies onto mesh's bounding boxes to count Lod. In worst case scenario I probably can switch to llviewerobject's dimentions (ones seen in editor) but they have no real ties to size of the mesh and can be manipulated by user...

Vir Linden commented at 2017-07-06T14:46:58Z

Our apologies, it appears this jira has been a victim of a spammer. We've cleaned up the offending comments, sorry for the mess!

AndreyK ProductEngine commented at 2017-07-06T14:54:15Z

State update: issue on hold until 'better content policies are made' due to lots of content missing lower lods.