Kokua: 6.3.6 release overview

The Kokua team released Kokua 6.3.6 on Wednesday, February 5th, 2019. The release brings Kokua up to parity with the Lab’s 6.3.6 code base (to the release – formerly the Xanté Maintenance RC, promoted on January 27th), and includes a number of Kokua-derived updates and ported TPV options.

The following notes highlight the key aspects of Kokua For a full list of updates and changes, please refer to the release notes.

This release sees Kokua incorporates the ability to remember username/password combinations for multiple avatars via a drop down menu added to the user name field at login.

The ability to manage saved / remembered user names is via a new Preferences option, found a a button called Remembered Usernames in the Advanced tab.

  • When clicked, it opens a new floater that lists all user names recorded by the the viewer, together with the grid where they have been used.
  • To delete an unwanted user name, click on it to highlight it, then click the Forget button at the bottom of the panel. If you want to completed remove all local data for the user name, click the check box below the button first.
The new Preferences button and floater to manage remembered users names

This release of Kokua also includes the ability to set media to Ask before playing. As Kokua already has changes which separate parcel audio and other media playing, for the new Ask feature to work you must have parcel audio set to play automatically as well (via Preferences→Sound).

Text Display Options

Previously Kokua used standard size text on script menu text and slightly smaller for menu buttons.

It is now possible to switch between standard/small text for both using new drop-down menus on Preferences→Kokua→Script. The text size control also governs the text size for the informative text on text entry boxes (llTextBox).

The two text size drop-downs and text size options. Note only one or the other can be displayed at any one time. The above is illustrative only

Other Notable Updates

  • World Map land sale information: previously, when viewing land for sale on the World Map, the parcel price would only be displayed when clicking the For Sale tag. This has now been revised so that the sale information is displayed when clicking anywhere in a parcel highlighted for sale.
  • This version of Kokua includes a port of Firestorm’s enhanced World Map region captions
  • It is now possible to enter a land selling price by entering the desired L$/square metre price as well as the total price.
  • The date display for Group Notices has been changed to ISO-style YYYY-MM-DD format which avoids a very old bug where group notice sorting would go wrong for the first few days of each new year (because the previous sort started with the month number so 12 of the previous year got sorted ahead of 01 for the current year).

RLV Specific Updates

  • The mouse pointer in RLV will now only change to a the required icon (hand / sit, etc.), when the action is going to be permitted (adopted from RLVa).
  • If a user is under RLV IM restrictions, a hint is displayed in in the IM window to inform those trying to contact them that IM communications are going to be suppressed. This allows the message to be abandoned without being sent (if it is still sent, the usual RLV message about IMs being blocked will be displayed). A similar hint is sent to Group chats, etc, ahead of the person under IM restriction trying to message others.
Kokua now offers a hint to warn people when someone is under RLV IM restrictions

Other RLV updates in this release include:

  • The name anonymising code for @shownames has been further improved to cope better with situations where one name is a sub-string of another.
  • When ALM is enabled and RLV effects based on changing RenderResolutionDivisor are in effect this used to cause the CPU and/or GPU to sometimes start running at full speed and sometimes could even result in a crash. This is now prevented by automatically temporarily disabling ALM when the RenderResolutionDivisor value gets to a point where ALM would not give any rendering benefits because the whole scene is too “blurred”. This protective code is also in the non-RLV version however RenderResolutionDivisor is less likely to be changed there.
  • The recent introduction of keyword alerts meant that on some occasions where @recvim should have squashed an incoming IM it would get through unaffected

Additional Links

Catznip R12.3 goes BoM!

Catznip version R12.3 surfaced on Tuesday, October 15th, and made it the default download / update version on Wednesday, October 16th.

This is a maintenance release, following on from version 12.2, which saw a “de-coupling” of updates that are more focused on bug fixes and improvements from larger releases that include significant updates and new capabilities. However, it does include one major new feature: support for Linden Lab’s Bakes on Mesh capability.

As always, details of updates are available through the official release notes, although given the size of the update, just about everything included is noted below.

Linden Lab Derived Updates

Viewer Parity

This release brings Catznip to parity with Linden Lab viewer release, formerly the Umeshu release candidate viewer (Dated September 5th, promoted to de facto release status by Linden Lab on September 10th).

Bakes on Mesh

R12.3 provides support for Bakes on Mesh (BoM). This is a capability to allow system wearable layers as used with the “classic” Second Life system avatar – skins, tattoos, underwear, shirt and jacket layers – to be used with mesh bodies and heads, and without the need for additional applier systems.

The system requires mesh bodies and heads to be “BoM enabled” – and many creators have already updated their products, or are in the process of updating their products to support Bakes on Mesh. In addition, some applier makers are producing applier systems that leverage Bakes on Mesh to apply wearables to mesh bodies and heads – although these may be limited in some respects due to differences between how skin textures and mesh bodies are made).

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

Bakes on Mesh support is required to both use the BoM capability and to correctly view mesh avatars using BoM.

For more detailed information on Bakes on Mesh, please refer to the following links:

Linden Lab:

Creator-related BoM documentation:

Informative Bakes on Mesh blog post:

Catznip Fixes

Release 12.3 also includes the following updates from the Catznip team:

  • Minor installer issues.
  • Revert SL-1579 and allow taking rezzed items if their originating folder was Received Items.
  • Crash in busy/crowded places while camming around (thank you Nicky from Firestorm).
  • CATZ-532: Avatar (sometimes) ends up deformed when detaching something while an Animesh attachment is worn.
  • CATZ-535: Remove Google+ links.
  • CATZ-539: Creator Name on the build floater is always disabled.
  • CATZ-542: Render Everyone As setting affects your own Animesh attachments.
  • RLVa – FIRE-24230: Login crash when RLV @showloc restricted with no teleport history file.
  • RLVa – BoM universal layer is missing from @getoufit.

Related Links

Firestorm 6.3.2: welcome to Bakes on Mesh

On Monday, September 30th, 2019, Firestorm released version of their viewer.

This release features the awaited support for Linden Lab’s Bakes on Mesh capability, together with a number of Lab-derived updates and updates from the Firestorm Team.

Please note that this update is for Second Life only – see below for more.


Table of Contents

As per usual, this article provides an overview of the more visible updates in the release. Please refer to the release notes for a full list of updates and all associated credits. Also, note that this update means that version will be blocked from logging in to the Second Life grid in the near future – check the Firestorm blog for updates.

Why No OpenSim Version?

Jessica Lyon, project lead for Firestorm, recently blogged on the situation regarding OpenSim, and some of the steps the team are having to reverse as well as to take in order to offer some level of support for OpenSim unless they can obtain an OpenSim developer to assist with the viewer. For details see OpenSim the Good, The Bad and the Ugly.

At that time, Jessica had been hoping to provide OpenSim support “as is” with future releases of Firestorm – and had planned this to be the case with this release. However, a major issue was found with this release that could result in OpenSim regions crashing.

This will take time to resolve – hence no OpenSim version with this release. Instead, Firestorm will continue to offer version for OpenSim users. As the release installs separately to, both versions can be run side-by-side on the same computer for those wishing to access both Second Life and OpenSim.

The Usual Before We Begin

As per my usual preamble:

  • There is no need to perform a clean install with this release if you do not wish to.
  • Do, however, make sure you back-up all your settings safely so you can restore them after installing 6.3.2.
  • Please refer to the official release notes for a full breakdown and changes, updates and credits associated with this release.

Again, please refer to the Firestorm 6.3.2 release notes for details of specific Lab-derived fixes for this release.

Lab Derived Updates

The version of Firestorm brings the viewer to parity with the Linden Lab 6.3.1 code base, with some cherry-picked updates from upstream release candidate versions.

Bakes on Mesh

Simply put, Bakes on Mesh (BoM) allows system clothing layers as used with the “classic” Second Life system avatar – skins, tattoos, underwear, shirt and jacket layers – to be applied to mesh bodies and heads, and without (necessarily) the need for additional applier systems.

The system requires mesh bodies and heads to be “BoM enabled” – and many creators have already updated their products, or are in the process of updating their products to support Bakes on Mesh. In addition, some applier makers are producing applier systems that leverage Bakes on Mesh to apply wearables to mesh bodies and heads – although these may be limited in some respects due to differences between how skin textures and mesh bodies are made).

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

Note that Bakes on Mesh support is required to both use the BoM capability and to correctly view mesh avatars using BoM.

Bakes on Mesh adds new options for applying suitable textures to the baking channels for application on a mesh body by the Bake Service

For more detailed information on Bakes on Mesh, please refer to the following links:

Linden Lab:

Creator-related BoM documentation:

Informative Bakes on Mesh blog post:

In addition, Firestorm has created their own Bakes on Mesh wiki.

External Note Card Editor

Note cards can now be edited using an external editor.  Firestorm has adopted this as follows:

  • Select your preferred editor:
    • Go to Preferences → Firestorm → Build 1 → External Editor
    • Click Browse alongside the External Editor text entry field.
    • Use the picker to navigate to your preferred text editor and select its .EXE / launcher.
    • Click OK
    • The path to the editor should now be displayed in the text field.
    • This generally only has to be done once, unless you opt to change your preferred editor.
You can now set an external editor when writing / editing note cards
  • To use the external editor:
    • Create / open a note card for editing.
    • Click on the Edit button in the bottom left of the floater.
    • Your external editor will open and load the text.
    • Edit the text as required, and save using the external editor.
    • The edited text will be uploaded to the note card and saved in it.


  • There is no charge applied for the upload and saving to the note card.
  • Rich text editing (bold, italic, indentation, etc) used within the external editor will be ignored and the text converted to plain text for saving to the note card.

Other Lab Updates of Note

  • Ability to duplicate a group role – allows you to duplicate a group role so that the copied role has the same permissions and you can just give the copied role a different title (see: BUG-226986).
    • Open the group profile → Members & Roles → Roles → Left click on a role to select it → Click the Copy Role button
  • Animesh objects not being highlighted when viewing objects owned by users in About Land fixed (see: BUG-227240).
  • Animesh objects should now be easier to select (see: BUG-226860).
  • Depth mode snapshots no longer broken when snapshot size is set to anything above current window size (see: BUG-227191).
  • Scoreboards and visitor trackers broken by the last CEF update should not longer be broken (see: BUG-226704).
  • Viewer-side support for playback of sound files up to 30s in length
    • Note this feature is awaiting simulator support to work.
  • The ability to share photos & post to Facebook has been removed from the viewer (see: BUG-225205).
    • This has been broken at the Facebook end for some time, with no sign of being fixed.
  • Build → Texture → Align Planar Faces should now work on normal or specular maps (see: BUG-6489).
  • Under Help → Report Abuse, Gaming Policy Violation has been revised to Skill Gaming Policy Violation for clarity.

Firestorm Updates

Link to Discord includes the ability to link your Second Life account with your Discord account. Once connected, Discord will show your Second Life on-line status & session length, and optionally, your user name and location in SL.

Discord floater


  • This capability only works with the Discord client – it does not work with the Discord web pages.
  • To work, you must have the Discord client running when attempting to link to it from Firestorm.
  • Both Discord and Firestorm must be running with the same access level (note: it is not recommended you run discord in Admin mode).

To link you SL and Discord accounts:

  • Go to Comm → Discord …
  • The Discord floater opens.
  • In the floater you can opt to:
    • Automatically display you are using Second Life / Firestorm whenever you log-in to the viewer.
    • Display your Second Life user name.
    • Select whether or not you wish to display your location in Second Life, or, if opting to show your location, opt to only display it according to the maturity rating of the region you are in.
    • Create a list of region names you do not wish to have displayed by Discord when you are visiting them, regardless of any maturity rating set in the panel.
  • When you have set your preferences, click the Connect … button.
  • Once connected, you can disconnect from Discord at any time by displaying the panel and clicking Disconnect …

Avatar, Appearance and Inventory

Attachment auto-refresh: Firestorm adds a timer for automatically refreshing attachments when an attempt is made to kill them after a teleport / region change. It is designed to help resolve issues where your attachments are invisible to observers after a teleport or region change, and provides the same functionality as the manual Avatar → Avatar Health → Refresh Attachments (Alt-Shift-R).

Optionally, if the debug setting FSExperimentalLostAttachmentsFixReport is set to TRUE, Firestorm reports attachments that were attempted to get detached during a teleport or region crossing to nearby chat, followed by reporting “Refreshing attachments…” to nearby chat when the auto-refresh starts.

See FIRE-12004 and BUG-7761.

Profile Links to Force Appearance Change: it has been possible for users to put obfuscated links (e.g. “Photo of me in RL”) in their profile floater that, when clicked by another user, would replace outfit with one of the default outfits from the inventory library.

With this update, such links will no longer work, and the obfuscated link will display as “Wear Inventory Folder”. This matches a similar fix included in the Linden Lab Legacy Profiles folder. See also: FIRE-24262.


  • Removal of the restriction on adding system layers with identical asset UUIDs at the same time (see: FIRE-24334).
  • LookAt target clamping no longer causes your avatar eyes to cross (see: FIRE-24175).
  • The Firestorm Animation Overrider should now work correctly with child prim sits.

General Updates of Note

  • Movement at region crossing: this release fixes the issue of region crossing Predict option (Preferences → Move & View → Movement at Region Crossing) behaving like Stop (see: FIRE-24184).
  • The option Use HTTP For Receiving Textures has been removed from the SL-only version of the viewer’s Preferences.
    • This option forced the viewer to switch from UDP texture fetching to HTTP.
    • As Second Life no longer uses UDP for asset fetching (including textures), the option is no longer required for the SL version of the viewer, thus prompting its removal (see: FIRE-24256).
  • Payment confirmation is now skipped if paying yourself (e.g. paying your own tip jar) – see FIRE-24208.
    • Also fixed a case where the payment confirmation notification would not be shown if the amount would be exactly the remaining L$ balance.
  • FMOD Studio updated to version 2.00.03.
  • RLV updated to RestrainedLove API: RLV v3.2.1 / RLVa v2.2.0.58052.


I actually don’t have a lot to report; I’ve been using the Bakes on Mesh betas for some time, and found the BoM functionality works fine after some early hiccups. One or two of the early beta gave some crashes for me, but the versions (the latter including a minor update from 58051) have between them been stable – although I’ve only had the 58052 version installed for the time it has taken me to write this review.

Related Links

Firestorm: the future of OpenSim Support

On Wednesday, September 18th, and after some lengthy deliberation, Jessica Lyon issued a Firestorm blog post outlining the future of that viewer’s future support for OpenSim environments.

The post is going to make difficult reading for OpenSim users, but the reality is that for assorted reasons, the Firestorm team have to consider priorities and how to best support their two disparate user communities.

The most important point with the blog is that Firestorm is not about to abandon OpenSim: but there are certain hard realities that need to be faced.

The first of these is that Firestorm are struggling to meet the demands of OpenSim support. While it is easy to talk about OpenSim in the singular – as if it is a single network of grids running to the same overall framework of server code – this isn’t really the case, as Jessica notes:

So many grids and no standard specification. Grid features that vary from grid to grid. We fix an issue on one grid that breaks something on another. Compatibility with OpenSim is vastly more difficult than it is with Second Life. Add to that the fact that we have to continue to merge upstream code from LL on a regular basis. We just don’t have the human resources.

Resources in this case being a developer who not only has the time to devote to OpenSim development on behalf of the Firestorm Team, but also the depth of knowledge of the various OpenSim protocols required to implement viewer-side updates while avoiding many of the problems Jessica mentions.

To try to assist in matters going forward, Jessica outlines some of the steps that the Firestorm team will be taking:

  • Firestorm will no longer accept OpenSim viewer features without direct communication via viewer patch contributions, or better yet, some kind of reference viewer. Simply put, the team cannot expected to keep up with all developments in OpenSim, which features have been introduced in some grids and how they might impact others.
  • Firestorm can only include features compatible with the current recognised OpenSim version number – features based on in-development or upcoming server code cannot be accepted, particularly those that may work on one grid one way, but differently on another or not at all.
  • Firestorm can no longer guarantee keeping old / deprecated protocols active within the viewer indefinitely. Attempting to do so  simply increases many of the complexities involved in developing and maintaining a viewer – and Firestorm is already hard-pressed in keeping pace with updates rolling out of Linden Lab for Second Life and with the major updates and improvements being made to OpenSim.

This last point has particular relevance when it comes to upcoming major releases like Linden Lab’s Environment Enhancement Project (EEP), which will entirely replace Windlight.  This is actually what prompted Firestorm to try to split viewer development between different repositories  – one for OpenSim and one for Second Life – which in turn resulted in a lot of concerns being raised by OpenSim users that have, in part, informed the thinking leading up to this blog post.

Simply put, Firestorm cannot continue to support both Windlight and EEP, and will be focusing on EEP as that reaches release for Second Life, with the hope that OpenSim will find the means to adopt the EEP protocols in the future. Similarly, it is likely that projects such LL’s on-going Love Me Render work to improve viewer rendering, the Estate Access Management project and others may well impact Firestorm’s ability to support OpenSim.

So What Does This Mean?

Simply put, it means that if Firestorm is to continue supporting OpenSim to the fullest possible extent, it is going to need the help and support of the OpenSim community.

Part of this can be due through the likes of communication and viewer patch submissions and testing, as noted above. However, the most practical way to help Firestorm is for those within the OpenSim community who are competent viewer developers and who have – or can quickly understand – the Firestorm code, to volunteer their time and expertise.

To do so, drop the Firestorm team an e-mail providing your name, contact details and a brief outline of your experience in viewer code development, and how you believe you would be able to help.

So if you are that person – please do considered applying; or if you know someone who can help – point them towards the Firestorm blog post. In the meantime, OpenSim users who may read this blog are asked to follow the link to Jessica’s blog post to read her comments first-hand.

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


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



Kokua: Admin changes and the 6.2.4 release

The Kokua team released Kokua 6.2.4 on Friday, August 16th, 2019, and with it come some changes to general administration of the viewer’s website and management tools.

In terms of the latter, and for ease on management going forward, a number of changes are in the works including:

  • The use of the Atlassian Confluence platform to provide:
    • A blog capability.
    • Release notes support.
    • A master download pages.
    • RSS feeds.
  • The use of Atlassian Jira (as used by Linden Lab and the likes of Firestorm) for bug reporting and tracking.

The switch-over is still a work-in-progress, so the existing blog, wiki and bug tracker remain in operation for the time being, however, relevant links for the new environment are given as:

While the switch-over is in progress, users are advised against linking to individual sub-pages within these sections, as pages may change as things are bedded-in. For this purposes of this blog, the new Kokua home page is referenced in the sidebar links (right, under Maintained Viewers) and within my Current Viewers Release Page and the weekly release summaries drawn from that.

Kokua 6.2.4

Kokua 6.2.4 brings the viewer to parity with the most recently Linden Lab viewer release (version, formerly the Love Me Render RC viewer dated August 5th, promoted August 12th). In addition, it updates the RLV version to Marine Kelley’s RLV

As has been customary with Kokua releases of late, the viewer is provided in three versions for each of the supported operating systems (Windows, Mac OS X and Linux, all 64-bit):

  • Non-RLV – version
  • “Standard” RLV (can be enabled and disabled via a viewer restart) – version
  • “Full Time” RLV (RLV is active all the time) – also version

In addition to these updates, Kokua 6.2.4 includes a number of third-party additions, most notably from Firestorm, as noted in the sections below, and with due credit to the originators of the code updates.

Settings Backup

Sometimes when installing a new version of a viewer, there can be a recommendation to perform a “clean install” – removing all cached and settings files. This can make any viewer installation labour-intensive, as settings all need to be restored after the installation is complete.

The Settings Backup (Preferences > Backup) eases some of the pain by allowing users to back-up many of their global and account settings to a local hard drive. Once done, the back-up can then be restored to an updated version of Kokua (e.g. if a clean install has been required, or if some settings have become corrupted). Settings can also be backed-up at any time as changes are made.

The Kokua Settings Back-up option, courtesy of Firestorm

Settings can be backed-up to any location on a local drive, and users can select those settings they wish to back-up by unchecking / checking the available options. It is also possible to save settings on a per account basis. So if you have several accounts, each with different settings, you can back-up each of them separately – just make sure each back-up has a unique location.

Restoring previously backed-up files requires the viewer is restarted after the restore – and again, this is conveniently taken care of by the viewer allowing you to quickly log-out following a successful restore – although you’ll have to manually re-start the viewer once you’ve been logged out.

Sounds Output Device Selection

Preferences >Sound and Media includes a new drop-down allowing users to select their preferred output device for playing in-world sounds.

Sound output device selection, courtesy of Firestorm

When using it, note that:

  • Selecting Default will always select the first output device in the list.
  • If Default is selected but the previous device is no longer available, the viewer will automatically switch to the next available “default” device as defined by your operating system.
  • Manually selecting an output device from the drop-down  prevents the viewer from automatically switching to another device if the selected device is no longer available. Instead, the field will show “Unavailable Device” until such time as the nominated device is again available, or the drop-down is changed to Default or an alternate is manually selected.

Updated Debug Floater

Finally from Firestorm, Kokua 6.2.4 includes an improved debug settings floater with search and sanity checking of key values.

The improved Debug floater, courtesy of Firestorm

Other Updates of Note

Finally there are a number of fixes/improvements on the Kokua code base itself, notably fixing the pie menus so that the Hover Height command appears (i.e. was there but a mistake in the file concerned prevented it being shown). For details, please refer to the Kokua 6.2.4 release notes.


Kokua 6.2.4 continues to maintain parity with the official viewer whilst also importing some additional updates from Firestorm that Kokua users will doubtless find useful and which are likely to help enhance Kokua as the go-to viewer for those who have used Firestorm , but who are looking for an alternative that offers reasonable familiarity.

Additional Links