[BUG-9962] [Project QuickGraphics] Avatars often permanantly stuck as jellybabies even when Max complexity = No Limit

[sl-service-account]

Steps To Reproduce

• Login on default settings (for myself, default graphics quality is High-Ultra).

• TP to a good test region with many avatars of varying complexity, for example http://maps.secondlife.com/secondlife/Franks%20Place%202/237/128/24

• Note that on my default of High-Ultra: Max Complexity = 60k

• Observe which avatars in the scene render as jellybabies.

• Disable the jellybaby feature by setting Max Complexity to No Limit.

• Observe if any avatars in the scene still render as jellybabies.

  Observed Behaviour

• After disabling the jellybaby feature by setting Max Complexity to No Limit, several avatars in the scene will still display as jellybabies.

• It does not matter how long you wait, those avatars will remain rendered as a jellybaby.

• See attached images - note Max Complexity = No Limit, I should not see any jellybabies.

  • Fig 1 - taken at 9.00 PM SLT.
  • Fig 2 - taken 21 mins later at 9.21 PM SLT - the same 2 avatars are still jellybabies.

• Setting the Max Complexity slider to a lower value then back to No Limit does not fix the problem.

• The perma-jellybaby avatars never load their complexity information (Advanced -> Performance Tools -> Show avatar complexity information).

• The only way to render these avatars is to disable standard imposters altogether. So either:

  • Disabling all standard imposters by setting Max # non-imposters to No Limit. Lowering the Max # non-imposters setting to anything less then No Limit renders the stuck avatars as jellybabies again.
  • Or, Right click the stuck jellybabies -> Always render fully (but I shouldn't have to do this if I disabled jellybabies).

• See Fig 3 gif attached showing stuck jellybabies unless Max # non-imposters = No Limit.

• Whirly_1.log attached from the session at Franks Place 2 where I took the attached images. I TP'd into Franks Place 2 at 2015-08-24T03:52:29Z.

  Expected Behaviour

• If jellybabies are disabled by setting Maximum Complexity to No Limit, I should never see a jellybaby avatar.

• All avatars should load their complexity information.

  Other Information

• It's now 37 minutes later and the stuck avatars are still jellybabies & their complexity information still hasn't loaded.

• Reproduces on different regions. See Fig 4 attached showing another stuck jellybaby which never rendered fully at http://maps.secondlife.com/secondlife/Sweethearts/129/7/24 In this image, Max Complexity = No Limit, Max # non-imposters = 65

Attachments

• Fig 1 - 9.00 PM SLT.jpg 2015-08-24 00:39:31
• Fig 2 - 9.21 PM SLT.jpg 2015-08-24 00:39:31
• Fig 3 - Disabling imposters.gif 2015-08-24 00:39:31
• Fig 4 - different location.jpg 2015-08-24 01:31:05
• Fig 5 - Repros on empty region.jpg 2015-08-24 01:58:36
• Still repros on 305448.png 2015-09-27 06:54:19
• Still repros on 305448 - 2.png 2015-09-27 07:23:19
• Whirly_1.log 2015-08-24 00:55:35
• Whirly_new.log 2015-09-23 08:18:19

Links

Duplicates

• [ ] https://github.com/secondlife/jira-archive/issues/496

Original Jira Fields

| Field | Value | | ------------- | ------------- | | Issue | BUG-9962 | | Summary | [Project QuickGraphics] Avatars often permanantly stuck as jellybabies even when Max complexity = No Limit | | Type | Bug | | Priority | Unset | | Status | Accepted | | Resolution | Accepted | | Reporter | Whirly Fizzle (whirly.fizzle) | | Created at | 2015-08-24T04:12:13Z | | Updated at | 2016-03-13T05:44:53Z | ``` { 'Business Unit': ['Platform'], 'Date of First Response': '2015-09-24T13:10:16.448-0500', 'ReOpened Count': 0.0, 'Severity': 'Unset', 'System': 'SL Viewer', 'Target Viewer Version': 'viewer-development', 'What just happened?': '...', 'What were you doing when it happened?': 'Filling in...', 'What were you expecting to happen instead?': '....', } ```

[sl-service-account]

Whirly Fizzle commented at 2015-08-24T05:57:28Z, updated at 2015-08-24T06:00:57Z

This bug does not only reproduce on busy regions.

I reproduced it with my alt on Testylvania Sandbox with only the 2 agents on that region.

• Both Whirly & Kippy are logged in on Second Life 3.8.4 (304433) Aug 19 2015 17:10:20 (Second Life Project QuickGraphics) at http://maps.secondlife.com/secondlife/Testylvania%20Sandbox/90/116/21

• Whirly wore a heavy outfit which set her complexity to >300k

• Kippy saw Whirly change to a jellybaby.

• Kippy then raised Max Complexity to No Limit and Whirly remained stuck as a jellybaby.

• See Fig 5 showing Kippy's screen - Whirly should be fully rendered, not a jellybaby.

• Note in this case, Kippy could see Whirly's complexity information loaded unlike the above repro cases.

[sl-service-account]

Whirly Fizzle commented at 2015-08-24T15:39:49Z

Note to self: Add AvatarRender tag to logcontrol.xml.

[sl-service-account]

Whirly Fizzle commented at 2015-09-05T05:04:25Z

So far on Second Life 3.8.4 (304761) Sep 2 2015 13:29:34 (Second Life Project QuickGraphics) I have not been able to reproduce this bug.

[sl-service-account]

Whirly Fizzle commented at 2015-09-23T12:17:41Z

Cross posted on BUG-10127

I'm also seeing lots of stuck Jellybabies on Second Life 3.8.4 (305063) Sep 14 2015 14:14:18 (Second Life Project QuickGraphics) when Max Complexity = No Limit. This really did seem fixed for me on the earlier build but maybe I was just lucky.

It doesn't matter how long you wait, the jellybabies never render normally unless you leave Max # non-imposters set to No Limit or right click -> Always Render Fully.

Example: http://prntscr.com/8jdo6i Whirly_new.log attached from that session where I took the snapshot. In my image, the green jellybaby is Quantie Resident & the blue jellybaby is Aleisha29 Resident (incase names are needed for the log).

Second Life 3.8.4 (305063) Sep 14 2015 14:14:18 (Second Life Project QuickGraphics)
Release Notes

You are at 219.2, 117.5, 29.0 in Black Mire located at sim10478.agni.lindenlab.com (216.82.51.184:13021)
SLURL: http://maps.secondlife.com/secondlife/Black%20Mire/219/118/29
(global coordinates 263,899.0, 255,606.0, 29.0)
Second Life RC BlueSteel 15.09.14.305053
Release Notes

CPU: Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz (3491.91 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.5582
OpenGL Version: 4.5.0 NVIDIA 355.82

libcurl Version: libcurl/7.38.0 OpenSSL/1.0.1h zlib/1.2.8
J2C Decoder Version: KDU v7.2
Audio Driver Version: FMOD Ex 4.44.31
Qt Webkit Version: 4.7.1 (version number hard-coded)
Voice Server Version: Vivox 4.6.0017.21209

Built with MSVC version 1800
Packets Lost: 3,617/199,362 (1.8%)

[sl-service-account]

Kyle Linden commented at 2015-09-24T18:10:16Z

Hello Whirly,

We are about to publish a new build of this project viewer. Will you please retest this issue on the latest Quick Graphics project viewer.

http://wiki.secondlife.com/wiki/Linden_Lab_Official:Alternate_Viewers

Thanks!

[sl-service-account]

Whirly Fizzle commented at 2015-09-27T10:53:23Z, updated at 2015-09-27T11:04:06Z

This still reproduces on http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/lindenlab_391-blizzard/rev/305448/index.html See:

• Still repros on 305448.png attached.

• Gif showing Mac complexity set on No Limit, then changing Max Complexity down to the minimum of 19999 then setting Mac Complexity back to No Limit: https://gyazo.com/fedab3bbd395a99461ac17de76b85350 Doing this does not stop those 2 avatars staying stuck as Jelly Babies.

• Gif showing that disabling imposters and then enabling imposters again does in this case fix the stuck Jelly Babies: https://gyazo.com/d67cf775e30eedf5dc9f9527301fa127

  I have a feeling this bug has the same cause as the invisible avatars that are still sometimes seen - ref BUG-10330

  
  Second Life 3.8.4 (305448) Sep 25 2015 14:08:38 (Second Life Project QuickGraphics)
  Release Notes
  
  You are at 52.0, 114.2, 26.5 in Heaven or Hell located at sim10321.agni.lindenlab.com (216.82.50.43:12035)
  SLURL: http://maps.secondlife.com/secondlife/Heaven%20or%20Hell/52/114/26
  (global coordinates 130,868.0, 323,698.0, 26.5)
  Second Life Server 15.09.14.305056
  Retrieving...
  
  CPU: Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz (3491.92 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.5598
  OpenGL Version: 4.5.0 NVIDIA 355.98
  
  libcurl Version: libcurl/7.38.0 OpenSSL/1.0.1h zlib/1.2.8
  J2C Decoder Version: KDU v7.2
  Audio Driver Version: FMOD Ex 4.44.31
  Qt Webkit Version: 4.7.1 (version number hard-coded)
  Voice Server Version: Vivox 4.6.0017.21209
  
  Built with MSVC version 1800
  Packets Lost: 1,567/45,992 (3.4%)

[sl-service-account]

Whirly Fizzle commented at 2015-09-27T11:05:25Z

Possible clue - both those avatars that were stuck as Jelly Babies were wearing particle emitting objects...

[sl-service-account]

Whirly Fizzle commented at 2015-09-27T11:31:53Z

Hmmm looking at all the avatars I am seeing stuck as jelly Babies on recent builds, they all seem to have one thing in common - a pretty high total attachment byte size (the bottom number when "Show avatar complexity information" is enabled.

[sl-service-account]

Whirly Fizzle commented at 2015-09-27T13:30:13Z, updated at 2015-09-27T13:53:31Z

Ok I'm convinced now a high total attachment byte size is the repro for the stuck Jelly Babies. I can reproduce it at will now with my alt when the alt has a high total attachment byte size. It seems that the total attachment size gets stuck at a high reading and triggers a permanant Jelly Baby.

I'm not sure how high the total attachment byte size has to be to reproduce this because different avatars see a different reading and it can vary by a lot. For example, Whirly sees her own attachment size as 20k (HUDs appear to be included in the reading you see for yourself but not included in the reading an observer sees) but my alt sees Whirly's reading as 11k. Even if you remove HUDs, the reading an observer sees still varies, depending on how close their camera is to your avatar - the closer the camera, the higher the reading. Is that expected behaviour?

Anyway this set of steps will always reproduce the problem for me now :)

REPRO

• Login Avatar A & Avatar B on http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/lindenlab_391-blizzard/rev/305448/index.html

• Avatar A - Wear lots of heavy attachments until your attachment byte size is large (orange or red colour when camera is very close to your avatar).

• Example, this is my reading for my Avatar A viewed on Avatar A's screen when camera is very close: http://prntscr.com/8l0x3m

• Note: It does not seem to matter what the complexity reading is for Avatar A - only the attachment size seems to matter. A fairly low complexity reading will still reproduce this bug.

• Avatar B set Max Complexity to No Limit

• Avatar B - set Max # non-imposters to No Limit. This is not a necessary step to reproduce but you may already see Avatar A stuck as a Jelly Baby so this step (disabling imposters) will fix that so you can reproduce it again.

• Avatar B - zoom camera away from Avatar A.

• While camera is zoomed away, set Max # non-imposters back to default (16 will do). Note when camera is zoomed away, you will see Avatar A's attachment size drop by a lot.

• Avatar B then zoom very close in on Avatar A and then zoom camera away slightly back to normal view.

Observed Behaviour

• When Avatar B zooms in on Avatar A, their attachment size increases by a lot.

• As soon as Avatar B has zoomed close to Avatar A, Avatar A is then stuck as a Jelly Baby, even though Avatar B has a Max Complexity setting of No Limit.

• When Avatar B now zooms camera further away from Avatar A, Avatar A's attachment size reading does not get lower, it stays stuck at a high value and Avatar A remains stuck as a Jelly Baby.

• If Avatar B right clicks Avatar A & chooses "Always render fully", observe that the attachment size limit then resets to the correct value and Avatar A is no longer a Jelly Baby.

• Here is a gif showing Avatar B's screen: https://gyazo.com/bd77d9685d97f8192fe625738235e525 Avatar B has Max Complexity set at No Limit so should never see a Jelly Baby. Avatar B zooms in on Avatar A and then zooms out again. Avatar A is then stuck as a Jelly Baby to Avatar B at all camera distances until Avatar B disables imposters.

[sl-service-account]

Whirly Fizzle commented at 2015-09-27T13:42:37Z, updated at 2015-09-27T13:45:03Z

Example outfit for Avatar A to wear which will always reproduce this:

• Wear the default femaile avatar - Develop -> Avatar -> Character Tests -> Test Female.

• Make 20 copies of the "Ponytail brown hair" and add them all to the default female.

  https://gyazo.com/995a66d33aa27fe3666c9bd926b3eb06

[sl-service-account]

Whirly Fizzle commented at 2015-10-06T05:07:15Z

This still reproduces on http://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Release/3.8.5.305528 Same repro as above.

[sl-service-account]

Kyle Linden commented at 2015-10-06T23:42:46Z

Hi Whirly,

This appears to be a case of hitting the 10MB limit for memory. As you slowly zoom in the memory count increases to deal with all that hair. I will update the team.

Thanks!

[sl-service-account]

Whirly Fizzle commented at 2016-03-13T05:44:53Z

So far I cannot reproduce this on http://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Release/4.0.2.312297 \o/