Month: July 2012

Singularity 1.7.0

Posted on by Inara Pey

July 16th marked a new Singularity release with a number of updates and new features, namely:

  • Support for multiple clothing layers
  • Region Windlight support
  • New build preferences
  • A new audio display floater
  • Mouselook aiming
  • RLVa 1.4 update
  • Shift-C crouch toggle
  • LSL editor update, including external editor support
  • Radar now indicates gesture/sound/particle/animation spam
  • Sound bugs fixed.

The following is an overview of the key changes to the viewer, and is not intended as an in-depth review.

Download and Install

The Windows installer is some 23.8Mb in size; it is recommended that any prior versions of Singularity are removed prior to installing 1.7.0. The viewer installed smoothly, and did not throw any false-flag anti-virus warnings for me (I use AVG anti-virus)..

Once logged in, inventory download was fast in comparison to V3-based viewers.Granted, I keep my inventory fairly tight and tidy (anything not in regular use gets packed away – particularly COPY items), but by the time I’d rezzed (itself only a handful of seconds), my inventory had loaded; this seemed a lot faster than with other viewers of late.

Multi-wear

The ability to wear multiple items on the same layer of system clothing is now pretty much a staple part of most viewers. However, Singularity stands apart from the rest in it’s offering by not only being compatible with the LL multi-wear code, but in also providing a very useful enhancement.

In most viewers providing multi-wear capabilities, adding an item of clothing to the same layer as an item already being worn will currently see the additional item appear to be worn “over” the existing item (i.e. if you are wearing a shirt layer item, any shirt layer item added to your outfit will appear to be worn “over” the item already being worn).

Singularity, however, provides two additional inventory menu options: Move Forward and Move Back, which allow you to change the order in which clothing items worn in the same layer are “stacked”, allowing them to appear to be worn under / over one another, as shown in the images below.

Multi-wear in most viewers: adding an item (in this case a shirt layer bustier) to a layer with clothing already worn will see the new item worn “over” any clothing on the same layer
Singularity’s Move Back and Move Forward inventory options allow the order of clothing items worn on the same layer to be changed relative to one another

Notes:

  • The menu options are context sensitive and will only be available for clothing items worn on the same layer
  • Which of the options is available for use depends on a clothing item’s position in the “stack” (e.g. if the item is the last item added to a layer, the Move Back option only will initially be enabled, but not the Move Forward option)
  • The options can be used with any number of items worn on a single layer (up to the standard maximum of 5 items per layer)
  • Any changes you make to the order of clothing items in the same layer will be correctly rendered in other viewers.

This should provide a very flexible way of additionally creating “mix’n’match” outfits. Kudos!

Along side of multi wear, Singularity 1.7.0 also provide full support of the Current Outfit folder as well.

Audio Display Floater

Accessed via the Singularity menu (Singularity->Streaming Audio Display), this displays a floater listing the artist and track name for any active media.

Audio display floater

Mouselook Aim / Zoom and Shift-C Crouch

Those into combat are likely to appreciate these additions – although they are not exclusively for such environments.

  • Mouselook aim / zoom: when in Mouselook, depressing the right mouse button and using the scroll wheel on a mouse, can zoom in / out of the direction you are looking
  • Pressing SHIFT-C will now toggle your avatar into a crouch until such time as you press SHIFT-C again, allowing you to move and do other things without having to hold down the C key yourself.

Build Preferences

The Build tab in PREFERENCES->SYSTEM has been extensively updated, as per the images below, offering users the ability to set global defaults on prims as they are rezzed and used (i.e. default texture type, permissions set against them, etc).

New Build Preferences

Performance

Running Singularity on my home platform (370m) with lighting and shadows off, Singularity rolled along at an average of 39-40 fps. With lighting & shadows active and sun/moon + projectors enabled, this dropped to 12-13 fps. On the ground on my home sim, these rates dropped to 7-8 fps with lighting and shadows, etc., on and around 17-18 fps with them off. Again, and while totally arbitrary, the tests were carried out on my usual system and with all other settings as defined in the panel on the right of this blog’s home page. Overall, the performance wasn’t far behind what I’ve seen on the new home sim with recent V3.2 viewers.

Opinion

As with the last release of Singularity (1.6.0), this is a long-awaited and tidy update. Feature changes may appear small – but they are by not means trivial. Much has been done to “future-proof” the viewer, although the Merchant Outbox functionality is still currently lacking.

What I particularly like in this release is the way in which multi-layer system clothing support has been implemented. The ability to alter the order of the clothing on a specific layer is very neat and a step ahead of other viewers – and is something that could prove very popular among users. It will be interesting to see if it appears in other TPVs moving forward.

For credits on the various elements and additions to this release of Singularity, please refer to the release notes (link below).

Related Links

Viewer release summary 2012: week 28

Posted on by Inara Pey

The following is summary of changes to SL viewers / clients (official and TPV) which have taken place in the past week. It is based on my Viewer Round-up Page, which provides 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 being in adherence with the TPV Policy.

This summary is published every Monday, and by its nature will always be in arrears. Therefore, for the most up-to-date information on viewers and clients, please see my Viewer Round-up Page, which is updated as soon as I’m aware of any changes, and which includes comprehensive links to download pages, blog notes, release notes, etc., for Viewers and clients as well as links to any / all reviews of specific viewers / clients made within this blog.  

Updates for the week ending: 15 July, 2012

  • SL Viewer updates:
    • Beta version: rolled 3.3.4.261355, July 10
    • Development: rolled to 3.3.5.261706, July 13th
    • Pathfinding rolled to 3.3.3.261768, July 14
  • Dolphin rolled to 3.3.12.24714 on July 14th, which had an issue with broken shadows and so was followed by 3.3.12.24707 on July 7th – core changes: code in SLPlugin has been changed in order to limit the number of virus warnings from anti-virus s/w; FIRE-6171/VWR-28846; ‘Save as’ dialog deadlocks on Ubuntu 12.04; FIRE-4730 – Client AO breaks attachments with animations, for example shoes with “Ankle locker”; additional Windlight settings from Firestorm; Fixed: Don’t block texture fetch threads for 2 minutes if the CURL callback fails  (release notes)
  • Firestorm released version 4.1.1.28744 on July 11th, which I review here (release notes)
  • Niran’s Viewer rolled to 1.44 on July 9th – core changes: use of LL’s Viewer rendering code; performance improvements; faster rendering of shadows, local lights, occlusion, etc.; integration of tone mapping from the Exodus Viewer
  • Zen Viewer rolled to release 3.3.5.2 on July 9th – core update: fixed a  Merchant Outbox Network Connect Error (release notes)
  • Cool VL Viewer made two releases:
    • The release version rolled to 1.26.4.22 on July 13th, reported as a bux fix release fixing breaks to the texture vertical offset spinner and the land brush force slider in the build tools floater
    • An experimental build 1.26.5.0 was also released on July 13th, which is the first phase of a  backport of the viewer v3.3 renderer to the Cool VL Viewer
    • change log for both
  • Singularity rolled to 1.7.0 on July 16 just prior to my viewer round-up being updated, and so makes this report; core updates – Multi-Wear release; general graphics engine update; region windlight support; RLVa partial update to 1.4; LSL editor update; sound system bug fixes & new sound system FMOD Ex; mouselook gun aiming incorporated; new build preferences; radar now indicates gesture/sound/particle/animation spam; holding Shift while crouching works as crouch toggle (release notes)

Related Links

Project Shining: what it means for the viewer

Posted on by Inara Pey

On the 29th June, Linden Lab announced Project Shining, aimed at improving avatar and object streaming speeds. At the TPV/Developer meeting on Friday 13th July, the project was discussed in terms of how the various elements within it will affect Second Life viewers.

The following is a summary of that discussion, based on the recording of the meeting, and focused primarily on the viewer changes / updates that will be most directly seen / felt by the majority of users.

HTTP Library

Commencing at 22:30 into recording.

The aim of this project is to improve the underpinning HTTP messaging that is crucial to simulator / simulator and simulator / Viewer communications. Monty Linden is leading this project.

Key points:

  • LL will release a project viewer containing a new “wrapper” implemented around how data is handled and a new texture fetch library  (see time frame comments at the end of this article)
  • Providing there are no major problems with the project viewer, the initial code release will move to a release version of the viewer
  • This will be followed by changes to group services and a “more ubiquitous” use of the library in the viewer – which is where Oz’s warning to TPV developers comes into play, as some services and the behaviours will start to change to improve throughput and reliability – and may even help improve the SL experience for those on older routers.

As a side note, some of this work has involved router testing aimed at determining what router hardware is compatible with Second Life. While it is hoped that work around the HTTP libraries will improve the SL experience for some using older router hardware as noted above, the tests have revealed that certain types of older router – Linksys WRT and Belkin G series routers were specifically named – are not compatible with running Second Life.

Avatar Baking

Bake fail: a familiar problem for many

Commencing at 32:38 into the recording.

The aim of this work (Project Sunshine) is to improve issues around avatar baking and to eliminate bake fail issues. It will primarily focus on moving the emphasis for the baking process from the viewer to a new Texture Compositing server. The viewer will retain some elements involved in avatar baking – the actual baking of the avatar shape (i.e. shape values and IDs) will still take place on the viewer side, for example.

Precisely how this new service will work on the server-side of things is yet to be fully determined by Linden Lab. However, work is progressing on the viewer side of the equation, with the current key points as follows:

  • The new service will use the Current Outfit folder to drive the new baking service
  • TPVs not currently supporting Current Outfits will have to implement it, otherwise they will effectively fail on avatar baking
  • The basic process will be that when it is time to send a rebake request (e.g. after a user has finished editing their appearance) the viewer must send a new message to the baking service which effectively says, “Look at the contents of my Current Outfit folder and give me back a new appearance based on that”
  • Viewers in general will have to support this new message that is sent to the service, and change how they perform the fetching of avatar textures; for the technically inclined, this will be HTTP without UDP fallback.

Currently, the plans is for LL to integrating the new way of doing avatar baking into their viewer code, which will be available for TPVs to integrate – although none of the Linden Lab 1.x code will be updated to support the new process, so this will effectively break their own Viewer 1.23.5, which currently is still in use within SL.

The viewer code will support both the “current” method of avatar baking (within the viewer itself) and the new baking service (using the Texture Compositing server) until the new service is fully rolled out across the grid. This means that if a user is in a region that does not make use of the new baking service, avatar baking will continue to be handled using the viewer-side mechanism we currently have. However, if the user is on a region that utilises the new baking service, avatar baking will be handled through that. The viewer will be able to recognise whether it is connected to a region supporting the “new” method through the region capabilities.

In order to ensure as smooth a transition to the new baking process as possible, LL are proposing a relatively long lead-in to the new service, making the code available well ahead of the new service being enabled, allowing TPVs to integrate it into experimental builds. The server-side changes will initially be implemented on a number of beta grid regions for testing with viewers there, prior to being scaled-up. The server changes will then be released onto the main grid in a controlled manner and then scaled up from there.

What Does This Mean for Users?

If all goes according to plan, and providing that you keep up-to-date with releases of your preferred viewer, this actually shouldn’t mean very much in real terms. There are however a number of things to be aware of:

  • If you use a viewer that is not updated to use the new code (i.e. the official viewer 1.23.5 or a viewer that is not updated to use Current Outfit folder and / or to support the new bake request message / HTTP texture fetch mechanism) OR you continue to use an old version of a viewer rather than updating, there will come a time when your avatar  – and those around you – will not bake correctly
  • There are two issues that may occur during the transitional period when both the “current” and the “new” baking methods are in issue:
    • When teleporting or crossing between regions that use the different methodologies, users will experience their avatar rebaking, as the viewer will effectively be using two sets of data for the bake process
    • If there are two adjacent regions, one of which is uses the current avatar bake process and the other is using the “new” baking service viewers in one region will not be able to correctly resolve the textures of avatars in the other region
  • It is hoped that the transitional period where both methods of avatar baking are active will only last for about two weeks.

Object Caching and Interest Lists

Commencing at 57:25 into the recording.

When you enter a region at the moment, your viewer receives a huge amount of information on what requires updating, much of it relating to things you can’t even see from your position in the region. The data is received in no particular order, with the familiar result that things appear to rez in your view in a totally random order – quite often with the thing you actually want to see being one of the last to rez due to the mechanics of Sod’s Law. What’s more, if you have previously visited the region, the chances are that much of the information being sent to your viewer is already cached.

Object caching and interest list changes: easing the pain of random rezzing

The focus of this project is to optimise the data being sent to the viewer, information already cached on the viewer and the manner in which that data is used in order to ensure it is used more efficiently so that things rez both faster and in a more orderly manner than is currently the case.

At this point in time, this work is in a greater state of flux than the HTTP library and avatar bake projects. This is more a process of optimisation both on the server-side of things and within the viewer itself, rather than that of new functionality within the viewer per se. There are no general time frames for this work at present, but there will be updates once things become clearer as to how the optimisation is going to be addressed.

Time Frames

The precise timeframes for implementing these changes have yet to be properly defined. However, Oz Linden hopes that there will be at least a two month period between Linden Lab making the code for each of these project elements available for integration by TPV developers into their viewers and the point at which the Lab states the code must be in use.

At the moment it is likely that the HTTP library element of the project will but rolled-out first, although this is unlikely to be within the next two months, for the reason given above. Project Sunshine, dealing with avatar baking, will then follow after that – or although how soon after has yet to be determined; as described earlier in this article, this will be a very controlled roll-out. It is possible that the object caching / interest lists part of the project many not be rolled-out for another six months. However, timeframes are still in discussion within LL, so any of this may well change.

Expect updates on all three of these project elements as and when more information is supplied by Linden Lab.

Related Links

CCIG: Calling builders and devs

Posted on by Inara Pey

As I’ve previously reported, the informal Content Creation Improvement Group this week had its second meeting, the majority of which revolved around mesh deformation and the available / potential options.

While the current emphasis on mesh is understandable given all that is going on, the focus of the group shouldn’t be thought of as being “only” about mesh. As I commented in my piece announcing the group:

 It is intended for developers and content creators alike, with the aim of providing a collaborative atmosphere which will allow members to discuss features, workflows, and modifications with the aim of enhancing content creation for everyone on SL. As such, the focus of the new group will be:

  • To provide a forum in which content creators can voice their ideas and / or concerns about the overall state of content creation in SL
  • Encourage the spread of knowledge about content creation methodologies and tools
  • Suggest / discuss new ways to facilitate content creation in SL (including the use of new tools or possible improvements to the viewer)
  • To provide a focal-point where content creators can have questions answered and issues highlighted that might otherwise go unanswered in other user groups.

This being the case, Geenz Spad, the CCIG’s chair is keen to see more participation in the group from TPV developers – to whom he put out a request in this week’s TPV/Developer’s Group meeting – and from content creators and builders from across the grid, “It would be nice to have some feed back on other content creation issues that don’t necessarily centre on mesh,” he commented to me immediately prior to the TPV/Developer’s meeting on Friday, “I’m sure there’s plenty of builders who’d like some progress in making their workflows easier as well.”

One potential area for discussion is that of the build floater. This has already received various degrees of attention within various TPVs, with some adding extra tools and capabilities (such as the prim alignment tool) others even giving it a complete overhaul in terms of presentation. Capabilities such as pathfinding, which sees an additional information panel added to the Build floater, stand to make it even more crowded. So there is a question to be asked as to what might be done to update / improve the floater in order to provide better access to tools and options – and this potentially falls into the remit of the CCIG.

The current official build floater (l) and the Pathfinding build floater (r)

Of course, TPVs are free to determine how they wish to develop floaters, etc., for their audience – and they do take a lot of feedback from users in doing so. But the CCIG offers an opportunity for developers and creators to work together on ideas and to develop proposals that can be fed back to Linden Lab and possibly influence their thinking on things – and even help them determine what needs to be done in order to make the tools and floaters with the viewer more accessible and user-friendly.

Given the CCIG is still formulating itself, now would be an ideal time for builders and creators who haven’t previously attended meetings to pop along and get a feel for what is going on.

There is a wiki page which contains the meeting agenda and links to meeting transcripts. If there is something specific you would like to see discussed, drop Geenz Spad a line in-world to have it added to the agenda. Meetings themselves take place every Tuesday at the Hippotropolis Auditorium in SL, commencing at 15:00 SLT. See the links below for more details.

Related Links

Pathfinding: Magnum RC roll-out, viewer tools and more

Posted on by Inara Pey

Pathfinding is drawing closer to a release across the main grid, and preparation work for the roll-out – which will constitute one of the biggest changes to SL – is underway on several fronts. This article is intended to be a high-level update on various elements of the project, gleaned from a variety of sources.

Magnum RC Roll-out

On Wednesday July 11th, the server-side pathfinding code was rolled-out to the Magnum Release Channel. There had been some predictions that this could lead to significant problems and issues as a result of the issues given within the release notes

Following the release, issues were experienced, notably with mesh vehicles, as reported on the forum thread discussing the releases for the week, and which have been rapidly responded to by Linden Lab personnel. there are still concerns around the roll-out and potential impact, and Linden Lab are continuing to monitor.

In discussing the RC toll-out at the TPV/Developer meeting held on Friday July 13th, Lorca Linden, the Associate Producer responsible for the project, commented: “OK, so pathfinding did go in RC on Magnum on Wednesday [July 11th]. As a whole, things are looking really, really good. We’re seeing very few crashes, the performance is working great we are seeing issues with some vehicles – definitely not all. That’s the only major hitch that we’re looking into, but as a whole the RC has been going quite smoothly.”

New Viewer Tools

As mentioned above, Lorca Linden (together with Stinson Linden and Prep Linden) from the pathfinding project attended the Friday TPV/Developer meeting on the 13th July, where they specifically discussed the viewer-side pathfinding tools. The tools are covered in detail in a new wiki page from Linden Lab, and may already be familiar to those who have been working on the pathfinding beta. They are currently in the Pathfinding Project Viewer, and will need to be incorporated in to TPVs as well. The wiki page provides comprehensive notes on the tools, complete with screen shots; the following in intended to provide a high-level summary and some background notes for those unfamiliar with the core elements of pathfinding, and to provide an overview of what this means for viewers going forward.

Navmesh and the Rebake Tool

For those not familiar with the term, navmesh is short for navigation mesh. This is a representation of a region’s geometry generated and used by the physics simulator to determine paths for pathfinding characters. The navmesh can be somewhat fluid in nature, depending upon what is going on in a region and what is being changed; a new path for a character, for example, will change a region’s navmesh. When this happens, the navmesh for the region needs to be updated, which can take some six hours  if left to update automatically.

To overcome this when pathfinding is rolled out, one of the new tools that will be appearing in the viewer will be a Rebake Region button. This will automatically appear at the bottom of the viewer window of all users within a region when the navmesh requires updating – regardless as to who may actually have altered the navmesh.

Rebake region button for navmesh updates (with thanks to Linden Lab)

Once baking has commenced, the button will fade on all viewers on which is displayed, indicating that an update is in progress (and preventing someone else from initiating a rebake). Once the rebake is complete and the navmesh is updated, the button will vanish from viewers.

Object Attribute Tools

By default, a navmesh treats all resident-made objects within the region in which it is active as obstacles that pathfinding characters must manoeuvre around. Obviously, this may not always be the case; there will be objects (e.g. stairs, ramps, sidewalks, floors, etc.), pathfinding characters need to traverse, climb, etc. This is achieved by altering the pathfinding atrributes associated with an object, and some of the new viewer tools are to allow this to be done and to also allow users to examine in-world objects to determine their status vis-a-vis pathfinding and how pathfinding characters will react to them.

These tools take the form of menu options and additional panels located in the Build and Object Profile floaters.

Dedicated Floaters

Also included in the tools are three dedicated pathfinding floater panels:

  • Linsket floater: designed to give advanced users and builders the ability to customize an area to achieve interesting effects with pathfinding-enabled characters
  • Character floater: designed primarily to help users to locate characters moving throughout a region and to identify the CPU cost of characters affecting the performance of a region
  • View / Test floater: intended for advanced users who are building pathfinding-enabled objects and characters.
Pathfinding characters floater (with thanks to Linden Lab)

Tool Status and TPV Integration

As mentioned above, these tools are all currently available in a Project Viewer. However, it is anticipated that they will be appearing in a Linden Lab beta viewer in “one to two weeks” (Lorca Linden). The tools themselves are regarded as feature complete by LL, and Lorca encouraged TPV developers at the meeting to consider integrating them into their viewers sooner rather than later.

Integrating the new tools in TPVs is liable to be in two parts:

  • An initial release containing the tools required for setting object attributes, etc.
  • A follow-up release incorporating the use of the Havok libraries Linden Lab is establishing and which will be made available under the new sub-licence arrangement.

The reasons for this are two-fold:

  • The attribute tools, etc., are vital for optimising pathfinding within regions and ensuring everything works correctly (e.g. to ensure pathfinding characters can climb the stairs they’re supposed to by climbing or walk along the prim sidewalk they are supposed to walk along, etc.
  • The Havok libraries are not yet available, although Oz hopes to have them in a position where he can talk in more detail to TPVs about them “pretty soon”, and while it is nice to be able to visualise the navmesh, etc., it is not quite such vital part of the pathfinding process.

Universal Tools

Alongside the viewer tools, pathfinding will see a set of universal tools rolled-out in console format. These will be available to region owners and estate managers and will allow them to change an entire class of object in a region to have certain pathfinding attributes once pathfinding goes live. Linden Lab are approaching this in terms of having all non-scripted objects set them to be static obstacles that pathfinding characters must manoeuvre around, while anything that is scripted is set to “dynamic”, as it is thought to be moving.

This obviously doesn’t fit all cases – vendor boards, for example are scripted, but they are hardly what can be termed “moving” objects. Indeed, it might be argued that the majority of scripted objects within a region are non-moving, and therefore should have their pathfinding attribute set to “static”. However, LL feel they have no way of easily differentiating between a non-moving scripted object and a moving scripted object, and thus feel that setting all scripted objects to “dynamic” is the better option and allowing the attribute to then be modified through the viewer where necessary, as setting them to “static” could result in a worse overall behaviour case within a region.

Other Tools and Items

Alongside the above, Linden Lab have previously indicated that they will be making the following available as pathfinding rolls-out:

  • A set of script templates used for the creatures found in the Wilderness areas
  • A script for a “master rezzer system”.

The latter is a means by which region performance and the number of pathfinding characters rezzed in the region can be monitored, and which will reduce the number of pathfinding characters within a region in response to the region’s performance / number of avatars within the region.

Potential Timescales for Roll-out

During the TPV/Developer’s meeting, Lorca outlined some potential dates for pathfinding. note that these are currently potential, and shouldn’t be taken as tablets of stone:

  • The pathfinding tools should be available in one to two weeks in a beta viewer
  • The server-side release is dependent upon how well (or otherwise) the current release to the Magnum RC progresses, and may potentially come within the next two-to-four weeks, but certainly no sooner than two weeks.

Again these are not confirmed dates, and may well change in the next couple of weeks – particularly if major issues are found with the Magnum RC roll-out.

Related Links

RFL 2012: Underway!

Posted on by Inara Pey

RFL of SL’s 2012 Relay Weekend has commenced. The sims are open, and the survivor / caregiver walk has set the stage for 24 hours of lapped themes around the track. The weekend kicked-off with a grand opening ceremony – which I have to confess to having to miss as I couldn’t get into the 4 regions where the ceremony was taking place – and will now run through until 10:00 SLT on Sunday 15th July, with track laps taking place at the start of almost every hour, and a host of events and activities taking place across the track regions.

From the visitor’s guide

If you are planning to walk the track, donate, and joy in events – and of course, you are planning to do just that! – make sure your first port-of-call is the welcome centre, where you can collect your pedometer and walk-and-talk attachments, as I mentioned last time around. Here to you can also get your RFL of 2012 Visitor’s Guide, which you can also view on-line.

Welcome centre

From here you can use the teleport system to randomly TP you to a point on the grid, or jump directly to one of the points of interest – the RFL blog has a list of events taking place at the various stages throughout today and tomorrow.

A look along the track

The weekend is liable to be popular, so please try to be as low-lag during your visit as possible and detach any / all unneeded attachments. Gift bags line the track itself, allowing you to drop your Lindens into them at any time, and you can of course opt to swing off the track at any time and enjoy any of the fabulous builds along the route before continuing on your way – the themed walks last an hour, which should provide a decent amount of time for admiring builds as well as for putting in your laps!

Given this year’s theme is Time for a Cure, many of the builds feature time and clocks within them – often in the most imaginative of ways. All the builds offer something special and are worth a visit in their own right, and really are worth visiting and exploring – and give you ample time to join in for a lap or two!

I’m hoping to join-in for at least two of the themed laps over the course of the weekend – I have my costumes at the ready – and look forward to see you there as well :).

Related Links