SL projects update: week 49 (2): Oculus Rift Support “soon”

Maestro Linden (foreground) leads the Server Beta meeting. The colony of bats to his left is Voidpointer Linden, who is working on the Oculus Rift project
Maestro Linden (foreground) leads the Server Beta meeting. The colony of bats to his left is VoidPointer Linden, who is working on the Oculus Rift project

Server Deployments week 48 – recap

As always, please refer to the week’s forum deployment thread for the latest news and updates.

  • Main channel, Tuesday December 3rd: received the maintenance package deployed to BlueSteel and LeTigre in week 47

Issues with Main channel deployment

Two issues were discovered post-deployment of the Main (SLS) channel  updates:

  • BUG-4637 “”Can’t rez object at { x, y, z } because the owner of this land does not allow it”when rezzing any object from Library”
  • BUG-4635 “”Selected / sat upon:” incorrectly shows objects that are not actually selected or sat upon. “

Maestro has verified a fix for the latter issue, which he described as occurring with vehicles which get into a “funky” state, ” The vehicle gets ‘bad’ if it loses the passenger right at region crossing,” he said by way of explanation, leaving them appearing to have somebody sitting on them per parcel accounting rules, but who is effectively a “ghost rider”.

It is hoped that these fixes will form a RC release together with some additional small updates prior to the no change window / code freeze kicking-in on Monday December 16th.

Animation fixes

Commenting on the llGetAgentInfo() update deployed to the RC channels at the Server Beta meeting on Thursday December 5th, Maestro Linden said:

The only change which should be visible normally is a fix for avatars with crouch / crouchwalk animation overrides. Previously, the llGetAgentInfo() LSL function would only return AGENT_CROUCHING if the avatar was playing the default crouch or crouchwalk animations, so if your avatar had an AO which replaced those animations, (either with llSetAnimationOverride() or possibly with classic AOs too), scripts couldn’t tell when you’re crouching. But with the fix, the function is looking at whether you’re actually crouching, regardless of which animations are playing.

He went on to note that there is a similar issue with ground sit, wherein if you sit on the ground, the viewer only presents the ‘stand’ button if your avatar is playing the default ground sit animation. Originally, llsetanimationoverride() allowed the ground sit animation to be replaced with something else, but this led to situations where a seated avatar could not stand up.

To fix this latter issue, Kelly Linden implemented a workaround for this problem by making “ground sit” play two animations, the default ground sit and any custom ground sit specified by the user, with the priority of the default ground sit hopefully being low enough not to clash with any custom animation also used. The change was viewed as a compromise to make the AO system compatible with viewer 2x/3x, and is why the SL wiki alludes to in ‘ State “Sit on Ground” will play the default animation in addition to any override set. This is required for correct viewer behaviour. ‘

SL Viewer

The Fitted Mesh project viewer was updated to version on December 5th.  The update addresses:

  • LL internal JIRA MAINT-3311 (Skinning to some collision volumes is broken)
  • STORM-1985 (Mesh garments don’t adapt to changes in avatar shape)

In addition, it includes the updated avatar_lad.xml and avatar_skeleton.xml  file developed by Jeremiah Linden in accordance with his notes on FITMESH-2 (notes dated December 2nd, 2013).

Oculus Rift Support

Oculus Rift: release of a "feature complete" viewer with Rift support "soon"
Oculus Rift: release of a “feature complete” viewer with Rift support “soon”

Also attending the Server Beta meeting, Voidpointer Linden reported that support for Oculus Rift is feature-complete and should be released “soon”.

There will be a formal announcement when a viewer with Rift support is released (no date as to when this will be as yet), however, a few clues were given out during the meeting:

  • The same viewer can be used in both a “normal mode” and a “Rift mode”
  • There will be no apparent changes to the viewer / UI when in “normal mode”
  • Frame rates when in “Rift look” will be very much down to the user’s own hardware  (unsurprisingly). Voidpointer apparently attended the meeting using a Rift headest and reported that he was getting frame rates ” pretty comparable to normal,” but also noted he has a good machine on which to run SL.

Details on the presentation of the UI, etc., were not provided, as these are apparently still under wraps. In the past, it had been indicated that the UI had been set to be floating “overhead”, just outside of your normal point-of-view, so you had to look up to see them. Whether this is still the case, remains to be seen.

There have been reports of people using the Rift (in general, not just with SL) suffering from nausea and motion sickness. Commenting on this, VoidPointer said, “I’ve been using it for a while now and I don’t really have problems with nausea at this point. [But] the Rift is very sensitive to frame rate, vsync, and other things.   Before the rendering was fully hooked up or optimized,it wasn’t as fun, I’ll say that.” He also revealed the Rift headset can be somewhat adjusted so it can be worn over glasses, if necessary.

As the Rift is not currently commercially available, those with the headset and SDK will be able to make use of the new viewer once released, and will require a DVI cable connected to the headset and their system for the video output and a USB connection for the head tracking capability (so the screen view follows the wearer’s head move to present them with the expected view). Commercial versions of the system will use HDMI for the video.

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

There was a lot of additional talk about possible future options for presenting in-world views with the Oculus Rift, however, as Voidpointer advised, “Heh, let’s get Rift support first, then talk about more :).”

Whether support for the Rift will be announced before or after the end-of-year break remains to be seen.

7 thoughts on “SL projects update: week 49 (2): Oculus Rift Support “soon”

  1. This is good news indeed about Linden Lab’s upcoming Oculus Rift support. Especially the bit about them optimizing the rendering. I was hoping that they’d do this; the rendering code isn’t very friendly to work with to say the least!

    I, and undoubtedly others, can’t wait to get my hands on their code to fill in any missing bits and try alternative features. And enable it to be used with OpenSim. Hopefully “soon” is, um, actually soon. : )


    1. As I commented on your blog (ta for the link, btw!):

      The realist in me tends to side with the idea that we’ll not see anything until January-ish 2014. The code freeze / no change window starts on Monday December 16th for both the server and the viewer, and no major updates will be made during that period, other than in an emergency.

      But … it has also been indicated that project viewers may be excluded from the no change window, as they have limited appeal amongst users. Given that the Oculus Rift isn’t yet available commercially, it may well be that the viewer is initially pushed-out as a project viewer; in which case, and depending on its overall status, we might see it appear as a Christmas stocking-filler (for those with headsets) an the next couple of weeks.


Comments are closed.