Category: SL Tech

CHUI: no, not a Wookie, a viewer from LL – with feedback requested

Posted on by Inara Pey

Linden Lab have launched, somewhat unexpectedly, a new project viewer, called CHUI. While sounding like a character from Star Wars (CHU-EE, geddit? *Ahem*. Sorry), it stands for Communications Hub User Interface. The blog post states:

With so many ways for users to communicate with one another in Second Life, there are quite a few communications tools in the Viewer. To make it easier to find, learn and use these tools, today we released a project Viewer that introduces CHUI (Communications Hub User Interface). In addition to bringing most of these communications tools “under one roof,” CHUI also introduces some new and improved features.

Among the listed features are:

  • The Conversation Log: providing you have enabled the option to save chat and IM logs to your computer, this allows you to open the entire history of a conversation with another user held in the past 30 days directly in your viewer, or review off-line IMs received from both friends and non-friends
  • Expanded conference calls: with CHUI it is possible to add people to a conference call after it’s started, or add someone to an existing one-on-one IM session
  • The ability to easily move your voice connection between open conversations including nearby chat, private IM, conference chat or group chat. Click the “add voice” button on any conversation to move your voice connection to that conversation. Click the “hang up” button and your voice connection is returned to nearby chat.
  • The ability to access chat preferences in a single click from the Conversation window
  • Change the volume of a single person’s voice by simply clicking on that person’s speaking icon in the Conversations window
  • A multi-line chat entry box which expands as you type.
CHUI Conversation Log

These features primarily found in two floaters: Conversations Log and a revised Conversations floater. The Conversations Log window lists all recent and past conversations, allowing them to be to scrolled through and opened for reading. As I’ve only jut started using the project viewer, I’ve actually not investigated this in-depth. Clicking on a listed conversation will open in the Conversations floater, and the Conversation Log contains two buttons for sorting the listed conversations (by name, by date, etc.), and a gear cog button for access various options – start an IM, enter a voice call, view profile, etc., for a selected conversation in the list.

For those who use TPVs with tabbed IM capabilities, the revised Conversations floater will look remarkably familiar,  bringing as it does local chat and all IM conversations into a single floater panel. Any conversations in the Conversation Loge will also open here as well.

The Conversations floater

The panel includes a number of buttons. These again allow conversation to be sorted, closed individually, etc., and also include a number of additional options:

Add someone else to an existing IM conversation, and establish a conference call. This will open the Choose Resident Floater, allowing you to pick a friend, someone nearby or search for someone.

Start a Voice conversation with a person or hang-up from a Voice conversation (the icon will change on the button, depending on the status of the call)

Open the Choose Resident floater to select someone with whom to start an IM or Voice conversation.

Break-out any conversation into its own floater.

The Conversations floater can also be compacted down into one of three sizes, using the left / right double chevron arrows. These help reduce the amount of space the floater takes up on your screen when not actively in use. It can be expanded either using these buttons or using the right-pointing arrows next to the names in the conversations list.

The three compact views of the Conversations floater

Overall, this is a significant attempt to centralise in-world communications, and there are some nice features here, particularly in the extended Voice options.

For Linden Lab, this is very much experimental, as noted in the blog post itself, and they are asking for people’s feedback on the features:

We’ve been testing CHUI inside Linden Lab for some time, but any major redesign requires a lot of people using it to make it as smooth and useful as it can be. This is where you come in.

Please think about these questions as you use the CHUI project viewer:

  • Are the new features useful?
  • Do the functions you commonly use seem more streamlined, or do they require more clicks than before?
  • Are all of the functions, both old and new, easy to find?

We’ll ask you to complete a survey in approximately one week to gather your thoughts on these questions.

There is a publicly accessible JIRA (https://jira.secondlife.com/browse/chuibug) available for the viewer, and if you do try it out and find a bug, LL request you report it there.

Also tucked away in the blog post is news that blocked users and objects can now be viewed from within the People floater, rather than via a separate menu option, and can also be unblocked from here via the right-click context menu.

Related Links

Viewer release summary 2012: week 42

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 Viewer Round-up Page, a list of  all Second Life viewers and clients that are in popular use (and of which I am aware) and which are recognised as adhering to the TPV Policy
  • By its nature, this summary will always be in arrears
  • The Viewer Round-up 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 as the week progresses
  • The Viewer Round-up 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: 21 October, 2012

  • SL Viewer updates:
      • Beta version rolled to 3.4.1.265898, October 16 (release notes)
      • Development version rolled to 3.4.2.266075 on October 19
      • The Mesh deformer project viewer rolled to 3.4.1.266081 on October 20
  • Kokua Beta released 3.4.0.0 (Pathfinding) October 15 – core updates: pathfinding tools
  • Niran’s viewer rolled to 2.0.2136 on October 18th – core updates: updates to top windlight toolbar buttons and to new Preferences overlay
  • Cool VL updates:
    • Stable branch jumped to 1.26.4.35 on October 21 – core updates: media plugin code to match the latest v3.4 viewer-development; backport of latest bug fixes from v3.4 viewer-development; further work on MOAP backport (which remains disabled as work progresses); implemented the new LL HTTP engine (currently disabled); added script editor support for new LSL functions and constants implemented in the latest LeTigre RC channel deploy; assorted fixes and clean-ups
    • Experimental branch jumped to 1.26.5.15 also on October 21 – core updates: Backported a v3.4-renderer-specific fix from viewer-development v3.4; implemented & enabled the new LL HTTP engine
    • Release notes
  • Lumiya release version 2.3.2 on October 20 – core updates:avatar name tags in 3D view; configurable avatar rendering limit; ability to touch attached objects; object menus displays as pop-up dialogue boxes in 3D world view; ability to view textures from inventory; support for subfolders in My Outfits. (release notes) – latest review in this blog
  • Libretto – removed from round-up page due to website being unavailable for a month and no response from creator on status (also removed from the SL Third-party Viewer Directory)

Related Links

Lumiya 2.3.2: tagging avatars, limiting their rendering, and wearing your outfits

Posted on by Inara Pey

Alina Lyvette has again been beavering away with Lumiya, adding features, fixing bugs and sorting a couple of things out. In this, I feel a little guilty, as one of the things she’s been sorting out is the Outfits folder. I mentioned last time around that there was a slight hitch with it, and Alina immediately started work correcting it, when really she should have been taking a break.

The result is yet another release for Lumiya, this one 2.3.2, which features the following key updates:

  • Avatar tags in 3D view
  • Object dialogs are now displayed as pop-ups
  • Ability to touch attached objects
  • Ability to view textures from inventory
  • Support for subfolders in My Outfits
  • Configurable avatar rendering limit

Avatar Tags in 3D View

Tagged!

This does exactly what it says on the label: displays the name tag over an avatar’s head, using either the avatar’s display name or legacy name.

Group names  are currently not displayed and frankly, when using Lumiya on a small screen, they’re something I can personally get by without; although I suspect Alina is working on adding them!

Note that there is an option on the Settings menu to display either legacy avatar names user names) or Display Names. This will determine whether Display Names or user names are displayed in the 3D world view as well as in chat, etc. Toggling between the two options will immediately switch between displaying other avatars’ user name or Display Names in chat and IM, but may require a re-log in order for the 3D world view to update correctly.

Object Dialogue Pop-ups

Until now, touching a scripted object in the in-world view and handling the menu was a bit of a convoluted affair: touch the object, switch to chat to see the menu, use the menu, swap back to the 3D view.

Well, no more. Touch an object and you’ll get an initial menu, complete with a TOUCH button. Tap that, and the menu for the object will overlay the in-world view, which you can used exactly as you would in a full viewer.

Touching Attachments

Lumiya 2.3.2 brings a new means of touching worn scripted attachments.

To touch one of your own scripted attachments:

  • In the 3D view open the Outfits window (hanger icon)  – note that the text mode shortcut for attachments is no longer available from 2.3.2.
  • Switch to the WEARING tab in the Outfits window (if using Lumiya on a small screen, you may have to tap “My Outfits” to display a menu which will allow you to switch to a list of worn items)
  • Scroll through the list of worn items to the one you wish to touch – it will have a TOUCH button associated with it. Tap this to display the menu
  • When you have finished with the menu, tap the Back button on your device to clear the menu dialogue box.
Touching a scripted attachment on your own avatar

If you wish to touch an attachment worn by another avatar, you can do so in one of two ways: via the 3D world view or via text mode.

In the 3D world view:

  • Long touch the avatar wearing the attachment – aim for the middle of the avatar, not the attachment itself
  • A menu is displayed at the top of the screen, which includes a TOUCH button if the avatar is wearing anything touchable. Tap this to display a list of touchable items the avatar is wearing
  • Tap an item on the list; if it is publicly accessible (or if you’ve been granted access to the attachment by the user), any menu associated with the object should be displayed
  • When you have finished with the menu, tap the Back button on your device to clear the menu dialogue box.

Continue reading “Lumiya 2.3.2: tagging avatars, limiting their rendering, and wearing your outfits” →

SL project news: week 42 / 3 – server news

Posted on by Inara Pey

There is a lot going-on server-wise at the moment, so best to break it down by heading.

Server Rebalancing

The Lab is currently engaged in a rebalancing exercise in an attempt to put neighbouring regions on the same server and generally do a logical organizing of the grid to help improve various aspects of performance. Speaking at the Server Beta User Group on Thursday 18th October, Oskar Linden explained that there has been a lot of moving around (in terms of regions) within and between the Lab’s co-location facilities, and so the re-balancing is warranted and needed.

This work takes time – a rebalancing operation earlier this year took around 6 weeks to complete. It requires that regions are organized into groups and then generally moved twice: the first time to a temporary sever, the second to the target machine, each move requiring a reboot, so people may notice additional and unexpected restarts to regions they are in as the work progresses. Two moves are required because the server topology is so tight, it often isn’t possible to move regions directly from one server to a target server, so an intermediary is required.

While this work will take time to complete, the result should be improvements in stability and performance with the likes of teleports, etc, and even improved region crossings.

More on the Server Deployments for Week 42

  • Main channel: Oskar provided some more information on the main channel update of Tuesday 16th October, saying, “The main channel got a tweak this week, but it was a really small change, and no sim code got changed. We recognised that we had some inefficient SQL queries where large groups were concerned, so we optimised them, and the effect was quite noticeable. The databases are more responsive [and] this helps at all levels.” He went on to clarify that these changes were not Baker Linden’s Group Services code changes, after some in the meeting appeared to think this might have been the case
  • BlueSteel received the updates which were tested in the network pile-on test in week 42. At the time, I commented that teleporting seemed a lot faster, but that might have been a placebo effect of being on Aditi. It was. Commenting on the test, Oskar said, “There were no simulator changes in that test code. We were just testing backend tweaks.”
  • Magnum received no update per se, as previously reported, but was merged with trunk and then redeployed
  • LeTigre received the biggest update, which included new LSL functions ad updates, and most importantly of all, a new version of Havok (see below). Of the LSL functions, Maestro had a warning about the new OBJECT_PATHFINDING_TYPE parameter in the pathfinding command llGetObjectDetails, “We misspelled a constant, OPT_UNKNOWN, so we plan to fix that.” The fix will probably be next week.

Havok

As mentioned above, Havok on LeTigre was updated to version 2012.1. The update enables Havok’s built-in terrain optimisation and should lead to improved performance as a result of the physics shape of the terrain being simplified. Prior to the deployment, there were concerns that it would lead to issues with mesh vehicles trying to cross between regions running different version fo Havok, as has previously been the case.

As reported in part one of this update, these concerns led to Andrew Linden contacting the deployment team in LL to check whether it would be possible to ensure none of the Blake Sea regions remained on LeTigre while two versions of Havok running on the grid to help alleviate at least some of the pain people would feel when using mesh vehicles there. This apparently happened, whether it was before or after the deployment is unclear, as some people did report issues following the roll-out. There was also a little confusion as to what had been swapped where.

At the Server Beta meeting, Oskar gave the impression that all Blake Sea regions were on LeTigre. However, at the Simulator User Group meeting on Friday 19th October, Andrew Linden indicated that records showed none of the Blake Sea regions are running on LeTigre, although they are spread across the other channels. Given that there were (according to Andrew) around six Blake Sea regions running on LeTigre to start with, it would appear to make sense that they have been rotated off to another channel, rather than attempting to rotate all of Blake Sea on to LeTigre.

Please use the page numbers below left to continue reading this article

Pages: 1 2

SL project news: week 42 / 2: viewer, mesh, shining and more

Posted on by Inara Pey

SL Viewer

After hopes that the latest beta version of the viewer would prove stable enough for things to start flowing again, it turns out that its crash rate is hovering around the 14% mark, with Oz reporting that a substantial portion of the crashes, which still appear to be related to memory problems, occurring as users exit the viewer. While these may go unnoticed by users, LL still want to bring the rate down to something closer to the release viewer (which is currently 10%).

As such, further candidate version of the beta viewer is being built, which should be released on Monday 22nd October with the hope that the changes being made will do just that. However, it is fair to say that the level of optimism within the Lab that this will be the case is currently low. Until the problem is resolved, further releases of code for projects are likely to remain blocked.

This issue is now the primary delay in moving a number of projects forward, including the Baker Linden’s Group Service project, Monty Linden’s HTTP texture project, updates for the Steam link-up and a host of other internal and contributed elements.

Mesh Deformer

A revised version of Darien Caldwell’s proposed addition for arbitrary shapes in the mesh uploader for us with the deformer

Darien Caldwell has been continuing to work on getting the deformer to work with arbitrary human shapes, and has some success. She has also ben working to refine the new options on the mesh uploader to cater for custom shapes, indenting the options to make it clear that they are a part of the Deform to Avatar Shape check box item (see right). Also, and while awaiting feedback from LL, she has moved the option to export an avatar shape as an XML file from a sub-menu on the Develop Menu (DEVELOP -> AVATAR -> APPEARANCE TO XML) to the Advanced Menu on her version of the Mesh Deformer project viewer.

However, as she comments on the JIRA (STORM-1716) for the deformer, there is also a problem.

Essentially, there are certain sliders (eleven in all) associated with armature bone length, which already deform mesh without using the deformer (see her JIRA comment for the full list of sliders). When these are adjusted to create a custom shape for making mesh items, problems arise because they are then deformed by both the viewer and the deformer, leading to odd results under certain situations.

The issue appears most pronounced when working on individual body elements, such as the upper body (as defined by SL) when using a custom shape (such as when creating a jacket). However, in a “full body” mesh, the problem is somewhat less pronounced.

Deformation issue: on the left, an “upper body” flesh-tome mesh (analogous to, say, a jacket) built to a custom shape is worn on that custom shape (in black). Note the mis-match. On the right, the same mesh, but combined with lower body elements applied to the same custom avatar shape. A much closer fit

As the sliders are placed closer to their default values, the issues become less and less pronounced. Darien had suspected this might be an issue, but until she started working with shapes other than the default, she had no way of determining if a problem existed. She has also a nagging concern that a small adjustment made to the deformer code itself might be having an unforeseen impact. However, from his own understanding as to how the deformer works and when discussing the matter at a delayed OpenDev meeting on Thursday 18th October, Oz Linden agreed this was unlikely to be the case.

When using custom shapes with the “problem” armatures set closer to their defaults, the problem is still present in “upper body” meshes (l) but is somewhat less pronounced, and again is barely noticeable on a “full body” mesh (r)

Currently, and assuming I’m understanding the matter correctly, the “fix” for this problem seems to be to define a custom avatar shape in SL, then adjust the eleven “problem” sliders to their default values prior to exporting the shape data to an XML file which is used shape to create the required mesh items (body, clothing). Once the finished items has been uploaded to SL, it can be worn with the shape and the desired settings for the eleven affected sliders can then be restored with the result that the mesh should deform as expected.

Darien will be carrying out further tests on the issue prior to offering her version of the deformer for wider use.

HTTP Libraries

As a result of beta viewer issues, it’ll be a while before everyone benefits from faster texture rezzing – but work continues on related services

While the viewer side of the new texture fetch library is blocked from going further than a project viewer at the moment, Monty Linden has resumed work on the server-side of things. Commenting on this at the TPV/Dev meeting on Friday 19th October, Monty had this to say, “I’ve been working on server-side work … and as part of the next part of the HTTP work, there will be a server change, grid change. sim OS change. And I just want to let everyone know that at some point we’re going to have to put up some beta servers on the beta grid and start some testing … It will be an interesting change to the services.”

This work is related to the number of connection an agent can have open to a given service – essentially the development of a “fairness policy” with regards to service connections. The changes and the policy itself are liable to be fairly dynamic as they come into effect and LL monitor use and potential abuse and start to focus down on ensuring a reasonable balance is met. This will require extensive testing from TPVs to ensure their viewers are handling the new services correctly, whether they can operate within the policy in terms of number of retries or back-offs on a failed connection, etc., and whether they need to limit the number of connections users can manually open (where this is the case).

Other Bits

Viewer and FMOD

No major news on this since reporting it in week 41. It is still LL’s intention to do something about it, however no resource has been allocated to it as yet  – with emphasis on the “yet” from Oz Linden. One of the hold-ups here is (again) the ongoing problems with the beta viewer, which require resources and effort to resolve.

Mountain Lion Support

The the TPV/Dev meeting on Friday 19th October, Oz reported that the Lab were making “great strides” on updating their Mac support for OSX 10.8 Mountain Lion, including gatekeeper support, and that the information should be available “quite shortly”.

64-bit Builds of the Official Viewer

The subject of 64-bit one that frequently arises in relation to the official viewer, particularly when mentions is made of memory leaks and the like, and it comes up not only among users. Remarking on it in the TPV/Dev meeting, Oz Linden said, “It is a bullet we have not yet decided to bite, but at some point we’re going to have to.”

He went on to point out that LL are already approaching a point where they’ll have to build OSX versions of the viewer in both 32-, and 64-bit, and that, “At some point the cost/benefit will tip the other way.” As such, he stated that any help LL can get from TPV developers in getting the code “64-bit clean”, etc., would be welcomed. In the meantime LAA support for the viewer has been merged into the development viewer (viewer dev) and is locked behind the current issues with the beta viewer.

Firestorm: SL, MOSES, OpenSim and the future

Posted on by Inara Pey

firestorm-logoLogging-on to SL today, I notice from the Firestorm MOTD that Jessica Lyon brings word on Firestorm and what is going on with SL’s most stable and most popular viewer – and the viewer of choice for many OpenSim grids.

The team has been hard at work on the viewer while LL have been busy sorting out stability and crash issues on their own beta. As Jessica comment in her blog post, one of the reasons Firestorm is on a long release cycle is that until now, she has preferred to see the viewer go out with significant updates which users will want to have / see (both new capabilities and bug fixes), rather than pushing out much smaller, more incremental releases which might get on people’s nerves the their frequency. The next release will be no different in that regard, with a range of further fixes and well as a host of new features, including William Weaver’s marvellous Phototools, which I simply adore. William (Paperworks Resident in SL) has been working closely with Firestorm developer Ansariel Hiller to get the tools integrated into Firestorm. I’ve been able to use the integrated version ahead of the release, and love the work both Ansariel and William have put in on this.

Phototools, fully integrated into Firestorm in the next release, allows stunning images to be produced from within the viewer without necessarily relying on external processing through PhotoShop, etc. (image courtesy of William Weaver)

However, in the future, it seems things will be changing, as Jessica states:

We plan to make that updating process easier for you by setting up seamless behind-the-scenes updates you will hardly even notice, allowing us to provide more frequent updates and even hotfixes to improve your experience faster!

This sounds like the team will be implementing an automatic update process similar to that used by LL to update the official viewer. It will be interesting to see how this is implemented and how people respond to it. While it is likely most people won’t mind  / will welcome the move, some may prefer to keep the option turned off (if possible) so they can track what changes are being made to their viewer installation.

MOSES: collaboration with Firestorm

An intriguing part – for me at least – of Jessica’s news is that the team are liable to be working with Doug Maxwell and his MOSES team.

This is interesting for me as I covered MOSES last year in an article in this blog, and also covered a major upgrade to the platform after meeting Doug at a presentation he gave on the project. He’s looking to enhance OpenSim security for the MOSES grid, and it appears he’ll be working with the Firestorm team on security aspects affecting the viewer, which will in turn be fed back into the OpenSim community.

In terms of direct OpenSim support, Jessica has this to say:

While Second Life still remains the primary focus of our development efforts, we have begun working towards bringing Firestorm Viewer into better compatibility with the OpenSim Platform. It is important to point out where the extent of that effort ends, though. We are making Firestorm work better on the “base” OpenSim Platform, but we cannot fix problems that arise on specific OpenSim grids because of changes those particular grids have made to their OpenSim code. For those issues to be fixed, we will rely on those grids to provide us code contributions to address those issues.

This is a pragmatic and sensible approach and typifies the considered manner in which Jessica approaches projects.

To help support the OpenSim effort, Firestom had two regions on OSgrid donated to them for their use, one of which has been outfitted to serve as Firestorm’s OSgrid headquarters and which has been named, somewhat appropriately, Firestorm Island. Directions for visiting it can be found in Jessica’s post.

All-in-all, an interesting update.