Materials processing: the what, why and where

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

Viewer release summary 2012: week 33

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

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

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?

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).

Pathfinding: playing inside buildings

Over the last couple of days, I’ve been experimenting with setting pathfinding characters roaming within buildings. What follows is not intended to be definitive, but more a case of what I’ve found so far. Until there is more up-to-date documentation from LL on setting-up pathfinding, this was very much thumb-in-the-air stuff, and as ever, YMMV. I’m still fiddling with things, and may add a further article later.

Characters with Impact

For the test, I used a basic pathfinding script to animate a cube (which I called “Charlie”). It was simple and was enough for the basic task. One thing to bear in mind with pathfinding characters is that they’ll have a land impact of 15. This is related to the character’s physics weight, and will not change as a result of adding / removing prims (a 1-prim character will still have a land impact of 15 as will a 30-prim character), although other factors (such as streaming cost) may raise the LI.

People may find the idea of a 15 LI character “harsh” (esp. if the prim count is lower). For my part, I don’t think it is that bad; it still allows for a fair few NPCs in a role-play region without significantly impacting prim counts.

Setting Attributes

Setting-up a building in which pathfinding characters can roam requires setting the correct pathfinding attributes. During my tests, I wasn’t trying for anything sophisticated like setting-up paths; rather, I wanted to see how a simple character (like a pet or animal) would roam and interact with its surroundings.

Pathfinding attributes, as outlined in my pathfinding overview, are set via the Linkset floater. There are a few points that need to be noted prior to doing this:

  • Only one attribute can be set for a linkset, so if your structure includes walls and floors within the same linkset, you cannot set one attribute for the floor, another for the walls, and so on
  • It is possible to set pathfinding attributes against NO MOD builds, as pathfinding attributes are not the same as object permissions. However, there are caveats to this – such as whether or not the build includes things like scripted doors (see the following bullet point)
  • Attributes which affect navmesh calculations (e.g. Walkable, Static Obstacle, Exclusion Volume, Material Volume), should not be set against linksets with scripted moving objects (such as doors). Doing so will prevent the scripts in the objects working as intended
    • If you have a structure which includes things like doors, these must be unlinked first and their attribute left as moveable obstacle
    • Obviously, in the case of NO MOD builds, this potentially limits your choices as to how you enable pathfinding within a building and in ensuring pathfinding is suitably optimised.
Pathfinding attributes for buildings require setting with care to avoid possible “breakages”

To set an object’s pathfinding attribute:

  • Right-click on the linkset for the object  and select Show in Linksets
  • Select the required attribute from the drop-down list
  • Apply the attribute to the linkset
  • Use the Rebake Region button which will appear at the bottom of your screen to update the region navmesh.
Setting an object’s pathfinding attributes

Walkable Areas

Broadly speaking, the following options are available when creating walkable areas in a building:

  • Set the entire structure to Walkable. This works reasonably well, however:
    • For modifiable builds, all scripted moveable elements must be configured as linksets separate to the main structure, as noted above
    • This option should not be used for NO MOD buildings with scripted moveable elements integral to the structure
  • If the building’s floor areas are already an independent linkset, set that linkset to Walkable
  • If the building is modifiable, unlink the floor areas and then re-link them as an individual linkset which can be set to Walkable
  • Create your own floor “overlays” from prims, position them over the existing floors and then set their attribute to Walkable (useful in NO MOD builds which include scripted moving elements).

Which of these options you use is down to the building you have and personal choice. I found that setting an entire building to Walkable (after taking care of the door linksets) worked perfectly well for the most part.

Placing a Walkable floor into a build. Left: the floor prim and house; right: as seen in navmesh view with house selected (wireframe) and the floor in green to indicate it is walkable. Note the floor equates to one room of the house

Note you can set the Walkable attribute for the floor prims prior to positioning them, but you’ll have to run a region rebake once you’ve done so. You can “hide” the floor prims by making them transparent.

I should also note that in terms of furnishings, I left anything set with the Movable Phantom attribute alone, and anything set to Movable Obstacle to Static Obstacle (this did not “break” any scripts for sitting, etc.).

Optimising

To give better control over characters roaming inside a building you might wish to set additional attributes against individual elements in a building. For example, in setting an entire building to Walkable and with Charlie moving at the default character speed, I found he would periodically “pass through” a wall or window and continue roaming around outside. I stopped this by setting the walls of the building to Static Obstacle. As well as potentially helping with character behaviour, setting additional attributes for linksets and objects helps optimise pathfinding for the entire region in which it is being used.

Use the page numbers below left to continue reading