Category: SL User Group Meetings

SL projects update week 13 (2): server releases, HTTP, and viewer notes

Posted on by Inara Pey

Server Deployments Update

On Tuesday March 26th, the SLS (Main) channel received the maintenance package previously deployed to BlueSteel and LeTigre in week 12, which includes a fix for a crash mode  – release notes.

On Wednesday March 27th, the RC channels received the following packages:

  • BlueSteel and LeTigre: a new maintenance package, which includes:
  • Magnum: should receive the same update as the Main channel (i.e. the package deployed in week 12 to BlueSteeel and LeTigre), otherwise retaining the updates and fixes deployed to it in week 12 – release notes.

As usual, there is a forum discussion thread for comments / feedback on the deployments.

Some issues have been reported following the Main channel deployment, but nothing which warranted any major action on LL’s part. Some reported noticeable improvements as a result of the pathfinding update.

Week 14 Deployments

While a final decisions has yet to be made on deployments for the week commencing Monday April 1st, Maestro Linden, hosting the  Server Beta group meeting on Thursday March 28th, indicated that the Magnum updates (which are all interest list related and include the vehicle region crossing fix for BUG-1814) is currently his personal favourite to be promoted to the Main channel and BlueSteel / LeTigre in week 14. If this proves to be the case, then he’s liable to have a lot of SL vehicle users very happy with him – myself included!

SL Viewer – CHUI, SSB and More

The SL development viewer moved to release 3.5.1.272979 on Thursday March 28th. As there are no release notes associated with development viewer releases, it is not always easy to determine what a new release contains; however, from tests, it would not appear that the release contains the viewer-side Server-side Baking (SSB) code.

The next major update to the release viewer is slated to be the Communications Hub User Interface (CHUI), which should be arriving “any time now” according the last-known plans from LL.

As previously noted, once CHUI reaches the release viewer, SSB will move to the beta viewer and make an appearance in week 14 – possibly (and coincidentally) on April 1st. Once in the beta viewer, it will remain there for up to four weeks (unless significant bugs are found), and no less than two weeks, prior to it moving to the SL release viewer. It is unlikely that any SSB server-side deployment will commence on the Main grid until after SSB has reached the release viewer – however, this is subject to final planning, and there may be a limited release of the server code while SSB is still in the beta viewer.

Work is still progressing on the materials code, and there is still no date for the release of a project viewer.

HTTP Project

On Wednesday 27th March, Monty Linden sent out an e-mail indicating the current beta testing on Aditi for his new HTTP capabilities will be drawing to a close “shortly”, and that anyone interested in carrying out tests in the three channels should do so sooner rather than later. Precisely when the beta test will close is unclear, but from Monty’s e-mail it would not be unreasonable to assume it will be within a week.

The next stage for this work is for it to progress to a Release Candidate channel – which will seem the “normal” configuration for HTTP services currently on channel DRTSIM-203 on Aditi carried forward to the selected RC channel(s). While there is no date as to when the HTTP work will reach a RC channel, Monty will be looking at the deployment as a more in-depth load test opportunity and seeing how well the new services might scale.

Other Items

Advanced Creation Tools Permissions

July saw the launch of the first phase of the Advanced Creation Tools, also referred to as experience tools. Following problems with an initial deployment of the tools in June, which resulted them being exploited as a means of griefing, the “first phase” of the release saw the tools implemented with existing permissions system in place, with the intention of updating the permissions system to allow the tools to be more fully used “in the future”.

After hearing that the work on the permissions system was again getting attention having been “stalled” for a time, there has been something of a further absence of news on progress. However, speaking at the Server Beta meeting on Thursday March 28th, Maestro was able to confirm the permissions system is currently on internal testing at LL – so it might be showing-up on Aditi (or in an RC deployment) in the not-so-distant future.

Scripted Avatar Rotation

The subject of scripted avatar rotation has come up for discussion at the last couple of server-related meetings. The idea is to use a scripted object to force the avatar to face a specific direction. It is not a new request, having been the subject of several JIRA in the past, most notably SVC-56, which also provides some suggestions as to how it might be achieved. Being able to turn the avatar to face a specific direction has a number of potential benefits – it could, for example, be used to have an avatar face a rock face which could then be “climbed”, or it could make avatar alignment for hugs / kisses a lot more accurate.

RLV already allows such rotation, although it may not be as accurate as required in some of the potential uses. Some objections to the capability have been put forward in the past – such as the potential for “griefing” others; although “griefing” of the kind envisaged perhaps shouldn’t necessarily prevent the development of such a capability, which would preferably be achieved by means of an attached scripted object, which wshould help minimise the risk of malicious use of the capability.

Andrew Linden, in discussing the idea at the Simulator User Group on March 26th commented:

Avatar rotation by script is actually hard to do. The reason it is so hard is a legacy thing… the protocol is basically set up such that the viewer tells the server where the avatar should be facing, and the server tries very hard to get it there. So in order for the server to turn the avatar, it would have to know when to listen to the viewer and when not; remembering such a state isn’t hard, but figuring out when to transition is hard … what would happen if a “turn the avatar” event was triggered and you started mashing on the keyboard to move the avatar elsewhere… what system should win?

Without committing to anything, Andrew concluded the discussion by saying, “I’ll think more about it. Maybe it’s possible. There must be a clever way. I don’t see it yet.”

SL projects update week 13 (1): server, AO capabilities, HTTP, group ban list

Posted on by Inara Pey

Server Deployments – week 13

On Tuesday March 26th, the SLS (Main) channel received the maintenance package previously deployed to BlueSteel and LeTigre in week 12, which includes a fix for a crash mode  – release notes.

Some issues have been reported on following the Main channel deployment. Regions have been slow to come back up, and several which have had issues with groups and display names failing to show, teleport errors, etc. However, at the current moment in time, these issues do not appear to be widespread.

On Wednesday March 27th, the RC channels should receive the following deployment packages:

  • BlueSteel and LeTigre: a new maintenance package, which includes:
  • Magnum: should receive the same update as the Main channel (i.e. the package deployed in week 12 to BlueSteeel and LeTigre), otherwise retaining the updates and fixes deployed to it in week 12 – release notes.

As usual, there is a forum discussion thread for comments / feedback on the deployments.

That the region crossing fix for BUG-1814 is not been deployed to the rest of the grid in week 13 is liable to cause some consternation.

New AO Capabilities

The new AO capabilities, due for deployment on BlueSteel and Magnum. I provided an overview for the new capabilities in week 12, and the Lab have now provided a set of wiki pages on the calls and permissions:

Ban List – and More

As recently reported, Baker Linden has started working on an update to the code for managing groups which will allow group owners / moderators to ban users who create problems (e.g. those who spam groups, people who are persistently abusive in group chat, etc.).

The work is being undertaken in response to JIRA VWR-29337, and is likely to prove very popular once available.Currently, Baker is working on the development documentation and plan for the work, and has been giving further thought on what the capability will be able to do. Speaking at the TPV Developer meeting on March 22nd, he gave a little more insight into how the capability might progress:

  • A possible format for how the Group Ban option might appear in the viewer, as visualised by Alyssalillian McMinnar
    A possible format for how the Group Ban option might appear in the viewer, as visualised by Alyssalillian McMinnar. LL have an internal design for the UI elements, but this is not something Baker is currently focused on

    The initial release will at least allow group owners and moderators to ban people, a will display the names of banned individuals and the date on which they were banned (presumably to owners / moderators only)

  • It may include a capability to specify why a person has been banned, even if this is initially a case of selecting from a pre-defined list of reasons
  • A future option may be to include a time ban option (although this is potentially more useful in banning people from accessing a region / parcel)
  • An initial design for the viewer-side Group floater has been developed internally by LL, but Baker isn’t so concerned with how the options will be presented through the viewer until after he had defined how the code will work
  • Baker is not planning on adding any on the ban capabilities for group to the existing ban capabilities for regions / parcels, nor will any of the new group ban capabilities be shared with region / parcel ban capabilities, due to the complexities involved.

At the same time as working on the group ban list, Baker has also opted to correct other long-standing issues:

  • The ability to search for people using their user name properly (i.e. no period in between first and last names)
  • A fix for the disallowing of leading spaces on display names.

These fixes will also likely roll-out the same time as the first phase of the group ban list function, once Baker is able to start coding and testing the latter.

HTTP Project

On Friday March 22nd, Monty reported that the Aditi testing had been subject to a couple of non-related hiccups (due to inventory issues), but otherwise the regions were stable and whole one significant bug within the code had been found – severe enough to take down some Apache web servers when HTTP-In was being tested, and which has now hopefully been fixed.

Load testing on Aditi has been a little light, but obviously, more practical load testing will occur when the capabilities reach a Release Candidate channel and things start to get fine-tuned.

Mainland Griefing

The subject of Mainland griefing was discussed at the Simulator User Group meeting on the 26th March. There has been a noticeable rise in object griefing and spamming recently, particularly by the so-called “goonsquad”. Several options for better means of combating the problem were raised, including JIRA SCR-19 (“Script function to return objects”) for the return of griefer objects where users do not have access to estate / region tools for return objects, and possible throttling of llDialog (SVC-8080) to try to overcome the use of dialogue spamming prims.

The Lab will obviously not be drawn into discussions on their own plans for combating griefing, but Andrew Linden took a series of notes on problems which are being encountered, while Simon indicated that the Lab is looking at some options which may help with issues.

Related Links

HTTP updates: the what, why, who

Posted on by Inara Pey

Update March 27th: Commenting on the open-source development mailing list, Monty Linden states: “It looks like Beta (Aditi test regions) will be wrapped up shortly. If you’ve wanted to try these out but haven’t yet, now would be a good time to jump in there.” 

Linden Lab is in the process of making a number of improvements to Second Life which should benefit both the platform and users. Once deployed, some of these updates will be clearly visible as they gain widespread use in-world, such as the upcoming materials processing capabilities. Others will be perhaps more noticeable because they require a viewer update – as is the case with server-side baking, rather than being obviously visible in everyday use. Some will have more of a “background” impact, rather than anything which is clearly visible in-world (although they may make their presence felt for the more keen-eyed).

Monty Linden
Monty Linden

Among the latter category of changes are the HTTP updates currently being tested on Aditi and which will soon be popping-up on a Release Candidate channel. This work is being spearheaded by Monty Linden, and has been under development as a part of the Shining Project initiative kicked-off by Linden Lab in 2012.

Several of my SL projects update reports have covered Monty’s work, and will continue to do so in the future. The aim of this article is to bring the various threads together in a single post, in order to provide a  broad overview of what it all means without getting caught-up in the technical minutiae.

Communications between the viewer and the SL servers are subject to many vagaries. Network issues can occur locally (i.e. with a user’s own network), or at the ISP level, for example, long before they actually involve the SL servers. There is little LL – or the support team for whatever viewer is used to connection to SL  – can do in these instances.

However, network issues aside, there is much work that can be done to improve viewer / server communications and make connectivity between the two more robust – and this is the focus of Monty’s work. Some of this has to do with gradually switching aspects of the service away from the older UDP services within SL to HTTP-based services, and some of it has to do with improving the existing HTTP services employed by SL and making them both more robust and (hopefully) a little easier on older models of routers.

Initial Work

As mentioned above, Monty’s work is encapsulated within the Shining Project, and is being carried out in a number of phases. The first phase of this work was actually completed during the second half of 2012, and focused on improving the HTTP texture fetch mechanism both server-side and within the viewer by which textures are obtained for rendering. This work started to go into widespread use around  November 2012, when the viewer code was made available and Linden Lab announced the new capability thus:

A new scheme for performing HTTP operations is introduced with this release. It is intended to reduce crashes and stalls while performing HTTP operations and generally enable performance and reliability improvements in the future. In this release, it is being used by the viewer’s texture retrieval code. Our expectation is that it will provide consistent and predictable downloading of textures.

The initial HTTP updates being driven by Monty Linden started to appear in around November 2012
The initial HTTP updates being driven by Monty Linden started to appear in around November 2012, with improvements to the texture fetching code in both the viewer and on the server end of things

Following the release of the viewer code, many reported they were seeing significant improvements in texture downloads, and a resultant improvement in texture rendering.

As a part of this initial work, Monty also started examining connectivity between the server and the viewer (number of actual connections opened, etc), and found that it can cause significant hardships for older classes of router, many of which incorporate a firmware-controlled “lock-out” which can be triggered when too many connections are opened when using HTTP, and so can cause users issues (hence the recommendation which some support teams give to disable HTTP textures within the viewer if connection issues are being experienced).

Second Phase

At the start of 2013, Monty commenced work on the second phase of the project, which is currently focused on the server-side of things (that is, there are currently no viewer-side code changes). In particular he is looking at further improving texture and mesh asset-fetching from the server and at implementing HTTP persistent / keepalive connections capabilities, which should enhance the overall robustness of such communications (some of which may hopefully see some connectivity improvements for those people using older model routers, as noted above).

Continue reading “HTTP updates: the what, why, who” →

SL projects update week 12 (3): viewer, CHUI, SSB, materials and releases

Posted on by Inara Pey

SL Viewer Updates

The SL beta and development viewers saw end-of-week updates in week 12, with the beta viewer rolling to release 3.5.0.272486 and the development viewer 3.5.1.272521, both on March 22nd.

The beta update is primarily focused on CHUI, and may be the final beta release for CHUI before the it appears in an official release version of the SL viewer (see below).

On March 20th, the Sunshine project viewer (Server-side Baking) updated to release 3.5.0.272211, which may be the last releases of the SSB code as a project viewer prior to the code arriving in the SL beta viewer – see the SSB section of this report (below).

Communications Hub User Interface (CHUI)

As indicated above, the Lab is hoping that CHUI, the Communications Hub User Interface, is now in its final beta viewer run with the release of 3.5.0.272486, and that the code should be appearing in the release version of the SL viewer, possibly later in week 13 (week commencing Monday 25th March).

CHUI: probably making a final appearance in the SL beta viewer prior to appearing in the release viewer
CHUI: probably making a final appearance in the SL beta viewer prior to appearing in the release viewer

However, TPVs are still considering how best to tackle CHUI in terms of integration and deployment in their viewers. Part of the problem here is that for some TPVs, the CHUI user interface changes conflict with changes the TPVs have themselves made, and so consideration needs to be given as to which parts of the UI updates and changes a given TPV wishes to adopt. A wider issue, however, is that CHUI also includes a large about of v3 code refactoring, all of which needs to be considered for implementation into views, particularly those which are v3-based.

Further, as most TPVs have been focused on SSB updates, it may take a while before CHUI itself appears either in whole or in part, in some third-party viewers.

The CHUI updates don’t only impact TPVs – there is a knock-on effect with some of the upcoming changes / code contributions flowing into the SL viewer code as well. For example, the viewer side of the request teleport feature (STORM-1838), which I originally commented on in week 4, has been delayed while it is re-worked in light of CHUI-generated changes.

Server-side Baking

Viewer-side SSB Code

Following-on from the recent pile-on / load tests carried out using the official viewer (Thursday March 14th) and Firestorm (Friday March 15th), the Lab believes that the viewer side of the code is doing “quite well” in testing, with both tests recording very similar results, including hitting the same problems related to inventory fetching / rezzing issues for attachments.

As a result of this, the Lab have been looking at releasing the SSB viewer code to the SL beta viewer (with CHUI integration) on or around April 1st (week 14). However, the discovery of a bug with the latest version of the SSB project viewer code ( version 3.5.0.272211), may delay matters.

SUN-57, raised by Tonya Souther, reports a fix for earlier issues (non-public JIRA SH-3941 and SH-3954), now appears to cause avatar bake fail issues when running the viewer-side SSB code on regions using the current avatar baking mechanism. Whirly Fizzle has been able to reproduce the issue when using pre-saved outfits in her My Outfits folder, and describes it thus:

Replace outfit with a ready saved Outfit A from My Outfits folder (Right click -> Replace current outfit). Relog Usually, but not always, I will see part of my baked textures as grey with this certain outfit A. This session my torso texture appears grey to me. My torso fully rezzed without needing to rebake in about a minute.

[Now] Replace outfit with Outfit B, which is a ready saved outfit from My outfits folder (Right click -> Replace current outfit).Outfit B bakes fast & looks correct to myself.

Wait 30 secs or so [and] replace outfit again with outfit A. My avatar will then show the correct head and lower baked layers from outfit A but my upper/torso layer will be that of outfit B.

The SUN-57 issue, as defined by Whirly Fizzle: left - Outfit A from her My Outfits folder replaces whatever she was previously wearing, and appears correct; centre - after a relog, she repalces Outfir A with Outfit B, and again, everything appears correct; right - she replaces Outfit B with Outfit A, but her skin fails to bake correctly, the head and legs showing the skin associated with Outfit A, the torso still showing the skin from Outfit B (shown naked for clarity) - images courtesy of Whirly Fizzle / JIRA SUN-57
The SUN-57 issue, as defined by Whirly Fizzle: left – Outfit A from her My Outfits folder replaces whatever she was previously wearing, and appears correct; centre – after a relog, she replaces Outfit A with Outfit B, and again, everything appears correct; right – she replaces Outfit B with Outfit A, but her skin fails to bake correctly, the head and legs showing the skin associated with Outfit A, the torso still showing the skin from Outfit B (shown naked for clarity) – images courtesy of Whirly Fizzle / JIRA SUN-57

Whirly further reports that the issue doesn’t resolve itself after several minutes, and rebaking using CTRL-SHIFT-R has no effect (other than reducing her to a cloud in other people’s view), while using Edit Appearance also fails to clear the problem.

Again, this issue only occurs when using viewers incorporating the latest SSB code, and only on regions which are not themselves running the server SSB code. It is of concern because the viewer code is designed to work with both the current baking mechanism and the upcoming SSB mechanism, and will be expected to do so during the SSB deployment to the main grid, when there will be a period when both the “old” and “new” baking services will for a time be running side-by-side as the latter is gradually rolled-out.

Continue reading “SL projects update week 12 (3): viewer, CHUI, SSB, materials and releases” →

LL announce new server-side AO capabilities

Posted on by Inara Pey

Update March 26th: This article now includes the links to the relevant wiki pages for the new capabilities, as released on March 25th. Also, permissions to animate an avatar are only auto-granted when a prim using the new capabilities is attached to the avatar (PERMISSION_OVERRIDE_ANIMATIONS), otherwise explicit permission required.

Note: article title revised to better reflect contents

At the Beta Server meeting on Thursday 21st March, the Lab informally announced the forthcoming arrival of a server-side Animation Override (AO) system utilising LSL commands.

Coded by Kelly Linden, this new capability is not seen as a replacement to existing AO systems, but rather as a means of making them, in Kelly’s words, “Do a significant portion of their work easier and smoother.”

Overview

The new system utilises a series of new LSL commands, which can be placed in a script located in a prim which has permission to animate your avatar, much like current AOs (granted automatically if the prim is attached to your avatar).  However, the advantage with the new calls is that they are keyed directly into the server’s animation states, unlike current AOs, which operate somewhat in conflict with the server’s animations states.

For example, with current AO systems, moving your avatar (i.e. walking) causes an update to be sent to the server, which initially tries to run the default animation required (i.e. the infamous “duck walk”). However, the AO script also detects the state change for your avatar, and then instructs the server to replace the default animation information with the required animation.

With the new system, rather than trying to run the default animation and then have an AO tell it what it should be doing, the server simply replaces the default animation with the required animation, thus vastly simplifying the process.

The new capability is currently available for testing on a number of regions on Aditi (CCMTEST17, CCMTEST22, CCMTEST23, CCMTEST26, and CCMTEST29, all on project channel DRTSIM-201), and it should be deployed to a Release Candidate channel during week 13 (week commencing Monday, March 25th).

Additional Notes

  • The new calls should be compatible with existing AOs, assuming appropriate priorities are used
  • Items such as idle animations and swimming animations are handled separately by the viewer, and so are not covered by the new calls
  • This capability does not require an viewer-side changes at present, although it is likely that a future update will be made to the viewer to allow the Stop Animating Me menu option to reset animation states set using the new calls
  • Seats and poseballs should continue to use trigger animations
  • Poseball type objects should use llStopAnimation(llGetAnimationOverride(“Sitting”)) instead of llStopAnimation(“sit”) in order to work smoothly with the new calls.

Animation States

New server-side AO capabilities coming soon
New server-side AO capabilities coming soon

The animation states specifically covered by the new LSL calls comprise:

  • Standing
  • Sitting
  • Ground sit
  • Standing up
  • Crouching
  • Walking
  • Crouch walking
  • Striding
  • Running
  • Turning right
  • Turning left
  • Jumping
  • Pre-jumping
  • Taking Off
  • Hovering
  • Hovering Up
  • Hovering Down
  • Flying
  • Flying Slow
  • Falling Down
  • Landing
  • Soft Landing

LSL AO Calls

The following LSL calls have been defined for use with the above animations.

llSetAnimationOverride(string anim_state, string anim);

  • Sets the animation that will play for a given AO state, where:  string anim_state is the name of the animation state being overridden (e.g. Walking), and string anim is the animation to be used
  • Requires a new runtime permission – PERMISSION_OVERRIDE_ANIMATIONS
  • Once an animation override is set for a given state, it is preserved for the rest of the session, unless reset (see below)
  • As the animation states are purely server-side, they get cleared on a relog.

llGetAnimationOverride(string anim_state)

llResetAnimationOverride(string anim_state);

  • Will reset the animation for the given state to the default
  • Includes a special “ALL” state, which will reset all animation overrides to their defaults
  • Requires new runtime permissions PERMISSION_OVERRIDE_ANIMATIONS.

[New addition, March 26th]. Note that PERMISSION_OVERRIDE_ANIMATIONS Only be auto-granted for attachments, otherwise explicit permission required.

Testing and RC Deployment

As mentioned above, there are a number of test regions available on Aditi where the new AO calls can be tired out by scripters and TPVs, and the new capabilities should be arriving on an RC channel in week 13. Any issues found with the capability should be reported via a JIRA, and, if deemed appropriate, raised at the Simulator User Group meeting on Tuesday, March 26th.

SL projects update week 12 (2): server, interest list, region crossings, particles

Posted on by Inara Pey

Server Deployments – Week 12

The planned server deployed went ahead as scheduled and as follows:

  • Second Life Server (Main channel): on Tuesday 19th March, the SLS channel received the server maintenance package which had been re-deployed to Magnum in week 11. As with the Magnum re-deploy, it excludes the fix for VWR-786 while LL go “back to the drawing board” to try to correct issues. However, it does include the following two fixes:
    • BUG-1612: region Owners and estate managers finding they are unable to teleport back to their region after disabling direct teleports to the region
    • SVC-8019: region visibility delays following region restarts.
  • Release Candidate channels: on Wednesday 20th March, the three RC channels received the following updates:
  • BlueSteel and LeTigre: received the same updates as deployed to the SLS channel on Tuesday March 19th, but otherwise retain the same updates received in week 11 – release notes (BlueSteel)
  • Magnum: should receive further updates to Andrew Linden’s interest list work, as per the release notes.  Specific interest list bug fixes included with this update comprise:
    • Updates for objects that are out of view are delayed for a maximum of 5 seconds, at which point they will be sent (mitigates BUG-1779)
    • Fix for “No object updates from vehicles after some region crossings” (BUG-1814) – see below
    • Fix for “Agent appears in incorrect position to other agents after being moved by a sim teleporter” (BUG-1795).

Interest List Updates

Vehicle Crossings

The Magnum RC channel received a potential fix for the vehicle crossing issues (BUG-1814) which have been experienced by many of late, and which appears to have been a major step in the right direction, going on feedback posted to the deployment thread on the forums.

Essentially, the problem lay in the fact that the recently deployed interest list code has only been updating the viewer with information relating to objects within the camera’s field-of-view. If an object moves out of the field-of-view for more than a few seconds, then updates cease until such time as it re-enters the field-of-view.

Where this becomes a problem when crossing a region in a vehicle, is that when transferring between regions, the camera position is effectively extrapolated first, and any vehicle the avatar is attached to is created “behind” the camera by the simulator just entered. Thus, to the interest list code, the vehicle is “outside” the camera’s field-of-view, and so updates on it are no longer sent to the viewer, and problems result.

The updated interest list code deployed to Magnum ensures updates relating to any object an avatar is sitting on are always maintained (or “subscribed to”, to use the official term) by the interest list code, regardless as to where the vehicle appears to be relative to the camera position. Thus, updates continue either side of a region crossing, allowing control of the vehicle to be maintained.

I took time out to test the code fix, with the aid of Erick Gregan, on Thursday March 21st and we agreed that for aircraft at least, it looked good – neither of us encoutered problems.

Flying a Spitfire XI by Erick Gregan over the four Magnum Sandbox regions, I encountered no isues with sim crossings
Flying a Spitfire XI by Erick Gregan over the four Magnum Sandbox regions, I encountered no issues with sim crossings

Those wishing to test the updated code across region boundaries with aircraft or ground vehicles can do so by visiting the Four Magnum Sandbox regions (accessible to members of the Beta Tester SL group – which is free to join). The update itself will hopefully be deployed to the entire grid in the week 13 deployments.

Object Updates

The lack of updates being received from objects outside of the camera’s field-of-view have resulted in other issues as well, which are also fixed in the Magnum release.

For example, if you are looking at a cube which is changing colour between red and blue every few seconds, and turn your camera so that it is outside your field of view and wait for it to turn blue before camming back, the cube will briefly still appear to be red in your view before suddenly changing to blue. This is due to the fact that when the cube is outside your camera’s field of view, the updates associated with it are no longer sent to your viewer until such time as it re-enters your field of view.

With the updates deployed to Magnum, updates for objects outside your field of view are once again sent to the viewer – but at  a very low rate (around one update every 5 seconds). While this uses a little more bandwidth then sending no updates at all, it also means that objects in a state of change behave more predictably when camming away from and back to them (BUG-1779).

Cacheable Objects

The Magnum update also implements the first set of changes to the re-use of cacheable objects held by the viewer in order to speed up rezzing / rendering. These changes take two forms: a change in what can be cached in the viewer, and a change the order in which things are rendered.

Up until now, any object or item containing a script was considered non-cacheable by the viewer, whether or not the object itself has changed at all.  So if the object disappears (because you teleport away from the region, for example), then all data relating to that object is discarded by the viewer, and has to be re-obtained from the simulator on re-entering the region, which slows rendering.

Continue reading “SL projects update week 12 (2): server, interest list, region crossings, particles” →