Update, April 6th, 2013: Please also see my updated status report.
The new avatar baking project took a step closer on December 14th, as LL started to release more in the way of technical details on the project and launched a project viewer.
Code-named Project Sunshine, and a part of the Shining Project, this work is aimed at improving avatar baking and at eliminate bake fail issues.
The project represents a sizeable change in how Second Life works, and as such will take time to fully implement, requiring extensive changes to the viewer itself – something which Nyx Linden has previously referred to as, “Some pretty scary viewer re-architecting”, as well as a good part of the back-end services – hence why it has taken so long for the project to mature. Because of the degree of changes taking place, Linden Lab have consistently promised, via Oz Linden, that TPV developers would some eight weeks notice prior to any initial deployment of the new service in order for them to ensure they can integrate the required viewer-side code changes, test them, and ensure they can support the new service.
Speaking at the TPV Developer meeting on Friday 14th December, Oz reiterated the 8-week lead time before adding, “Today begins the clock! … You get at least two months from now before we begin rolling server-side baking out to the main grid, at least beyond a test region or two.” So while the precise timescale as to when the new baking service will start to appear on the main (Agni) grid remains open, TPVs can now start to engage in the project, a step which itself brings it one step closer to reaching the grid.
A Quick Recap: How It Is and How It Will Be
Currently, avatar baking is essentially driven from the viewer. In summary (and without drilling too much into detail), this means that when a system layer outfit or item of clothing is changed (including alpha layers), the updates are applied locally in the user’s viewer. They are then uploaded to the server the user is connected to, which then passes the updates out to the other viewers connected to it, so that other users get to see the change as well. This process has several points of potential failure: communications between the viewer and the server may be interrupted, for example, with the result that the server doesn’t receive all the information pertaining to an outfit change, with the result that – again as just one example – the user sees their avatar perfectly fine, but others see the avatar as blurred / grey. In some instances, the process can fail such that while the user sees their avatar wearing the desired outfit, other see the same avatar still wearing the “old” outfit.
The new service will hopefully eliminate these issues by moving much of the emphasis for the baking process from the viewer to a new “Texture Compositing Service”. The viewer will retain some elements involved in avatar baking – the actual baking of the avatar shape (i.e. shape values and IDs) will still take place on the viewer side, for example. However, the new compositing service will take over most the donkey-work and handle the majority of avatar baking data and communications (excluding prim-based attachments).
As with many of the new services being introduced into Second Life by LL, the new baking service will be HTTP driven (the current system is UDP protocol based) which should have an additional benefit of speeding up the entire avatar load process when logging-in to SL and in fetching textures.
How the entire process should work can be summarised as follows:
- The new service will use the Current Outfit folder as its viewer-side driver. This means that in order to use the service a viewer must have the Current Outfit folder properly implemented
- When a rebake request is due (e.g. after a user has finished editing their appearance) the viewer sends a message to the baking service essentially asking it to look at the contents of the viewer’s Current Outfit folder and then return an updated appearance based on the contents of that folder
- At the same time as the data is returned to the user’s viewer, it is also sent to the simulator to which the user’s viewer is connected, so that the simulator can send the appearance information to all other viewers connected to it.
To further TPV developers understand the new system and answer their questions, Nyx Linden dropped by the TPV developer meeting on Friday 14th December. Note that what follows is an overview of Nyx’s discussion from the point-of-view of providing digestible information on the new service for “general” users, rather than a in-depth review of the full technicalities of the system and Q&A session.
Please use the page numbers below to continue reading this article
Inara Pey: Living in a Modemworld 
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…
LikeLike
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?
LikeLike
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)
LikeLike
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?
LikeLike
well darn it ! lol
LikeLike
Does this mean less burden to a user’s CPU?
LikeLike
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.
LikeLike
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.
LikeLike
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?
LikeLike
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.
LikeLike
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
LikeLike
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.
LikeLike
Will this have any impact on using Temporary textures at all?
LikeLike
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..?
LikeLike
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.
LikeLike
Thx very much hun for clearing that up 🙂
LikeLike
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.
LikeLike
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.
LikeLike
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!”
LikeLike
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.
LikeLike
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
LikeLike
“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.
LikeLike
Well in any event, seeing as I use Phoenix only this will effectively take me out of SL. I will never use the SL viewer, nor is Firestorm a option to me.
LikeLike
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.
LikeLike