Second Life viewer: Starlight UI skins and options

Hitomi Tiponi's Starlight set provides a total of 10 different skinning options for the official viewer, together with a range of additional UI tweaks and options
Hitomi Tiponi’s Starlight set provides a total of 10 different skinning options for the official viewer, together with a range of additional UI tweaks and options (Starlight Silver Blue skin shown on viewer 4.0.6.315555) – Click any image for full size, if required

Reader Wolf Baginski posted a comment on the subject of alternative skins for the official LL viewer, prompting me to think about Starlight. This is a set of alternative UI skins and additional options available for the official viewer (and for some TPVs, although they are outside the scope of this article), which I last wrote about in these pages page back in 2010/11 when I was using it with viewer 2.x.

So, given I haven’t written about Starlight for a good while, and given there may be users of the official viewer who haven’t previously come across it, I thought it might be a good idea to take a look at Starlight as it is today, and offer something of an introduction for those unfamiliar with it.

Overview

Produced and maintained by Hitomi Tiponi, Starlight has been available for the English language version of the viewer for a good few years, as noted above. Today, it includes no fewer than 10 alternative UI skins and a range of other UI updates and tweaks which may appeal to users. The ten skins comprise:

  • Original Orange: a dark theme with a touch of orange
  • Nostalgia Blue: features buttons and some layout changes to remind you of Viewer 1.x
  • Silver Blue: a ‘dark on light’ theme using a cool blue
  • Silver Pink: as above, but with a hint of pink
  • Mono Teal:  a high-definition black on grey / white & teal green buttons
  • Orb Red: designed to make the interface seem less one-dimensional
  • Orb Blue: as above, but a deep shade of blue
  • Original Teal: The Lab’s original viewer 2.x colour scheme with slightly improved contrast
  • Two customisable skins which can be modified via the  StarLight Colourful User Interface (CUI):
    • Custom Dark: for using with a backdrop of a black, navy blue, dark red etc.
    • Custom Light: for a brighter, vibrant look, ideal for integrating black text with a lighter theme.

The additional UI items offered within Starlight include, but are not limited to:

  • Top bar Draw Distance slider (between 32 and 992 metres)
  • Revised Preferences panels
  • Additional Toolbar buttons
  • Film menu, for photography and machinima fans
  • Inclusion of a “lite” version of PhotoTools
  • Comprehensive Shadows, Rendering, Depth of Field and Local Lights settings in Preferences > Graphics
  • Assorted UI layout improvements / updates.

For a full list of such options and updates, please refer to the Starlight wiki page.

Starlight-7_001
Starlight also offers a range of UI options, including updated floater layouts, new floaters, additional toolbar buttons, easy access Draw Distance slider and more. Click for full size, if required

Installing Starlight

Note that while available for the official viewer, Starlight is a third-party product, and isn’t supported by Linden Lab.

  1. Log out of Second Life.
  2. Go to the Downloads section of the Starlight wiki page.
  3. Read the notes on downloading the correct version.
  4. If you download the .ZIP file (suitable for Windows, OS X and Linux) following the manual installation instructions on the wiki page.
  5. If you download the Windows Easy Installer:
    • Launch the installer and follow the on-screen instructions
    • Make sure you install Starlight to the installation location of the viewer with which it is to be used
    • If you use different RC and project viewers, and wish to have Starlight available for all of them, you must install it for each one.

Note that if a new version of the viewer is subsequently installed to the same location used with Starlight, the Starlight files will be removed as a part of the installation process. You’ll therefore need to re-install the latest version of Starlight in order to keep using it. However, as the Second Life settings files are not removed during viewer updates / installations (they are only removed if you manually carry out a completely clean installation), the viewer should revert to the last active Starlight skin once you have re-installed your Starlight files.

For photographers and machinima makers, Starlight adds the Film menu to the viewer's menu options (Starlight Mono Teal skin shown)
For photographers and machinima makers, Starlight adds the Film menu to the viewer’s menu options (Starlight Mono Teal skin shown)

Running Starlight

  1. Launch the viewer.
  2. Select a Starlight skin from the drop-down displayed below the log-in button.
  3. Re-start the viewer and log-in.

Repeat these steps should you wish to change skins.

Selecting a new Starlight Skin
Selecting a new Starlight Skin

Additional Notes

Well documented and supported, Hitomi generally has an updated version within hours of any new official viewer de facto release, offering a good cross-section of UI skins and some excellent UI additions, Starlight remains the add-on for the official viewer.

As per Wolf Baginski’s suggestion, I’ll be adding links to Starlight wiki page to my Current Viewers Release List and my weekly viewer release summaries going forward, to help people more easily find it.

Firestorm 4.7.9.50527: “I see jelly people!”

firestorm-logoMonday, August 8th saw Firestorm release version 4.7.9.50527 of their viewer. Coming a little over four months since the last release, 4.7.9 brings with it a lot of important changes from the Lab – perhaps most visible Avatar Complexity and graphics pre-sets – as well as a large number of nips, tucks, fixes and improvements from the Firestorm team and open source / TPV contributors.

As per my usual MO, what follows is  not an in-depth review of the release, but rather an overview, highlighting some of the more significant / interesting changes, updates and  fixes, which I feel will be of most interest to users.

For full details of all changes, and all due credits to contributors, etc., please refer to the official release notes.

When installing this release, uninstall the existing version and then install the new 4.7.9 release – no need for a clean install.

Available Downloads

Prior to getting stuck into the details, please note that with this release:

  • There is no 32-bit Havok version for OS X, due to incompatibilities with the RLVa update
  • Firestorm have discontinued producing a 32-bit Havok version of the viewer for Linux, due to the relatively low demand for it.

Firestorm is and will continue to be available as a 64-bit non-Havok (“OpenSim”) version for OS X and in both 32-bit and 64-bit non-Havok (“OpenSim”) versions for Linux. These versions can obviously be used with Second Life, and are available for the 4.7.9.50527 release.

This means it is unlikely there will be any Firestorm Havok support for either Max OS X or linux until Linden Lab release the 64-bit versions of the Havok library alongside their own upcoming 64-bit viewers. In the meantime, the Firestorm team offer their apologies for any inconvenience caused, and ask that those on either OS X or Linux who require Havok functionality (e.g. for mesh uploads reliant on Havok physics or for pathfinding purposes) to briefly switch to the LL viewer.

Log-in Credentials Display Update

The first noticeable aspect in this release is the log-in credentials area at the bottom of the splash / log-in screen have been revised, offering a slightly more Viewer 4 style look and bringing all the options together alongside of a single, obvious log-in button.

The revised log-in credentials area of the splash / log-in screen
The revised log-in credentials area of the splash / log-in screen

Note that if you prefer the old login screen layout, you can set the debug setting FSUseLegacyLoginPanel to TRUE.

Another change with this update is that opening Preferences from the log-in screen should no longer cause splash screen layout problems, thus fixing FIRE-17518.

Lab Derived Updates

Firestorm 4.7.9 brings the viewer up to parity with the Lab’s 4.0.6 code base, and so includes the Avatar Complexity (aka “Jelly Dolls”) and graphics presets, as noted above, and includes many maintenance fixes, things like Voice updates and the most recent HTTP updates.

Avatar Complexity – or “Why is everyone I’m looking at an odd colour?”

Avatars can often be the biggest single rendering load on our computers. Hence why the bottom falls out of your viewer performance in a crowded place. Avatar Complexity is a means to offset this impact by allowing you to set a “complexity limit” for avatar rendering. Any avatar (including their attachments) exceeding this limit will be rendered as a solid colour – a “Jelly Doll” – putting a lot less load on your computer. You can adjust the limit according to your needs, and you can also override the setting for individual avatars around you. Do note as well that the setting only applies to other avatars in your view; your own avatar will always be rendered fully.

When first installed, a viewer with Avatar Complexity will set a default limit for you based on your current viewer graphics settings. Hence why you might see a lot of solid colour avatars around you when logging-on for the first time with Firestorm 4.7.9. These default limits are:

  • Low: 35,000
  • Low-Mid: 100,000
  • Mid: 200,000
  • Mid-High: 250,000
  • High: 300,000
  • High-Ultra / Ultra: 350,000

You can adjust you Maximum Complexity setting at any time in Firestorm in one of two ways either via Preferences > Graphics or via your Quick Preferences.

In both cases, moving the Max(imum) Complexity slider to the right increases your threshold, allowing more avatars around you to be fully rendered, while moving it to the left decreases your threshold, increasing the number of avatars liable to be rendered as solid colours.

"Avatar

Note that you can set the Max(imum) Complexity slider to No Limit (all the way to the right). However, this isn’t recommended simply because it leaves your viewer vulnerable to any graphics crashers some inconsiderates still occasionally try to use. It’s far better to simply set your viewer to a high limit (e.g. 350,000) if you don’t want to be bothered by seeing Jelly Dolls

Displaying Avatar Complexity Information

You can display Avatar Complexity information for all avatars (including your own) in Firestorm in one of two ways, depending on your preference (or both can be active at the same time, if you so wish):

  • By going to the Advanced menu (CTRL-ALT-D if not visible) > Performance Tools > Avatar Complexity Information (previously Show Render Weight for Avatars). This displays three items of information over the heads of all avatars Including yours):
    • The render complexity for each avatar
    • A ranking of the avatar’s distance from your camera (1=closest)
    • The attachment surface area for an avatar, expressed in square metres
  • Or by going to Preferences > General and checking Show Avatar Complexity (if not already enabled). This will display the render complexity for each avatar in their name tag, and includes two sub-options, which are pretty self-explanatory:
    • Only [show avatar complexity, when enabled] If Too Complex
    • Show Own Complexity.
The Firestorm options for displaying Avatar Complexity information in the viewer
The Firestorm options for displaying Avatar Complexity information in the viewer

Continue reading “Firestorm 4.7.9.50527: “I see jelly people!””

Alchemy 4.0.0: released

Alchemy-logoOn Saturday, June 26th, the Alchemy team announced the official release of Alchemy 4.0.0.37571, which essentially moves the recent Beta releases to release status, together with some tweaks and tucks.

As Alchemy beta users will know, 4.0.0 brings Alchemy up to parity with the Lab’s 4.0.0 code base, and also adds some upstream fixes from 4.0.1. This means the viewer includes the Chromium Embedded Framework (CEF) for media handling.

Given I have provided a couple of overviews for the February and April beta releases of the viewer, the following is a quick bullet-point list of major updates in the viewer:

  • Client-side AO (see my April Beta release overview)
  • Automatic update capability (matching the official viewer update capability) – Preferences > Setup
Alchemy 4.0.0 includes auto-update options to help with maintaining parity with latest releases / receiving beta version updates
Alchemy 4.0.0 includes auto-update options to help with maintaining parity with latest releases / receiving beta version updates
  • Enhanced environmental tools
  • In a change introduced on the April Beta, the local chat bar (see my February Beta release overview) no longer has a chat check-box to activate the option (Preferences > Chat). Instead, the chat bar will open automatically if your mouse focus is in-world (e.g. not already focused on the conversation floater or another floater) and Preferences > General > Pressing Letter Keys is set to Starts Local Chat.
The Alchemy local chat bar and options, as it appears in the 4.0.0. release version of the viewer
The Alchemy local chat bar and options, as it appears in the 4.0.0. release version of the viewer

At the time of writing, the full release notes were reported as “will be generated soon”, so users are referred to the Alchemy web site for these and a detailed breakdown of updates.

Related Links

Avatar Complexity and Graphics Presets in Second Life

Avatar Complexity provides users with the adbility to
Avatar Complexity is a means to help people who may suffer from performance issues in crowd areas

On Wednesday, May 18th, Linden Lab promoted the long-awaited Quick Graphics viewer to de facto release status. This viewer includes two important new features:

  • The updated Avatar Complexity settings
  • The ability to create, save and load different groups of graphics settings quickly and easily.

Avatar Complexity

As avatars can often be the single biggest impact on the viewer in terms of rendering, particularly in crowded places, so  Avatar Complexity adds a new slider to the viewer which can be used to set a level above which avatars requiring a lot of processing will appear as a solid colour – the casual term to refer to them being “Jelly Dolls” – greatly reducing the load placed on a system compared to having to render them in detail, so improving performance.

The idea is that you can adjust the setting according to circumstance, so that when in a crowded area with lots of avatars, you can dial down the Avatar Complexity setting, found in Preferences > Graphics (and in the Advanced Settings floater), with the result that more of the avatars around you are rendered as solid colours, reducing the load on your graphics card and system, thus improving performance. Then, in quieter areas, the setting can be dialled back up, allowing more avatars to fully render in your view.

Note: this only applies to other avatars in your world view: your own avatar will always fully render in your view.

The Avatar Maximum Complexity slider sets a threshold on avatar rendering by your viewer. Any avatars in your view exceeding this value will be rendered as a
The Avatar Maximum Complexity slider sets a threshold on avatar rendering by your viewer. Any avatars in your view exceeding this value will be rendered as a “Jelly Doll”, sans attachments

If you have a good system with a high-end graphics car, you can set the value on the slider quite high and thus ensure all avatars render fully for you wherever you are.

Note: You can sett the Avatar Maximum Complexity to “No Limit”. However, this is not entirely recommended. some irritants in Second Life still use worn graphics crashers to overload GPUs and crash the viewer. If you set Avatar Maximum complexity to “No Limit”, then such tools, should you ever encounter an irritant using one, will still be effective; so it’s better to set a reasonable high value, leaving your viewer with a cut-off point which should defeat their efforts in crashing you.

There are a few other points to note with Avatar Complexity:

  • You can opt to always render or to not render avatars around you, regardless of your Avatar Maximum Complexity setting by right-clicking on them and selecting your desired action from the context menu
    You can opt to always render or to not render avatars around you, regardless of your Avatar Maximum Complexity setting by right-clicking on them and selecting your desired action from the context menu

    To help you understand how complex you own avatar is, every time you change your appearance, each time you change the appearance of your avatar, a small notice with your new complexity value will appear in the upper right of your display for a few seconds

  • The complexity value of your avatar is transmitted to each simulator as you travel around Second Life. In return, you’ll get a brief notice in the upper right of your screen telling you approximately how many of those around you are (or are not) rendering you because of your complexity
  • If you have a friend or friend you wish to see fully rendered no matter how low you dial Avatar Maximum Complexity (while out at a club, for example, where it may be beneficial to set a lower complexity threshold), you can right-click on those individuals and select “Render Fully” from the context menu
  • Similarly, and if you prefer, you can selectivity render avatars in your view as grey imposters, by right-clicking on them and selecting “Do Not Render” from the context menu.

Note: Both “Render Fully” and “Do Not Render” will only apply during your current log-in session; the options are not persistent between re-logs.

To help people understand Avatar Complexity, the Lab has produced the following:

  • A blog post to accompany the promotion of the Quick Graphics viewer to release status
  • An Avatar Complexity Knowledge Base article
  • A video tuTORial, which I’ve embedded below.

https://www.youtube.com/watch?v=PxWrqd0o3dc

Continue reading “Avatar Complexity and Graphics Presets in Second Life”

Alchemy 4.0.0: client-side AO

Alchemy-logoAlchemy viewer updated to version 4.0.0.37561 (Beta) on April 16th. This is another progressive update, containing a lot of under-the-hood improvements and fixes – notably around rendering – and a new visible update in the form of a client-side animation override capability, modelled after the one most popularity seen in Firestorm.

The update also sees a Linux 64-bit release as well, although going by the comments following the release notes blog post, there appear to be log-in issues associated with the Linux version.

This, and the previous “beta” release are intended to get the team’s own updates in front of users ahead of some major updates which will be forthcoming as Alchemy (as with all other viewers) merge with some significant releases coming down the pipe from Linden Lab (including the Avatar Complexity capabilities and – eventually – the Project Bento updates).

As the AO update is the most visible change with this release, and given I am not a regular Alchemy user (although I find it possibly the best viewer for video capture), the rest of this article focuses on the AO aspect of the update.

The client-side animation override (AO), is intended to replace he need for HUD-based scripted animation overrides, instead driving animations – walks-sits-standing poses, etc – directly through the viewer, thus freeing-up simulator resources. Using one does require a little work in setting-up (but so can HUD-based systems), but you can run multiple animation sets directly from the viewer.

Essentially, the AO system comprises three parts:

  • The animations you wish to use, which you will need to copy / move from any associated HUD system to your inventory – placing them in a folder within your Animations system folder is often a good way to do this
  • A configuration note card defining the animation you wish to use. Like configuration note cards found in many ZHAO -based animation overrides (so simply using the note card found within your scripted AO system should work OK), this defines animations by type: stand, walk, sit, etc (you can also manually create an animation set if no configuration note card is available)
  • The viewer UI elements.
To use the client-side AO, you'll need to have the animations you wish to used stored within your inventory (not within another AO system) (l), and a suitable note card defining the animations you wish to use with the AO (r)
To use the client-side AO, you’ll need to have the animations you wish to used stored within your inventory (not within another AO system) (l), and a suitable note card defining the animations you wish to use with the AO (r)

Once you have done this, you’re ready to set-up the client-side AO system.  You can access the AO floater in one of two ways:

  • By adding the AO button to your viewer toolbar and then clicking on it to open the AO floater
  • By hovering the mouse over the AO icon at the top right of your screen to display a minimised AO floater.

The latter is actually the easiest, given the way Alchemy have implemented to AO system. Assuming you take this approach, click on the spanner icon in the minimised AO floater to expand it.

The client-side AO floater - minimised (l) and expanded (r)
The client-side AO floater – minimised (l) and expanded (r)

Now, simply drag and drop the configured animation note card from your inventory to the AO floater. This will cause Alchemy to configure the AO system ready for use, and result in a list of your animations appearing in the floater. At the same time, a set of links will be created in the Animation Override folder in your inventory – do not delete these!

Alternatively, if you don’t have a configuration note card for an animation set, click the + button on the AO system floater, type in a name for your animation set, then drag and drop all of the animations you want to use in the set from your inventory into the AO system floater.

The AO floater with the loaded animation set (l) and the associated links in the Animation Override folder in your inventory (r)
The AO floater with the loaded animation set (l) and the associated links in the Animation Overrides folder in your inventory (r)

Continue reading “Alchemy 4.0.0: client-side AO”

Firestorm 4.7.7: get ready to update!

firestorm-logoThursday, March 17th saw Firestorm release version 4.7.7.408706 of their viewer. Coming four months after the last release, this update is slightly later than planned, but includes a number of important updates from the Lab as well as a good mix of updates, improvements and fixes directly from the Firestorm team and contributors.

As per my usual MO, what follows is an overview of the release, highlighting some of the more significant / interesting changes, updates and  fixes to be found in the release, and which I feel will be of most interest to users.

For full details of all changes, and all due credits to contributors, etc., please refer to the official release notes.

The Usual Before We Begin Notes

For best results when installing this release:

This update means that Firestorm 4.6.9 will be blocked in approximately 3 weeks time.

Lab Derived Updates

Firestorm 4.7.7 brings the viewer up to parity with the Lab’s 4.0.1 code base, and so includes the TLS 1.2 and CEF changes. These and other Lab derived changes are outlined below.

TLS 1.2 and Viewers

The reason this release might be regarded as becoming a mandatory update for Second Life users is the integration of TLS1.2 into the viewer – and by “viewer”, I mean all current or upcoming viewer releases, LL or TPV.

TLS, the successor to Secure Sockets Layer (SSL), is a cryptographic protocol for communications security intended to provide privacy and data integrity between two communicating computer application (such as the viewer and the Lab’s servers).

TLS 1.2 is currently being implemented by Linden Lab under the umbrella of their work of fiscal compliance, This involved changes to both the viewer and LL’s servers, the upshot of which means that, once TLS 1.2 has been fully implemented, any viewer that does not support TLS 1.2, will not be able to do any interactions with cashier or anything that involves L$. While there is no precise time frame for this work to be completed, indications from the Lab are that it will be sooner rather than later.

Again, this is not an arbitrary decision on the part of either the Firestorm team or Linden Lab; the work is being carried out as a compliance requirement.

Chromium Embedded Framework

Firestorm 4.7.7 includes the Lab’s implementation of Chromium Embedded Framework (CEF) for media management (and more). CEF completely replaces the old llQTwebkit for media management within the viewer, replacing it with current web technologies such as HTML5, CSS3 support and WebGL, which can allow direct manipulation of objects on a browser page displayed in-world with ease.

CEF should also enable things like viewing PDF files in-world, editing PDF documents via Google Docs, etc. See the CEF forum thread for more.

CEF integration into the viewer means that Flash and QuickTime content require third-party support (see this Knowledge Base article on enabling Flash support for CEF viewers, for example). However, because they do rely on plug-in support, there is no guarantee given by Firestorm or Linden Lab that either will work, and are regarded as unsupported.

Other Updates from the Lab

Materials (texture / diffuse, bumpiness / normal and shininess / specular) in the Build floater Texture tab can now be selected via radio buttons, rather than picking from a drop-down list, to make locating and selection them easier (see BUG-10149).

Firestorm replaces the materials drop-down selection menu (seen in version4.7.5, left) with the radio buttons for materials types (right), as also seen in the official viewer
Firestorm replaces the materials drop-down selection menu (seen in version4.7.5, left) with the radio buttons for materials types (right), as also seen in the official viewer
  • A fix for ALM enabled + full bright + shiny objects failing to display texture on Mac (see FIRE-12681)
  • A fix for activating Show Avatar Complexity disabling all llSetText (hovertext) viewer is restarted (see BUG-10488)
  • A fix for show land owner colour overlay is only visible where there is water in deferred rendering (see FIRE-11654)
  • A fix for a black screen if ALM is enabled while in wireframe mode and then wireframe is disabled (see BUG-4543)
  • A fix for rotating an object that is used as grid reference going crazy (see FIRE-2593 and BUG-9419)
  • A fix for “Ban Member” in the group chatters list context menu being greyed out (see FIRE-16160 and BUG-10500)
  • A fix for animated agents at high altitudes randomly showing up at 0,0,0 (see bug FIRE-14439 and BUG-6648)
  • A fix for having to open ‘About Land’ twice to get parcel ban timings to load in the parcel ban list when banned names are not cached (see bug FIRE-17408 and BUG-10831)
  • A fix for a stuck freeze frame state if snapshot floater is closed with freeze frame left enabled and the viewer window is subsequently resized (see FIRE-16739 and BUG-9952)
  • A fix for opening a note card with the same name as one already open failing to work (see  VWR-2981)
  • A fix for replacing current outfit with contents of a non-outfit folder creates a folder link in the Current Outfit Folder (see BUG-11274)
  • A fix for opening an experience compiled script in an object in an adjacent region failing to show the script is compiled with an experience in the script editor (see BUG-8980).

Continue reading “Firestorm 4.7.7: get ready to update!”