Category: SL User Group Meetings

2018 SL UG updates #16/1: Simulator User Group

Posted on by Inara Pey

La Virevolte; Inara Pey, March 2018, on FlickrLa Virevolte – blog post

Server Deployments

As always, please refer to the server deployment thread for the latest updates.

  • On Tuesday, April 17th, 2018, the Main (SLS) channel was updated with server maintenance package 18#18.03.29.513939, previously deployed to the RC channels and containing internal fixes.
  • On Wednesday, April 18th, 2018, the major RC channels, BlueSteel, Magnum and LeTigre should all be updated with the same server maintenance package 18#18.04.09.514272, containing internal fixes and a fix for BUG-214702.

SL Viewer

With the exception Animesh project viewer (see below), there have been no updates to the current SL viewers thus far in week #16, leaving the pipelines as follows:

  • Current Release version 5.1.3.513644, dated March 27, promoted April 13 – formerly the media update RC – NEW
  • Release channel cohorts:
  • Project viewers:
  • Linux Spur viewer, version 5.0.9.329906, dated November 17, 2017 and promoted to release status 29 November – 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.

Animesh Project Viewer Update

The Animesh project viewer updated on Monday, April 16th. Version 5.1.4.514468 brings the viewer to parity with the current release viewer. In addition this viewer has revised streaming cost/land impact formula for Animesh objects, which are also reflected in ARC (avatar rendering cost) calculations for Animesh items.

In summary, the updates are:

  • Animesh attachment limit = 1: only one Animesh object can be attached to an avatar at a time. This is unchanged from the original estimates.
  • Triangle Count Limit = 100,000: an animesh object (linkset) can have at most 100k triangles, where the count is based on the estimated size of the largest LOD (normally this is the high LOD). This includes all mesh triangles, static or rigged.
  • Land Impact: streaming cost = 15.0 + 1.5 * ktris + cost of non rigged prims: for a rigged mesh prim in an animesh linkset, the streaming cost will be 0.0015 * effective_tri_count – that is, 1.5 per thousand triangles. The value for effective_tri_count is derived from the estimated triangle count of the various LODs in the prim as follows:
    • High LOD: all of the estimated triangle count included in the effective_tri_count.
    • Medium LOD, Low LOD and Lowest LOD: the allowed number of triangles can be up to ½ of the LOD above, or 64, whichever is larger (i.e. Medium can be up to ½ of High, or 64, whichever is larger). If there are more triangles than this limit, that excess will be added to the effective_tri_count.

See Vir’s explanation in the Animesh updated limits and cost formulas forum thread for a complete explanation of these limits and how they have been arrived at.

An important point to note is that these formulas only apply to Animesh; there is a second, and longer-term project – ARCTan – a re-evaluation of all object and avatar rendering costs (and which may see further changes to Animesh calaculations). It is hoped that overall, ARCTan  will improve viewer-side performance and provide creators with positive incentives to build more performant content.

You can find out more on ARTan in this blog post and this blog post in this blog.

Viewer Texture Cache

As noted in several of my TPV Developer meeting updates, Linden Lab are trying to improve viewer caching – starting with the texture cache. Commenting on the work, Oz Linden said, “We’re experimenting with a number of different changes. Some that you might think (I did) would make things better turned out not to, but we’re making progress.” It’s not clear if / when any project viewer utilising any new texture caching capability will be available for general use.

LlRequestUserKey and LlName2Key

The Lab has released two new LSL functions: llRequestUserKey and llNameToKey, both of which are in connection to the upcoming return of Last Names (see this blog post and this blog post for more):

  • llRequestUserKey:
    • Requests the Agent ID for the agent identified by name from the dataserver. The name given may be either the current name of an avatar or a historical name that has been used in the past. If no agent can be found with the supplied name this function returns the value NULL_KEY.
    • It returns a handle (a key) that can be used to identify the request when the dataserver event is raised.
    • Note that agent being searched for with this function does not need to be signed on to Second Life.
    • See the llRequestRequestUserKey wiki page for more.
  • llName2Key:
    • Returns a key the Agent ID for the named agent in the region. If there is no agent with the specified name currently signed onto the region, this function returns the value NULL_KEY. Names are always provided in the form “First[ Last]” or “first[.last]” (first name with an optional last name.)
    • If the last name is omitted a last name of “Resident” is assumed. Case is not considered when resolving agent names.
    • Uses a different mechanism to look up agent information to the older llKey2Name().
    • See the llName2Key wiki page for more.

2018 SL UG updates #15/2: TPVD meeting

Posted on by Inara Pey

Isle of May; Inara Pey, March 2018, on FlickrIsle of May – blog post

The majority of these notes are taken from the TPV Developer meeting held on Friday, April 13th 2018. A video of the meeting is embedded below, my thanks as always to North for recording and providing it. Time stamps in the text below will open the video in a new tab at the relevant point of discussion.

The meeting was reduced to under 15 minutes, with extended pauses marking a greater portion of it.

Server Deployments

As always, please refer to the server deployment thread for the latest updates.

  • The Main (SLS) channel was not updated on Tuesday, April 9th, nor was there a restart.
  • BlueSteel, LeTigre and Magnum are all now on server maintenance package 18#18.03.29.513939 after Magnum was updated on Wednesday, April 11th.

SL Viewer

[0:05-1:32] The Media Update RC viewer, version 5.1.3.513644, dated March 27th, was promoted to de facto release status on Wednesday, April 11th. As a result, the remaining RC viewer were updated to parity on Friday April 13th, as follows:

The remainder of the SL viewer pipelines remain as:

  • Project viewers:
  • Linux Spur viewer, version 5.0.9.329906, dated November 17, 2017 and promoted to release status 29 November – 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.

[1:33-1:50] With regards to the 360 snapshot project viewer, this is being routinely updated internally by the Lab to keep pace with release viewer promotions. However, no actual work is being carried out on the 360 snapshot element at the moment. Work will resume in the future.

[1:58-2:29] A new Voice update RC is due in the future at some point, which fixes some issues from the last Voice release. However work on this is currently a “low priority”.

Off-Line and Abuse Reports Capabilities

[2:31-3:30] Two new capabilities are now grid-wide server-side:

  • A new abuse report cap which replaces the need for the viewer to have AR categories hard-coded into it.  Instead it will request the list of valid categories directly from the simulator.
  • A new IM cap is to overcome of off-line IMs failing to be delivered when a user logs in. This cap will allow the viewer to request off-line IMs, which the server will package and deliver to the viewer via HTTP, rather than sending off-lines en masse whether or not the viewer is ready.

Both of these caps require viewer-side updates in order to work. However, there is currently a bug impacting the viewer update for the new off-line IMs capability. In short, if you receive an off-line Friend request, there is no way to accept it with the new capability in place. The abuse report capability appears to be working correctly, so expect both to appear in a viewer update soon.

Friending can be fragile, and the Lab hope to make it more robust over time.

 

2018 SL UG updates #15/1: Simulator User Group

Posted on by Inara Pey

Spirit of Sun; Inara Pey, March 2018, on FlickrSpirit of Sun – blog post

Server Deployments

As always, please refer to the server deployment thread for the latest updates.

  • The Main (SLS) channel was not updated on Tuesday, April 9th, nor was there a restart.
  • On Wednesday, April 11th:
    • The BlueSteel and LeTigre will not be updated, and remain on server maintenance package 18#18.03.29.513939, containing internal fixes.
    • The Magnum channel will apparently receive a further revision to 18#18.03.29.513939.

SL Viewer

  • The Love Me Render RC viewer updated to version 5.1.3.514115, dated April 5th.
  • The Ouzo Maintenance RC viewer updated to version 5.1.3.514128, dated April 5th.

The remainder of the SL viewer pipeline remains unchanged from the end of week #14:

  • Current Release version 5.1.2.512803, dated February 23, promoted March 1 – formerly the Nalewka Maintenance RC – No change
  • Release channel cohorts:
  • Project viewers:
  • Linux Spur viewer, version 5.0.9.329906, dated November 17, 2017 and promoted to release status 29 November – 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.

Bakes on Mesh

This is the project to extend the current avatar baking service to allow wearable textures (skins, tattoos, clothing) to be applied directly to mesh bodies as well as system avatars. This involves server-side changes, including updating the baking service to support 1024×1024 textures, and may in time lead to a reduction in the complexity of mesh avatar bodies and heads.

This work does not include normal or specular map support, as these are not part of the existing baking service.

As noted in my last CCUG update, the project viewer, version5.1.3.513936, arrived on March 30th, 2018 (see the Bakes on Mesh JIRA filter for reported issues). There is a forum thread on the project, which carries a degree of misinformation on the project. Siddean Munro has sought to clarify things in a blog post, and Cathy Foil has produced an introductory video as well.

Environmental Enhancement Project

This is the project to create a set of environmental enhancements including the ability to define the environment (sky, sun, moon, clouds, water settings) at the parcel level; new environment asset types (Sky, Water, Days – the latter comprising multiple Sky and Water) that can be stored in inventory and traded through the Marketplace / exchanged with others; Experience-based environment functions and an extended day cycle (e.g a 24/7 cycle) and extended environmental parameters. The work involves simulator and viewer changes, and includes some infrastructure updates.

Rider Linden is working on EEP, and he reported, “I’ve been dealing with a little bit of a tangent having to do with internal inventory. Turned out to be a bit more complex than I anticipated when I said: “Sure, I’ll just knock that off as part of EEP”. It is almost resolved and then I can get back to direct EEP development.”

He also revealed more on how EEP will be “layered”: “EEP will have four different altitude layers. (Right now I’m operating with ground, 1km, 2km and 3km.) … The use case I see for the layers isn’t so much skyboxes, more for landing areas for RP sims that may want their own atmosphere; orbiting space stations , etc. (and the layers need to be set by the parcel owner.)”

Aditi Inventory Sync

Usually, sync on inventory from Agni, the Main grid, to Aditi, the Beta grid is designed to take place during a routine syncing operation run at around 2:00am PST daily, triggered by an Aidit log-in (see here for more).

However, as most of those who routinely log-in to Aditi will know that the system isn’t working correctly, and often, a ticket is required to get your Aditi inventory correctly synchronised with your Agni inventory. Commenting on the situation at the Simulator User Group, Mazidox Linden said, “We’ve got a dev working on the inventory sync to Aditi. We’re making some interesting progress, hopefully more news soon.” Oz Linden further indicated that a fix is in the pipeline.

 

2018 SL UG updates #14/2: CCUG summary

Posted on by Inara Pey
Animesh dragons by Wanders Nowhere and used by Lucia Nightfire as Animesh test models

The following notes are primarily taken from the Content Creation User Group (CCUG) meeting, held on  Thursday, April 5th, 2018 at 13:00 SLT. For the purposes of Animesh testing, the meetings have relocated to the Animesh4 region on Aditi, the beta grid – look for the seating area towards the middle of the region. The meeting is chaired by Vir Linden, and agenda notes, etc, are usually available on the Content Creation User Group wiki page.

Medhue Simoni Live streamed the meeting, and his video is embedded at the end of this summary. My thanks to him for providing it. Time stamps are included in the text below to allow easy referencing to the video for details. Please note that Vir’s microphone was not behaving during the meeting, causing his voice to drop-out at times, breaking up the context of his conversation (I had the same issue with my audio recording).

Bakes On Mesh

Project Summary

Extending the current avatar baking service to allow wearable textures (skins, tattoos, clothing) to be applied directly to mesh bodies as well as system avatars. This involves server-side changes, including updating the baking service to support 1024×1024 textures, and may in time lead to a reduction in the complexity of mesh avatar bodies and heads.

This work does not include normal or specular map support, as these are not part of the existing baking service.

Resources

Current Progress

The project viewer is now available – version 5.1.3.513936, which as noted in previous updates, was released on March 30th. This is the first pass of the viewer, and there is much more work to come.

General Notes from the Meeting

[2:55-04:00] Some mesh body creators are already involved in looking at Bakes on Mesh, and the Lab has been gathering names and details of creators, but there has – as of the time of the meeting – been no direct outreach to any of them. Siddean Munro (Slink) is reported to be “thrilled” with the capability, and sees it as a means to dramatically reduce her workflow.

[4:45-5:55] Status of 1024×1024 support: While the first part of the Bakes on Mesh project was to update the Bake Service to support 1024×1024, currently, these back-end changes have not been deployed, so all Bakes on Mesh testing currently use the existing 512×512 textures supplied by the Bake Service. The deployment has been delayed due to other work being carried out on the Baking Service, but it is hoped it will be deployed in the next few weeks.

[13:26-14:22] It terms of 10242 texture support with the baking services is eye textures. Currently 128×128, these will be increased to 256×256, the pixel density on so small a target compensating for the lower resolution.

When  the increased texture resolution support is deployed, the Lab will also be implementing additional servers to support the additional load on the Baking Service.

[6:01-8:49] Wearable/ Texture Map issues: It’s been noted that the eyelashes are tied to the avatar eyeball texture, not the avatar head, which might cause some issues.

The right / left arm being mirrored in the texture map has also been re-noted. This is prompting some creators to consider re-purposing the system skirt or hair wearable (which are now almost never used) to be assigned to one or other of the arms. This would  allow, for example, a tattoo to appear on one arm only, rather than being mirrored on both arms, as is currently the case on system avatars.

[9:52-11:05] In order for this to work, the textures would need to be uploaded as a skirt or system hair. Basically, the system wearables act as containers of the textures, so if you want to apply a texture to a specific body region (as supported by the viewer / Bakes on Mesh), you can assign it to that wearable (e.g. the texture can be applied to the undershirt, shirt or jacket wearable to be applied to the upper body, or to the skin wearable to be applied to the entire body).

Cathy foil also gave feedback on using Bakes on Mesh to apply system eye textures to mesh eyes.

[8:53-9:49] Will the baked texture slots be expanded in to future? (there are currently 6 slots: BAKE_HEAD, BAKE_UPPER, BAKE_LOWER, BAKE_EYES, BAKE_SKIRT, BAKE_HAIR.) Possibly, but not being considered with Bakes on Mesh at present. Currently, the bake texture slots are tied to the supported wearable textures. Adding more slots  would require defining the underpinning data to be stored in the additional slots (i.e. define additional wearables).

[12:10-12:36] One thing to remember is that if an alpha layer in used to hide your system avatar (or a major part of it), it will be baked as well, and if that bake is applied to a mesh, it can end up masking more of the mesh than intended, due to the extent of the alpha.

[14:42-17:02] Hiding the base avatar: a means to hide the system avatar without having to use an alpha mask has long been a request, raised again during the Bakes on Mesh project. No decision has been made on if this will be done or how. One approach might be to make a further change to the Bake Service so it ignores the base avatar; another might be it use an unassigned texture slot to “hide” the avatar from the Bake Service – this has the advantage of not requiring a change to the Bake Service.

[17:29-25:00] A general discussion on how a more flexible use of Bakes on Mesh might be achieved – such as re-purposing rarely used texture slots, or extending the Bake Service itself.

  • Re-purposing texture can be done with care – such as using the skirt or system hair as described above to give individual texture for the arms.
  • Further extensions to the Bake Service itself – e.g. additional bake slots beyond the current 6  are unlikely to form a part of this project, but might be considered for any follow-on that comes after it.

The Lab also have some concerns about opening-up the Bake Service further include the potential for performance hits, possible abuse.

Cathy Foil demonstrates Bakes on Mesh. Left: she is wearing a mesh body with system layer clothing applied to it, as seen through the Bakes on Mesh viewer. Currently, only those using the Bakes on Mesh project viewer will still mesh bakes in this way. Right: until the Bakes on Mesh code is incorporated in all viewers, those running viewers without the code will see avatars using Bakes on Mesh with place holder textures on place of the baked texture.

[25:09-27:35] Extending the Bake Service to support materials: this is a complex step to take, which may not even be properly defined. Maps (diffuse (texture), normal and specular) all have to be defined by layer and brought together properly in a composite bake in such a way to ensure normal and specular maps from one layer are correctly associated with the diffuse map from that layer, so they aren’t displayed over another layer. As such, materials support will only be considered as a potential element for a follow-on project to the current Bakes on Mesh work. See also BUG-214631 for a proposal on how materials support might work.

[33:37-34:11 and 36:40-37:20] Bakes on Mesh for HUDs / Bakes and Textures: conversation on bakes on mesh and HUDs, expansion on Bakes on Mesh vs. appliers, and texture and Bake UUIDs. In short: Bakes on Mesh can also be applied to HUDs, which could help reduce the number of textures commonly found in them (a single composite rather than multiple textures). Complexity of HUDs might also be reduced, simply because the texture applying elements may no longer be required as textures will come via the Bake Service – although applier HUDs for materials will still be required.

Some are concerned allowing bakes on HUDs increases the risk of texture theft (by allowing the textures to be screen capped, for example). However given this can be done anyway, simply by displaying a texture on a cube and then attaching the cube to the screen as a “HUD”, it’s hard to see what the fear really is (it’s also not the most efficient way of wrongly getting a texture out of SL).

[42:40-44:13] Fewer textures: the general hope with Bakes on Mesh is that over time, it will allow mesh bodies  / heads to be less onion layer complex, and also reduce the number of different textures being applied, by allowing layers (e.g. skin, make-up, tattoo, etc.), to be composited down to a single baked texture.

[44:26-45:52] Wearables cap: a reminder that up to 60 wearables can be applied to a single avatar in any combination of layers, and the order in which they are displayed corresponds to the individual layers (e.g. undershirt, shirt, jacket), and the order in which multiple items in those layers are worn. See this 2015 project update for more on the global wearable allowance.

[47:17-47:32] Can local textures be used with Bakes on Mesh? No. local textures are just that, local to a user’s system; they are not transmitted to LL’s servers, and therefore, they cannot be baked.

[48:10-49:00] Bakes on Mesh and Edit Appearance:  it’s been noted that mesh bakes don’t update with changes made in the Edit Appearance mode (see BUG-216014). This is because Edit Appearance is local changes within the viewer, usually applied to the system avatar. Bakes on Mesh require the data to be sent to the baking service, composited, and applied – which only happens on exiting Edit Appearance. Vir has indicated it might be possible to add the logic required to have the appearance editor update in real-time when using mesh bakes.

Continue reading “2018 SL UG updates #14/2: CCUG summary” →

2018 SL UG updates #14/1: Simulator User Group

Posted on by Inara Pey

Bay of Dreams; Inara Pey, February 2018, on FlickrBay of Dreams – blog post

Server Deployments

As always, please refer to the server deployment thread for the latest updates.

  • The Main (SLS) channel was updated on Tuesday, April 3rd  to server release 18#18.03.27.513831, containing internal fixes and updates the new off-line IM and Abuse Report capabilities (see below).
  • On Wednesday, April 4th, the BlueSteel and LeTigre release candidate channels should receive server maintenance package 18#18.03.29.513939, containing internal fixes; the Magnum RC has no planned deployment, and remains on 18#18.03.27.513831.

SL Viewer

There have been no changes to the viewer pipelines at the start of the week, leaving them as:

  • Current Release version 5.1.2.512803, dated February 23, promoted March 1 – formerly the Nalewka Maintenance RC – No change
  • Release channel cohorts:
  • Project viewers:
    • Bakes on Mesh project viewer, version 5.1.3.513936, March 30 (note this version of the viewer does not support applying bakes to mesh bodies / heads).
    • Animesh project viewer, version 5.1.3.513013, March 7 – project overview.
    • 360 snapshot viewer, version 5.1.3.513006,  March 6 (this version can have significant rendering issues, see my hand-on update).
  • Linux Spur viewer, version 5.0.9.329906, dated November 17, 2017 and promoted to release status 29 November – 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. This viewer will remain available for as long as reasonable, but will not be updated with new features or bug fixes.

Region Crossings

As I’ve reported in recent Simulator User Group meetings, Joe Magarac (animats) working on a scripted workaround to improve region crossings (“partial unsits, etc.) – see BUG-214653. The Lab is also working on crossings on the simulator side. While no time frames for the work were given, Oz Linen did observe, “How successful we’ll be remains to be seen, but we’re optimistic that we can make significant improvements.”

2018 SL UG updates #13/4: TPVD meeting

Posted on by Inara Pey

Cuivieenen; Inara Pey, February 2018, on FlickrCuivieenen – blog post

The majority of these notes are taken from the TPV Developer meeting held on Friday, March 30th 2018. A video of the meeting is embedded below, my thanks as always to North for recording and providing it. Time stamps in the text below will open the video in a new tab at the relevant point of discussion.

The meeting was reduced to under 15 minutes,with minor topics of discussion taking up the latter half. Please refer to the video for these.

Server Deployment Update

  • The Main (SLS) channel was updated on Tuesday, March 27th, to server release 18#18.03.14.513292, containing the new off-line IM and Abuse Report capabilities (see below).
  • The Magnum and LeTigre RC channels were updated on Wednesday, March 28th with server maintenance package 18#18.03.27.513831, containing internal fixes and the new off-line IM and Abuse Report capabilities (see below).
  • The BlueSteel RC was updated on Thursday, March 29th with server maintenance package 18#18.03.27.513838, comprising internal fixes.

SL Viewers

Viewer Pipeline

Note: At the time of the meeting, the viewer had just been approved for issue, but it wasn’t clear if it would be released before or after the Easter weekend. However, it was in fact issued after the meeting – see below.

[00:24-3:02] At the time of the meeting, the viewer pipelines were as follows:

  • Current Release version 5.1.2.512803, dated February 23, promoted March 1 – formerly the Nalewka Maintenance RC – No change
  • Release channel cohorts:
  • Project viewers:
  • Linux Spur viewer, version 5.0.9.329906, dated November 17, 2017 and promoted to release status 29 November – 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.

Off-Line and Abuse Reports Capabilities

[0:44-1:36] Two new capabilities are now grid-wide:

  • The new IM cap is to overcome of off-line IMs failing to be delivered when a user logs in. Currently, these are delivered via UDP, whether or not the viewer is ready to receive them. With the new capability (once grid-wide and implemented within the viewer), the viewer will request off-line IMs, which the server will package and deliver to the viewer via HTTP.
  • The new abuse report cap will replace the need for the viewer to have AR categories hard-coded into it. Once fully deployed, and a viewer update released, it will mean the view will request the current list of AR categories from the server when starting up, making the management of the list easier, and hopefully reducing the number of ARs filed under outdated categories.

However, both require further revision, and they require viewer-side updates as well. These should be appearing in the next Maintenance RC viewer issued by the Lab.

Bakes on Mesh Project Viewer

The Bakes on Mesh project viewer, version 5.1.3.513936, was released on Friday, March 30th after the TPV Developer meeting had concluded.

From the release notes (link above):

Bakes on Mesh is a new feature to allow system avatar baked textures to be shown on mesh attachments. Currently you will need a special project viewer to use it. Bakes on Mesh does not depend on simulator code, so it should work in all regions and all grids.

Basic features

  • Any face of a mesh object can be textured using one of the server baked textures.
  • The corresponding region of the system avatar is hidden if an attached mesh is using a baked texture.

Benefits

  • Avoid the need for appliers -> easier customization workflow
  • Avoid the need for onion avatars -> fewer meshes, fewer textures at display time
  • Avoid the need to sell full-perm meshes. You can customize any mesh you have modify permissions for simply by setting the flags and equipping the appropriate wearables.

Avatar wearables are baked into six different textures (BAKE_HEAD, BAKE_UPPER, BAKE_LOWER, BAKE_EYES, BAKE_SKIRT, BAKE_HAIR) by the baking service. You can now apply these textures to your avatar’s object attachments’ diffuse texture slot. Right click on the attachment, click edit and from the edit face menu select textures. Click the diffuse texture icon to open up the texture picker. The texture picker has an extra radio button mode called ‘bake’ for selecting server bakes. The ‘bake’ radio button mode has a drop-down for selecting BAKE_HEAD, BAKE_UPPER, BAKE_LOWER, BAKE_EYES, BAKE_SKIRT, BAKE_HAIR server bake textures. When an attachment is using a baked texture, the corresponding base mesh region of the system avatar is hidden.

If a mesh face is set to show a baked texture but is not attached to an avatar, you will see a default baked texture. If you are using an older viewer without bakes on mesh support, then faces set to show baked textures will also display as the default baked texture, and base mesh regions will not be hidden.

Known Issues

Detaching a mesh object that’s using BAKED_HAIR, does not make the base hair region visible. You have to log back in or teleport again. This will be fixed in next release.

A filter for Bakes on Mesh JIRAs has been created by Whirly Fizzle.