Avatar Baking: “and the clock has started!”

Forwards and Backwards Compatibility

A key concern raised – and also addressed in the wiki page – was that of forwards / backwards compatibility between the new system and the old system.

Project Sunshine has been designed with the assumption that all viewers will be updated with the new viewer-side code before the server code gains widespread adoption across the grid as it will take time to test and scale-up the server code and deploy it across all the release channels (including Release and Main Candidates).

As such, the viewer code developed by Linden Lab is designed to work whether or not the server-side code has been implemented. Essentially, the viewer will continue to use the old-style avatar baking protocols until such time as it connects with a region which has the new protocols enabled. At that point, the user’s appearance message will be converted to a server-generated message that will persist even if the viewer subsequently connects to a region which is not running the new code, and new-style appearance messages will remain flagged as such. Since textures are fetched from a central service, updated viewers will be able to fetch an avatar’s textures even if the server does not support it.

How the viewer code will initially work: when connected to a region supporting the new baking service, it will use that service (left), with the compositing baking service communicating with the simulator (top right & centre). Should the viewer initially connect via a region not running the service, the current method of baking will be used (lower right & centre) until such time as the viewer connects to a region running the new service (image courtesy of Linden Lab, view the Baking Service wiki page)

The only exception to this is when forcing a rebake (CTRL-ALT-R) or changing outfit when in a region which is not running the new baking protocols. When this happens, the viewer will revert to uploading local bakes for distribution by the server (as is the process now). These will be automatically overwritten on connecting to a region supporting the new protocols.

However, the server-side of things will not support any form of “backwards compatibility” – it will only work with updated viewers. This means that once the new service has been fully deployed:

  • The viewer will no longer be able to upload avatars textures to the simulator as it currently does; that part of the pipeline is being removed from the simulator code
  • Anyone logging-in to Second Life using viewer which does not support the Current Outfit folder and/or which does not have the viewer-side code implemented will be unable to see fully textured avatars around them. Other avatars will either fail to render and remain as clouds, or will render as “grey ghosts” which never texture
  • In addition, while someone logging-in to Second Life using a viewer without the new code may look perfectly OK in their own world view (because their appearance has been generated by their viewer), they will be ghosted or greyed out to those around them using the new service.
"I see grey people", demonstrating the new baking service on Aditi: Left - I'm running Firestorm and appear OK, but my CTA is running the Sunshine project viewer, and appears grey; Centre - the view from the Sunshine project viewer, and I'm left ghosted; Right - both on the Sunshine viewer, properly textured (note that numbers appear to be an artefact of the project viewer, which is pre-Alpha
“I see grey people”, a look at what may happen when using a viewer which has not been updated to use the new avatar baking code. Left – I’m running Firestorm and appear OK, but my CTA (running the Sunshine project viewer), and appears grey (note her hair and shoes are rendered as they are prim attachments, and so are handled separately from baking process) ; Centre – the view from the Sunshine project viewer: I appear ghosted (running on the Firestorm viewer) and my CTA appears fine. Right – both avatars on the Sunshine viewer, properly textured (note that numbers are a testing artefact and will not appear in any release viewer using the code)

In terms of viewers, the majority in use with Second Life already support the Current Outfits folder, which means the emphasis for most TPVs will be in the implementation of the the viewer-side baking code. As such, and as both LL and TPVs reach a point where they can start releasing viewers for general day-to-day use and the server-side code starts being deployed, the majority of users shouldn’t notice any change whatsoever, as the new code does not require any changes to the viewer UI or anything (although there will be a knock-on effect with temporary texture uploads – see below). Nor should the differences between how the two baking services work be in any way visible – other than bake fail issues (hopefully) going away, or at least seeing a dramatic reduction in their occurrence.

However, for those using viewers which do not support the Current Outfits folder (such as the official 1.23.5 viewer, which is still used by some) Second Life will become increasingly grey / cloudy where other avatars are concerned as the server-side deployment of the new service progresses. Even so, LL have no plans at present to physically block any viewer which does not support either the Current Outfits folder or the new baking code from accessing the grid once the new service is deployed.

Approximate Time Frames

There are still no definitive time frames for the deployment of the new baking service. However:

  • TPVs have been given the go-ahead to start merging the viewer-side code with experimental branches of their own viewers and running it on an initial test region created on the beta (Aditi) grid for precisely this purpose, with the aim of having all major testing completed by around mid-February
  • LL will continue to work on their viewer code in the interim to deal with a number of known issues and bug, and expect to update the code with a few patches – which will also be made immediately available to TPVs
  • It is hoped that by around mid-February, the viewer code will be sufficiently well advanced to be merged into the viewer development code branch and from there into the beta code branch, which could trigger the start of server-side code deployments. However, this is dependent upon the issues / bugs / problems TPVs may encounter with the code as well as issues uncovered in more general testing and reported through the project JIRA.
  • Any deployment of the server code will be dependent upon further and significant load tests. These are viewed as essential in ensuring the new compositing service has sufficient hardware for it to support avatar baking across the entire grid. Plans for this testing have yet to be finalised, but may include deploying the service to small sections of the main grid ahead of any “official” RC channel deployments, as well as the potential for LL to request assistance in carrying out “pile-on” tests with the service in the New Year
  • A further issue which may impact deployment plans is in ensuing the new service to provides “pixel perfect” baking which does not have unintended consequences in terms of texture appearance and alignment, etc. This work is still ongoing, although Nyx commented the Lab was getting “pretty darned close” to matching the current baking service, the aim again being that when the service is deployed, users will be unable to see any visible difference between the old and the new service – other than no longer experiencing the headache of bake fail.

Taking all of the above into account, it would seem reasonable – but not certain – that the service could see deployment underway by mid-March.

Points of Note

HTTP Service

The new avatar baking service is HTTP based for texture fetching. This is not the same code  / pipeline as Monty Linden has been working on to improve in-world texture fetching and rendering, but it does use the same framework. This means that users will need to ensure they keep the HTTP option in their graphics preferences checked at all times (viewers tend to have this option enabled by default).

Alpha Mask Creation

Linden Lab recommend that when creating an Alpha mask for all / part of the avatar body via the Edit Outfit floater, the alpha transparency check boxes should be ticked where appropriate, rather than a transparent texture being applied. This will assist the avatar rendering process by simply rendering the required part of the body transparent, rather than fetching / applying the transparent texture.

To lighten the rendering load, it is suggested the transparency checkboxes are used for creating alpha masks when using the Edit Floater, rather than applying a transparent texture
To lighten the rendering load, it is suggested the transparency check boxes are used for creating alpha masks when using the Edit  Appearance Floater, rather than applying a transparent texture

Temporary Texture Uploads

One side issue of the new service (and the one likely to cause controversy) is that once it will disable the “temporary textures” upload capability common to most TPVs. This does not mean that it will no longer be possible to preview textures without payment to the main grid for testing purposes – the new baking service will not impact the Local Textures capability found in the official viewer and most TPVs. However, what it does mean is that textures uploaded using the “temporary textures” facility will not be viewable by others (as they can be at the moment) in the same way that textures uploaded using the Local Textures option cannot be seen by others. It also means that temporary uploads using scripted agents (for demonstrating clothing designs, etc.), also will not longer work.

Related Links

With thanks to Tara Lynn for pointing out the keystroke error :).

Advertisements

43 thoughts on “Avatar Baking: “and the clock has started!”

  1. Good news indeed. The schedule seems to be a bit off — I thought this was part of a bundle of features due to be delivered as a Christmas gift to all SL residents 🙂 — but it’s nice to know that LL continues to release a deployment schedule with relatively accurate dates.

    Now, hmm, will this be (finally) the end of 1.23.X-based viewers? I mean, after all this work, who will wish to view a world where all avatars are grey (or cloudies) and objects are strangely distorted spheres and cylinders? (I expect that the Cool Viewer team will continue their development in integrating new features on the old renderer, though).

    It’s also very interesting to know how the OpenSim crowd will deal with this issue. Well, now that there is some development code to see how LL does it, the OpenSim core team with have some two months to reverse-engineer the process. I’m crossing my fingers 🙂 And, of course, in any case, the fallback code will still be in place, of course…

    Like

    1. I think Latif called it the closest as he put the deployment as being at least six months from mid-July 2012, which would put the start of deployment in mid-January. If you allow him a little room with the post-Christmas pick-up at the Lab, then his estimate is into February, and he’s almost bang-on even without the “at least” part of his estimate :).

      As to v1 viewers, all of the “current” v1-based viewers support Current Outfits (including Cool VL), so the only ones which are liable to be affected at LL’s own 1.23.5 (which is effectively depreciated anyway), Imprudence and the likes of Meerkat (is that still in use?) and other oldies. Also, the new system only applies to avatar system layers – skin, clothing layers, tattoo layers, alpha layers; attachments and mesh on other avatars will still render correctly. As mentioned in the article, this means that in the majority of cases anyone on an “old” viewer will see other avatars either completely unrendered or as grey people with rendered attachments – which would include grey bodies which would otherwise be hidden by an alpha layer being seen as poking through mesh clothing / avatar parts.

      I’m not sure OpenSim is under any kind of deadline. The viewer-side code will work with both baking processes, so there is no immediate issue facing OpenSim in terms of any back-engineering. While LL have indicated they will eventually “clean up” the viewer-side code to remove support for the old system, that won’t be for a good while yet. This gives those TPVs wishing to support both SL and OpenSim (and who have not signed-up to the Havok sub-licence agreement) a good deal of time to determine how they will handle things going forward, while those which are supporting both SL and OS and have signed the Havok sub-licence agreement have already forked viewer development, so have no need to merge the new baking code into the OpenSim viewer offering unless and until OpenSim itself moves in that direction…

      Perhaps the most critical issue with this new service is still internal – and it is called “getting the word out to users”. LL are (from comments made during the meeting) bracing their support staff for a tide of users support issues when the service rolls out – but questions on whether there were plans in place to actually announce the new service, the replies were somewhat less than reassuring, ranging from “Oh there will be an announcement somewhere…” through to, “At least I hope so…” Given they are already briefing support staff, etc., one would hope the “boys upstairs” will be considering the whole question of user communication ahead of the deployment.

      I mean, they did with pathfinding, right?

      Like

  2. ooooooh texture compositor to me sounds like material mixing stage for maybe normal maps and specularity, maybe even reflection.. maybe, maybe? huh? pleeeeeeease.
    Inara do you think it’s too soon to start a materials are just around the corner rumor.
    Dear Santa Linden, normal maps for Christmas would be wonderful (even if the present was delivered a bit late)

    Like

    1. Avatar baking and materials are totally separate.

      The “Compositing Service” is a bit of a misnomer – but it was the term originally coined by LL when announcing the project (and I actually wrestled with re-using the term here). Also, materials processing – normal and specular maps – will not be applicable to avatar system layers (skins, clothes, etc.) in the initial deployment, as again covered in my reports on that side of things.

      So sorry on both counts :(.

      As to when materials is going to arrive – good question. Everyone involved is playing their cards close to their chest (and some, I’d hazard a guess, have at times enjoyed the tease factor in doing so!). I didn’t expect it prior to 2013 (but then at one point, time-frame wise, I got my wires crossed between than project and avatar baking – it really doesn’t take much to confuse me at the best of times). As it is, I still doubt we’ll see anything before 2013, simply because of the upcoming “code freeze” windows over the Christmas period, & LL having some issues they’re trying to srot-out server-side as well as finalising the catch-up on the viewer release backlog.

      Perhaps the question should be framed as will materials arrive before or after avatar baking?

      Like

    1. AFAIK, shouldn’t make much of a difference, CPU-wise. The communications load should be lightened for older classes of router as a “side benefit” due to the why LL are handling the HTTP connectivity and limiting the number of ports which can be opened (and thus overwhelming older routers). Over bandwidth use and internal processing with the viewer really shouldn’t change that much, tho.

      Like

    2. I would think CPU load will probably be the same.

      Your GPU might get a bit of a break from compositing (baking) multiple texture layers into one, because now the server will be doing (most of) the heavy lifting on that score. But your client will still be responsible for all the post-production effects, such as delayed lighting, depth of field, antialiasing, Windlight settings, and so on and so on, because all of those are contingent upon YOUR graphics preferences, and can’t affect other viewers. Rendering textures in 3D isn’t all that hard, but tweaking them with lighting, focus, lens flare, and bokor tricks to make them look realistic DOES take computing power, and this is where most modern GPU’s earn their keep.

      Where you WILL see an improvement is with the move to HTTP. Most networks these days are optimized to transfer HTTP packets (they ARE the chosen protocol for most Web-based applications after all). So that’s one less set of protocols your network stack has to manage, along with your switches, your gateway device/router, and so on. The other benefit is that HTTP can be transmitted in parallel, with lots of connections for small files to be opened at once rather than as a sequence of transfers one after the other. Again, thank the Web browser development crowd for this – they engineered the HTTP standard to allow stuff to flow in many smaller streams, so that slower connections could get to the task of displaying pages even before all the images or other media had completed loading.

      Like

  3. That note on alphas. Is this meaning they want to discourage the use of alpha-masks? Alpha-masks are very common in mesh clothing and furry attachments to block out small parts of the body that otherwise would poke through the mesh.

    Are they saying this is a bad thing to be doing?

    Like

    1. No.

      They are saying the there is a means to render parts of the avatar body transparent without applyng an alpha layer, and where those options can be used, people should try and use them in preference to using an alpha layer applied to the avatar. The options for rendering the avatar as transparent are limited (head, eyes, hair, upper body, lower body), and so are not ideal (or even possible) to use in every case (such as just trying to hide the lower legs for something like boots, foe example).

      However, where they can be used (such as hiding major parts of an avatar – torso, arms, legs, for example when wearing a full body mesh) – then the request is that people should consider the options provided in the viewer rather than apoplying and using any alpha layer which may have been supplied with an outfit which does the same thing.

      Obviously, it is something of a big ask, as fiddling around with the appearance editor is a lot less convenient than applying an alpha layer, but Nyz made a point of putting forward the request in the meeting. Hope that clarifies.

      Like

  4. it can’t make much of a difference either since the ones made in appearance without a texture are only that, alpha layers created with no texture applied to them. still, there is that weird way that worn alphas and tattoo layers generally seem to update on a different time schedule than other system textures. i wonder where they serve those up from. hmmm

    Like

    1. Think it is more a case that the defaults applied through the viewer are effectively masks, rather than applied layers with unique asset UUIDs & entries in the COF. But I admit, I’m far from clear on this.

      Like

    1. Oops! Ignore my question…I missed page 2 of the article.

      One more question though, first you mention the temporary texture will be disabled, but then you say we can still use it but it will function similar to Local textures. Can you clarify this for me please…does this mean we still will be able to temporarily upload textures but only we can see it, or will it just be unavailable all together leaving us to use Local textures for testing etc..?

      Like

      1. The “temporary textures” upload as it exists in many TPVs will be “broken” once server-side baking is deployed.

        However, the “local textures” (and also see here), which is available in the official viewer and in many TPVs will see work.

        The core difference is that local textures cannot be seen by others, so they cannot be used in collaborative projects on the main grid where there may be a need to “preview” textures by two ore more people, prior to using them (although the Aditi grid could always be used to “preview” textures when required).

        Hope that clarifies things.

        Like

        1. um, for me the core difference is local textures can be viewed in world and updated in real time as you work on ’em in your graphics program (!!). but if the big thing from your view is seeing how something looks without paying 10 lindens, they do that too. however they only last a single log in. and only the person who uploaded them can see them.

          Like

          1. Yep, that’s explained in the articles linked-to in my comment. The other aspect is that local textures doesn’t actually upload anything – it’s all handled locally within the viewer (hence why on-the-fly changes are updated).

            I used “core” in the sense that it is the the loss of the ability for others to see “temporary texture” uploads which has caused the most outcry whenever the risk of the “temporary texture” capability being broken has been mentioned (by LL or anyone else). Perhaps a bad choice of word on my part in this instance.

            Like

  5. So when is this going to actually deploy? For some of us myself included, we need to migrate from Phoenix to something else, and quite honestly I like so many others loather the SL V2 viewer considering it user unfriendly. I need to decide which way to go, or if to just tell SL a polite way of “Take this world and shove it!”

    Like

    1. As per the article, there is no definitive time-frame for the full deployment of this project. In theory, things should start moving ahead mid-to-late February. However, here is a cautious approach bing taken, as TPVs need to integrate the viewer code, test it, raise issues (possibly suggest solutions) and then LL have to fix the code and get it to a position where it can be merged-up to their viewer & TPVs – and some of this is taking slightly longer than originally hoped.

      I’ll continue to carry news on progress in my SL project news reports so you can hopefully keep pace with what is going on.

      As to migration, viewer with the v1-style UI which are supporting the code are Cool VL and Singularity.

      In terms of functionas and options, Firestorm remains the clostes to Phoenix, and now includes a Phoenix-like UI which, while not a perfect clone of the v1 UI, has been found to be very usable by many ex-Phoenix users.

      Sorry I can’t be more precise on time scales right now.

      Like

  6. ok i am only a user of firestorm and i dont know all the alpabet soup talk like v1-style or the tpv please be a little kinder to the average joe’s that are playing this game ..is firestorm going to crap or will i be forced to use the sl viewer which is crap…and getting the message out to users is easy…i will tell everyone i know its not your computer it’s the server..ty

    Like

    1. “v1-style” refers to the viewer’s user interface as it used to appear in the original SL viewer and TPV (third-party viewers, the term used to mean any viewer based on the Linden Lab vode, but enhanced by developers in the open source community, such as Firestorm). So, in this context, Firestorm’s “elder sister” viewer, Phoenix, is a “v1-style” viewer.

      The sort version of this post is that there are a large number of changes coming to both Second Life and all viewers which connect to it. In Firestorm’s case, this means that the viewer could be going through a rough patch with the next release, depending on how much time the team have to work on the code. However, if this does happen, things will improve in the future.

      Firestorm isn’t isolated in terms of what is happening, all viewers are facing technical challenges of verying degrees in order to successfully implement the changes required to support the new capabilities coming to Second Life which should, once implemented and settled, should provide for a much more predictable experience for people connecting to the platform.

      Like

    1. Have you tried Singularity or Cool VL Viewer? Both offer the older “v1-style” UI, the same as Phoenix, and both offer a lot of the capabilities (although not all of the same capabilities) found in Phoenix. Cool VL Viewer is already running a version which supports Server-side Baking as well, and Singularoty are working on implementing the SSB code.

      Like

Have any thoughts?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s