[BUG-227041] Camera distance to avatar in neighbouring region incorrect

[sl-service-account]

What just happened?

Avatars in a neighbouring region are being incorrectly reported in respect to camera distance. This causes the LODs to display incorrectly.

What were you doing when it happened?

First noticed at a stage show at Elysion. The stage is on a separate region to (theoretically) allow the performers to have lower lag than if they shared with the audience. One of the performers appeared like this If the observer moved to the same region, this would be corrected.

The distance problem is easily illustrated in FS where the "LOD Info" metadat a function works.

The avatar is standing just across the region border and not 160m away, and given this outght to be the camera distance irrespective of the avatar location it is clearly wrong.

I reproduced this using the Second Life Viewer in New Babbage estate. An avatar is standing in The Academy Of industry region looking across the border to another avatar in Babbage Palisades.

The avatar then steps over the border, moving barely a metre in "real" terms.

The problem is shown well in FS where the non-avatar objects can be seen as reporting to be within a few metres of the camera, yet the avatar is 161m further away.

For completeness the same image taken with the avatar back in the same region, shows avatar and non-avatar to be more or less as expected

What were you expecting to happen instead?

Avatars should not LOD faster because they are across a region border. This affected the avatars in these examples on just their non-rigged attachments, which in turn shows how utterly broken the LOD decay of rigged mesh is as it still shows high LOD at 160+m distance (but that is a whole other battle to be fought)

Other information

Attachments

• BUG-227041.diff 2019-05-28 19:39:51

Original Jira Fields

| Field | Value | | ------------- | ------------- | | Issue | BUG-227041 | | Summary | Camera distance to avatar in neighbouring region incorrect | | Type | Bug | | Priority | Unset | | Status | Closed | | Resolution | Accepted | | Reporter | Beq Janus (beq.janus) | | Created at | 2019-05-27T00:05:03Z | | Updated at | 2021-06-07T17:42:57Z | ``` { 'Build Id': 'unset', 'Business Unit': ['Platform'], "Is there anything you'd like to add?": '\r\n', 'ReOpened Count': 0.0, 'Severity': 'Unset', 'System': 'SL Viewer', 'Target Viewer Version': 'viewer-development', 'What just happened?': 'Avatars in a neighbouring region are being incorrectly reported in respect to camera distance. This causes the LODs to display incorrectly.\r\n', 'What were you doing when it happened?': 'First noticed at a stage show at Elysion. The stage is on a separate region to (theoretically) allow the performers to have lower lag than if they shared with the audience. \r\nOne of the performers appeared like this\r\n!https://i.gyazo.com/da9e2c76100eb69a395f64a4843d4d38.gif!\r\nIf the observer moved to the same region, this would be corrected.\r\n!https://i.gyazo.com/d092b133aca6e23a0f9a6f0b2eacf120.jpg!\r\n\r\nThe distance problem is easily illustrated in FS where the "LOD Info" metadat a function works. \r\n!https://i.gyazo.com/bd62384b1ab32bbf10fd5a07b3cb06ee.png!\r\n\r\nThe avatar is standing just across the region border and not 160m away, and given this outght to be the camera distance irrespective of the avatar location it is clearly wrong.\r\n\r\nI reproduced this using the Second Life Viewer in New Babbage estate.\r\nAn avatar is standing in The Academy Of industry region looking across the border to another avatar in Babbage Palisades. \r\n!https://i.gyazo.com/c534156770af2fa1382283e3a46d1b99.jpg!\r\n\r\nThe avatar then steps over the border, moving barely a metre in "real" terms. \r\n!https://i.gyazo.com/61776e572ea1d2d82b2272fd9b866fae.jpg!\r\n\r\nThe problem is shown well in FS where the non-avatar objects can be seen as reporting to be within a few metres of the camera, yet the avatar is 161m further away.\r\n!https://i.gyazo.com/7b93c17d1d3b43eea11b527650739f76.jpg!\r\n\r\nFor completeness the same image taken with the avatar back in the same region, shows avatar and non-avatar to be more or less as expected \r\n!https://i.gyazo.com/e93fd55e6f5c27a292cbc5c79911b09d.jpg!\r\n\r\n!https://i.gyazo.com/c534156770af2fa1382283e3a46d1b99.jpg!\r\n\r\n', 'What were you expecting to happen instead?': 'Avatars should not LOD faster because they are across a region border. This affected the avatars in these examples on just their non-rigged attachments, which in turn shows how utterly broken the LOD decay of rigged mesh is as it still shows high LOD at 160+m distance (but that is a whole other battle to be fought)', 'Where': 'Does not appear to be location specific any two regions will work. ', } ```

[sl-service-account]

Beq Janus commented at 2019-05-27T17:02:30Z, updated at 2019-05-27T17:17:30Z

The magic number of 161 is the result of an original distance of 256, which is then adjusted in the calcLOD() method of VOVolume.cpp. The effective distance is then adjusted depending on the RendvolumeLODFactor and a small adjustment (it is multiplied by PI/3).

256 is a much more reasonable "random" number and suggests that we may not be accounting for the distance between the two region origins. 

EDIT: This can be further illustrated by moving across more sims. The error appears to be the distance between region origins. This is illustrated here.

! !

 

[sl-service-account]

Beq Janus commented at 2019-05-28T02:46:49Z

I believe I have fixed this.

I will submit a patch and an update after sleeping on it (and testing some more)

The problem is that the code assumes that av_box extents are local to the region containing the object, they are not, they are relative to the region of the agent, having been calculated as part of the spatial extents processing.

This gave the off by 256 error when in a neighboring region.

Patch to follow.

[sl-service-account]

Beq Janus commented at 2019-05-28T23:40:02Z

There's a secondary bug. Note sent offline to Kyle, Oz and Vir. For now I'm patching just the original bug

 

BUG-227041.diffPatch file attached

 

Once I fixed the reasons that the non-rigged attachments were misbehaving the question arose why was it affecting only them in the first place. 

The full answer is that it wasn't,  all attachments rigged and non-rigged were being incorrectly dealt with but the entire calculation is discarded for rigged in favour of the avatar's drawable's distance. (not the attached volume's drawable's distance) in the calcLOD method. If this is the intended behaviour then we can save a lot of wasted work in calculating the distances for the rigged mesh.