Month: March 2013

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” →

The Drax Files 2: dipping into history

Posted on by Inara Pey

Coming out a little ahead of schedule, Draxtor Despres launched the second segment of The Drax Files on Friday March 22nd. As with the premiere show, the format uses mixed reality, cutting between Second Life and real life to look at another aspect of the former and those from the latter who have made it possible.

The second show in the series focuses on the 1920s Berlin Project and the driving force behind it, Jo Yardley, from Amsterdam.

1920s Berlin project
1920s Berlin Project

Jo has worked on the 1920s Berlin project almost since her arrival in Second Life, and in doing so, demonstrates one of the major abilities of the platform: the creation of an immersive environment which not so much stands as a static reproduction of a place and era, but which actually brings it to life, allowing those involved in the project as residents and those coming to it as visitors to experience life as it was in Berlin during the inter-war years of the twentieth century.

As with the first segment, Drax takes a backseat in things, rather than opting for an interviewer-lead reportage-type approach to the subject. This allows Yo to present both her involvement in Second Life, and how it naturally overlaps with her real life in Amsterdam in an entirely natural style which draws you, almost intimately, into her life and passion for history.

1920s Berlin Project
1920s Berlin Project – image courtesy of Jarla Capalini, via the 1920s Berlin Project Flickr Group

There are times when Second Life is seen by those in the world at large as being for those lacking a “first life”, people without interests, hobbies or friends which and with whom to engage. By allowing us to see into her real life, as well as exploring her Second Life work with her, Yo presents the real, human heart and soul of Second Life – the ability to use it to extend hobbies and interests, the opportunity to provide immersive environments which both engage and inform and in doing so, meet with people from all over the world and form bonds and communities which perhaps run both broader and deeper than  those we might forge purely through the likes of Facebook and other two-dimensional social media.

What emerges is a warm, informative picture of Second Life and why people do care so much about it, how it can offer-up unique opportunities for those wishing to explore it and which further demonstrates how mixed reality is an ideal format for promoting Second Life. Witness, for example, the way in which we see an audience at the 1920s movie theatre in Second Life are in turn able to see into Yo’s real life activities as they are projected up onto the silver screen.

It is this care with the editing and composition of the show which, to me, does much to set The Drax Files as a beacon to those looking to positively promote SL to a larger audience through the use of machinima and mixed-media. Drax demonstrates an intuitive skill, doubtless spurred by his own passion for Second Life, to produce shows which are beautifully balanced from editing through the soundtrack selection to the final cut, to produce a unique and insightful window into the platform and its users.

Kudos, once again!

Related Links

1920s Berlin Project
1920s Berlin Project

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” →

SL Buddy Walk concert

Posted on by Inara Pey

SL-Buddy-Walk-basic-signThursday March 21st will see an all-day concert staged at the SL Buddy Walk 2013, which I previewed recently.

The live concert kicks-off at 14:00 SLT to mark World Down Syndrome Day, although there will be music from DJs throughout the morning and leading up to the concert itself, kicking off at 10:00 SLT.

All proceeds made during the concert via the donation boxes on and around the spectacular stage will go directly to the National Down Syndrome Society (NDSS).

Concert Schedule

  • 14:00: Tom 2.0
  • 15:00: CQ – Colorful Quiet
  • 16:00: Maximillion Kleene
  • 17:00: The Follow
  • 18:00: Porter Paquot
  • 19:00: Amforte Clarity
  • 20:00: Colt Shostakovich
  • 21:00: Noma Falta
  • 22:00: Edward Kyomoon
Early morning: the 2013 SL Buddy Walk dnace floors and stage beyond. The concert starts at 14:00 SLT on Thursday March 21st.
Early morning: the 2013 SL Buddy Walk dance floors and stage beyond. The concert starts at 14:00 SLT on Thursday March 21st.

DJs for the Rest of the Event

The current line-up of DJs and music entertainment for the rest of the event comprises (please check with the SL Buddy Walk blog for updates):

  • Thursday, March  21st:
    • 10:00 – midday: Meca4life
    • Midday – 14:00: Lette4life27
  • Friday, March 22nd:
    • 16:00 – 18:00: Willybenz
    • 18:00 – 20:00: Jennifer Lunz
    • 20:00 – 21:00: Kaleb Avedon
  • Saturday, March  23rd:
    • 14:00 – 16:00: Mystic Glenwalker
    • 18:00 – 20:00: Dalliah Love
    • 20:00 – 21:00: Michy Hendisson singing live
  • Tuesday, March 26th:
    • 16:00 – 17:00: Kakeb Avedon
  • Sunday March 31st:
    • 13:00 – 15:00: Nimeral Bearsfeet
    • 15:00 – 17:00: Kaleb Avedon

Also remember that the SL Buddy Walk fair continues through until March 31st, featuring a host of SL designers and creators, with all donates make via the donation boxes in the fair plazas going directly to the NDSS, as do the proceeds of sales from the special vendors creators have on display, with some creators donating up to 100% of all proceeds from their sales – look for the in-store signs.

One of the two fair plazas at the event
One of the two fair plazas at the event

Related Links

Neva again!

Posted on by Inara Pey

Update: Neva River is currently closed to public access.

I covered Neva River very briefly last year. The region is Neva Crystall’s private home, and every so often she will remodel it and then open it to the public for a couple of weeks, so that everyone can enjoy her builds – anyone who has visited Neva River will know why.

I recently saw word via Ziki Questi that Neva was moving towards re-opening the region. Since then, I’ve been waiting (not a little impatiently, I admit – along with a lot of other people!) for the doors to once again open.

Neva River
Neva River

Well, on March 20, the doors did open!

This is inevitably going to lead to a stampede to get to Neva River – indeed, but the time I got there, the place was fairly teeming with people; it’s a measure of the popularity of Neva’s builds. If you have 30-40 minutes some time in the next couple of weeks, I urge you to join the queue, particularly if you are, to borrow from Honour McMillan, a landscape junkie.

Neva River
Neva River

Last time around, the region focused on a water theme, with low sandbanks, waterlogged copses and small fields of grass beneath an orange sky. This time, Neva has gone for something far more undulating, but with a few little eclectic twists. From coastal beaches through rural country to deep gorges, with high bridges, meandering streams, and broad lakes, Neva River presents a landscape which offers much to see, and not a few things to do.

Neva River
Neva River

Starting at the tall lighthouse, located at the headland at one end of the region, you can follow wooden walkways, paths and rutted tracks across the region, encountering other visitors, the local animals (mostly sheep) and various delights and oddities which make a visit to Neva River something of an exploration (just how did a fishing boat end up so land-locked…?).

The region come with its own late afternoon windlight setting, but as is my wont, I opted to go for my “standard” settings, based around a couple of windlight presents I’ve slightly tweaked, and which I like as I feel they give a more natural look and feel to places (one is actually my default viewer’s standard windlight setting nowadays). If the images here don’t do the build justice, blame me, not Neva Crystall!

Neva River
Neva River

I will confess that I had a few problems during my wanderings through the region. However, I think these were pretty much down to the fact that the place is rather busy, people-wise, right now and the fact that I’m using a pre-release of a viewer, so SL is a little bit on the bumpy side for me right now.

All-in-all the rebuild has been worth the wait; once again Neva River is on the list of “must places” to visit in SL – but those wishing to do so had best hurry; the doors may not be open for ever!

Related Links