sl-service-account
commented
2 years ago Maestro Linden commented at 2022-03-22T23:23:26Z
Hi @tomkreatures, thanks for the detailed report. From your video, it does look like there's some sort of issue with objects beyond the draw distance not affecting updates of objects that are actually off-view.
I did a simple test with the Second Life Release 6.5.3.568554 viewer on 2022-03-01.569051, and it seems to me that object update traffic in general is strongly affected by draw distance in that scenario. Here's what I did:
- Set up a simple unlinked "pyramid" object, consisting of simple boxes ranging from scale <10, 10, 0.5> at the base down to <0.5, 0.5, 0.5> at the top
- Each section of the pyramid contains this script, which can cause the object to either rotate at a regular interval or texture swap at a regular interval
- rotation triggers a 'terse' object update, which contains only positional and color data of the prim
- texture swapping triggers a full object update, which contains the full prim parameters {code}/* Mode is defined as: 0: no updates 1: spin - rotate at 45 degree intervals 2: toggle texture back and forth between TEXTURE_BLANK and TEXTURE_PLYWOOD */
- Each section of the pyramid contains this script, which can cause the object to either rotate at a regular interval or texture swap at a regular interval
integer Mode;
default { state_entry() { llListen(5, "", NULL_KEY, ""); }
listen(integer channel, string name, key id, string msg)
{
list args = llCSV2List(msg);
string command = llStringTrim(llList2String(args, 0), STRING_TRIM);
float period;
if(llGetListLength(args) > 1)
{
// arg used to determine the rate of updates
period = (float)llList2String(args, 1);
}
llWhisper(0, "got command '" + command + "'");
if(command == "die")
{
llDie();
return;
}
else if(command == "stop")
{
Mode = 0;
llSetTimerEvent(0);
}
else if(command == "spin")
{
Mode = 1;
llSetTimerEvent(period);
llWhisper(0, "spin at rate " + (string)period);
}
else if(command == "texture")
{
Mode = 2;
llSetTimerEvent(period);
llWhisper(0, "texture swap at rate " + (string)period);
}
}
timer()
{
if(Mode == 1)
{
// spin 45 degrees
llSetLinkPrimitiveParamsFast(LINK_THIS, [PRIM_ROTATION, llEuler2Rot(<0,0,PI/4>)\*llGetRot()]);
}
else if(Mode == 2)
{
key next;
if(llGetTexture(0) == TEXTURE_BLANK)
{
next = TEXTURE_DEFAULT;
}
else
{
next = TEXTURE_BLANK;
}
llSetLinkPrimitiveParamsFast(LINK_THIS, [PRIM_TEXTURE, ALL_SIDES, next, <1,1,0>, ZERO_VECTOR, 0]);
}
}}```Java
Set up a basic controller object, which:
Contains the scripted pyramid object as a coalesced object in prim inventory
Rezzes the pyramid test objects in a grid across the region, when the "rez" command is given
Relays owner chat commands on channel 0 to the pyramid objects at a region-wide scale
* Source:
integer PyramidRows = 16;
integer PyramidCols = 16;
float RezHeight = 30.5;
string PyramidInv;
RezPyramids()
{
llOwnerSay("Rezzing '" + PyramidInv + "' in " + (string)PyramidRows + " x "
+ (string)PyramidCols + " grid at height " + (string)RezHeight + "...");
integer i;
integer j;
vector originalPos = llGetPos();
for(i = 0; i < PyramidRows; i++)
{
for(j = 0; j < PyramidCols; j++)
{
vector pos;
pos.z = RezHeight;
pos.x = ((float)i / PyramidRows) \* 256.0 + 256/(PyramidRows\*2);
pos.y = ((float)j / PyramidCols) \* 256.0 + 256/(PyramidCols\*2);
llSetRegionPos(pos);
llRezAtRoot(PyramidInv, pos, ZERO_VECTOR, ZERO_ROTATION, 1);
}
}
llSetRegionPos(originalPos);
llOwnerSay("Rezzing complete.");
}
default
{
state_entry()
{
llListen(0, "", llGetOwner(), "");
PyramidInv = llGetInventoryName(INVENTORY_OBJECT, 0);
}
listen(integer channel, string name, key id, string msg)
{
msg = llStringTrim(msg, STRING_TRIM);
if(msg == "rez")
{
RezPyramids();
}
else
{
llOwnerSay("Relaying '" + msg + "' on channel 5");
llRegionSay(5, msg);
}
}
}
{code}
1. Said "rez" in chat, so that the controller object would go on and rez 16\*16 pyramids (2816 prims total)
1. Said "texture,2" in chat
- This causes each prim to change its texture every 2 seconds
1. Stood in the back corner of the region
- I think this should be okay, given that you mentioned the viewer is appearing to properly cull based on view frustum. Mostly, I wanted to give myself an easy-to-replicate avatar and camera position
- maestro_objects_setup.png shows what the setup looked like
1. Monitored the "UDP Data Received" stat in the viewer's Statistics Bar, for different draw distances
- While there may be some UDP traffic unrelated to object updates, I think they're in the minority
1. Slowly cranked up my viewer's draw distance from 64m to 256m, and noted how it seemed to affect bandwidth usage, in the steady state
Here's what I see with the objects running "texture,2" with my avatar standing in the corner:
|Draw distance (m)|UDP data (KB/s)|
|
|-|-|-|
|64|100|
|
|96|160|
|
|128|250|
|
|160|360|
|
|192|470|
|
|224|580|
|
|256|640|
<br>
<br>With the same setup, I also tried "spin,2" (having each object update its rotation every 2 seconds), with these results. I gave ranges for each setting, as the UDP traffic stat was annoyingly bursty and cyclical:
|
|Draw distance (m)|UDP data (KB/s)|
|
|64|30-70|
|
|96|50-120|
|
|128|80-150|
|
|160|120-230|
|
|192|160-270|
|
|224|180-350|
|
|256|190-400|
<br>
<br>Overall, there seems to be a pretty strong correlation between the viewer draw distance setting and the bandwidth coming in to my viewer, which is what one would expect - with higher draw distance, the simulator sends more updates to the viewer.|
What just happened?
Spammy objects (in the context of updates) which are out of draw distance are impacting update performance for nearby objects.
What were you doing when it happened?
Please see this video to exhibit the issue:
http://www.kreatures.net/extras/final-drawDistance.mp4
What were you expecting to happen instead?
The simulator should ideally not be sending updates for objects which are frustum-culled
The simulator should ideally be prioritising object updates for objects which are closer to the camera
Other information
Attachments
Original Jira Fields
| Field | Value | | ------------- | ------------- | | Issue | BUG-231952 | | Summary | Object updates not being culled based on draw distance | | Type | Bug | | Priority | Unset | | Status | Needs More Info | | Resolution | Unresolved | | Created at | 2022-03-22T16:41:58Z | | Updated at | 2022-03-23T17:27:20Z | ``` { 'Build Id': 'unset', 'Business Unit': ['Platform'], 'Date of First Response': '2022-03-22T18:23:25.713-0500', 'ReOpened Count': 0.0, 'Severity': 'Unset', 'System': 'SL Simulator', 'Target Viewer Version': 'viewer-development', 'What just happened?': 'Spammy objects (in the context of updates) which are out of draw distance are impacting update performance for nearby objects.', 'What were you doing when it happened?': 'Please see this video to exhibit the issue:\r\n\r\nhttp://www.kreatures.net/extras/final-drawDistance.mp4', 'What were you expecting to happen instead?': '1. The simulator should ideally not be sending updates for objects which are frustum-culled\r\n\r\n2. The simulator should ideally be prioritising object updates for objects which are closer to the camera', } ```