Category: SL Tech

SL projects update week 48: region crossings, scripted camera and region restarts

Posted on by Inara Pey

Server Deployments week 48

As this is Thanksgiving week in the USA, it is a code freeze week with no scheduled deployments for the grid. Deployments will resume in 49.

It was a quite Simulator UG meeting in terms of news from LL due to this being Thanksgiving week (image: stock)
It was a quite Simulator UG meeting in terms of news from LL due to this being Thanksgiving week (image: stock)

SL Viewer

There are no planned RC releases or updates  for week 48, again because of the Thanksgiving code freeze.

Oz Linden is, however, working on getting another maintenance RC together in the near future, although it’s not clear exactly what this will contain at this point in time.

There have also been reports of issues with test versions of viewers built using the latest Sunshine External repository (the SSA “polish” code and AIS v3). The exact cause of the problems is not known, but it is leading to a high number of Current Outfit Folder mismatch issues on Windows. A request has been passed to the Lab to check the automated build process in order to help ascertain if there is a problem in the code, or whether an issue in merging the code is causing problems. These issues don’t affect any released versions of viewers, only those using the latest SAA / AIS v3 code for testing purposes.

Default Object Permissions

A number of TPVs include the ability to specify the default permissions applied to a new prim object (cube, cylinder, torus, etc.) on creation. A similar capability is being developed for the LL viewer (STORM-68) by Jonathan Yap, a long-time contributor to the viewer. However, this work also requires updates to server-side  capabilities, and Andrew Linden is now looking into this, and at the moment is specifically trying to figure out how to propagate the default perms through teleports and region crossings.

Other Items

Region Crossing Issues

The three RC channels are all running the same simulator version, which includes a fix for “Sim crossing on vehicle fails when parcel at opposite sim border is full.” (BUG-4152). Describing the issue at the Simulator User Group meeting on Tuesday November 26th, Simon Linden said, “The server was doing a parcel check at the wrong location … you’d cross, and at one point it would check a parcel based on the new region coordinates in the first region.   If that happened to be a full parcel, it failed.” This issue has been reported as occurring on Main channel regions as well, under a variety of  reports including SVC-8007. As such, it is hoped that when the package currently on the RCs is promoted to the Main channel in week 49, these issues may also be rectified.

In the meantime, and to test whether the fix may work for SVC-8007, the mainland region of Epirrhoe has been moved to the Magnum RC to allow vehicle crossings to be tested between it and the neighbouring region of Jodis, which has been a crossing which has experienced repeated issues with SVC-8007 for the SLRR.

llSetCameraParams([CAMERA_DISTANCE, x])

Many vehicles of all types in SL use llSetCameraParams to establish a “follow camera” which allows the vehicle to be effectively guided by the driver / pilot.  However, there has been a long-standing issue the CAMERA_DISTANCE  rule, which is clamped to distances far shorter than draw distance. This can make it next to impossible to create a scripted follow camera for very large vehicles such as realistically sized spacecraft, airships and ships.

Clamping with CAMERA_DISTANCE can lead to issues when trying to script a follow cam for very large vehicles using
Clamping with CAMERA_DISTANCE can lead to issues when trying to script a follow cam for very large vehicles using llSetCameraParams

The original JIRA (SVC-3499) was closed as “Won’t finish”. However, commenting on the matter at the Simulator User Group meeting, Andrew Linden said:

If we were to expand the clamp limits then some poorly written scripts will change behaviour. How much do we care about breaking such poorly written scripts? And… I wonder why it was clamped so tight? It would be nice to ask around to see if anyone remembers why some limits were set … Well, it would be possible to expand the distance limit and test to see how it works with different limits. If nothing breaks too bad, then perhaps we could ship it.

A new BUG report has been filed as a feature request for this to be looked at (BUG-4594), which is likely to be looked-at the next time feature requests are sorted, and quite possibly passed to Maestro Linden.

Region Restart and Visibility Issues

An unusual issues has been reported which appears to be related to region restarts and visibility, but it only noticeable on regions which have multiple neighbours, all of which are restarted at more-or-less the same time (within about a minute of one another). The problem can be broken down into a number of related points:

  • Observers are standing in region A, which is surrounded by regions B, C, and D – all of which are restarted at pretty much the same time
  • Following the restart, there is a high probability that some or all of regions B, C, and D will not be visible to those observers on region A (which was not restarted), and they show-up as red on the mini-map – something which has been confirmed on both the SL viewer and Firestorm
  • However, anyone entering region A after the restart will see all of regions B, C, and D as expected. Similarly, anyone on region A at the time the other regions restarted can resolve problems by relogging
  • Those observers who were in region A at the time the surrounding regions were restarted are able to fly into any of them which are showing as red on the mini-map, and although nothing physically renders for them, they will experience object collisions. Furthermore, it is possible to exit the “red” regions on the mini-map and fly into the void where no regions actually exist.

In tests with a specific set of regions, the above issues occurred in 8 out of 12 tries. That there is a unique problem with the regions on which the tests were carried out has been pretty much discounted. Whirly Fizzle, who has been poking at the issue with a number of people, provided a screen capture show how her alt managed to fly through a “red” zone and into the void where no region exists.

Following a region restart, Droom is shown in red on the mini-map, to observers located in Mote (lower left on the mini-map) at the time of the restart. However, these observers were able to fly through Droom, although nothing would render for them (but collisions would occur), and then into the void space where no region exists (image courtesy of Whirly Fizzle, click to enlarge)

Commenting on the matter, Simon Linden said, “It sounds like it’s getting confused and not realizing the old connection went away …  I’d bet on the timing.”

Agreeing with this point of view, Andrew added: “If Region A thinks your viewer can already see into Region B, it wouldn’t initiate the connection,” hence why relogging would appear to fix the issue for those experiencing the problem and those arriving in the region after those around it have been restarted: as you arrive in the region, it (re-)initiates the connection between the  viewer and the surrounding regions. This is also why people encountering the situation can enter void areas where no regions exist, as Andrew also explained: “The region you’re on expects the other region to inherit your avatar, o it lets you walk beyond the region boundaries until the other region picks you up. But if the exchange never completes, you get to walk around outside of the region boundaries for a while.”

This can be seen in the image Whirly supplied: while she is clearly in a void space where no regions exist, the title bar of her viewer still reports her as being in Mote (her “region A” during the test), because the “hand-off” between Mote and Droom (shown in red on her mini-map) never completed.

Andrew recently fixed another issue related to connections to neighbouring regions, and has offered to look into the matter himself to find out what is going on and how it can be rectified.

Lance provides further news on Dolphin

Posted on by Inara Pey

dolphin-logoIt’s been several months since the release of the last Dolphin viewer update (March 2013). This means the viewer is lagging behind many of the 2013 updates from the Lab, including things like Server-side Appearance, materials, etc.

Lance Corrimal, the man behind Dolphin is not unaware that this is the situation. His real life this year has been such that it has required almost all of his attention (including starting a new job which sees him travelling and away from home a lot of the time), all of which has limited the time he can devote to the viewer, as much as he’d like to be able to do so.

In July and August he gave a couple of short updates on his situation, which I also passed on through these pages, and on November 22nd, he posted a further update on the Dolphin website, which reads in part:

I am not exactly happy about what I have to announce here, but this is how it is going to be:

The next Dolphin Viewer is not going to be around any time soon.

I have looked at the mess that my current state of the sources would produce, and I have (finally but far too late) come to this decision:

I will start from scratch.

Right now, taking the current Dolphin Viewer source and just “shoe-horning” in everything new from the official sources produces a terrible mess that does not compile cleanly, let alone works. Besides, the last Dolphin Viewer has a quite large number of features that don’t work any more, due to changes that the Lab has made in the meantime, temp uploads being one of them.

So, I’ll basically have to reinvent everything. That will of course take some time. I’m guessing “several months” right now, not the least due to the fact that with my new job that I have been doing since April, I’m travelling a lot, so I’m not even home all that much. I’ll see how much I can do on my company laptop.

I will go back to my usual “release early, release often” policy, as soon as I have something that is properly branded as Dolphin Viewer and has more to offer than just the name.  I will plan to release at least a public beta as soon as I have something.

This would suggest that an updated Dolphin viewer is unlikely to emerge before the end of the year, and that we may be a few months into 2014 before one does. However, the upside of this is that Lance is not abandoning the viewer, which has enjoyed a loyal following. Patience remains the order of the day as he tries to balance the demands of real life and Second Life on his time.

One additional consequence of everything going-on for Lance right now is that he plans to  eventually stop building / providing openSUSE rpm packages for some of the other third-party viewers; as he notes himself, he just can’t seem to pack more than 24 hours into a day.

Further news / updates from Lance will be reported as they become available.

Viewer release summaries 2013: week 47

Posted on by Inara Pey

This summary is published every Monday and is a list of SL viewer / client releases (official and TPV) made during the previous week. When reading it, please note:

  • It is based on my Current Viewer Releases page, a list of  all Second Life viewers and clients that are in popular use which are recognised as adhering to the TPV Policy (and of which I am aware), including
  • By its nature, this summary will always be a week in arrears
  • The Current Viewer Releases page is updated as soon as I’m aware of any releases / changes to viewers & clients, and should be referred to for more up-to-date information
  • The Current Viewer Releases page also includes comprehensive links to download pages, blog notes, release notes, etc., as well as links to any / all reviews of specific viewers / clients made within this blog.

Updates for the week ending: November 24th, 2013

Official LL Viewers

  • Current Release version updated on November 21st to version 3.6.11.283787 (dated November 15th) – formerly the GPU table updates RC (download page, release notes)
  • Release channel cohorts (See my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself):
    • No updates
  • Project viewers:
    • Fitted Mesh viewer 3.6.11.283899 released on November 20th – This viewer adds new “collision bones” to the standard avatar skeleton. Properly rigging mesh objects to those bones will cause the garment to adapt to changes in the avatar shape made using the avatar editor sliders and avatar physics (download and release notes)

LL Viewer Resources

Third-party Viewers

V3-style

  • Black Dragon updated on November 18th to version 2.3.8 (Maintenance #3) – core updates: UI updates; RLVa update; rendering fixes (release notes)
  • CtrlAltStudio Experimental version updated on November 18th to version 1.1.0.34376 – core updates: variable-speed walk / fly; Kinect gesture support for avatar movement (release notes)
  • Kokua updated on November 18th to version 3.6.10.30662  – core updates: parity with SL 3.6.9 / 3.6.10 code base; significant rewrite to area search with context menu active; link to grid support groups (if available in settings file) added to Help > About Kokua  (release notes)

V1-style

  • Cool VL Experimental version updated November 23rd to version 1.26.11.0 and again on November 25th to version 1.26.11.1 – core updates: 1.26.11.0 implemented “project interesting” updates; 1.26.11.1 fixed 2 bugs within the 1.26.11.0 release that prevented cache files to be written to the disk (losing the benefit of caching on return to visited regions) and which prevented object flags (touch, pay, modify, etc) to be propagated from the cache to the rezzed objects on cache updates (making it impossible to touch, pay, edit, etc random objects in the avatar’s field of view) – release notes

Text Clients

  • Group Tools updated on November 23rd to version 2.2.24.0.

Additional TPV Resources

Related Links

SL projects update week 47 (3): viewer, Sunshine / AIS v3, HTTP and more

Posted on by Inara Pey

The following notes are taken from the TPV Developer meeting held on Friday November 22nd. A video, courtesy of Northspring, can be found at the end of this report. The numbers in braces after each heading (where given) denote the time stamp at which the topic can be listened-to in the video.

TPV Developer meeting (stock)
TPV Developer meeting (stock)

No Change Windows

[00:31-02:26]

Thanksgiving

As has been previously noted in this blog, week 48 (commencing Monday November 25th) is code freeze / no change window due to it being Thanksgiving in the United States. This means there was be not server deployments during the week and there will be no viewer release channel updates for the week.

Christmas

The Christmas code freeze / no change  window is scheduled to run from Monday December 16th through until Wednesday January 1st. This most likely means that once the code freeze comes into effect,  there will be no major server updates until the 2nd week of 2014 (commencing Monday January 6th, 2014), and viewer updates may be likewise.

Both the Thanksgiving and Christmas no change windows effectively mean there are only two full weeks left in 2013 in which server deployments and major viewer updates are liable to be made. However, it is possible both periods could see project viewer updates appearing. This is because any project viewer which may be available will have limited use (only those particularly interested in using / testing it are liable to run it), and so minor updates, etc., to such viewers are not seen as being potentially problematic in terms of support issues.

Viewer Updates

[00:18-00:31]

As note in part 2 of this week’s report, the release viewer was updated using the GPU table updates release candidate, leaving just the Project Interesting RC in that channel.

There are upcoming RCs in the pipe awaiting release, including an updated version of the Google Breakpad viewer and another maintenance viewer RC, while the Project Interesting viewer is to update an update as well. However, as week 48 (commencing Monday 25th November) is a code freeze week for Thanksgiving, it is unlikely there will be any releases in the viewer release channel during the week.

Fitted Mesh Viewer

[03:36-08:44]

A number of JIRA have been filed in relation to the Fitted Mesh project viewer, and are receiving attention within Linden Lab. “We’re getting the repairs together,” Oz Linden reported to those attending the TPV Developer meeting, “And when we’ve got enough of them together to do a release with, that have been tested, then we’ll do an update to that one.”

Avatar Skeleton Files

The Fitted Mesh viewer actually contains a small number of actual code changes; the majority of the changes lay within the avatar skeleton and its associated filed (e.g.  Avatar_skeleton.XML / avatar_lad.XML). This has led to speculation that other viewers can update relatively simply by using the revised avatar skeleton files. Responding to this, Oz said:

Ideally that’s true, but it turns out not to be quite completely true. It turned out that there were some code bugs that the new skeleton and weighting exposed. So there are actually some changes that will be beyond that. That is some code [to be changed].

“Adding bones exposed some limitations,” Nyx added.

One of the code fixes which is in progress appears to deal with the issue of how garments weighted to use the new skeleton appear in viewers which do not have the updates, as demonstrated in my preview article on the Fitted Mesh viewer, and shown below.

Time Frame for Formal Release

While the Fitted Mesh project viewer may well see one or more updates before the end of the year, there are no plans to progress it to a release candidate status before the start of the New Year (again, the no change windows would preclude that, at least in part).

Even with the changes now being made, the number of code changes within the viewer is “very, very small”, so when the code is in a position where the Lab is comfortable with TPVs taking it and merging it into their repositories, it should not create major issues. One thing that is not clear at this time is whether merging and incorporating the Fitted Mesh changes will be dependent upon merging other code releases coming out of the Lab, such as the Sunshine / AIS v3 code and the Project Interesting code.

Project Sunshine / AIS v23 Updates

[09:44-14:41]

Nyx Linden
Nyx Linden

Nyx Linden reports that the Sunshine / AIS v3 updates are going “really well”, and the Lab is focused on cleaning up the last few bugs of which they are aware, and it is hoped that the code will be ready for QA and then a project viewer soon, possibly prior to the December no change window coming into force.  If the viewer does make it to a project release prior to that happening, Nyx will likely hold it over until early January.

In the meantime, the Lab is still keen to get started on more extensive load testing for the new inventory service, AIS v3, using the Sunshinetest regions (1-4) on Aditi. They’d preferably like the assistance of TPVs with this, the latter having been given access to the code a couple of weeks ago so that they could start work merging it into test versions of their viewers for this purpose.

Firestorm released a version of their viewer with the new Sunshine / AIS v3 code updates to their Beta testers in week 47, although this has yet to have the legacy baking code added back into it for the OpenSim version of Firestorm.  The team is approaching this cautiously, as there is a need to try to isolate the code used in the legacy avatar baking process (which is still used on OpenSim) so that it does not interfere with / get altered by future merges with code from Linden Lab. Once this has been done, Firestorm plan to make the code available to other TPVs so that they do not have the same headache  when faced with trying to reintegrate the legacy baking code into their viewers.

Both Firestorm and Kokua (the latter having integrated the Sunshine / AIS v3 changes into a test viewer at the start of November) have indicated they are now in a position to assist with any load tests. The hope is that this will take place during December.

One of the reasons the Lab is keen to get the load testing underway is so that any remaining issues with the server-side code can be identified, investigated and fixed prior to the code being deployed on any RCs on the main grid. Any initial deployment of the server code on the main grid would likely be handled “pretty quietly”, simply because it wouldn’t be exposed to any viewers that did not have the necessary updates.

HTTP Updates

[14:41-22:12]

Monty Linden
Monty Linden

“It is currently still in QA,” Monty Linden reported in reference to his current work with HTTP 1.1 changes within the viewer. while no bugs have so far been found with the new code itself, he did reveal that the work has uncovered “quite a few bugs in mesh in general”, which are being filed internally. Currently, it is predicated that the QA round is unlikely to finish before Tuesday December 3rd, so and project viewer will not be appearing until after that date.

In addition to QA testing not finding any bugs within Monty’s code, all the numbers coming out of the performance aspects of the testing are described as “equal or better than past history”.

In the interim, Monty is continuing to lay the foundations for HTTP pipelining. As indicated in my last update on his work,  he’s been going through the third-party libraries and their repositories which are used in the viewer builds and updating them. This has led him into a number of “interesting” discoveries  as a result of tracking through all of the repository dependencies, etc., and identifying the various package mismatches and unnecessary libraries which are being packaged with the viewer (noticeably in the Linux version of the viewer), as well as one or two libraries which are not being packaged when they should be, as well as the use of multiple versions of the same library (e.g. 3 different version of Boost, 3 or 4 different versions of zlib, etc.).

Continue reading “SL projects update week 47 (3): viewer, Sunshine / AIS v3, HTTP and more” →

SL projects update week 47 (2): server, viewer, general items

Posted on by Inara Pey

Server Deployments week 47 recap

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

  • Tuesday November 19th: the Main channel received the maintenance package previously deployed to BlueSteel and LeTigre in week 46. This package comprises further infrastructure changes for the yet-to-be-announced Experience Keys (experience tools) project
  • Wednesday November 20th:
    • Magnum remained on the same maintenance project as deployed to it in week 47, but which features a further update to the grey goo fence, now only applies to objects which are both large and physical. This alteration is in response to BUG-4448, wherein it was reported that building rezzers were running up against the fence when attempting to rez complex builds
    • BlueSteel and leTigre received a new maintenance package comprising those changes deployed to Magnum in week 46, with additional bug fixes.
Server Beta Meeting (stock)
Server Beta Meeting (stock)

Notes on the Deployments

Commenting on the BlueSteel / LeTigre updates during the Server Beta meeting on Thursday November 21st, Maestro Linden underlined the last four bug fixes listed in the release notes, together with the final “new feature” item, as being newly introduced with the deployment.

With regards to the BlueSteel  / LeTigre fix for  “Vehicles containing a mesh are returned to the owner upon region crossing when destination parcel is full”, he added, “I believe the issues with region crossing on vehicles due to ‘parcel full’ should be fixed, though there’s still that bug about certain vehicles sometimes going crazy upon region crossing.”

A question was asked if the change to the grey goo fence (BUG-4448) might impact llGiveInventory object-to-object transfers. Apparently there were reports n the Advanced Scripters of Second Life that people were encountering a “give inventory failure: grey goo fence: rapid or recursive inventory transfer” warning on Magnum regions following the update.

Commenting on this, Maestro Linden said, “I checked with Simon about this one; the GGF change should only affect rezzing of objects; when you simply pass items around with llGiveInvenotry(), the object geometry data hasn’t been loaded, so it wouldn’t have the opportunity to apply a penalty. However, he thinks that if you hit the GGF for rezzing objects , the GGF may also prevent llGiveInventory() from operating.”

Maestro also indicated that new restart scripts were using during the RC deployment which displayed the restart messages in “big, bold letters”. Whether these changes are in addition to the restart message changes made by Simon Linden and deployed in September is unclear; Maestro also referenced the fact that restarts will now occur as soon as the last avatar departs a region, rather than waiting for the countdown to complete, and this was a change initially deployed in September.

Week 48 (Week Commencing Monday November 25th)

A reminder that there are no deployments / rolling restarts planned for week 48 due to it being Thanksgiving week in the United States (which also means the Server Beta meeting will not be taking place.

SL Viewer

The SL release viewer was updated on Thursday November 21st to version 3.6.11.283787 (dated November 15)  – formerly the GPU table updates RC. This release contained no functional changes to the viewer, but saw support added for the following GPU families:  newer nVidia GTX 700 series; AMD R7/R9; Intel Iris Pro  (download page, release notes).

Fitted Mesh Project Viewer

RedPoly
Redpoly Inventor, who first looked into the use of custom bones for mesh garment deformation in SL

Thursday November 21st also saw the release of the Fitted Mesh project viewer 3.6.11.283899. This viewer includes a new avatar skeleton with additional collision bones which allow mesh garments rigged to the collision bone structure to adjust with changes to an avatar’s shape using the Edit Shape sliders.

The system is modelled at the approach first mooted during the Closed Mesh Beta and later prototyped by RedPoly Inventor, and which has been subsequently employed in approaches such as Redgrave’s “Liquid Mesh” range of garments.

The official blog post on the release can be read here, and I was fortunate enough to be given preview access to the viewer a little ahead of the launch, and my own overview is also available.

This approach to fitting mesh garments is still at a project status, and those trying it are requested to file any issues they have via a JIRA to the Fitted Mesh project.

Other Items

Copying Large Numbers of Items to the Inventory of an Object

Many people are likely to be familiar with this issue: select  a large number of items from inventory and attempt to drop them into the contents of a prim in a single go, and part / all of the process may fail. This is a long-standing problem, and there had been something of a limit of around 42 items which could be successfully transferred into an object’s contents in a single go. However, there have apparently been renewed reports of problems, and a suggestion that the threshold for moving a large number of objects in a single go may now be around the 30 mark. Maestro Linden has updated a bug report from Dan Linden on the issue with this information in the hope it will assist in narrowing-down the possible cause.

Aircraft Region Crossing Issues

Yuzuru Jewell reported further issues with some aircraft encountering problems on attempting to cross regions. It takes the form of aircraft using mono scripts with collision detection  are failing to cross region boundaries. A similar bug has been reported for mesh vehicles – BUG-4084 is “Mesh car starts to bounce like pinball after sim crossing”, but the Lab has been having problems reproducing that issue.  One workaround that seems to prevent the problem is for the collision event to be moved to a separate script compiled as LSL2 rather than mono.

In the discussion Maestro noted this approach had also been put forward in dealing with BUG-4084, except that in that case, all scripts were being compiled as LSL2, possibly because the issue hadn’t been identified as perhaps being with collision event handlers. Maestro believes the pointer towards collision events may well  be an interesting lead and has requested that anyone able to reproduce the issue and show that specific events / functions are responsible, it will obviously make it easier to determine a resolution.

CtrlAltStudio gains Kinect support and is adapted for use by a university

Posted on by Inara Pey

CAS-logoDave Rowe contacted me earlier in the week to let me know that he’s updated his CtrlAltStudio viewer with both a variable walk speed and support for Kinect for Windows.

Commenting on the updates, which can be found in CtrlAltStudio release Alpha 5 1.1.0.34376 (Windows only), Dave explains:

In the time-honoured tradition of making things do that which they weren’t quite designed for, I’ve added a variable walking speed to the CtrlAltStudio Viewer, Alpha 5 1.1.0.34376. I’ve also added “spot standing” Kinect control of avatar movement for people to try out. These two items can be used with all display modes: normal, stereoscopic 3D, and Oculus Rift.

The variable walk speed came about as a result of some issues when walking / flying in-world when using the Rift, and Dave was pointed in the direction of a possible solution after reading a Firestorm JIRA raised by Adeon Writer requesting that the ability to more easily toggle between “full” and “quarter” speed movement when walking, running or crouching than solely by pressing and holding the spacebar.

Dave notes that his solution, which employs a slider in the Movement sub-tab of Preferences > Move and View, may not be ideal at present, and only affects avatar walking speeds.  He also notes it may not work properly on OpenSim Grids or with the SpaceNavigator (at least at present in the case of the latter).

The new variable walk speed slider and the Kinect options in CtrlAltStudio Alpha 5
The new variable walk speed slider and the Kinect options in CtrlAltStudio Alpha 5

In all the slider has five presets, from “slow” (left) to “normal” (right). When using the viewer, I found that with the mid-point “half speed” and the preset between it and “normal”, my avatar (on an uncrowded region) moved forward reasonably well and was relatively responsive when turning as I walked. Walking backwards was also OK, although if you enable the option to turn your avatar around when walking “backwards”, you may find your avatar’s movement becomes jerky and it constantly tries to turn and put its back to you; something which becomes more pronounced at the lower settings.

I found the “slow” setting to be somewhat akin to being caught in a heavy lag situation, but without any accompanying rubber-banding or sudden speed-ups with walking; my avatar moved very slowly and was subject to intermittent pauses and froze on a couple of occasions, requiring me to adjust the slider more to the right.

While this may not sound promising, do remember that this is only the first cut at the work on Dave’s part.

Kinect Gesture Support

As well as the variable walking speed, Dave has also added gesture support for the viewer, which can be used via the Microsoft Kinect system.  The supported gestures allow you to set your avatar walking, stop it, turn it around and fly up and down or stop gesture-driven control. He’s produced a set of easy-to-understand drawings of the gestures for each, and notes that you can also stop gesture-driven motion by walking out of the Kinect’s sensor range, and also fly down by crouching.

Kinect gestures (image courtesy of Dave Rowe)

In discussing the use of the variable walk slider and the Kinect options, Dave notes:

The variable walk speed improves the usability of Kinect “spot standing” control, usable in Windows builds on PCs with Kinect for Windows sensors installed. You set a “home” position of zero movement, then once you move out of a dead zone around that position your avatar starts moving in the direction you’ve moved in. Avatar movement starts off slow and increases speed as you move further out, with the maximum being that of the walk speed you’ve configured. Except that for forwards movement you start running after the maximum walk speed.

Even if you don’t have either active stereoscopic glasses or an Oculus Rift headset, but you do have a Kinect system (with Runtime or Software Development Kit installed on your PC), you can still use the Alpha 5 version of CtrlAltStudio to try both the variable speed walk and the gesture controls out – just leave both the Stereoscopic and Oculus options disabled. Note you do not have to have Kinect in order to try-out the variable speed walking.

A further change with this release is the inclusion of a Prediction Delta slider with the Oculus Rift options.  Again, as Dave notes in his blog:

Sensor prediction helps reduce latency and you can configure how far into the future your orientation is predicted. With your Rift on, adjust the Prediction Delta value until moving your head feels most comfortable.

predict
the new Prediction Delta slider in the Oculus Rift section of the Display Output sub-tab for helping to reduce latency and configuring how far into the future your orientation is predicted for a more natural head movement when using the Rift.

You can find out about these , and the other updates within the Alpha 5 version of CtrlAltStudio via the release notes.

CtrlAltStudio Adopted and Adapted by St. Andrew’s University

Dave’s work on CtrlAltStudio has not gone unnoticed. None other than St. Andrews University in Scotland have adopted and adapted it as a part of their own work to create a new viewer they’ve called ACE.

Faculty members and students at the university have been using virtual environments for historical reconstructions as a part of their Open Virtual Worlds project for some time now, running their own dedicated OpenSim grid (which is hypergrid enabled, or people can access by creating a log-in account).

Project members have now taken Dave’s work with CtrlAltStudio viewer and combined it with their own Kinect bindings created as a part of their Chimera project in order to produce their own ACE (Armadillo Control Extensions) viewer. This can be used to explore and experience their in-world reconstructions using Oculus Rift and without the need for any physical device to assist them.

The ACE viewer also requires the installation of the Kinect Runtime or SDK to be installed on the host computer in order to work, but once these and the viewer are installed, it can be used to connect to any grid (OpenSim or SL).

A blog post on the ACE viewer is available on the Open Virtual Worlds blog, as is a video demonstrating it in use.

Related Links

CtrlAltStudio

Open Virtual Worlds Project

Kinect Runtime & SDK (required for Kinect use)