The Rift and the hype

Ever since LL announced they were actively working on integrating Oculus Rift into Second Life, there has been a lot of upbeat blogging and speculation as to what it will do / mean for the platform. Reading some of the more enthusiastic posts on the subject, it’s hard not to escape the feeling that we’re apparently standing on the edge of a new age in virtual worlds interaction, and that Oculus Rift is going to bring new depth, new meaning (and new users) to Second Life.

Not all agree with the upbeat messages surrounding the headset and SL. Coinciding with the appearance of a photo showing the Lab’s CEO trying-out the headset, Mona Eberhardt and Will Burns each blogged on the Oculus Rift and some of the factors which could limit its wider use with SL. Both of them raise some valid points, and while I don’t agree with all their arguments, they do present food for thought.

Rod Humble tries out Oculus Rift in a photo released on July 18th
Rod Humble tries out Oculus Rift in a photo released on July 18th, 2013

Oculus Rift is a first-person experience, and this could immediately limit its appeal. The problem here is not so much interacting with the UI or in-world objects – the UI can be updated to handle such shortfalls; some TPVs already allow far greater access to the UI view and to in-world objects than the official viewer when using the first-person (aka Mouselook). Firestorm, for example, presents users with the toolbar buttons in Mouselook which can then be used to display and interact with various UI elements, and it also allows right-click/menu interactions with in-world objects. Ergo, it’s not exactly that hard to re-work things to make them more accessible when using something like Oculus Rift. Similarly, the  upcoming updated / new experience tools could also provide the means for better interactions with  in-world objects such as teleport portals.

Rather, the problem is that most people seem to intrinsically prefer the third-person view, with the greater freedom (e.g. camera movement, etc.) it presents for the vast majority of their in-world interactions and experiences. Coupled with the price tag for the headset (something I’ll return to in a moment), this could possibly count against the Oculus Rift in terms of general use.

Then, as Mona and Will point out, there is the problem that the headset isolates the wearer from the primary means they have of interacting with other people: the keyboard. While the conversations floater can easily be displayed (CTRL-H), it still leaves the problem of actually being able to see the keyboard in order to type accurately. This leaves those wanting to use Oculus Rift either needing to become very proficient touch-typists, or they’re going to have to settle for using voice.

SL is inherently keyboard-focused for the vast majority of users
SL is inherently keyboard-focused for the vast majority of users (image courtesy of Prad Prathivi)

Will Burns points to issues of headsets and open microphones as being a problem when it comes to voice. but I tend to disagree with him. For one thing, it’s not as if a headset / microphone combination can’t be worn with the Oculus Rift. More particularly, and from the in-world meetings held in voice I routinely attend, people actually do leave their microphones open, as the barking dogs, ringing ‘phones  and the clicks of lighters being flicked in the background tend to demonstrate. No, the problem is actually more basic than that.

It’s this: since its introduction in 2007, voice tends to have been avoided by what seems to be the vast majority of SL users. Many simply will not use it, period. So if voice is seen as the means for person/person interactions when using Oculus Rift, then it is quite likely to further marginalize take-up with the headset, no matter what the promise of Exciting New Things it might bring.

In his piece, Will also points to the limitation of the headset when trying to perform tasks such as building. Such critiques might appear to be unjustly harsh and leave people saying, “Well yes, but Oculus Rift isn’t designed to be used for everything!“. However, while such a reply is true, it actually underlines Will’s central point: that the headset is liable have niche applications in Second Life which could further limit its appeal among the wider user base.

Continue reading “The Rift and the hype”

SL projects update week 20 (2): materials beta, SSB/A

Server Deployments – Week 20

As always, please refer to the release forum  thread on the weekly deployments for the latest updates and discussions.

Second Life Server (Main channel)

On Tuesday May 14th, the Main channel received the Experience Keys project. This means the project is now available across the grid, although there are no visible changes to be seen at this point. Release notes.

Release Candidate (RC) Channels – JSON Capabilities

On Wednesday May 15th, all three RC channels received a new server maintenance project (release notes (Bluesteel)).  The project is designed to fix two crash modes and two bugs, and introduce new LSL support creating and parsing of JSON-formatted strings – see part 1 of this week 20 report.

Commenting on the JSON capabilities at the Server Beta meeting on Thursday May 16th, Maestro Linden said, “There are some issues with this week’s Json functions… the keys in key-value pairs are not quoted, but should be and right now you’ll run into problems when you add stings which contain escaped quotes.”

In addition, a further confirmed bug has been found in the code on the three RC channels (BUG-2601), described by Lucia Nightfire as:

Seems that the release on the RC channels has brought about an annoying bug that affects control event triggering in attachment’s child prims after changing regions.

There are two different effects depending how you enter a version 13.05.14.275813 RC region.

After going into an RC region while using any controls, those controls will lock under execution and remain locked until you reset the script or the control perms or detach the object.

After going into an RC region without using controls like with a teleport, the control event will not trigger when attempting to use any controls until you re-request/re-grant control perms or go back to a main channel region.

Should this problem be encountered, returning to any Main channel region should restore the broken functionality.

Because of both of these issues, it is believed the code currently on the three RC channels will remain on them for a further week while fixes are developed and implemented.

SL Viewer Updates

Beta Viewer

The current SL beta viewer code, which contains the FMOD Ex updates is expected to be merged with viewer release shortly, prior to going to testing. Depending on the results of the testing, an updated SL release viewer should appear early in week 21.

Viewer Release Process

Because the version upgrading changes will move to the viewer release channel with the move of the current beta viewer, the viewer beta repository will stop being used, and viewer releases will start switching over to the new release process. As a part of this, two new wiki pages will be appearing in the next future (probably in week 22).

The first of these will be a revamped Alternate Viewers page on the wiki, which will list all the available LL project viewers and beta viewers and release candidates which are available, as well as the current viewer release, all of which will have download links and links to their respective release notes.

The second wiki page will have the same information together with pointers to which repository used to build the viewer, which changesets were used to build a viewer, and whether or not the repository is public.

The plan remains that under the new release process, all beta and release candidates will have public repositories, while project viewers many not initially have public repositories, but will have as they reach the later stages of their development.

Cocoa Project

The Cocoa project for Mac versions of the viewer has been largely stalled as a result of redeploying TPV assistance from that project to the materials project. It is anticipated that once materials moves to a beta viewer status, the emphasis will shift back on to the Cocoa viewer work

Materials Processing

Providing all goes according to plan, the Materials Processing code should move to a beta  status within its own repository and hopefully also make an appearance in week 21. Commenting on this, Oz Linden said at the TPV Developer meeting o Friday May 17th, “It’s still not 100% there; there’s still a few known bugs, but we think we’ve got all the serious ones and so we’re going to put it out where people can play with it.”

Once the materials viewer does reach beta, the anticipation is that it will remain there for “a little while” and the it will not be a one-spin beta release prior to moving on.

Detail on the hint of a Katana created entirely using the new materials capability. The sword is made by June Dion and has an LI of 7
Materials used to create details on the hilt of a Katana created by June Dion – soon to be visible in the Materials Processing beta viewer

Continue reading “SL projects update week 20 (2): materials beta, SSB/A”

SL projects report week 17 (3): server, group bans and Oculus Rift

Server Deployments – Week 17

The scheduled server channel deployments took place as planned this week.

The SLS Main channel

As previously reported, this received the update package deployed to the three Release Candidate channels in week 16, primarily comprising the new server-side LSL Animation Override capabilities, complete with a fix for BUG 2164release notes

BlueSteel and LeTigre

Both of these channels received the first part of a new experience tools project – referred to as the “Experience Keys project” in the release notes.

Interestingly, the release notes refer to BlueSteel and LeTigre receiving server release 13.04.19.274370; however, the viewer reports both of the channels running 13.04.05.273550. I contacted Maestro on this, who replied, “There was an error during the roll, so a slightly older version (which doesn’t include the changes from this week’s main channel update) was deployed.”

Not too much is known about the new Experience Keys project, although the emphasis on “new” indicates this is more than just a deployment of the outstanding permissions system for the current advanced creation / experience tools, and speculation has been running high. At the Simulator User Group meeting on Tuesday 23rd April, Simon Linden indicated he was unsure as to what he could / could not say on the matter (particularly as it appeared the documentation was still being written-up).

Commenting on the Bluesteel / LeTigre deployment at the Server Beta meeting on Thursday 25th April, Maestro Linden was also somewhat circumspect on the matter, commenting, “The team doesn’t want to announce the features yet, so I can’t give many details … some other parts need to be released for the new features to be usable. So ideally, nothing visible should change there.”

The reference to “some other parts” which need to be released for these new features may include a viewer update. Whether such an update will appear ahead of or behind the materials capabilities (still currently in a project viewer) is unclear at this point in time.

Magnum

Magnum received additional LSL support for new HTTP contents types, as document in the release notes. It also received a change to how certain message types are handled by the server, which Maestro described thus:

There’s a change to make the server smarter about how it throttles certain messaging types to prevent certain types of ‘DoS’ attacks, where a ‘bad’ object could prevent your avatar from getting llDialog notifications from other objects. All objects owned by UserA share the same throttle for sending llDialog() messages to UserB, but objects owned by anybody else would have a separate throttle pool.

This should hopefully reduce the incidences of iiDialog being used in spamming attacks which can result in the viewer either being severely slowed down or crashing altogether.

SL Viewer

The beta viewer gained a further release (3.5.1.274558) which reached public availability on April 24th, containing further CHUI and SSB/A dixes and updates, as detailed in the release notes. The development viewer also received a further release (3.5.2.27469) which also gained public availability on April 24th.

Group Bans

Baker Linden: Group Ban work coming, just not quite yet
Baker Linden: Group Ban work coming, just not quite yet

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.). This work is in response to JIRA VWR-29337. In my last report on this, Baker has written-up the documentation for the work and was having some other Lindens cast an eye over it.

Attending the Server Beta meeting on Thursday April 25th, Baker provided an update on his activities. “I’m still working on group bans, but I decided to fix a couple small bugs first. They both relate to searching people using the choose resident floater. They’re in the system where I’ll be adding group ban stuff, and now that I can test the changes, I can get them pushed to an RC. However, he did go on to say, “It’s going to be a while before Group ban stuff is ready.”

Second Life and Oculus Rift

There has been considerable interest in the Oculus Rift headset and its potential for use within Second Life, as reported back in week 14 and more recently. Jon Brouchoud in particular blogged on why SL would be a “killer app” for the headset, and a video I featured back in week 16 has also appeared on numerous SL blogs (hardly surprising, given it has pretty much gone viral where the Oculus Rift is concerned 🙂 ).

On Wednesday April 24th, Hamlet Au covered the fact that the Lab is already looking to integrate the headset into Second Life, and have given official confirmation, with company spokesman Peter Gray (Pete Linden) quoted as saying, “We plan to strongly support Oculus Rift. That means code, client, and server-side, to make the Oculus Rift experience excellent in Second Life.”

Continue reading “SL projects report week 17 (3): server, group bans and Oculus Rift”

SL projects update week 16 (1): SL viewer, materials, SSB and other bits

SL Viewer Updates

There’s no movement on the release viewer, and likely won’t be until Server-side Baking moves to it, having finally arrived in the Beta viewer on April 12th (see below). The Development viewer was also updated on April 12th, with the release of version 3.5.2.273873, which includes both SSB and CHUI updates.

Materials Project

An update to the materials processing project viewer was released on Friday April 12th – 3.5.1.273855 – with a series of bug fixes included in it. There are further updates on the way, with the next release due around the middle of week 16, which will have further bug fixes and, hopefully, some Alpha mode updates as well. Commenting on the latter at the Content Creation User Group on Monday April 15th, Geenz Spad said, “Actually just got normal maps working on alpha blended objects, and trying to get everything else working on them as well.”

One fix currently pending is that for MATBUG-16, Changing one material, or setting causes another material texture to be lost. This is an issue which can happen as a result of several factors. For example, setting a normal or specular map for one face of an object can result in maps already applied to other faces of an object either being removed or replaced with the most recently added map. The same issue can occur when applying a setting such as glossiness to one face of an object using materials.

MATBUG-16 demonstrated using 2 deiffuse maps and their associated normal maps. (l) the prim with a diffuse map added to one face & with the "stone" normal map still showing for all faces. (r) the normal map add
MATBUG-16 demonstrated using 2 diffuse maps and their associated normal maps. A prim previously set with a stone diffuse map and associated normal map has a green diffuse map applied to one face – the normal map is unaffected (l). However, when the normal map is updated, it changes for the entire prim (r)

This problem doesn’t happen every time mixed materials elements are used on object faces, but can occur when adding multiple materials elements to an object in quick succession. “There are a couple of problems there,” Oz Linden said while discussing the problem at the Open-source Dev meeting on Monday, April 15th. “The updates to the server are happening faster than it will allow, which is one problem. The other is that the updates are not applied locally as smoothly as they should be.”

Tonya Souther, who re-worked the Build floater for materials processing added, “Yeah, that bug has been driving me batty ever since I first did the UI. And I think that’s due to the design of the system…the UI has to ask the server for the material separately, and apply the values retrieved from it to the UI components when they arrive. That ‘s the only way that the UI won’t get out of sync with the actual values stored on the server … I just need to find a way to make the delay not apparent to the user and handle changes that come along in that period.”

For now, the answer seems to be that if you experience any issues with normal / specular maps vanishing or being replaced when using multiple maps / effects across different faces of an object, then allow a short pause between adding the various maps / effects so the viewer and server can keep pace with your work.

Elsewhere, Geenz Spad, one of the architects of the materials processing system, has started a new blog series on materials, Second Life Materials:  A Content Creator’s Guide. In the first part of the series, he answers the question, What’s a material? In the next installment, he promises to take a look at some of the tools which can be used to create normal maps.

Server-side Baking

The viewer Server-side Baking /Appearance code reached the Beta viewer in week 15 with the release of 3.5.1.273869 on April 12th. The initial stats apparently show it is doing well, crash-wise, but the status of incoming bugs is currently unclear. However, it still looks as if the code is currently on course for around a two-week stint in the beta viewer prior to moving to the release viewer channel.

A key bug fix for the system has been SUN-57, which now allows multiple layer of clothing to be worn / swapped on regions which are not running the SSB server-side code (on Aditi), which removes a potential road block from server-side code deployment (remembering that for a time during the server-side deployment, updated viewers must support both the old and new avatar baking services).

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, which saw issues occurring in avatar baking using a viewer supporting the upcoming “new” SSB/A service and changing outfits on a region only supporting the current avatar baking process, which saw outfits and skins failing to update correctly following changes. Reportedly now fixed

There are still no definitive timescales for any Agni deployment for SSB/A. As previously reported in this blog, it is still unlikely that any major deployment operations will commence prior to the SSB cove reaching the release viewer.

Other Items

I recently blogged about Oculus Rift and  speculation as to whether it would see use in Second Life. On April 7th, Jon Brouchoud blogged on why SL would be a “killer app” for the headset – an article which has seen widespread reprinting / referral in SL / Opensim related blogs. While I have no particular opinion either way as to Oculus Rift / Second life (although how it will work with the SL UI does intrigue me), I have to admit the following video demonstrating Oculus Rift had me smiling from ear-to-ear. It’s not really related to Second Life, but it is well-worth watching.

SL projects update 14 (1): CHUI, SSB, and getting immersive

The best laid plans of mice, men and Linden Lab gang aft a-gley…

Back in my week 12 update, I reported on the Lab’s hoped-for deployments, viewer-wise in the upcoming weeks, noting that if all went well, CHUI would reach the release viewer late in week 13, and open the door for Server-side Baking to move to the Beta viewer at the start of week 14 – possibly even on April 1st (and no, that wasn’t an early April Fool’s joke from Oz!).

However, a couple of things have come up which are tweaking things slightly.

Communications Hub User Interface

There are a number of unresolved issues with CHUI, not all of which might necessarily prevent the code moving to the release channel, but some of which do have  significant performance / useability impacts, such as:

  • CHUIBUG-132 – Frequent performance issues on recent CHUI builds – fast timers show problem is in “URL Complete”
  • CHUIBUG-183 – cancelling an inventory search before the search is complete results in blank inventory contents (issue thought to be the result of a refactoring of the inventory code which is included with the CHUI code)

As a result, there was a further release of the CHUI beta viewer on April 1st (3.5.0.273174), which was followed by a further development viewer update (3.5.1.273259) on the same day.

Server-side Baking

Server-side appearance baking - no beta viewer just yet
Server-side appearance baking – no beta viewer just yet

It had been hoped that the viewer code for SSB would move to the beta channel once CHUI had moved to the release channel. As CHUI is now remaining in beta for a while longer, the move with SSB has been delayed.

In terms of SSB’s viewer beta run, LL are re-assessing the time frame. Again, on March 22nd, Oz Linden suggested that the beta run would be between two and four weeks and liable to sway towards the latter – with the caveat that a lot depends on issues / bugs which are found during the beta run. The current thinking at LL appears to be more pragmatically focused on seeing what occurs during the beta run, rather than pinning matters to a firm timescale – as such, SSB is liable to be in beta for around two weeks, possibly longer.

However, in terms of the server code, the plan remains to cut-over to the new server code capability after the SSB code has reached the release channel of the SL viewer – although again, it is possible some initial testing regions may be running on Agni prior to the SSB code appearing in the release viewer. Until now, LL have indicated that the server-side deployment will be gradual, again as indicated in my week 12 notes linked-to above; however, exact plans still have to be confirmed within the Lab, so this may well also be subject to change in the future.

One issue with the SSB server-side code is that crossing from an SSB-enabled region to a non-SSB region triggers the need for a manual rebake (going from a non-SSB region to an SSB-enabled region will trigger and automatic rebake), and some concern has been raised that this might cause some upset as the SSB code is deployed. However, and as Oz Linden points out, manual rebakes are currently a fact-of-life on SL, and as such, this is unlikely to be seen as a reason for an immediate deployment of SSB right across the grid; nor does it warrant time being spent on ensuring rebakes are handled automatically during such region crossings as once server-side deployment does commence, the issue is liable to be relatively short-lived.

Oculus Rift and Leap Motion

The Oculus Rift headset has been garnering a lot of interest. While still very much under development, the headset has already gained considerable support from the likes of Valve Software and other game-makers. This has inevitably lead to some asking whether LL have their eye on the technology.

Whether they have or not is unclear. What is clear, and while not quite the same, is that there has been some informal experiments with the Leap Motion system, courtesy of Simon Linden, as reported on in the SL blog and also in these pages.

Commenting on the Leap Motion work which chairing the Open-source Dev meeting on monday April 1st, Oz Linden said, “If an open source dev wanted to pick up what Simon started, that would be great. That was a side project of his, and right now we don’t have time to do much more with it internally.”

The code for the work Simon has completed was also made available when his experiments were made public – so if anyone is up for the challenge, the links are still live!