Skip to content
This repository has been archived by the owner on Feb 28, 2024. It is now read-only.

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

Open
1 task
sl-service-account opened this issue Aug 24, 2015 · 13 comments

Comments

@sl-service-account
Copy link

sl-service-account commented Aug 24, 2015

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

Links

Duplicates

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
Copy link
Author

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
Copy link
Author

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

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

@sl-service-account
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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:

@sl-service-account
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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/

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant