Today, Linden Lab has announced a major new open source initiative to improve graphics rendering performance within the viewer. The announcement reads in full:
One of the challenges that virtual world creators face is the trade-off between rich visual detail and geometric complexity. Ideally, by adding more and smaller faces to an object, a designer can model different surface textures and create realistic variations in the interplay of light and shadow. However, adding faces also quickly increases the size of the model and its rendering cost. Normal and Specular Maps are ways to address this by allowing for the appearance of a complex surface without actually modelling fine scale geometry.
A Normal Map is an image where the color codes indicate how the renderer should reflect light from each pixel on a surface by modifying the direction that the pixel “faces” (imagine that each pixel could be turned on tiny pivots). This means that pixels on a simple surface can be rendered so that they appear to have much more detail than the actual geometry and at much lower rendering cost. Light and shadow are rendered as though the surface had depth and physical texture, simulating roughness, bumps, and even edges and additional faces.
Similarly, a Specular Map allows each pixel to have its own degree of reflectivity, so that some parts of a single face reflect sharply, while adjacent pixels can be dull.
The open source developers of the Exodus Viewer are contributing Viewer support for Normal and Specular Maps, as well as some additional controls for how light reflects from faces. Linden Lab is developing the server side support so that this powerful tool will be available in Second Life.
Design and development are under way. Watch this blog and the Snowstorm Viewers page for information on when test Viewers with these new capabilities become available.
For additional information, or to learn more about how you can participate in the open source program, please contact Oz@lindenlab.com.
A video has also been released, demonstrating the capabilities.
As I reported a while back, the Content Creation Improvement Informal User Group has started looking into the matter of the Build floater.
Like many things in the viewer, the Build floater has to cover many tasks, some of them quite basic (moving a lounge chair across a room) through to very complex building and texturing activities required by content creators. Over the years, this has led to the Build floater becoming considerably more cramped and complex as options, capabilities and tools have been added to it.
Even redesigns of the UI – as with Viewer 2.x and Viewer 3.x have brought with them issues of their own. Some of these are code-related, some of them are very much impact the usability of the floater, e.g. localisation problems wherein languages other than English don’t readily fit the floater size and layout, etc.
Some TPVs have sought to tackle the issue over the years, but efforts have tended to revolve around working with the constraints defined by the current Build floater, rather than looking what needs to be done in order to make the use of tools traditionally grouped together as “build tools” more task-oriented.
Firestorm and Phoenix, for example, have retained the old V1 capability of being able to show a minimal toolbar (remember the MORE and LESS options on the old, old Build floater?) which can be used to perform basic object movement and rotation tasks without having a plethora of additional information thrown at the novice user.
The V1-inspired “minimal Build floater” as exemplified by Firestorm
Niran’s Viewer has also sought to address how information within the Build floater is presented: offering it in a left-to-read format which is potentially more readable for many people as it is easier to visually scan.
However, such approaches suffer their own drawbacks. Niran’s Viewer may present the information in a more logical left-to-right flow, but this is really a cosmetic change rather than a fundamental shift in emphasis in how the tools are presented in terms of user needs as opposed to content creator needs. Similarly, the Firestorm / Phoenix approach retains the minimal information approach from Viewer 1.x, but again, even this potentially contains too much information for, say, someone merely wishing to pull out a sofa and position it in their lounge or who wants to adjust the location of a bracelet attachment on their wrist.
Niran’s Viewer: attempting to make the Build floater a little more logic
The CCIIUG is therefore looking not so much to redesign the Build floater itself, but what needs to be done to present options and tools more logically, such as through one or more floaters that could eventually replace the Build floater as we know it. As such, the Group has been discussing requirements in terms of use rather than function:
What tools does the lay user, with no interest in content creation, need to be able to see and access in order to complete the simplest of tasks such as the aforementioned positioning of an in-world object or to resize an object (in-world or attached) to suit their needs?
How can these be presented in a user-friendly manner that doesn’t swamp the “consumer user” with information superfluous to their needs
Where does the cut-off come between “basic” tools (as described above) and the more advanced tools generally the preserve of the content creator?
How should the more advanced tools be presented?
These are actually tough questions to answer as they cover very specialist areas, code design, UI design, etc., as well as a need to clearly understand what “consumer” or “novice” users actually require (itself a tough question for anyone who has been engaged in Second Life for any reasonable length of time, as views naturally become more subjective as time passes). However, the work is potentially pertinent for a number of reasons:
The Build floater is seeing more and more being pushed into it as functionality within Second Life continues to be enhanced with new tools and features – mesh saw the additional link and pop-up panel; pathfinding has seen the addition of new information panels, etc.
It is thought that there may well be a further change pushed into the Build floater as a result of “something new” (no specifics available) coming down the line
Even if any new approach coming out of the CCIIUG isn’t adopted by LL, as it amounts to UI improvements, as so long as it does not impact how the in-world experience is shared between viewers, it does not fall foul of the TPV Policy, and so TPVs will be free to adopt whatever improvements may arise from discussions if they so wish.
A working party within the CCIIUG is being formed to look more closely at the matter, and with a view to putting together mock-ups of ideas as to what a new Build tool UI might look like. As such, input is being welcomed from both TPV developers and from users in general on the matter, with the aim of eventually presenting ideas to Linden Lab at some point in the near future.
If you’d like to be a part of the working party, you can join by attending the weekly CCIIUG meetings, held every Tuesday at 15:00 SLT at the Hippotropolis Auditorium. Information on the Build tools discussions to date, please see the links below.
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.
Dolphin rolled to 3.3.18.24749 on August 10th – core updates: Asset Blacklist redcord region name when object added; Media Filter list now shared between all avatar accounts on same OS; slider add the Graphics Prefs for improving mesh rez times in areas with a lot of mesh; added improved avatar vertex weights from STORM-1800 for better avatar bending / stretching; Improved handling of SLurls between webpages and running Dolphin viewer (release notes)
Niran’s Viewer rolled to 1.48 on Aug 6 – core changes: Alterations to the log-in splash screen; addition of core pathfinding tools to menus; merge with Exodus rendering pipe; assorted fixes (release notes)
Cool Viewer: Stable branch rolled to 1.26.4.24 and Experimental to 1.26.5.3, both on Aug 11th – core updates in both: initial pathfinding support; various SLV 3.3. code back ports (release notes for both)
Lumiya release version 2.2.0 on Aug 8th and then 2.2.1 on Aug 11 – core updates: completely revised and enhanced UI; split-screen functionality; options to add / remove friends, offer teleports, set and auto response message (release notes) – read my review here
Wednesday August 8th saw the launch of Lumiya 2.2.0, followed on Saturday August 11th by 2.2.1. With them came a host of goodies, including:
A new user interface
Split-screen layouts for tablets
The ability to:
Add and remove friends
Set an auto-response for incoming IMs
Send teleport offers to others
Support for legacy user names (rather than only using Display Names)
Avination added to grid list.
As we shall see, this is really quite a modest representation of what amounts to a huge amount of work to completely overhaul what was already a very usable and increasingly intuitive application and turn it into a highly polished product.
This review was written using a Samsung Galaxy S2 smartphone running ICS 4.0.4. Note that as I do not have a tablet device, I’m unable to do any direct screen comparisons, therefore some details might differ on a larger display.
Sign-In Screen
The changes are apparent from the moment you launch Lumiya, as a slick new log-in page appears, complete with new widgets.
The older (l) and newer (r) log-in screens – note the widgets, top right, in the latter
The widgets are at the top right of the screen and comprise (in left-to-right order):
Account Manager: easily access all of the accounts you’ve used Lumiya to log-in to SL. Tapping on this will display a list of accounts, including the name of the grid the account is used to access. Tapping an account name will return you to the sign-in screen, with the user name and password fields auto-completed with the required credentials, and the client pointing towards the required grid
Settings: tap on this to access and set / amend your preferred settings for Lumiya.
Settings Options
Before getting into the various changes within Lumiya itself, it is worth covering the Settings options, as these include some important updates. Chief among them is the new Light skin option. Until now, Lumiya has presented itself on a dark background. On smaller screen, than can be hard on the eyes and lead to discomfort. The Light skin option displays Lumiya’s screens on a white background which on smaller screens especially can be easier on the eye.
The two visualisation options for Lumiya
Also within Settings are the new options to: use legacy names rather than Display Names; enable the split-screen display and when it will be activated (see Screen Orientation, below); and display local chat in the 3D world view (see Conversing in the 3D World View, on the next page).
Grid Access
The grid access list can now be displayed in one of two ways:
By tapping the name of the currently selected grid. This will display a pop-up list of grids
By tapping the Menu button on your device and selecting Grids from the menu which is displayed. This will switch to a full-screen list of defined grids
Tapping on the name of a grid in either list will automatically return you to the sign-in page, with the grid selected. Both lists also include the option to add further grids, as I’ve documented in my last review of Lumiya.
Menu Options and Icons
Tapping the Menu button on your device in earlier versions of Lumiya would pop-up a set of on-screen buttons. This has now been replaced by what I’ve dubbed here the “Lumiya menu”. This is a set of context-sensitive menus which will display options in accordance with the screen you are using / function you are performing and which take into consideration screen orientation (see below). These make working with Lumiya even smoother and more intuitive.
Greater use is also made of on-screen buttons as well. These are also context-sensitive and present a far slicker and faster means of performing activities within Lumiya than with previous versions. As the buttons rely on icons extensively when in portrait mode (at least on smaller devices), a PDF-format guide to the icons and their functions can be found here. A long touch on an icon will also show an on-screen tool tip.
Screen Orientation
Lumiya now includes much better screen orientation options when rotating between portrait and landscape modes, and adds a split-screen capability.
When rotating between portrait and landscape views the screen layout will automatically adjust itself. This will generally result in better screen utilisation in either orientation. However, when in landscape mode, it may appear as if buttons are vanishing from the screen due to the use of icons & labels – not so! Any buttons that are not displayed as icons are moved to the Lumiya menu, accessed via the Menu button on your device.
Where the icons go: rotating the Lumiya display to landscape may seem to cause buttons to vanish from the layout. Tap the Menu button on your device to display them within the Lumiya’s menu
The a split-screen option is primarily intended for tablet devices, but can still be useful when used with suitable screens on mobile phones. It is enabled via Settings (tap the Menu button on your device to display the Lumiya menu and then tap Settings), and can be set to one of the following:
Automatic: Tablets will automatically switch to split-screen when in landscape orientation, devices with smaller screens may not
Always in Landscape: the split-screen will activate whenever the device is rotated to a landscape orientation, regardless of screen size
Always: the split-screen mode will be active in both landscape and portrait modes, again regardless of screen size
It’s been a while, but the Exodus team released a new version of the viewer on Thursday August 9th. Version 12.08.09.1 is liable to be the first of two updates to Exodus this month (the second being aimed at incorporating the pathfinding tools for those keen to get to grips with pathfinding in Second Life). This release is the first to be made since Katharine Berry recently joined the Exodus team, and she’s been engaged in a number of the features presented with this release.
The 12.08.09.1 release (also referred to as Beta 8), brings with it a range of updates, including:
Ability to upload images from the snapshot floater to Flickr
New linear, Renhard and filmic tone mapping
New avatar troubleshooting menu
Ability to mute group chat
Inclusion of floating point “Normalized Blinn-Phong” shading LUT for deferred rendering
Latest RLVa support
Various UI updates including:
Vertical chat tabs (from Catznip)
Web browser toolbar button
Additional slider in the Quick Preferences floater for adjusting your own sound locally
Request teleport button added to IM windows
Merge with the SL Viewer 3.3.3 codebase, bringing with it:
Merchant Outbox support
Local Textures (by Vaalith Jinn)
Graded shadow support
Various fixes to the mesh queue
This article has been written using the Windows release of 12.08.09.1, and is intended to be an overview of the core updates rather than an in-depth review of the Exodus viewer (see articles list at the end of this items for further information on Exodus).
Download and Install
The Windows downloader weighs-in at a modest 28.4Mb. Installation on my system was fast and smooth (as per usual, this was a clean install for me). Start-up revealed the familiar Exodus blue sky screen with core information (particularly updates from the Grid Status Page) along the bottom. No implementation of the official splash screen here. However, if you do have issues trying to run Exodus following installation – and in particular get error messages relating to .dll problems, you might try visiting the Exodus FAQ page and following the link therein.
Logging-in revealed the familiar Exodus default screen layout, with buttons to the left and button of the screen, which can still be repositioned to the left or right, top or bottom of the screen.
Avatar Troubleshooting
Avatar Troubleshooting takes a leaf from the Firestorm book and offers three options for dealing with avatar issues. These can be found in a menu under Me->Troubleshooting and comprise:
Reload My Avatar Data: sends a request to the SL servers to download your avatar data once more. Useful where you’re seeing outfit changes but other’s aren’t (often indicative that something is going wrong within your computer, rather than anything at the server end)
Rebake my avatar textures: performs a normal local rebake, with the data sent to the server for distribution
Reset my avatar: Ruths your avatar to default shape and clothing, allowing you to rebuild it in the event of a drastic error.
Toolbar Buttons
This release of Exodus includes two additional buttons, Web, which opens the viewer’s built-in web browser, and Panic. The latter is a hang-over from testing nightly builds and debugging. As such, it is not intended for general use and may be removed or re-purposed in the next release. It is not recommended you employ the button, as it is intended to crash the viewer and generate a crash log.
Snapshots to Flickr
Flickr is a popular medium for SL photographers, so having an option to save pictures directly to it is likely to be a benefit to many. With this release, Firestorm obtains Katharine Berry’s code (Katharine also recently joined the Exodus team) to enable snapshots to be uploaded directly from the viewer to a Flickr account.
The option is presented as an additional button on the snapshot floater. The first time you click on this, it will cause a pop-up to be displayed:
Setting-up Flickr to accept snapshots from Exodus
Clicking on YES will take you to the Flickr authorisation page, which will outline the possible risks of connecting Exodus to Flickr (a standard alert page, common when using inter-application authorisation). Read the warning carefully, and if happy, confirm yo wish to proceed (refusing cancels the link and denies Exodus the ability to upload to Flickr).
Confirming that you’re happy to proceed will display a code number on the Flickr web-page. Type this into the authorisation pop-up displayed in Exodus. This will activate the link and allow you to take your snapshot and send it to Flickr. Again, note the authorisation process only has to be completed the first time you attempt to upload a snapshot directly to Flickr, thereafter snaps will be sent to your Flickr account without hindrance.
Nalates Urriah has been keeping an eye on the more technical aspects of pathfinding, and has routinely provided excellent updates and commentary on the project. Her work is largely the reason I’ve not delved overly deeply into the subject here, and why my own Pathfinding overview attempts to cover the subject from a lay user’s perspective.
Alongside yesterday’s roll-out came a lot of confusion regarding pathfinding and its impact on region performance. As a result of this, Nalates published a piece seeking to clarify matters. If you are concerned as to the impact of pathfinding, and you’ve not already done so, I thoroughly recommend you give her article a careful read.
Today, Lorca Linden took the extraordinary step of commenting on Nalates blog in order to lend further clarification on the subject. While I do not agree with his stated reasons as to why Linden Lab did not communicate more on the actually roll-out (which, in fairness, has potentially contributed to the confusion / misinformation circulating about pathfinding), the key points of Lorca’s comments vis-a-vis overall performance are nevertheless important in helping to spread better understanding of the matter. I’m therefore reprinting his comments here in full, with the key paragraph on performance underscored, in the hope that it will help them reach a wider audience.
“Although Lindens do not generally post on Resident blogs, I am going to make an “exception in this one case. Don’t expect us to make a habit of it, though 🙂
“I want to start off by thanking Nalates for what I feel has been even-handed coverage of pathfinding as a whole. While I disagreed with several of the assertions made in the “Tsunami” post, it did make us realize that there were misconceptions about pathfinding that needed clarification (particularly in regards to performance implications) and was a useful data point in identifying Resident concerns while we were still in the development phase.
“The 18% performance hit figure referenced on the Phoenix Viewer blog is a worst case scenario that will rarely be seen in practice – eg, you could see that large of a hit on a poorly optimized region that contains hundreds of pathfinding characters running simultaneously. Average perceived (viewer side) fps grid wide was actually .03 fps higher yesterday afternoon than it was the afternoon before. Average server-side performance grid wide was also inline before and after pathfinding server code was rolled out. Region crash rates – excluding a bumpy couple hours during the roll out – remain low. All of this is to say that as far as the Lab can tell, Pathfinding has not had a negative performance or stability impact in the vast majority of situations.
“I also want to make clear that the impact on some vehicles is not directly related to pathfinding per say but rather the underlying physics and terrain optimizations that made pathfinding possible and have benefits beyond pathfinding. As far as we can tell, only a small percentage of existing content is affected by this physics upgrade.
“We do not consider pathfinding to be fully released until the pathfinding viewer tools are out of beta. This is why we have not yet made an official announcement. I agree that we need to do a pass on our pathfinding related wiki as some of the information there has not been updated since we were in alpha. We plan to make a blog post in the near future that will address some common misconceptions we have heard about pathfinding. We also plan to continue updating the “Good Building Practices” guide so that it will be a useful resource for Residents looking to make optimized content.
“We understand that pathfinding can be a confusing topic at times and appreciate the effort interested Residents are making to absorb the technical details. If you have any burning questions about pathfinding, please come to our user group on Pathtest1 (on Aditi) at 4PM SLT Thursdays and ask away. Above all, we are extremely excited to see what you Residents create with the new pathfinding tools and LSL functions!”
Inara Pey: Living in a Modemworld 