Not a lot to report – the meeting was largely a solstice party with live music. Simon Linden did, however, use the larger-than-usual gathering to monitor animation performance, lag and streaming performance.
Server Deployments
Update, September 28th: a rollback was performed across the grid on September 27th/28th, which apparently moved all regions back to server release 2019-09-06T22:03:53.530715, first deployed on September 10th, this was due to widespread issues being reported across the grid in relation to the script timing / performance fixes that were deployed – and which revealed a further underpinning issue. See this status update for more.
On Tuesday, September 24th, the SLS (Main) channel was updated with server release 2019-09-13T20:04:44.530946, comprising minor improvements to starting and stopping regions and EEP updates and fixes, and which was originally deployed to the Magnum RC channel.
On Wednesday, September 25th, the RC channels are to be updated with two deployments (no channel details provided):
2019-09-20T23:03:22.531148, comprising internal logging changes and improvements to simulator state saves intended to make deployments smoother.
Legacy Profiles viewer, version 6.3.2.530836, September 17. Covers the re-integration of Viewer Profiles.
Project Muscadine (Animesh follow-on) project viewer, version 6.4.0.530473, September 11.
360 Snapshot project viewer, version 6.2.4.529111, July 16.
Linux Spur viewer, version 5.0.9.329906, dated November 17, 2017 and promoted to release status 29 November 2017 – offered pending a Linux version of the Alex Ivy viewer code.
Obsolete platform viewer, version 3.7.28.300847, May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7.
On Tuesday, September 17th, the SLS (Main) channel was updated with server release 2019-09-06T22:03:53.530715. Originally deployed to the Magnum RC on September 11th, it contains the fix to address most cases of experience-enabled scripts losing association with their experience – see this blog post.
On Wednesday, September 18th, the RC channels are to be updated as follows:
Internal Script Improvements – these should see further improvements in script processing, with the selected regions representing around 15% of the total grid.
Fixed “Avatar Sounds” feature fails to disable all scripted sounds.
[EEP] Smoothen transition time of llReplaceAgentEnvironment.
Updated to include current Second Life Server changes.
Magnum should be updated with server release 2019-09-13T20:04:44.530946, comprising minor improvements to starting and stopping regions and EEP updates and fixes.
SL Viewer
On Tuesday, September 17th, 2019 the following viewer updates were made:
The Vinsanto Maintenance RC viewer, version 6.3.2.530962.
The Legacy Profile project viewer was updated to version 6.3.2.530836.
On Monday, September 16th, the Ordered Shutdown RC viewer, version 6.3.2.530901, was released. This viewer has changes intended to make crashes on shut-down less likely, but does not have any changes to existing features.
At the time of writing, the rest of the current official viewer pipelines remain as follows:
Project Muscadine (Animesh follow-on) project viewer, version 6.4.0.530100, August 19th.
360 Snapshot project viewer, version 6.2.4.529111, July 16th.
Linux Spur viewer, version 5.0.9.329906, dated November 17, 2017 and promoted to release status 29 November 2017 – offered pending a Linux version of the Alex Ivy viewer code.
Obsolete platform viewer, version 3.7.28.300847, May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7.
In Brief
The Lab is “very focused” on the problem of avatars teleporting into or out of a region overpowering local performance (scripts, etc.).
It’s been widely assumed that the performance is due to things like overall complexity and / or script load, etc.
However, while both script load and avatar complexity do have a general impact on performance, LL does not believe they are responsible for the issues seen when avatars enter / leave a region.
Data has been gathered on the problem, and Rider Linden indicated that LL feel they have a reasonable handle on the problem and are in a position to start experimenting to verify their findings in the near future.
There is period of voice maintenance due on Thursday, September 19th. This involves back-end updates to the voice system.
It is not clear if these updates will assist those users who, when activating voice, appear to be in their own channel with just one or two other users and must relog to join the main channel with all the others on voice.
This is a problem LL has noted, but Vivox have been unable to determine the cause.
There is a voice viewer update in the works that includes additional debugging capabilities that might help with determining the problem.
On Tuesday, September 10th, the SLS (Main) channel was updated with server release 2019-08-29T20:20:39.530516 – comprising “simulator component of deploy tooling and process improvements”, and previously deployed to the main RC channels in week #36.
This is the update that doesn’t report channel names to the viewer, so Help > About will always report the channel to be “Second Life Server” (SLS) regardless of the channel the region you are on is assigned to.
There is a race condition that can cause double rolls of a deployment some 2 or so hours apart. The Lab is aware of the issue and investigating the cause.
One Wednesday, September 11th, the main RC channels will be updated as follows:
BlueSteel was updated with server release 2019-09-06T18:49:52.530700, containing the simulator-side script usage improvements.
Magnum and LeTigre were updated with server release 2019-09-06T22:03:53.530715, containing the fix to address most cases of experience-enabled scripts losing association with their experience.
SL Viewer
The Umeshu Maintenance RC viewer, version 6.3.1.530559 and dated September 5th, has been promoted to de facto release status. At the time of writing, the rest of the current official viewer pipelines remain as follows:
Project Muscadine (Animesh follow-on) project viewer, version 6.4.0.530100, August 19.
360 Snapshot project viewer, version 6.2.4.529111, July 16.
Legacy Profiles viewer, version 6.2.3.527749, June 5. Covers the re-integration of Viewer Profiles.
Linux Spur viewer, version 5.0.9.329906, dated November 17, 2017 and promoted to release status 29 November 2017 – offered pending a Linux version of the Alex Ivy viewer code.
Obsolete platform viewer, version 3.7.28.300847, May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7.
In Brief
Group Chat: there are some reports that group chat has been improved over the last couple of weeks with less drop-outs and issues, although conversations arrived with the original post missing still appears to be an issue.
Oz Linden acknowledged the Lab is still tweaking on things to try and brig about improvements.
Simon Linden indicated that it is one of those problems where running the service on more capable hardware doesn’t always improve things – as the Lab found out in tests earlier in the year.
Sound file duration: a good while ago, the viewer had a change to allow 30-second sound files. However, it has been awaiting a server-side update to support it. When asked about the status of the update, Oz Linden replied:
Can’t predict now when the 30 second sound limit will happen, but it’s part of a high priority bundle of stuff, so Pretty Soon™
Apparently, as a result of Labor Day in the USA and the threat of hurricane Dorrian, there was no SLS (Main) channel deployment on Tuesday, September 2nd.
As a result, on Wednesday, September 4th, there will be deployments across the entire grid – the SLS (Main) and the primary RC channels. The order of deployments will be the SLS (Main) channel, starting 30 minutes ahead of the usual time. Once completed, and providing there are no issues, it will be followed by the RC deployments.
The SLS (Main) channel is to be updated with server maintenance package 19#19.08.23.530380, comprising maintenance fixes and Log improvements, and previously deployed to the Magnum and LeTigre RC channels.
The three main RC channels (Magnum, LeTigre and BlueSteel) will all be updated with the same server maintenance package – 2019-08-29T20:20:39.530516 – comprising “simulator component of deploy tooling and process improvements”. This update sees the introduction of the new Simulator release notes pages (see below).
There will also be a small move of more regions (around 100) to the Cake RC channel on Thursday, September 5th. This will be a further expansion for the script usage improvements. People wishing to test these updates can put in a ticket to have their region moved to Cake – but should note that updates to that channel do not necessarily follow the same weekly schedule as the main RCs.
Release Notes
In May 2019, the viewer release notes moved to a new series of web pages (see: New SL viewer release notes pages: an overview). The RC deployments scheduled for Wednesday, September 4th will see the all release notes for the RC channels move to these pages as well. This means:
The there is a new link for simulator release notes on the main About Release Notes page.
The release notes themselves have a new “more specific” version number system – as witnessed with the simulator release for the RC channels noted above.
It has been promised that these pages will be “more informative” with release information. This appears to take the form of Jira report reference numbers.
The link to the simulator release notes is now live on the About Release Notes page – click for full size, if required
SL Viewer
At the time of writing, there have been no updates to the current list of existing official viewers, leaving the pipelines as follows:
Current Release version 6.3.0.530115, formerly the Bakes on Mesh RC viewer, promoted August 26th – NEW.
Project Muscadine (Animesh follow-on) project viewer, version 6.4.0.530100, August 19.
360 Snapshot project viewer, version 6.2.4.529111, July 16.
Legacy Profiles viewer, version 6.2.3.527749, June 5. Covers the re-integration of Viewer Profiles.
Linux Spur viewer, version 5.0.9.329906, dated November 17, 2017 and promoted to release status 29 November 2017 – offered pending a Linux version of the Alex Ivy viewer code.
Obsolete platform viewer, version 3.7.28.300847, May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7.
In Brief
“[Second Life: Failed to grant capabilities”] – this is an error people have been seeing recently. It generally occurs as a result of a general failure to set up communication between your viewer and a region when moving into that region.
When first connecting to a region, the viewer asks for – and should receive – a set of “capabilities” – URLs where the viewer can connect and get or send info.
If this fails, it’s unlikely the viewer will be able to work with the region. The most effective way to deal with this is have the region restarted – so if you’re not the region holder, please drop them a line to let them know the region needs restarting or file a support ticket. If you are the region holder and you cannot restart the region or the issue is not resolved following a restart, please file a support ticket.
LL continues to investigate the issue whereby any scripts compiled to an experience prior to simulator version 19.08.06.529800 will not recompile on 19.08.06.529800 or later. In fact, Simon Linden was working on the issue while attending the meeting). The root cause does not appear to be within the updated server code, and for now, the only solution appears to be recompiling everything in the experience – which is acknowledged as being less than optimal.
There was no deployment to the SLS (Main) channel on Tuesday, August 27th, leaving it on server maintenance package 19#19.08.06.529800, containing internal fixes.
On Wednesday, August 28th, the core RC channels should be updated as follows:
Among other things, this update will see the RC channel name be removed from Help > About in the viewer (it will simply be recorded as “Second Life Server”), and the channel name will no longer be returned for LSL enquiries.
Note this is the RC channel name that will be changing – both the simhost name and the simulator version will still be visible, contrary to comments in the forums. Also, simulator version number will remain available to LSL; it is again, just the channel (sim_channel) that will always return “Second Life Server”
Magnum ad LeTigre should receive server maintenance package 19#19.08.23.530380, very helpfully referred to as “Maintenance fixes” and “Maint Train woo woo chuga chuga chuga chuga”
There will be a further small-scale RC deployment that will (if I understand things correctly) comprising the script usage improvements – the smaller deployment being cautionary after things went sideways when an attempt was made to deploy these updates to an RC channel in week #34.
SL Viewer
The Bakes on Mesh viewer was promoted to de facto release status on Monday, August 26th, with the release of version 6.3.0.530115. You can find out more here:
As a result of this promotion, the Umeshu Maintenance RC viewer updated to version 6.3.1.530411 on Tuesday, August, 27th, bringing it to parity with Bakes on Mesh. This will likely be the next viewer to be promoted to release status in around 2 weeks time.
The rest of the viewer pipelines see no change at the start of the week and remain as follows:
Project Muscadine viewer (Animesh enhancements), version 6.4.0.530100, August 19th
360 Snapshot project viewer, version 6.2.4.529111, July 16th.
Legacy Profiles viewer, version 6.2.3.527749, June 5. Covers the re-integration of Viewer Profiles.
Linux Spur viewer, version 5.0.9.329906, promoted to release status 29th November 2017 – offered pending a Linux version of the Alex Ivy viewer code.
Obsolete platform viewer, version 3.7.28.300847, May 8th, 2015 – provided for users on Windows XP and OS X versions below 10.7.
In Brief
The planned changes to RC deployments (see the blog post links above) has caused some drama, partially due to people misunderstanding that the RC channel names will be less obvious, as noted above – but not the simulator / simhost names.
However, it is true that the downgrading of ready access to RC channel names will make it harder for users to recognise which channel they are on – which could made testing capabilities and features harder, given that people are not so familiar with simulator versions and simhost names.
The flip side to this is that in some respects, the Lab doesn’t want people to know which channel they are on to stop preconceptions about issues, etc., they may encounter (e.g. “I was on Magnum, which has X release on it, and I have this issue – so it MUST be X that is at fault!”) – and according to Oz Linden, they would like to see more testing of new features on Aditi ahead of any main grid RC deployment.
To help people understand what is being released, the simulator version release notes are promised to be “more informative” in future and where relevant. That said, “Maint Train woo woo chuga chuga chuga chuga” isn’t exactly setting the bar that high in terms of informative release notes.
There is a reported issue with experiences whereby any scripts compiled to an experience prior to simulator version 19.08.06.529800 will not recompile on 19.08.06.529800 or later. The issue is further described thus, following any attempt to recompile:
Checking Properties for the recompiled scripts will show no compiled experience. Plus shift-copying or using the edit menu to copy or dropping an experience script in a host, will all result in the experience being completely lost from the script compile. However, llResetScript() doesn’t trigger the loss.
A bug report has been raised on group chat lag (BUG-227477). The Lab is aware of this and has left the report open for further input from those experiencing issues. Constructive and informative feedback is clearly being sought, along the lines of the comments thus far left.
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.
![][Octopussy][ goes Cuba; Inara Pey, July 2019, on Flickr](https://live.staticflickr.com/65535/48250373461_9467c8ce90_o.jpg)
Inara Pey: Living in a Modemworld 