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!

11 thoughts on “SL projects update 14 (1): CHUI, SSB, and getting immersive

  1. I am not comfortable about the way in which Oz dismisses the possible need for manual rebakes.
    The annoyances from different Physics versions were bad enough, and that really only affected vehicle users, This is going to affect everyone, unless they spend their time in one region.
    Manual rebakes are “a fact of life”?
    In my experience, the need is not frequent, they are often associated with general network ungoodness, and it is unusual to move from one region or another and need a rebake. Oz Linden again seems to have an image of what happens in Second Life which is poorly rooted in the reality. (It’s possible the bakefail issues get reported through support, and nobody has tried to figure out just how frequent an experience they really are. Support effort can be misleading, even when fixing the problem is worth doing in terms of support costs.)
    Do the Lindens coming in to user group meetings ever do a region crossing?

    Like

    1. While the incidence of rebakes has reduced hugely on a personal level over the last few years, I’m still finding the need to perform personal rebakes myself – often after teleports, when I find that one or other body part (head, torso or legs) fails to bake; and the general consensus from users at the meeting was that manual rebakes are familiar enough to all that any short-term discrepency while the code is being deployed isn’t going to be that much of a hardship.

      As to region crossings – in fairness, prior to the threaded region crossing code roll-out and prior to the initial interest list code deployment, there were tests. The problem the Lindens had with the latter is that because the camera / snagging issue wasn’t happening on all vehicles, they had trouble reproducing the issue until a) they received sample vehicles, as per their requests, b) a JIRA was filed with specific details. Once both of these were obtained, the matter was further examined and a fix quickly developed. That fix (BUG-1814) should be deployed across the entire main grid as a result of the Tuesday April 2nd deployment.

      Like

      1. I was referring to the rollout of the new Physics engine needed to support the Pathfinding code. For sundry understandable reasons, a vehcile could go from old-Physics region to new-Physics region without any problems. The reverse jouney was a total failure (was it only mesh-built vehicles, I’m not sure). And the layout of the RC channel used messed up the Blake sea, and just about every boat-racing course I knew of. The layout of RC regions was also so scattered and disconnected it was hard to test the region crossings against the new Physics. It all looked damnably incompetent.
        The threaded region crossing code, and that other problem, might have been more readily detected if the Lindens had taken the trouble to choose an RC, and even organise it on the map, to allow sensible testing of the new-to-new region crossings. I know the Blake Sea has finally been tidied up, and there are the Magnum sandboxes, but I can’t escape the feeling that the Lindens couldn’t test their way out of a wet paper bag.
        There is a very simple point to all this: if you want to be sure how new code affects region crossing, it’s the new-cde to new-code crossings that matter, and all that you get from other crossings involving new-code, when you know they will fail anyway, is annoyed customers.

        Like

  2. On Oculus VR: I’ve tried one viewer, in the days before Viewer 2, which gave a 3D Image with those coloured glasses. I think they’re called anaglyphs. So that data is available at viewer level for a 3D display, whatever technology is used to get the images into the eyes. I did hear of a viewer in the V2 family which did the same. Apparently there is some open source code out there for the anaglyph generation.
    Frame rates sucked, and would be a bit low even with my current hardware.
    I need spectacles. Many of these personal displays seem poorly designed to work with spectacles, and my visual defects are not compatible with contact lenses. I coped with those cheap cardboard coloured specs, but after an hour or two I get a headache.
    Oculus VR support might be fairly easy to implement in the viewer, but it’s unlikely to be something I would try.

    Like

    1. In terms of anaglyph glasses, Kirsten’s viewer had a 3D capability utilising them back in 2011 as well. I tried it when Lee released it but found it hard on my eyes (and on my hardware with all other bells and whistles on), so do emphasise with you.

      There’s an SDK kit available for Oculus. I’ve not looked into the requirements for obtaining a copy; maybe someone elsewhere already has one and is tinkering.

      Like

    1. Leap Motion and building…. could it lead to people using Lego in the real world and seeing what happend prim-wise in-world: 😀

      Like

  3. .Crossed more then 30 sims today, on the Blake sea, seamless and at 100pct throttle!
    Then from San Catalina airport all the way to Honah lee airport and then to Satori!
    So Cross sim fix is working!

    Like

  4. in cHUIBUG-183 (Non-repopulating inventory)… whats that music playing…? I would really like to know. >.>

    Like

Comments are closed.