Bakes on Mesh – a basic primer

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. In theory, this means:

  • Users can avoid the need to use appliers, but can add wearables to their mesh avatar directly from inventory.
  • It provides the opportunity to simplify avatar mesh bodies, by removing the need for some of the “onion” layers, helping to reduce rendering complexity and  – in time – thus hopefully improving people’s SL experience (and 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.
    • Obviously this will also depend on how well BoM is adopted by creators and users.

Note: 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 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, Omega have a experimental BoM applier system available in-world, which I understand works with existing bodies – instructions here. Note that this is only an experimental  – and potentially limited in terms of overall availability – option at present.
  • 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.

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 amount 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

Advertisements

SL Legacy Profiles project viewer

In February 2019, it was indicated in a Third-Party Viewer Developer (TPVD) meeting that an upgrade to the system powering user profiles seen in the viewer, on the web, together with the  feeds, etc., was in the pipeline (see 2019 SL User Groups 7/3: TPV Developer Meeting).

At the time of the announcement, it was indicated that the overall impact of the update on the feeds has a whole had yet to be determined. However, it was also made clear that the current web-based profile floater seen in the Lab’s viewer would in the coming months be replaced by a “legacy” style profile floater (e.g. the type seen within the Firestorm and Cool VL viewers).

On Wednesday, June 5th, the Lab took the first public step towards this by issuing the Second Life Legacy Profiles project viewer, version 6.2.3.527749. This viewer offers a first pass at the re-introduction of the “old” style profile floater to the official viewer, utilising code originally contributed by Kadah Coba of the Firestorm team.

The new Legacy Profiles project viewer replaces the current web-based profile panel (left), with an “old-style” profile floater panel (tight)

With this viewer, it is important to note a couple of things:

  • This is an initial release of the viewer with the profile floater. As such, it may be refined / altered / fine tuned as the viewer progresses towards release.
  • There are a number of known issues with this initial release – see the release notes for a list of these.

As TPV user – notably (but not exclusively) Firestorm – I’ve always tended to find the legacy style of profile floater to be preferable: it tends to be faster loading, and (to me) has a more user-friendly means of navigation. As seen within the project viewer, the “new” floater is perhaps a little large in its default size, but adjusting it is easy enough – although having it a little smaller by default perhaps wouldn’t go amiss.

Those interested in trying this project viewer can do so via the Alternate Viewer page.

New SL viewer release notes pages: an overview

Update, May 21st: The Alternate Viewers wiki page has been retired and replaced by a new Alternate Viewer page, which follows the same broad format as the Release Notes page (making the two slightly confusing, as they both reference recent RC viewers. However, this new page also draws a distinction between RC and project viewers, thus overcoming some of the concerns voiced in the second half of this article.

As noted in my week #20 SL Content Creation summary, Linden Lab have unveiled their new viewer release notes pages.

At the time of writing, the new pages are focused on the release candidate (RC) viewers that are in development and currently available as download cohorts in place of the de facto release viewer. It is not currently clear if project viewers will be included in the new format or not.

As Steven Linden from the viewer team notes in a Tools and Technology blog post on the subject, these new pages are part of a new website for viewer release information. This website comprises a dedicated home page with an introduction to viewer release notes. together with links on the left side to:

  • “Recent viewer releases”: a clickable list of the most recent RC viewer updates, provided as viewer version numbers. These are provided in release date order, with the most recent updates at the top.
  • Additional links to viewer-related support information:
The new Release Notes home page – access specific viewer release notes via the version numbers outlined in red on the left

Individual viewer release notes can be accessed by clicking one of the the listed version numbers, which will open a page specific to that viewer. These pages comprise:

  • Icon links to the available OS versions (Windows 32/64-bit, Mac OS).
  • The general release notes (description, etc.).
  • A list of resolved issues.

A significant change in these pages is that, where relevant, Jira links in the Resolved Issues section now, wherever possible, reference “public” bug reports (e.g. BUG-XXXXXX), rather than the Lab’s internally cloned versions of such bugs (e.g. MAIT-XXXXXX).

Currently, the new pages can also be accessed from the existing Alternate Viewers wiki page, (click the Release Notes link for an RC viewer on that page). However, whether this page will remain relevant if the release notes for project viewers are also converted to the new format, remains to be seen.

An example of the revised release notes for a viewer (in this case the Teranino Maintenance RC) – note the use of “public” Jira numbers where relevant, in the known issues list

The new pages are a lot easier on the eye, although I have a number of reservations at this time.

  • While I understand understand why version numbers are used to reference individual viewers (they are URLs and so can be dropped into the pages without necessarily requiring human intervention), they are less user friendly to those wishing to quickly look-up the specifics on a viewer.
  • The “recent Viewer Releases” lists can include links to multiple versions of a given viewer (at the time of writing, two versions of the EEP and Teranino RC viewers are listed, for example). This might cause a degree of confusion for some users, who may mist he “most recent at the top” arrangement of the list.
  • If project viewers are to be added to these pages, I would hope there will be some form of clearer distinction between them and any listed RC viewers, other than just a top-down list of version numbers, again for ease of user reference.

Related Links

SL Estate Access Management project viewer – overview

The Estate Access Management (EAM) project viewer (dated August 7th) is a new project viewer to enhance  – as the name implies – the estate access management tools available to region holders and their estate managers within the viewer.

In brief:

  • New viewer UI for displaying Estate Managers, allowed groups and allowed  / banned individuals within a region.
  • New capabilities for sorting  / searching lists.
  • Additional information recorded and displayed for banned accounts.
  • Number of Estate Managers increased from 10 to 15.

Under the current viewer, the lists for managing Estate Managers, allowed groups and allowed or banned avatars in a region / estate have been crammed into the first tab of the Region / Estate floater (World > Region / Estate).

This has made management of the lists difficult, given only around 5 names can be displayed by each – which can be problematic when the Banned list allows up to 500 names. In addition, lists cannot be searched and, again in the case of the Banned list, no other information is provided against a banned name, making it hard to determine whether or not a ban might actually be rescinded, thus helping with general list management.

As such, there have been long-standing requests for the estate access controls to be improved.

The Estate Access Management project attempts to address these issues by introducing both back-end changes in support of managing ban lists and by revising how the various lists themselves are displayed within the viewer and how they can be used.

In particular, the EAM project viewer introduces a new Access tab in the Region / Estate floater (World > Region / Estate). This tab in turn has individual tabs for managing the lists for Estate Managers, Allowed avatars, Allowed Groups and Banned avatars.

The Estate Access Management lists as they appear in the current SL viewer (l), and the new Access tab with individual tabs for Estate Managers list and each of the Allowed / Banned lists. Note as well the increase in allowed Estate Managers (ringed in each image). Click for full size, if required

In terms of adding or removing names and groups, the new sub-tabs work exactly as the lists in the current viewer work.

However, with the new design, additional functionality is added to some of the lists:

  • The Banned list additionally records:
    • The last date on which a banned individual logged-in to Second Life (to assist with housekeeping the list – if an account hasn’t been used in X months or years, why keep it on the list?).
    • The date on which an individual was banned.
    • The name of the EM / region holder banning them.
    • Note this information will be displayed by the EAM viewer for all accounts going forward – even those banned using other viewers, reflecting a change to the back-end database for managing bans. Banned accounts existing at the time the EAM updates were introduced will simply have “n/a” recorded for each of these fields.
  • The Banned tab can be sorted into ascending / descending order by banned name, date last logged in, date banned, or by person banning them. Click on the column title to sort.
The Banned List includes columns for date of last log-in, date banned, and region holder / EM who banned them. These columns can also be sorted into ascending or descending order by clicking on the field title, as can the account name column.
  • The Estate Managers, Allowed and Allowed Groups tabs can be sorted into ascending / descending order by name. Click on the column title to sort.
  • The Allowed Groups, Allowed and Banned tabs all include a search option.
  • The number of allowed Estate Managers is increased from 10 EMs to 15 EMs – again in response to many requests from region holders.

Feedback Sought

The Lab is keen to have feedback on these new tabs and the improvements made to handling estate access control. If you are a region holder with EM rights, or an Estate Manager, please consider downloading this project viewer and  giving it a try. Any issues should be reported via the Second Life JIRA, using the [EAM] project reference in the title.

Related Links

Note: names intentionally removed from fields and columns in the images used in this article.

Lab provides “Unloop” viewer for 32-bit Windows users

On May 31st, 2018 Linden Lab updated the Love Me Render Release Candidate, viewer version 5.1.5.515811 to de facto release status.

Unfortunately, during the release process, there was an error defining the location of the Windows 32-bit version of the Second Life viewer download, which meant Windows users downloading the viewer when first released received the 64-bit version, regardless of which version of the operating system they are running.

While the issue has been addressed, it did leave some 32-bit Windows users found their systems stuck in a loop of trying to install the 64 bit version of the viewer. As I noted at the time, instructions were issued on how to break out of the loop. However, it appears some 32-bit users may still be encountering problems.

To this end, the Lab has released the “Unloop” Release candidate viewer, version 5.1.6.515965, which as the release notes state:

…is a special release just for Windows 32 bit systems who were caught in an endless loop of 64 bit viewer updates between 5/31/2018 and 6/1/2018. Except for its incremented build number, it is in every other way, identical to the last release.

So, if you are a 32-bit Windows user and are still having issues as a result of the promotion of the Love Me Render release, you might want to try a fresh installation of the Unloop viewer.

Second Life 32-bit Windows viewer oopsie

Update, June 6th: for those 32-bit Windows users still experiencing problems with this issue, the Lab has issued the Unloop RC viewer.

On May 31st, 2018 Linden Lab updated the Love Me Render Release Candidate, viewer version 5.1.5.515811 to de facto release status.

Unfortunately, during the release process, there was an error defining the location of the Windows 32-bit version of the Second Life viewer download. Because of this error, all Windows users downloading the viewer received the 64-bit version, regardless of which version of the operating system they are running.

While the issue has now been fixed so that 32-bit Windows users will receive the 32-bit version of the viewer, anyone running 32-bit Windows who downloaded the viewer during the 24 hours when the incorrect location was available (12:00 noon SLT on Thursday, May 31st, 2018 through 12:00 noon SLT on Friday, June 1st, 2018) may now find their system is stuck in a loop of trying to install the 64 bit version of Second Life.

Because of this, Kyle Linden issued a forum post on how to correct the problem for those caught in the loop, and I’m reproducing those instructions below for those who may have missed the forum post:

There is a way out of this loop.

  1. Uninstall the 64 bit version of Second Life.

  2. Install the 32 bit version from: http://download.cloud.secondlife.com/Viewer_5/Second_Life_5_1_5_515811_i686_Setup.exe

For the technically inclined there is a more surgical method to quickly recover.

  1. Open your file explorer in Windows.

  2. In the address bar type in %appdata% and press Enter.

  3. Locate the SecondLife folder and open it.

  4. Locate the downloads folder and delete it.

  5. Launch Second Life as normal and the correct update will be applied.

Thank you for your patience and understanding, we stumbled and we’ll make corrections to our processes to ensure this doesn’t happen again.

For those needing further information, please refer to Kyle’s forum post.