Firestorm 6.3.2: welcome to Bakes on Mesh

Posted on by Inara Pey
On Monday, September 30th, 2019, Firestorm released version 6.3.2.58052 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 5.1.7.55786 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 6.0.2.56680 for OpenSim users. As the 6.3.2.58052 release installs separately to 6.0.2.56680, 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.

Notes:

  • 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

 6.3.2.58052 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

Notes:

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

Fixes:

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

Feedback

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 6.3.2.58051/58052 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

Published by Inara Pey

Eclectic virtual world blogger with a focus on Second Life, VR, virtual environments and technology.

11 thoughts on “Firestorm 6.3.2: welcome to Bakes on Mesh”

  1. I am not sure that Bakes-on-Mesh is going to be all that useful. But I am speaking as a Creator who already makes and uses efficient meshes. Mesh body and clothes, and Avatar Complexity showing as under 20k, sometimes under 10k. I check the LOD switching distance, and how big triangles will appear on screen. I use texture sizes that look good (the system relates the texture size used to the pixel count on-screen, but it needs much more work, download and calculation, to show something at 1024-size). And I see big-name creators (and Linden Lab) using a 1024-size for a mesh item that is about the size of your hand.

    The SL16B freebie outfits, handed out for free by Linden Lab, were horrible for this excessive complexity. And this was for outfits pushed for use at crowded events. It left me with the feeling that Linden Lab doesn’t know what they are doing. This whole thing reminds me of times I was ejected from regions because “Furries lag sims!”, when my avatar, then, was about a quarter of the complexity of any of the humans. There seem to be a lot of myths lingering in the Forums.

    Bakes-on-Mesh was a lot of work, and maybe will have some benefit, but Linden Lab would have got a better return from writing clear documentation for creators. The info I used to get the low complexity was hard to find. A common problem is stuff spread over several web pages, as some features were upgraded, with new-to-old links, but nothing old-to-new, and search systems which prefer the oldest page.

    I shall think about using Bakes-on-Mesh, but the way in which UV maps are involved mean I may be horribly limited in the options. It looks an easy way of putting different slogans on a T-shirt, but the interactions between any transparency and the underlying avatar will need some practical experiments.

    Like

    1. Regarding the SL16B gifts, I think that was a matter of public visibility.
      Anything that is not made to be over the top or with 1024×1024 is labeled by the uneducated SL user (I.E. most people) as “not at all good.”

      As a content creator yourself I’m sure you have had messages from people displeased that they cannot press their noses against your creations and have all the detail of a 1024×1024 texture in there. I remember many years ago someone had a small marketplace store with mesh clothes, and the creator specifically said in every item description that every item was created with optimal sized textures, that meant although they wouldn’t be as sharp as 1024×1024, the performance gain would be worth the quality loss.
      All that creator got in the reviews was 1 star and people complaining it wasn’t as good as this or that brand.

      This is just the perception of the public in SL, and had LL produced anyone other than something with unnecessary high geometry and textures, the public would have complained about the quality of such freebies.
      So I don’t think it’s a matter of “they don’t know what they are doing” when they can create perfectly fine complete looking avatars with 2,000 or about complexity.

      Like

    2. Yes, in some ways Bakes on Mesh can appear limited in application; if your mesh body uses totally unique UV meshes, as you note, then BoM may not work entirely satisfactorily. However, as I noted in more detail in my Basic Bakes on Mesh Primer and mentioned in passing here, it could help reduce the complexity of onion layer body and head products. Plus, right now using appliers, we have a body using a 1024×1024 skin, with potential one or two further layers – tattoo (/make-up), clothing (and perhaps even multiple layers of clothing from different appliers) all at 1024×1024. With BoM, these all get composited down to a single texture that viewer need to handle – so again, the potential for improvements.

      Currently, most human head / body makers are working to adopt mesh flagging in their products – but TBH, I’ve not examined things in great detail to see if better “optimisation” (= fewer “onion layers”) really is happening – largely because the makers of my own body / head have yet to release fully BoM compatible items. Even so, I’m also somewhat sceptical as to the overall “improvements” BoM will bring in terms of things like performance.

      In terms of documentation / guidance – that is actually a frequent topic of conversation at the Content Creation User Group, where it is acknowledged more could be done to pull information together and repackage for better presentation, and it is something LL are cogitating over – they’re just not actively seized with re-working it at this point in time.

      Like

      1. I have heard this confusion about UVs many times. Custom UVs work just as well with Bakes On Mesh as the LL default avatar UVs. The UVs don’t matter to Bakes On Mesh. What matters is that when the textures are originally created and uploaded to SL they use the same UV pattern as the final mesh those textures are going to be applied to.

        OK lets say you make a custom mesh body. You decide the body is going to have two faces an Upper Body and Lower Body. Kinda like LL default avatar but you decide to make custom UVs. You then make custom textures for it as in skin textures that obviously use your custom UVs.

        Then you upload the mesh body to SL and set it to use Bakes On Mesh so that the Upper Body face will use the BAKED_UPPER and the Lower Body face will use BAKED_LOWER. Then you upload your two skin textures you made for your mesh body. In your inventory in SL right mouse click and select “New Body Part”<"New Skin". Wear your new skin and edit it and place your two new skin textures in the Upper Body slot and in the Lower Body slot and save the skin.

        If you are not wearing your custom mesh body with the custom mesh UVs then yes the LL default avatar will look messed up but as soon as you wear your custom mesh body that is setup to use Bakes On Mesh the textures will look the way they are supposed to look because the mesh body and the textures are using the same custom UV layout.

        You don't have to use BAKED_UPPER and BAKED_LOWER if you didn't want to. You could use any baked slot. You could use BAKED_AUX 1 for the upper body of your custom mesh body and BAKED_AUX 2 for the lower part of your custom mesh body. Then instead of using a system skin you could use a new Universal system clothe and put the two textures you just uploaded in the two slots. Of course you would have to hide your LL avatar with a full body alpha just as we had been doing before Bakes On Mesh.

        All the mesh body and head designers I know are busy trying to match their UVs as close as possible to the LL default avatar UVs so that more skins, makeup, tattoos and clothing textures work on their bodies and heads. Also many system clothes have their own appearance sliders so by using the same UVs as LL default avatar UVs their mesh bodies and heads can take full advantage of them.

        While the LL default avatar UVs have much to be desired they are the closet thing to a universal standard we got. So if you are a mesh head designer or mesh body designer it is a very good idea to use the LL default avatar UVs but if you want to use custom UVs that is OK too. Bakes On Mesh will happily apply textures made for custom UVs on your mesh that is using the same custom UVs.

        Like

  2. Thanks for the thorough review. One issue that has arisen today (10/3/19) is that the fix for “Movement at region cross” for Predict has now broken the Stop feature. If you use the Stop feature for your plane, car or motorcycle, it will not work in the new version.

    Like

    1. I’ve found the Stop function to be somewhat unpredictable – even before the “Predict breakage” – and dependent upon a range of factors, including vehicle speed on encountering a region crossing, whether travelling in a straight line or turning, etc. In testing 58051 and 58052 with several boats and aircraft, I personally found the Stop behaviour to be pretty much the same as before the “Predict Breakage”, so didn’t really note any issues.

      If you have a specific issue (or issues) you can reproduce, the best thing is to raise a Firestorm Jira bug report, supplying the full description of what you’re seeing and how. You might want to include details of types of vehicle with which you’re seeing the behaviour as well.

      Like

        1. Interesting. The angular motion (e.g. the roll of an aircraft in a bank) is something I’d seen prior to the “Predict breakage”; ergo, didn’t really classify it as a breakage with this release.

          Like

          1. But with “Stop” in the previous version there was no roll or spin – you just stopped until the handoff happened. The FS code was replaced with LL code and that fixed Predict but it broke the Stop function. I ended up downgrading back to previous version of Firestorm so I could continue to use my vehicles. The previous version is working as it should, the new version of stop does not work.

            Like

    1. Not sure what you mean by “angle shoot”. If you mean using different camera angles, you already can and in any viewer, as they all use the same basic camera control code.

      Like

Comments are closed.