The following notes were taken from the Tuesday, October 12th, 2021 Simulator User Group (SUG) meeting. The meeting was recorded by Pantera Północy, and the video is embedded at the end of this summary. Note this summary focuses on the key points of the meeting, where there is something to report; the video video should be referred to should full details of the meeting wish to be reviewed.
Server Deployments
The planned deployment for this week has been postponed due to late-breaking issues, and so will not be deployed for a week. However, regions that have not been restarted in 10 or more days will be restarted. See the (“lack of”) deploy plans notes for more.
SL Viewer
There have been no updates to the current crop on official viewers to mark the start of the week, leaving the pipelines as:
- Release viewer: version version 6.4.22.561752, formerly the CEF Update RC viewer, issued July 24 and promoted August 10.
- Release channel cohorts:
- Apple Notarisation Fix RC viewer, version 6.4.23.564172, issued September 24 – this should remove the warning messages which are currently popping up.
- Maintenance RC viewer updated to version 6.4.23.564063, on September 21.
- Simplified Cache RC viewer, version 6.4.23.562623, dated September 17, issued September 20.
- Project viewers:
- 360 Snapshot project viewer, version 6.4.23.563579, issued September 3.
- Performance Floater project viewer, version 6.4.23.562625, issued September 2.
- Mesh Optimizer project viewer, version 6.4.23.562614, issued September 1.
- Legacy Profiles viewer, version 6.4.11.550519, dated October 26, 2020.
- Copy / Paste viewer, version 6.3.5.533365, dated December 9, 2019.
Region Crossings
- The subject of region crossings came up again, specifically in reference to multiple sequential crossings via vehicle, and the problems that can occur (passing from one region to the next, and then on to the next before all relevant data between the first two has been fully transferred). There should be code in place to handle this, but the Lab acknowledges there may be cases there this doesn’t work well.
- Rider Linden acknowledged that more work is required on the entire physical region crossing protocol, but that, “it may involve starting from scratch and rethinking how the entire protocol works. That’s going to be a big job.”
- The question here is, how best to delay interpolation to ensure all information on a vehicle and its passengers is received by one region so all of it can be passed on to the next. User Animats submitted a code contribution to Firestorm in 2018 (which has since been further revised) to help with this, but it is not perfect. The problem here is, too much delay – say more than around 1/2 a second – is noticeable and can impact immersion; a second problem is, what may help ease some types of region crossing may make others more noticeable.
- Another problem is that physical / vehicle region crossings are such that there is little opportunity for any kind of “pre-transfer” of vehicle and avatar data, until the vehicle is on top of / crossing the actual region boundary (the 1m boundary). This is because there is no guarantee that a vehicle will turn away from a crossing without actually moving between regions – so simulator time (on both sides) is taken up in handling the pre-transfer without no point to the exercise.
Another option (again, to stress **as an example**) would be to always have up to date data on all adjacent regions. But that would cost us real money. How do we recoup that increased cost in a way that is fair to the people who actually make use of the increased data availability? I’m just trying to give examples of why none of these solutions are “free” or “simple”.
– Mazidox Linden on region crossings + potential solutions
- The suggestion was made to run regions on virtual machines, such that adjacent regions are on the “same machine”, removing the need for transferring data between different physical simhosts. The problems here are:
- a) The number of “adjacent” regions can be huge (e.g. Blake Sea and the surrounding private estates + Mainland continents, and the Mainland continents as a whole).
- Even if broken down into more manageable groups of regions all on the same hardware, but this again doesn’t entirely eliminate problems, an will result in some region crossings appearing smoother, and others (where they remain between different hardware) appearing “worse” by comparison.
- Also, if the hardware fails fails running a batch of virtual machines, that’s potentially a larger number of regions that go with it than is currently the case. And while hot shadowing is possible so that if a server does fail, it’s shadow can automatically take over, that’s doubling overall hardware requirements + associated costs, which would have to be met somehow.
- As it is, the move to AWS has seen an overall improvement in region crossings, primarily because the hardware and infrastructure available via AWS is a lost more recent, and so more powerful (hardware) and faster (network) than the Lab’s old infrastructure.
- Whilst not just related to region crossings, an experiment on the Lab’s to-do list is to try to group clusters of regions by hardware, something that has not been tried in some time.
In Brief
- A major focus on the server / simulator side of Second Life remains the work in updating the tools the Lab has at its disposal, which is to be followed by / overlap with a major operating system upgrade (not to 64-bit, which is viewed as a “humongous” piece of work, but one that will eventually need to be addressed, depending on the platform’s continued longevity).
- There is a brief discussion at the end of the meeting concerning mesh decimation, avatar meshes, rendering, and possible improvement, much of which is a subject of CCUG meeting discussions.
