EEP Tutorial: reflective floors

With EEP, it is now possible to have reflective floors at the parcel level that everyone can see, and contained within the parcel

Within Second Life there have been numerous ways to produce reflective floors within buildings – the most popular being to build a near-duplicate of what is in a room / building and inverting it “below” a textured, semi-transparent floor, allowing the duplicate to act as a reflection.

It’s a clever means of achieving the idea of reflections in polished floors, and has the advantage of being relatively “efficient” performance-wise (if a little hard on land impact, depending on the degree to which a person goes with the “reflected” items under the floor), as it means re-use of loaded textures and avoids rendering avatar reflections and mirroring movement. Although that said, the fact that the technique doesn’t show avatar reflections can spoil the effect.

Nitroglobus Roof Gallery provides an excellent demonstration of using a duplicate build to create the illusion of a reflective floor (although note the lack of any avatar shadow)

As has long been known, Linden Water can also be used as a means of producing reflective floorsthat can reflect avatars as well as objects. However, under Windlight, it has tended to suffer from a couple of observable weaknesses: if applied at the region level, it meant all water viewed from the region with produce the mirror effect – which could be a problem when outdoors (e.g. a mirror-flat surrounding sea); while to use it at parcel level meant using a viewer that accepted viewer-side parcel Windlight support – so anyone not using such a viewer would see a building / room with “flooded” floors.

EPP, with its simulator support for for parcel-level environment settings, means that is now possible to use Linden Water to create reflective floor effects within ground-level building that can more easily been seen by anyone entering the building, regardless of the viewer they are using. There are some pre-requisites involved, both it terms of creating the effect and viewing it, but even so, it is relatively easy to implement for anyone who wishes to do so.

Those prerequisites are:

  • As the approach uses Linden Water, it can only bee used at ground level (and on ground-level rooms of such buildings).
  • Some skill with terraforming is required, in particular:
    • Lowering / levelling land – this is important as the “reflective” floors must be at water level.
    • Ability to sub-divide land into parcel – this is particularly important if there is Linden Water is visible from outside the building with reflective floors, as you’ll be making changes to how Linden Water appears.
  • For parcels, you’ll need to have permission to set the environment at parcel level – if you do not own the region, and parcel level EEP support has been disabled via the region level controls, you will have to discuss the matter with the region holder / owner.
  • Those visiting the building must have Preferences → Graphics → Water Reflections set to All Avatars and Objects or Everything in order to see the water reflecting everything, including avatars.

The approach works best with your own builds, but can be used with pre-fab builds if they are modifiable, and can have floors modifed / replaced.

1 Prepare Your Land and Building

The first thing you need to do, is determine the shape of the floor space you wish to has as a reflective space and prepare the part of your land where it is to go.

  • Make a simple prim template of the shape of the room / building.
  • Place the template on your land where the room is to be positioned.
  • Keep in mind that depending on your location, you may want to sub-divide your land (if you have the necessary permission) so you can see natural-looking Linden Water when outside your house.
  • Use the terrafrorming tools in the Build / Edit floater to carefully lower the land under the template to expose the Linden Water.
  • Note that the “reflective floor” will, when the work is finished, need to sit just below the level of Linden Water. This means you may have to set it lower than the floors in other rooms on the ground floor of the building, or have the building itself surrounded by a mesh / prim surround to blend it with the ground level.
  • When you’re set, position the building and if necessary sub-divide your parcel.
  • Edit the building and:
    • Sset each of the floors you wish to be reflective to around 80% transparent – note that you may have to experiment with this setting, depending on the floor texture you use.
    • Apply a suitable texture for the reflective floor(s) (e.g. a wood texture for a polished wooden floor, or a marble effect for a public building).

2. Set the Water Environment

As noted above, you’ll need a suitable normal map to replace the one used for Linden Water.

  • The easiest way to do this is to use the Mirror Water environment asset that is included in the viewer under Library → Environments → Water.
  • You will need to copy this asset from its default Library location to your inventory (e.g. to the Settings folder – or a sub-folder within Settings, if you organise your EEP assets in sub-folders).
You can use the Mirror Water environment asset to help create your reflective floor. Make sure you copy it (e.g. via drag-and-drop) to your Settings folder
  • With the Mirror Water environment asset copied to your inventory, double-click on it to edit it. This will open the Fixed Environment – Water panel.
  • Within the panel, make the following changes (see the image below for reference):
    1. Set the water fog colour to white (note that depending on things like ambient lighting, the floor texture you use, etc., you may need to adjust this towards a more grey colour).
    2. Set all of the following to 0.0:
      • Fog Density Exponent and Underwater Multiplier.
      • Fresnel Scale.
      • X, Y, Z Reflection Wavelet Scale.
      • Large and Small Wave Speed.
      • Refraction Scale (Above) and (Below).
    3. Set Fresnel Offset to 0.50 (note that depending on things like ambient lighting, the floor texture you use, etc., you may want to adjust this up or down).
    4. Set Blur Multiplier to 0.80 (note that depending on things like ambient lighting, the floor texture you use, etc., you may want to adjust this up or down).
    5. From the Save / Apply Drop-down, select Save As and save your updated environment asset under a new name (e.g. “Reflective Floor”).
Adjusting the water settings for a reflective floor effect
  • Once saved, Select Apply to Parcel from the Save / Apply drop down to apply the environment to the parcel.

3. See How It Looks / Fine Tuning

You should now have a nicely reflective floor to your building, as shown below.

The finished product again, as per the banner image, note the avatar reflection and well as the reflections of in-world objects (1), and also the use of steps to access the low-set floor of the gallery from the outside “ground level” (2)

What’s more, if the building is sitting within its own parcel, when you leave the building, any visible Linden Water should look like natural water  / waves (although if you cam into the building or glimpse the “reflective floor” from outside of the parcel, it might look a trifle odd until you actually enter the parcel).

You might find that some additional “fine tuning” of the build is required to achieve a perfect result. If you’ve placed your floor a little above the level of Linden Water, for example, you may find your avatar “floats” over its reflection (below left), or if the floor is set a little too far below the level of Linden Water, the avatar and reflection may appear to “merge” at feet / ankles. But errors can be corrected with careful adjustment of your floor either down or up.

You may have to adjust the floor level relative to the Linden Water level to prevent avatar reflections giving the impression avatars are floating above the floor (l) – or standing with feet embedded in it – and actually standing on the floor (r).

Conclusion

There are still some limitations on the effectiveness of this approach: as noted above, it can only be used for ground-level interiors, and the effect does require visitors to have their graphics preferences set to reflect avatars in Linden Water. However, once set-up, it can add a certain edge to places like stores and galleries.

I’m not sure how much of a performance hit would occur in viewers trying to render a lot of avatars and their moving reflections in a ballroom or other dance venue, so these might require greater consideration. But if you do want to have a different ground-level flooring for your building, and you can meet the prerequisites noted above, it might well be worth giving it a go.

Tutorial: Viewer Camera Presets

The default viewer camera placement has long been the bane of the Second Life viewer. Placing the camera well above and behind the avatar, it gives an awkward over-the-head view of the world, rather than the more intuitive over-the-shoulder view seen in many video games.

While the camera’s debug settings have allowed a custom camera preset to be set-up, it has never really been possible to easily create, save, and swap between presets according to need.

Table of Contents

The Camera Presets controls, developed and contributed by Jonathan Yap, the developer responsible for the graphics presets options in the viewer (see Avatar Complexity and Graphics Presets in Second Life for more), changes this. It is a capability that allow users to create one more more custom camera presets within the viewer to suit particular needs and then save them. This means, for example, you can now have a camera position for general exploring, another suitable for combat games, another for building, etc., all of which can easily be accessed and used at any time.

This tutorial explains how to create and use presets via Camera Presets options.

Note: at the time of writing, the camera presets options are only available in the official viewer, version 6.4.2.541639 or later.

UI Elements

There are five UI elements associated with creating and using camera presets:

  • The Camera Presets icon and drop-down – presenting the means to quickly access and use created camera offsets.
The Camera Presets icon, found in the top right of the viewer window, and a populated version of the drop-down that can be displays on clicking on it.
  • The Camera Controls floater. This provides access to provides access to the following:
    • The familiar “on the fly” controls for positioning the camera / selecting any of the pre-set camera positions, setting the camera focus or switching to Mouselook. These can also now be used to create a custom camera preset.
    • Camera Position floater for creating new camera presets numerically.
    • Save Camera Preset floater – save any preset you have created or replace an existing preset with new values.
    • My Camera Presets floater – allows you select and delete any preset you have created, or reset your camera to one of the viewer’s default front, side or rear camera positions.
    • In addition, the Camera Controls floater includes a drop-drop menu to provide quick access to any custom camera presets you have created.
The Camera Controls and camera presets floaters – click for full size, if required

Creating a Custom Camera Preset

Using the Camera Controls

  1. Open the Camera Control floater by:
    • Hovering the mouse over the Custom Preset icon at the top right of the viewer window to open the drop-down and then clicking the Open Camera Floater button OR.
    • Clicking on the Camera Controls (Eye) button in your viewer’s tool bar, OR
    • Selecting Me→Camera Controls… from the viewer menu bar.
  2. With the Camera Control floater open, clicked the required view button (Front, Side, Rear) if required.
  3. Use the camera orbit, slide and zoom controls on the left of the camera floater to position your camera as you would like it to be relative to your avatar.
  4. When you are satisfied with the camera position and angle, click Save As Preset button in the floater, and:
    • Either make sure the Save As New Preset radio button is selected and type a name for the preset in the text box.
    • Or click the radio button for Replace a Preset, then click the button to display a list of current presets and highlight the one you wish to replace (including one of the three default positions, shown in italics).
  5. When you have entered a name or made your choice, click Save.
Using the camera controls to create a camera preset

Using the Precise Controls

If you have a numeric set of camera and focus offsets you use (e.g. such as those provided by Penny Patton, or use the table below to set your camera to some typical view points):

  1. Open the Camera Control floater by:
    • Hovering the mouse over the Custom Preset icon at the top right of the viewer window to open the drop-down and then clicking the Open Camera Floater button OR.
    • Clicking on the Camera Controls (Eye) button in your viewer’s tool bar, OR
    • Selecting Me→Camera Controls… from the viewer menu bar.
  2. In the Camera Controls floater, click on Use Precise Controls.
  3. In the Camera Position floater:
    • Enter the X, Y and Z figures for the camera offset position.
    • Enter the X, Y, Z figures for the focus offset position,
    • Use the slider to set how near / far the camera is to be positioned from your avatar.
  4. When you are satisfied with the camera position and focus, click Save As Preset button in the floater, and:
    • Either make sure the Save As New Preset radio button is selected and type a name for the preset in the text box.
    • Or click the radio button for Replace a Preset, then click the button to display a list of current presets and highlight the one you wish to replace (including one of the three default positions, shown in italics).
  5. When you have entered a name or made your choice, click Save.
Setting a precise position for a camera preset

The following table offers Penny Patton’s recommended positions for over-the-shoulder camera presets.

Over the Left Shoulder
Centre
Over the Right Shoulder
Camera Offset
X= -2.0
Y= 0.4
Z= -0.2
X= -2.0
Y= 0.0
Z= -0.2
X= -2.0
Y= -0.4
Z= -0.2
Focus Offset
X= 0.9
Y= 0.7
Z= 0.2
X= 0.9
Y= 0.0
Z= 0.2
X= 0.9
Y= -0.7
Z= 0.2
Offset Scale Slider
1.5 1.5 1.5

Using Your Custom Presets

From the Presets Icon

  1. Hover the mouse over the Custom Preset icon at the top right of the viewer window to open the drop-down.
  2. Click on the required preset name to select it.

From the Camera Controls Floater

  1. Click on the Use Preset button in the Camera Controls floater.
  2. A drop-down of custom camera presets is displayed.
  3. Click on the required preset name.
  4. The preset is selected, and the button updates to display the preset’s name.
Using a custom camera preset

Deleting or Resetting Default Presets

Notes:

  • You can only delete custom presets and reset default presets.
  • No confirmation is requested: actions will be immediately implemented – so if you have overwritten one of front, side or rear camera position presets, your custom version of that preset will be lost when reset.
  1. Display the Camera Controls floater.
  2. Click the gear icon.
  3. The My Camera Presets panel opens (may default to the top left of your screen).
  4. Hover the mouse over the preset you wish to delete or reset.
    • Custom presets will display a trash can. Click it to delete the preset.
    • Default presets will display a reset icon. Click it to return the preset to its original values.

Environment Enhancement Project: a primer

The Environment Enhancement Project (EEP) is a set of environmental enhancements designed to replace windlight XML settings to control the water and sky environments seen in Second Life, and provides a wide range of additional / new capabilities for region holders, parcel holders and general users. It represents a fundamental shift in how environment settings are used and applied.

In brief EEP:

  • Uses environment objects that you can keep in your inventory and / or share with others.
  • Provides parcel-level control of environments.
  • Allows up to four different, independently controlled sky layers.
  • Allows the Sun, Moon and Cloud textures to be replaced with custom textures uploaded to the viewer.
Table of Contents
  • Provides an extended day cycle of up to 168 hours (thus allowing a 7-day, 24-hour day / night cycle to be defined, for example).
  • Allows users to override region / parcel settings as seen within their own viewer, by either attaching EEP settings to their avatar or through the Personal Lighting floater.
  • Provides new LSL functions to allow scripts to interact with parcel environments.
EEP allows you to have a little fun, if you wish. Credit: Bellimora

Many have already gained familiarity with EEP whilst it has been in development, using both the original project viewer and iterations of the release candidate viewer. However, given it is such a fundamental shift in how environment settings are created and used, I have attempted to break things down into more easily digestible pieces through the use of this EEP primer, and a more comprehensive EEP tutorial.

  • This primer is designed to provide an overview of the basic EEP capabilities and options from the point-of user of someone wishing to use them.
  • The EEP Tutorial is intended to provide a comprehensive breakdown of EEP capabilities, including how to create new EEP sky, water and day settings for personal use or which can be given or sold to others.

You can use either this primer or the tutorial to better understand EEP (the information here is also presented in the tutorial, which also explores the various floaters and options in greater depth).

For official information on EEP, please refer to the Environment Enhancement Project SL wiki page.

EEP Basic Concepts and Terminology

In brief EEP:

  • Uses environment objects that you can keep in your inventory and / or share with others – including selling (subject to the SL permissions system) via in-world stores and on the Marketplace.
  • Provides parcel-level control of environments.
  • Allows up to four different, independently controlled sky layers.
  • Allows custom textures for the Sun, Moon and clouds.
  • Provides an extended day cycle of up to 168 hours (thus allowing a 7-day, 24-hour day / night cycle to be defined, for example).
  • Means that as environments settings are simulator-side, and so by default are automatically seen by anyone using any EEP enabled viewer on entering the region / estate / parcel.
  • Still allows the use of “personal” settings seen only be the use applying them, for the purposes of photography, machinima, etc.

Terminology

EEP uses some key terminology that should be understood.

  • Settings: used to define the environment you see. There are three settings types:
    • Sky: define the atmosphere and lighting for a day (or night); the movement, density, etc., of the clouds; and the appearance of the Sun and / or the Moon (which remain in a fixed point in the sky).
    • Water: define the appearance of Linden Water (prim or mesh animated water is not affected): water colour and reflection; wave movement; amount of light refraction, etc.
    • Day Cycles: collections of Sky and Water settings that are combined to present a dynamically changing environment over a user-defined time period representative of a “day” (by default this is set to the legacy Second Life day / night cycle of 4 hours, but can be extended out to represent physical world time periods of up to one week).
    • Note that Sky and Water settings are referred to as Fixed Environments.
  • EEP assets: physical “containers” for storing EEP settings. These are inventory items that by default, are stored in the new Settings folder in your inventory (see below), they are split into three types:
    • Sky – Sky settings. Icon: a blue sky with clouds.
    • Water – Water settings. Icon: a water droplet.
    • Day Cycle – for Day Cycles. Icon: a split Sun / Moon.
    • EEP assets (permissions allowing) can be exchanged, given away, and / or sold through a store or via the Marketplace.

Note that EEP settings are:

  • Created or edited using their corresponding EEP asset (e.g. to create Sky settings, you use the Sky asset type).
    • New EEP assets can be created directly from inventory, just like any other system inventory asset type (notecard, clothing item, gesture, script, body part).
    • Creating / editing EEP assets and settings is covered in depth in my EEP tutorial.
  • By default stored within a new system folder in inventory – the Settings folder. This folder may be hidden until such time as an EEP asset is created.
By default, EEP assets are stored and created in the Settings folder in your inventory (l). If you want, you can manually sub-divide your settings into suitable folders for easier tracking (r)

EEP Permissions

There are a few notes on permissions associated with EEP settings / assets.

  • Copy/no-copy: EEP settings assets may never be marked no-copy. A person who owns a setting object may always make a copy of it in their inventory.
  • Transfer/no-transfer: the no-transfer permission is persistent. If you import any no-transfer day or water setting into a day cycle, that day cycle will also become no-transfer. Once saved, this change cannot be undone.
  • Modify/no-modify: these permissions behave as normal.

EEP Library Assets

EEP includes a collection of Sky, Water and Day Cycles, together with a set of textures that can be used for clouds and / or to replace the Sun and Moon, etc.

  • These are located in Inventory (CTRL-I) → Library → Environments.
  • They can be used in one of two ways:
    • Unmodified, directly from Library → Environments.
    • By copying them to your inventory (e.g. to your own Settings folder, if it is visible through the creation of an EEP asset; if not, any other folder can be used), where they will become modifiable, allowing you to adjust them / use them to create your own settings.
    • See my EEP Tutorial for editing / modifying EEP assets and settings.

Differences to Windlight

Some of the key differences between EEP and windlight are:

  • EEP settings are stored in inventory assets, not as XML files saved to your computer.
  • Because they are server-side, EEP settings are by default seen by any viewer affected by the. This can mean:
    • Parcel owners using a specific set of environment settings no longer have to request visitors manually switch to them.
    • Settings are no longer dependent on visitors to a parcel with a custom environment having the precise windlight XML file stored on their computer.
  • EEP setting do not require any external storage (e.g. Dropbox) in order to be shared with other users, if they are to be given away.

Tutorial: Environment Enhancement Project (EEP)

Note: As I’ve had a number of Firestorm users directed here from the Firestorm Team’s EEP Beta release blog post who have commented directly to me about that release, please note that I am aware of it, and in fact blogged it at the time it was made available – see Firestorm 6.4.5 Beta: EEP and Camera Presets – which highlights some of the additional EEP / Phototools integration work the Firestorm team has carried out.  

EEP, the Environment Enhancement Project, is a set of environmental enhancements designed to replace windlight XML settings to control the water and sky environments seen in Second Life, and provide a wide range of additional capabilities for region holders, parcel holders and general users. It represents a fundamental shift in how environment settings are used and applied

In brief EEP:

  • Uses environment objects that you can keep in your inventory and / or share with others – including selling (subject to the SL permissions system) via in-world stores and on the Marketplace.
  • Provides parcel-level control of environments.
  • Allows up to four different, independently controlled sky layers.
  • Allows the Sun, Moon and Cloud textures to be replaced with custom textures uploaded to the viewer.
  • Provides an extended day cycle of up to 168 hours (thus allowing a 7-day, 24-hour day / night cycle to be defined, for example).
  • Allows users to override region / parcel settings as seen within their own viewer for the purposes of photography, etc.
  • Provides new LSL functions to allow scripts to interact with parcel environments.

In addition, key aspects of EEP are:

  • Estate / region / parcel settings are simulator-side, and so by default are automatically seen by anyone using any EEP enabled viewer on entering the region / estate / parcel.
  • Provision of a Personal Lighting capability that allows photographers, etc., to make rapid / temporary changes to an region / parcel’s environment visible only in their viewer.
  • Allows environments settings to be applied to your own avatar, allowing you to see the same environment (sky, clouds, Sun / Moon position, etc.) wherever you go in-world – useful for vehicle drivers travelling across multiple regions.
Table of Contents

This tutorial is designed to walk you through the essentials of EEP, including the terminology used. It is split into a number of sections:

  • Terminology and Concepts – key terminology and concepts with EEP.
  • The viewer UI elements associated with EEP.
  • An overview of creating and editing EEP assets.
  • An overview of applying EEP settings
  • Breakdowns of the floaters used to create Sky, Water and Day Cycles in EEP.
  • An overview of importing windlight XML files into the viewer and saving them as EEP settings / assets.
  • A summary of EEP LSL resources with links.

Some of these sections are self-contained, other can be used together (e.g. creating assets, using the Sky, Water and Day Cycle floaters, and applying EEP settings). To further assist referencing, major topics appear on their own page – please make sure you use either the table of contents or the page numbers at the foot of each page for ease of navigation.

Official information on EEP can be found in the EEP section of the SL wiki.

Note: at the time of writing this piece, the official Second Life viewer – version 6.4.0.540188, dated April 15th (or later) to see / use EEP capabilities. However, TPVs will be releasing version supporting EEP in due course. Check their websites, listed in the panel on the right, for updates that may not be covered in these pages.

My sincere thanks to Rider Linden, EEP maestro, for his assistance in the writing of this tutorial.

As well as bringing a range of new environment capabilities, EEP also lets you use custom textures for the Sun and Moon (and clouds). So Isla Pey can appear with Earth slowly setting, and Jupiter and one of the Galilean Moons also strangely in the sky! Note that both the size of the “sun” and “moon” textures can also be adjusted

Terminology and Concepts

EEP uses some key terminology that should be understood.

  • Settings: used to define the environment you see. There are three settings types:
    • Sky: define the atmosphere and lighting for a day (or night); the movement, density, etc., of the clouds; and the appearance of the Sun and  / or the Moon (which remain in a fixed point in the sky).
    • Water: define the appearance of Linden Water (prim or mesh animated water is not affected): water colour and reflection; wave movement; amount of light refraction, etc.
    • Day Cycles: collections of Sky and Water settings that are combined to present a dynamically changing environment over a user-defined time period representative of a “day” (by default this is set to the legacy Second Life day / night cycle of 4 hours, but can be extended out to represent physical world time periods of up to one week).
    • Note that Sky and Water settings are referred to as Fixed Environments.
  • EEP assets: physical “containers” for storing EEP settings. These are inventory items that by default, are stored in the new Settings folder in your inventory (see below), they are split into three types:
    • Sky – Sky settings. Icon: a blue sky with clouds.
    • Water – Water settings. Icon: a water droplet.
    • Day Cycle – for Day Cycles. Icon: a split Sun / Moon.
    • EEP assets (permissions allowing) can be exchanged, given away, and / or sold through a store or via the Marketplace.

Note that EEP settings are:

  • Created or edited using their corresponding EEP asset (e.g. to create Sky settings, you use the Sky asset type).
    • New EEP assets can be created directly from inventory, just like any other system inventory asset type (notecard, clothing item, gesture, script, body part).
    • Creating / editing EEP assets and settings is covered in depth in my EEP tutorial.
  • By default stored within a new system folder in inventory – the Settings folder. This folder may be hidden until such time as an EEP asset is created.
By default, EEP assets are stored and created in the Settings folder in your inventory (l). If you want, you can manually sub-divide your settings into suitable folders for easier tracking (r)

EEP Permissions

There are a few notes on permissions associated with EEP settings / assets.

  • Copy/no-copy: EEP settings assets may never be marked no-copy. A person who owns a setting object may always make a copy of it in their inventory.
  • Transfer/no-transfer: the no-transfer permission is persistent. If you import any no-transfer day or water setting into a day cycle, that day cycle will also become no-transfer. Once saved, this change can not be undone.
  • Modify/no-modify: these permissions behave as normal.

EEP Library Assets

EEP includes a collection of around 200 Sky, Water and Day Cycles, together with a set of textures that can be used for clouds and / or to replace the Sun and Moon, etc.

  • These are located in Inventory (CTRL-I) → Library → Environments.
  • They can be used in once of two ways:
    • Unmodified, directly from Library → Environments.
    • By copying them to your inventory (e.g. to your own Settings folder, if it is visible through the creation of an EEP asset; if not, any other folder can be used), where they will become modifiable, allowing you to adjust them / use them to create your own settings.
    • See my EEP Tutorial for editing / modifying EEP assets and settings.

Differences to Windlight

  • EEP settings are stored in inventory assets, not as XML files saved to your computer.
  • Because they are server-side, EEP settings are by default seen by any viewer affected by the. This can mean:
    • Parcel owners using a specific set of environment settings no longer have to request visitors manually switch to them.
    • Settings are no longer dependent on visitors to a parcel with a custom environment having the precise Windlight XML file stored on their computer.
  • EEP setting do not require any external storage (e.g. Dropbox) in order to be shared with other users, if they are to be given away.

Tutorial: Second Life Names Changes

via and © Linden Lab

Second Life offers Premium Account holders the opportunity to change the the first name, the last name or both the first and last names of their account at any time, or to revert to any name they name have used in the past (again, first name, last name or both).

This Tutorial is intended to provide an overview of using the Name Change capability.

Important Points

First some points to note:

  • Premium members may change their first name or their last name or both their first and last name whenever they wish.
    • First names are free-form.
    • Last names are selected from a list, with the available names updated periodically.
  • There is a fee applicable each time the capability is used. This fee is displayed as a part of the Name Change process.
    • VAT at applicable rates will be added to accounts in VAT-paying countries.
  • Once a first name+ last name combination has been applied to an avatar account, it cannot be used by any other account (so “Josephine Bloggs” cannot use Name Change to become “Inara Pey”).
  • It is possible for you to revert back to any previously-used name assigned to your account.
  • If you are Premium and use the Name Change capability, then subsequently downgrade to Basic, you will retain whatever avatar / account name you have at the time you downgrade. You will not not “revert” to any past name you may have had, and you won’t be able to change you name again until such time as you re-up to Premium.
  • Name Changes is not replacing Display Names – these will remain available at no charge to all who wish to use them.
  • Name changes are made via the Second Life dashboard, and you must be logged-out of Second Life in order to make sure any Name Change you make is correctly applied to your account.

Changing Your Name

Note: It is possible (and based on some feedback received), that a name change might take a little time to propagate through SL’s various services, which may have some impact on things like scripted objects such as security systems.

Premium Members can change their names as follows:

  • Log out of the viewer if you are currently in-world.
  • Log on to your dashboard at secondlife.com.
  • Click Account on the left-menu.
  • Click on Change Name.
  • The Change Your Account Name page is displayed. This comprises:
    • The account availability of Name Changes (including a link for Basic account holders to upgrade to Premium.
    • The fee that will be applied to your account, including and VAT that may be added.
    • A reminder than you can change your first name, your last name or both.
    • An option to go ahead and change your account name.
The Change Your Account Name page
  • Click the Next Step button to proceed.
  • The Choose a New Name page is displayed. This comprises three parts:
    1. The Change First Name option.
    2. The Change Last Name option with a list of currently available last names names.
    3. A list of previous last names you have used – if you have not previously used Name Changes, only your current last name is displayed.
The Choose a New Name page, showing the three options for changing your first name (1); selecting an new last name from a list of currently available names (3), and for any previously-used last names (if available – 3)

Change Your First Name Only

  • Leave the Change First Name option checked.
  • Use the text input field to enter your desired first name.
  • Uncheck the Change Last Name option.

Change Your Last Name Only

  • Uncheck the Change First Name option.
  • Leave the Change Last Name option checked.
  • Click the radio button next to last name you would like to use.

Change Both Your First and Last Names

  • Keep both the Change First Name option and the Change Last Name option checked.
  • Enter your desired first name in the text input field under Change First Name
  • Click the radio button next to last name you would like to use.

Reverting to a Previously Used Name

If you have previously used Name Changes, and would like to change back to an “old” name:

  • Enter the first name in the Choose a First Name text input field (if required).
  • Click on the require last name from the list of your previously used Last Names (if available).

Completing the Change

  • When you are happy with the name(s) you have set / selected, click the Review Changes button.
  • A summary of your changes is displayed (if you have made no changes, you’ll be taken back to the Change Your Account Name page).
The Name Change summary – use it to make sure you are happy with the name(s) you have selected
  • Make sure the details are as you want them, or use the Go Back link to change your selection(s).
  • If you are certain of the changes:
    • Log out of the viewer if you have not already done so.
    • Click on Continue to Checkout.
  • On the check-out page, you are presented with your payment options:
    • Via an US dollar balance on your Tilia account.
      • Requires acceptance of the Tilia Terms of Service, if you have not already done so.
      • If you have a sufficient US dollar balance on your Tilia account, but do not with to use it, click the Don’t Use button.
    • Via any credit / debit card already tied you your Second Life Account.
    • By clicking the More Payment Options… and making a selection (e.g. assigning another credit / debit card to your account).
  • When you have selected your preferred payment method, click the blue Buy Now button to complete your Name Change.
Name Change payment options

Bakes on Mesh – a basic primer

Updated with an overview of “Bakes on Mesh appliers” for Mesh bodies and head yet to be updated to support BoM.

Monday, August 26th, 2019 saw the formal release of Bakes on Mesh (BoM) for Second Life, and with it, an attempt to make system wearables (skins, tattoo and clothing layers) usable on modern mesh avatar bodies, utilising the avatar Bake Service and without the need for a dedicated applier system.

While Bakes on Mesh has been in development for over years, and much of it is known to many users, this article has been written to provide something of an introduction / overview of BoM, covering things like system wearables, the Bake Service, that changes that have been made, where to find information on using BoM, and what it may mean for Second Life users in the future, depending upon how well the capability is received by creators.

Some Basics

System Wearables and the Bake Service

System wearables as they appear in inventory

Without going too deeply into specifics for those unfamiliar with them, system wearables are a special kind of inventory asset (some of which are shown on the right) that can be directly worn / added to the system avatar to produce a “dressed” look.

These wearables come in a number of “layers”- skin (which must always be worn on the system avatar), tattoo, undershirt, shirt, and jacket.

The naming of the layers isn’t that important – a creator could be assign a bra or a shirt or a pair of pants to any one of the tattoo, undershirt, shirt and jacket layers, depending on how flexible they want their clothing to be. What is important is that the always follow an hierarchy: skin is always at the bottom and so “covered” by the other layers, which are in turn “covered” by the next (so undershirt wearables always apply “over” tattoo wearables; “shirt layers “over” undershirt wearables, etc), with the avatar able to wear up to 62 wearables in any combination of layers at one time.

This might sound very complex, but for those familiar with the system, it is very easy to grasp; however, what is important is what comes next. When an avatar’s look is complete, the information about all these wearables are sent to the simulator and then to a back-end set of servers called the Bake Service over a series of channels called the “bake channels”, which define where the layers appear on the avatar. These channels are:

  • BAKE_HEAD, which defines all the wearable elements that have been applied to the head (e.g. skin, and tattoo layers used for make-up)
  • BAKE_UPPER, which defines all the wearable elements – skin plus any tattoo, undershirt, shirt and / or jacket layer(s) that have been applied to the avatar body above the waist and below the neck (with the left arm mirrored from the right).
  • BAKE_LOWER, which defines all the wearable elements – skin plus any tattoo, undershirt, shirt and / or jacket layer(s) that have been applied to the avatar body from the waist to the feet (with the left leg mirrored from the right).
  • BAKE_EYES and BAKE_HAIR (both pretty self-explanatory).
  • BAKE_SKIRT, which defines skirt / dress style wearables.

The Bake Service then composites (bakes) the layers received on each of these bake channels into a single texture, and sends the results out to every viewer able to “see” the avatar. So, for example, facial / head skin and any make-up tattoo(s) received via the BAKE_HEAD channel are baked to become a texture seen on the avatar’s head, while the layers received over the Bake_Upper channel are baked into a texture seen on the avatar’s upper body, and so on, ensuring the avatar consistently appears to everyone dressed at the user intended, while also removing the need for individual viewers to manage the complex layering and rendering of all the individual wearable layers on other people’s avatars.

Mesh Bodies and Complexity

Since their introduction, mesh bodies have not been able to leverage this approach. Instead, they require a dedicated “applier” mechanism to achieve the same ends, together with the use of an alpha layer to hide the system avatar.

Further, to enable clothing items to be layered – so you can have an applied shirt / blouse appearing to be “under” a jacket, for a example, mesh bodies have had to be constructed in a complex manner, with several layers closely packed together (colloquially called “onion layers”) that effectively mimic the system wearable layers. This actually makes the avatar a lot more complex than they otherwise might be, resulting in their relatively high rendering costs.

Enter Bakes on Mesh

So, Bakes on Mesh has been developed to allow system wearable to be applied directly from inventory to worn mesh faces (e.g. avatar bodies and wearables) that have been correctly flagged by the creator to support Bakes on Mesh. Through Bakes on Mesh, Linden Lab hopes:

  • Users can avoid the need to use appliers, but can add wearables to their mesh avatar directly from inventory.
  • Creators will be able to simplify avatar mesh bodies and heads by removing the need for some of the “onion” layers. This should – if done – reduce the rendering complexity for bodies and heads, thus hopefully improving people’s SL experience (as avatars won’t be quite so resource intensive or require quite so much “assembly time” when encountering them on logging-on or after teleporting somewhere).

Notes:

  • As with all new features, use of Bakes on Mesh will only be apparent to those actually using viewers running the Bakes on Mesh code; anyone not on such a viewer will likely see something of a mess.And as with new features, it will take time for the Bakes on Mesh code to be implemented by all TPVs.
  • Bakes on Mesh does not mean user “have” to go back to using system wearables nor does it mean that applier systems can no longer be used. It is simply a means of making system wearables work with mesh bodies and heads, hopefully with the benefits given above. Those who wish to can continue to use applier-based clothing as they always have.
Bakes on Mesh adds new options for applying suitable textures to the baking channels for application on a mesh body by the Bake Service

An introduction to using BoM can be found in the Bakes on Mesh Knowledge Base article. This includes information on trying BOM using a test mesh body – the best way to do this is to use Aditi, the beta grid. I’m not going to go into specifics here, simply because there are multiple resources available to assist users and creators – some of which are noted at the end of this article, and I want to keep this as a more general, easy-to-understand primer.

When considering Bakes on Mesh it is important to remember it is not necessarily intended as an outright replacement for appliers and current mesh bodies from the get-go. Rather, it is initially an alternative – although if the popularity / take-up among creators and users are sufficient, then over time it could obviously become the system of choice over appliers and more complex mesh bodies. However, existing mesh bodies / heads and applier systems will continue to work as they always have.

Key Points of Bakes on Mesh

This list is not exhaustive, but is intended to give a feel for Bakes on Mesh and its use:

  • System skin layers, tattoo layers, clothing layers and alpha layers all work – the mesh just needs to be flagged by its creator as supporting Bakes on Mesh and correctly set-up for alpha layers to work as intended.
    • As an alternative, there are assorted “BoM appliers” designed to work with mesh bodies  / heads that have not (yet) been updated with Bakes on Mesh support – see below for more.
  • You do not need a full body alpha to wear a Bakes on Mesh flagged mesh. If the flag is present when you wear the mesh, the body section it is flagged for disappears. So, if you wear a lower body “Bakes on Mesh ready” avatar part, then entire lower body of the system avatar will disappear.
  • The Bake Service has been updated to support 1024×1024 resolution textures, so it offers the same texture resolution for wearables as offered through applier systems (prior to Bakes on Mesh the maximum resolution for wearables was 512×512).
    • Obviously, the wearable must be made at this resolution in order to utilise it; a 512×512 wearable will not magically appear to be 1024×1024 resolution when applied.
  • In order to be fully effective, mesh bodies using BoM and BoM wearables should match the system avatar UV map as closely as possible.
    • Fortunately, most of the current range of avatar bodies sold under brands such as Maitreya, Slink etc., do tend to stay close to the system avatar UV map. So any new BoM-specific versions / updates should continue to do so.
  • Alpha support means that  layers means that mesh bodies should no longer need to be split into multiple pieces for individual alpha-masking to prevent a body clipping through clothes. Alpha requirements are back in the hands of the clothing creator, and should be made alongside the clothing, so that when used and providing the body is correctly set-up they should just “work”. In addition, clothing makers may not longer need to include auto alpha scripts.
  • Changing mesh body parts should be easier, providing both bodies are flagged to use Bakes on Mesh. The body takes whatever is worn on the system body – skin and make-up instantly appear on each change of head, for example.
  • Skin makers will be able to offer more options by including tattoos with their skins, allowing for a variety of make-up options, whilst there will no longer be any limitation on the use of tattoos (one per zone).
  • Applier support will still be required for the following: nails; eyelashes; standalone ears, hands, feet, lips, bust implants, etc.; lip gloss; materials finishes (see Some Possible Points of Contention, below); neck blenders, anything not intended to look “painted” on.

New with Bakes On Mesh

To provide full “wearables” support, Bakes on Mesh introduces some new elements that will be of key import to creators:

  • The introduction of 5 new bake channels – LEFT_ARM_BAKED, LEFT_LEG_BAKED, AUX1_BAKED, AUX2_BAKED, AUX3_BAKED:
    • These can only be used with Bakes on Mesh, and are not available to the system avatar.
    • LEFT_ARM_BAKED and LEFT_LEG_BAKED are intended to help with making mesh avatars where the left and right limbs have different textures (and so can be asymmetric, as can currently be achieved with applier systems).
    • The AUX channels are general purpose, and could be used for body regions not possessed by system avatars (such as wings) or for other purposes.
    • This means BoM has 11 possible channels for wearables to use for textures, and for the baking service to produce.
    • However, the new channels listed above do not have alpha support like the other channels, and so cannot have “holes” cutting through the mesh face they are worn against.
  • BOM also adds a new wearable type called Universal.
    • While specifically added to allow the wearing items that use the new  channels described above, the Universal wearable has slots corresponding to all 11 of the bake channels, offering extensive flexibility of use. In layering order, universal wearables go between the tattoo and body layers.

Note that for others to see your avatar correctly when you are using Bakes on Mesh they must also be using a Bakes on Mesh viewer. If they are not, they will see your avatar as a mesh of red, blue and yellow colours showing through your mesh parts.

Left: Bakes on Mesh when seen via a non Bakes on Mesh viewer: the system avatar will show through the mesh body parts, covered by default system-supplied BoM marker textures. Centre and Right: using a “Bakes on Mesh applier” on a non-BoM body and head and via a Bakes on Mesh capable viewer. The centre image shows the “before” avatar state: the system layer skin and clothing are worn, but do not conform to the mesh body and head (which must be worn without their corresponding alphas for this type of applier to work), and so “poke through” (highlighted in places by the red circles). The right image shows how things look after the”Bakes on Mesh” appliers have been used – the system layer clothing and skin now mostly conform to the mesh head / body, with the exception of fingers and toes (highlighted) which will generally require an additional “glove” or “mask” fix.

“Bakes on Mesh Appliers”

During the testing of Bakes on Mesh, at least two experimental applier systems were produced to allow BoM to be tested on non-BoM flagged bodies and heads. For example, Omega produced an experimental BoM applier system, with instructions here.

Since then, and given that several mesh body and head creators have yet to produce BoM flagged updates to their bodies / heads, several more such “BoM appliers” have been produced, some of which are available for free, some are provided by the mesh head / body creator, and others are available at a nominal cost, and may be for specific purposes (e.g. the Bakes on Mesh skin applier (Omega) by Conor Shostakovich at L$125).

These essentially work by allowing you to dress your system avatar with the required system wearables, then wearing your mesh body / head without their alpha masks, and then using the applier to apply the system layers to the mesh body / head in a similar manner to “traditional” appliers – but again, as a single composite layer when baked.

  • How effective these systems are can be variable.
  • Due to differences in the way skin skin textures / UV maps work and the way mesh bodies tend to be put together, such appliers may not work particularly well around feet and hands.

Note: links to products does not constitute endorsement. Always check the Marketplace for products and reviews.

Such appliers are intended as an interim “fix” for using Bakes on Mesh until such time as the major head and body creators provided full Bakes on Mesh support.

Some Possible Points of Contention

However, there are what might be regarded by some as “negatives” around Bakes on Mesh, a couple of the more prominent ones being:

  • The Bakes Service – and thus Bakes on Mesh – does not support materials (normal and specular maps). How much this impacts people’s acceptance of BoM is open to debate. However, when needed, materials still can be added manually (if the mesh / mesh face in question is editable) or via a suitable applier.
  • Appliers are convenient, as they are an all-in-one solution requiring only one or two items in inventory – the outfit applier HUD and possibly an intermediary relay tool like Omega.
    • With Bakes on mesh, wearables are all individual inventory assets, which could lead to inventory growth, some of which might be quite extensive as a result of creators providing multiple options / layers (although in fairness, some applier systems can be like this – I have seen a Hugo’s Design outfit with no fewer the 40 individual items, both system layer clothing and multiple applier options).
    • Some of the inventory “bloat” BoM might cause can potentially be managed via the use of the viewer’s Outfits capability (although this obviously also adds to bloat with inventory links) or via a new form of applier system that utilises system wearables created at 1024×1024 resolution.

How much these may impinge on consumer’s willingness to adopt BoM remains to be seen.

Closing Remarks

Like all new capabilities, Bakes on Mesh will take time to gain understanding and traction. Also like all new features, it has its outright fans, and those who have – even before really getting to work with it in earnest – decided its is bad / wrong / pointless / a step back, etc.

I’m personally sitting in the middle. If it does what is claimed on the tin, and if it gains traction among mesh body and head creators (and several have been working on BoM for the 12+ months its been in development) and clothing creators, then it could do its own little bit towards a better “optimisation” (quotes used intentionally, as there is still a lot more than can be done in terms of optimisations cross SL), and make things a little better for everyone.

But it will take time for Bakes on Mesh to mature in terms of general use – creators need to update their heads / bodies (although Slink is apparently ahead of the curve, and their new bodies are said to work with existing appliers, and other creators may also be providing products / updates, I’ve just not encountered any as yet). Those making system wearables are going to need time to update to the 1024×1024 where preferred (if they haven’t already, and so on. And, most obviously, it will take a little time for the Bakes on Mesh code to percolate out to all TPVs.

In the meantime, some links to useful resources.

Resources