Category: SL Tech

Helping the community: the Phoenix Firestorm Support region

Posted on by Inara Pey

Update Aug 25th: The region is now open. See the link at the end of this article to visit.

This weekend, the Firestorm team will be launching a new in-world venture: the Phoenix Firestom Support island.

The region is designed to serve two purposes. One is to provide help and support for users of any calibre, via the use of in-world tutorials supported by real life help in the case of users new to SL, and via the provisioning of an area more focused on providing real life help for users more familiar with SL and the viewer. The second is to provide an in-world base of operations to support Firestorm users in particular.

Firestorm’s new support island

The region is somewhat mindful of the old SL Orientation Islands where new users to SL learned about the basics of the viewer and how to do things – so much so, in fact, that I was half-expecting to find a beach ball and table during my preview explorations :). While neither turned up, I did smile on coming across a large and talkative phoenix, itself a reminder of the OI parrot…

However, this is not to say that the region has been deliberately modelled on the old Orientation Islands. As Jessica Lyon, the Phoenix / Firestorm project lead pointed out to me as we discussed the island and the ideas behind it, it’s a matter of form following function. A relaxed and visually pleasing tutorial path with few distractions naturally lends itself to this kind of open-air approach.

The main element of the region is a path which leads people around the island from the arrival point, taking them past various lessons in gaining familiarity with Second Life and the viewer. These are very much focused on “learn by doing” – such as jumping over a fence to understand walk / jump – and are very clearly and cleanly presented, and obviously intended for the more novice user.

Arrival point

The signs are clear and concise, and while based on Firestorm running in a default mode (i.e. with the pie menu active), they easily translate to other viewers, whether they are using pie or context menus.

Within this sits a central area where questions about Second Life and viewer use that go beyond those that tend to be asked by “new” users can be addressed. This can be reached via a bridge from the outer area of the island or via a teleporter located at the arrivals point.

The central area, where the more experience user can seek focused assistance from staff and mentors

A key aspect of the region is that is designed to be staffed. Although it had originally been hoped that in-situ help relatively small, things haven’t quite work out as originally envisioned. “Our original plan,” Jessica told me, “Was to have a first entry to SL region for zero – 30 day accounts only, and would staff it with our own support staff and a careful selection of mentors/helpers. We have a RegAPI from LL [which would allow Firestorm to run a sign-up page and deliver new users directly to the region]. Unfortunately, it doesn’t work with “Resident” last names, so we had to switch to plan B. Plan B is to open the region to the public, and heavily staff it with mentors and helpers to ensure new and old residents alike get real help from real humans.”

As a result of the switch to “Plan B”, and to ensure the island is properly staffed, invitations to participate have been sent to the RHN, White Tiger Mentors, Mental Mentors and other groups. One potential benefit of this is it will help ensure there’s a much more diverse wealth of experience on-hand to deal with viewer-centric questions than might otherwise be the case were the island solely staffed by Firestorm-focused volunteers.

Continue reading “Helping the community: the Phoenix Firestorm Support region” →

Materials processing: the what, why and where

Posted on by Inara Pey

On August 16th, Linden Lab announced the forthcoming arrival of material processing in SL in the form of specular and normal maps. At the same time, a video was released demonstrating some of the capabilities. But what does this actually all mean for the everyday user in SL? Here’s what I hope is a lay guide to things, including comments from one of the architects of the new system, Geenz Spad, as to how it came about.

Materials Processing

This is not intended to be a technical discussion on computer graphics mapping in general or on normal or specular maps in particular. Rather, it is intended to provide a broad, non-technical explanation as to how the latter work. 

Materials processing is the combining of various computer graphics “maps” to significantly increase the level of detail that appears on any object or surface within a computer game. Within Second Life, textures (themselves a form of computer graphics map called a diffuse map) are routinely used to add the illusion of surface details to in-world objects and surfaces. The new material processing capability will introduce two further kinds of computer graphics map to SL which can be used in-world with textures to dramatically increase the detail and realism of objects and surfaces. These additional maps are called normal maps and specular maps.

Normal  Maps in a Nutshell

Normal maps (sometimes referred to as bump maps, although they are more rightly the most common form of bump map) are a means of faking high levels of detail on an otherwise bland surface by means of simulating the bumps and dips that create the detail. Normal maps can be created in several ways.

For example, when working with 3D models, a common method is to make two models of the same object: one a very complex, highly detailed model with a high polygon count, the other a much lower polygon count model with significantly less detail. An overlay process is then used to generate a normal map of the detailed model’s surface features which can be applied to the less complex model, giving it the same appearance as the highly detailed model, but for just a fraction of the polygon count, reducing the amount of intensive processing required to render it.

Using a normal map to enhance the detail on a low-polygon model. The image on the left shows a model of some 4 million triangles. The centre image shows a model with just 500 triangles. The image on the right shows the 500-triangle model with a normal map taken from the model on the left applied to it (credit: Wikipedia)

Another common way to produce a normal map is to generate it directly from a texture file. Most modern 2D and 3D graphics programs provide the means to do this, either directly or through the use of a plug-in (such as the nVidia normal map filter for Photoshop). When combined with diffuse maps, the normal map creates the impression of surface detail far greater than can be achieved through the use of the texture alone.

Normal map from a texture: left – the original texture (diffuse map) and its normal map shown as a split view; right – the material resultant from applying both maps to surfaces inside a game (credit: Valve Corporation)

Specular Maps

In the real world, every highlight we see in an object is actually the reflection of a light source. Surfaces and surface details reflect light differently to one another, depending on a range of factors (material, lighting source point(s),  etc.). Specular maps provide a means of simulating this by allowing individual pixels in an object to have different levels of brightness applied to them, giving the illusion of different levels of light being reflected by different points on the object.

When life gives you lemons: a mesh lemon with (l) a  normal map  applied, and (r) a normal and a specular map together. Note how light is apparently being reflected across the surface of the latter (credit: Mind Test Studios)

Like normal maps, specular maps can be produced in a number of ways, both within 3D graphics modelling programs and in tools like PhotoShop. As shown above, they can be combined with normal maps and textures to add detail and realism to 3D models and flat surfaces.

What Does This Mean for Second Life?

Second Life itself already includes a dynamic example of how normal and specular maps can be used: Linden Water. This is created using an animated normal map to create the wave-like effect for the water, while an animated specular map adds the highlights and reflections. The result is a very realistic simulation of moving water able to catch and reflect sunlight.

Just as the use of normal and specular maps create a very real illusion of water with Linden Water, the new materials processing capabilities will significantly enhance the look and realism of both mesh and prim content within SL. Mesh content should additionally benefit as it will be possible to produce high levels of detail on models with low polygon counts (as shown in first image in this article). This will improve rendering performance while also having the potential to lower things like land impact for in-world mesh items.

The only initial limitations as to where and how normal and specular maps can be applied is that they will not be applicable to avatar skins and system layer clothing. Any decision on whether the material processing capability should be extended to include these will depend upon at least two things:

  • Community feedback – whether there is a demand for normal and specular maps to be used with avatar skins
  • Understanding what is happening with the avatar baking process, and determining what is involved in getting the new baking process and material processing to work together.

Use the page numbers below to continue reading

Pages: 1 2

Viewer release summary 2012: week 33

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: 19 August, 2012

  • SL Viewer updates:
    • Development: rolled to 3.4.1.263582 on Aug 16
  • Dolphin rolled to 3.3.19.24756 on August 17 – core updates: hotkey to open / close Outfits floater; added Preferences option (Prefs->Dolphin Viewer 3->Build) to save scipts as LSL or Mono when editing directly from Inventory; added “auto media play” button (“A”) to media controls at the top right of the viewer window; Client (avatar) Phantom option hidden (no longer functional under pathfinding) – release notes. Dolphin also announced cessation of OpenSim support in preparation for Havok sub-licence compliance
  • Exodus release version 12.08.14.1 on August 16, (release notes) – primarily a hot fix release for the 12.08.09.1 release, incorporating Visual C++ 2010 runtime to avoid installation errors ability to rez objects under land group; updates to visual presets and raid advisor lists formats to conform with LLSD
  • Niran’s Viewer rolled to 1.49 on August 14 – core changes:  further updates to the Preferences overlay; Graphics tab in default Preferences updated; bug fixes (release notes)
  • Restrained Love Viewer released version 2.8.3.4 on August 17 – core updates: pathfinding tools (excluding Navmesh visualisation*), improved Mouselook aiming controls; JPEG library handling improvements to reduce crash rates (release notes)
  • Zen viewer rolled to version 3.4.0.2 on  August 17, after rapidly cycling through updates on the 13th and 14th August. Core updates – pathfinding tools (excluding Navmesh visualisation*); removal of mesh deformer; Keyword Alerts added to Preferences->Chat; Remove Scripts option added to menus; updated shaders; numerous bug fixes (release notes)
  • Cool Viewer: Stable branch rolled to 1.26.4.25  and Experimental to 1.26.5.4, both on August 18 – core updates in both: initial pathfinding support (excluding Navmesh visualisation*); various SLV 3.3. code back ports (release notes for both)
  • LittleSight released version 1.1.0 – fix fix release for failed log-ins and other issues

(*requires Havok sub-licence.)

Related Links

Pathfinding: starting to reach TPVs

Posted on by Inara Pey

The pathfinding tools are starting to find their way into TPVs well ahead of showing any sign of moving from the SL Beta Viewer to the release version.

The delay in updating the release viewer may be down to several reasons. One of these might be that Linden Lab staff acknowledge the pathfinding documentation is currently undergoing update and rationalisation, and so the capability is still regarded as being “in beta”.

The table below is a list of current TPV versions (August 19th) of TPVs which have started to embrace pathfinding, and indicates the tools provided.

(click to enlarge if required)

Note that the Navmesh View  / Test option is tied to the new SL Havok sub-licence arrangement, as such none of the above viewers are able to include it unless / until they sign the sub-licence agreement (and are eligible to do so). However, visualising the navmesh is not essential to setting pathfinding attributes for objects in-world or optimising regions where pathfinding is being actively used. Other “missing” functionality as indicated in the table above will doubtless be addressed by the viewers in future releases.

Links for these viewers, including to their release notes, can be found on my Viewer round-up page.

Related Links

The grid divide: TPVs and OpenSim support

Posted on by Inara Pey

At the start of the month, Hypergrid Business reported on Linden Lab’s removal of support for the –loginURI parameter from versions of the SL Viewer.

This command is most commonly used to modify the command path used to launch the viewer, allowing it to connect to grids other than Second Life. It has already been removed from the latest development ad beta versions of the viewer, and as such will find its way to the release version in the near future.

For the majority of people who use the official viewer and only access Second Life, the announcement passed largely unnoticed. Even among those who do routinely bounce between Second Life and other grids using TPVs, the impact of the change was minimal – most viewers openly supporting access to both Second Life and OpenSim grids tend to do so through the use of a grid selector / grid manager option – which remained unaffected by the change.

The Shape of Things to Come

However, the removal of support for –loginURI was the tip of the iceberg.

In April of this year, Linden Lab announced a sub-licencing arrangement involving the Havok physics engine. While there is already some Havok functionality evident in the viewer as it is (used in conjunction with mesh uploads and pathfinding), the licence arrangement enables Linden Lab to develop a library of Havok functions for the viewer. In time, this may prove to have significant benefits for Second Life; however, there is a catch.

Once the new Havok libraries are in place and available for use, the terms of the sub-licence require that any viewer accessing them only connects to Second Life. Period. Ergo, no grid selector, no grid manager and no support of –loginURI or any other means of provisioning OpenSim log-in support for such viewers.

In other words, once the arrangement is up and running, those TPVs that currently support both Second Life and OpenSim access, and which are eligible to make use of the new LL Havok libraries, have to make a choice as to their future direction:

  • Do they sign-up to the new sub-licence agreement to gain access to the new libraries and completely forgo any OpenSim support they may have provided?
  • Do they fork their development to provide two flavours of their viewer – one configured to access SL only and make use of the new Havok libraries, the other specifically aimed at OpenSim and unable to access the Havok functions?
  • Do they abandon SL altogether and instead focus solely on OpenSim?
  • Do they perhaps opt to forgo the use of the new library functions and continue “as is”, ignoring any new capabilities provisioned via the Havok libraries?

The option to fork development between SL and OpenSim probably comes down to matters of bandwidth, maintenance and audience. Does a TPV have the bandwidth to develop two flavours of viewer? Does it enjoy a sufficiently largely audience in both SL and OpenSim to warrant the time and effort needed to do so?

Firestorm

The Firestorm team announced in June that they would continue to support both Second Life and OpenSim by forking the development of the Firestom viewer between the two in the near future (if this has not in fact already happened in the intervening time).

While one version of Firestorm will remain focused on Second Life, the second branch will be geared towards general support of the OpenSim platform and not incorporate code from Linden Lab that is ring-fenced by the new sub-licence arrangement.

Niran’s

In July, NiranV Dean confirmed Niran’s Viewer would not be supporting OpenSim – although the decision was possibly as much based on a personal preference as having anything to do with the upcoming Havok sub-licence situation.

Dolphin

dolphin-logoNow, with the new sub-licence arrangement looming, Dolphin Viewer developer Lance Corrimal formally announced on August 18th that future versions of Dolphin will be solely focused on Second Life as he doesn’t have the bandwidth to maintain three flavours of his viewer across two environments (Second Life and OpenSim). He will, however, be providing a clone of the original repository should anyone wish to fork it and make an OpenSim specific version.

It remains to be seen if other TPVs will make formal announcements and which route they will opt to take.

Looking to the Future

Some commentators, on hearing the news regarding –loginURI, reacted negatively, with some citing the move as a further indication of the demise of SL. These reactions would appear unwarranted. It is unlikely that any split in how either Second Life and OpenSim are accessed is going to have a major impact on either the use of SL or its longevity.

Similarly, while some may be personally inconvenienced (having to move between two viewers depending on whether they are logging-in to SL or an OpenSim grid),  it is hard not to see this situation as anything but beneficial for OpenSim. If nothing else, it frees those viewer developers who wish to focus on OpenSim to develop functionality and capabilities  within the viewer that are specifically geared to the platform (e.g. much improved OSSL support) and unfettered from any constraints or worries about maintaining compatibility with SL (such as the 4,096-region teleport limit).

Related Links

SL Viewer: getting up steam for Steam?

Posted on by Inara Pey

secondlifeFollowing-on from the announcement that Second Life will soon be available through Steam, it appears the viewer itself is going through some small changes in order for it to be better used with SL.

Yesterday, I downloaded the latest Development version of the viewer. As per usual, I performed a clean install, removing the older version & the associated user and log files. On starting the viewer, I was surprised to see the log-in screen displayed with an additional pop-up:

SL Development Viewer 3.4.1.263582, (August 16)

Clicking Create Account pops-up the familiar “Do you want to open your web browser” dialogue box, prior to taking you (on clicking OK) to the SL sign-up page. I confess I have not (as yet) run through th actual sign-up process to see if that has changed in preparation for the Steam tie-in, but I’ll be doing so around the time the tie-in is announced as being live, if only out of curiosity.

Clicking Continue from the prompt will allow you to log-in using an existing account, and the prompt to sign-up is not repeated the next time you launch the viewer.

Alongside the new pop-up message, the actual log-in area of the viewer splash screen has been tidied-up and made more presentable.

The cleaned-up log-in credentials area of the splash screen, completed with grid access option enabled (Main and Beta grids only)

Assuming these changes are a part of the preparations for the link-up with Steam, they would appear to answer how users coming to Second Life via Steam will be directed to the sign-up pages. As such, it will be interesting to see what, if anything, will be done to make at least the initial sign-up page more informative as to what Second Life is, or whether this will be handled directly through the SL page(s) on Steam itself (I personally suspect the latter).