Server Deployments Week 4
There was no Main Channel deployment on Tuesday 22nd January due to the issues encountered in week 3, which saw the interest list code on BlueSteel and LeTigre rolled back due to stability issues, and the maint-server release on Magnum having problems of its own (including regions not showing up in search, etc.).
There will be RC deployments on Wednesday 23rd January, as follows:
- BlueSteel and LeTigre should receive the region crossing improvement project. This project makes sim performance smoother when objects and avatars cross between regions. This is the same project which was on BlueSteel and LeTigre in week 2; the only change is a fix for a crasher – release notes (BlueSteel)
- Magnum should receive the interest list improvement project. This update should reduce the bandwidth usage of viewers due to object updates, and should improve simulator performance, especially in sims with many connected avatars. This is the same project which was on BlueSteel and LeTigre briefly in week 3; the only change is a fix for two crash modes – release notes
According to Simon Linden, speaking at the Simulator User Group on Tuesday 22nd January, the issue(s) relating to Magnum regions / parcels failing to show up in search also has a fix, which is apparently included in code due to be deployed to those regions, although there is no comment on this in the release notes themselves at the time of writing.
Work continues on the viewer development side of things with further updates an merges and new versions appearing almost every other day, but little is currently filtering through to the beta viewer code branch at present.
Similarly, the CHUI developement viewer is going through a rapid series of updates, reaching 126.96.36.1999264 on Tuesday 22nd January, although updates from the last series of development releases have yet to reach the CHUI project viewer.
Work has been promised to update the Sunshine (avatar baking) viewer code, whether this has been done or not is unclear as there was no Content Creation meeting on Monday 21st January due to Martin Luther King’s birthday; however, the current release of the project viewer remains 188.8.131.528071 at the time of writing.
Merges are also still awaiting on the Mesh project viewer in order to bring that back into line with more recent viewer-dev code updates.
STORM-68 and Object Permissions
In last week’s report, I mentioned the release of SVC-7996 with the Magnum deployment for week 3. This was the first phase is a viewer project (STORM-68) being undertaken by a code contributor to ensure that content creators can assign default permissions to items they create from within the viewer which are persistent and applied whenever an object is created, rather than being over-written by server-side defaults. As the first part of this work, SVC-7996 is designed to ensure that scripts inherit the default permissions set within the viewer.
However, In order for default permissions to be set, the viewer will require a new floater, which is the focus of STORM-68 itself. Speaking at the Simulator User Group meeting, the code contributor working on this aspect of the project gave a preview of the new floater, as it currently stands (and which is still subject to possible revision).
An important aspect of this panel is to ensure that, until manual changes are made by the user, it correctly inherits expected defaults as seen within the build floater today in order to avoid any confusion in initially updating permissions. The panel itself has yet to go to LL’s QA, so it is unlikely to appear in the viewer in the immediate future. Further updates are also required to the server code in addition to SVC-7996 to ensure that all permissions set through the panel are correctly applied server-side.
Server Object Rezzing Code
As I outlined back in week 1, Baker Linden is working on improving how objects with large file sizes (as opposed to them being physically large when rezzed in-world) are handled by the simulator software when being rezzed.
The key point about this work is that it is specifically aimed at preventing the simulator processes from choking and a region stalling when there are a number of large object files being read / parsed, not at actually “speeding up” the physical rezzing process. As such, it is unlikely that objects will appear any faster in people’s in-world view as a result of this work. However, what it does mean is that the simulator code will be better able to handle rezzing multiple “large file” objects without the attendant region lagging which can occur as a result of the simulator being unable to process messages from viewers and other simulators, etc.
Commenting briefly on the work at the simulator User Group meeting on the 22nd January, Baker indicated that the code is going forward for testing by LL’s QA team in the next few weeks and that, “We’re looking at some sim stats, and it seems like the threading is doing a good job of keeping the simulator running at full framerate. That’s good because that means more things can get processed every frame.”
Once the code is live (mostly likely on Aditi initially), Baker will make an announcement via the Simulator and Server Beta groups, so that people can assist with large-scale testing before the code moves to an RC channel.
Teleporting and Terrain
In the second part of my week 2 updates, I reported on teleport issues wherein teleporting via the map can lead to some odds results, including the potential for arriving underground. A (closed to public viewing) JIRA – BUG-1280 – has now been raised on the problem, however, there is some speculation as to whether it is related to other terrain issues arising from the deployment of the new Havok physic engine alongside pathfinding.
Problems resulting from the Havok changes been widely reported for the last several months, often in the form of fast-moving objects “snagging” the terrain and becoming stuck, rather than moving smoothly over it. The issue is believed to be related to the terrain being treated as a mesh object, rather than being defined as a heightfield (/heightmap).
When terrain was defined by a heightfield, there was a concept of “inside” and “outside” which helped in calculating collisions between objects and the terrain, enabling adjustments to be made as an object moved across the terrain. With terrain now defined in terms of a mesh, there is no concept of “inside” and “outside”, just a concept of colliding with the “underside face” of the mesh, which pushes a moving object in the right direction. However, with fast-moving objects, it is theorised that rather than colliding with the “underside” of the mesh, it is possible for an object to penetrate the mesh or “tunnel through” it (to use Andrew Linden’s term), and become stuck – like a pin penetrating a sheet of paper.
When it comes to avatars, this issue is corrected by an algorithm which can detect the avatar’s position relative to the terrain’s mesh map and adjusting the avatar’s position accordingly (hence the “popping up” when a teleport delivers an avatar underground). However, the algorithm works because avatars are a guaranteed given shape as far as the physics engine is concerned, making calculations relatively straightforward. Moving objects are harder to deal with as their physics shapes are more complex, and using a similiar algorithm to handle them when the terrain mesh is “penetrated” could lead to a sizeable performance hit as the algorithm constantly checks and re-checks whether or not the object is penetrating the mesh, rather than colliding with it.
The problem here is how to resolve the issue. Andrew Linden’s thoughts on the matter is that it might be feasible to utilise the mesh terrain physics for the majority of cases, invoking the older heightfield approach when problems occur. However, it is by no means certain this can be achieved, and further investigation is required.