We have heard various Team members, Jessica, and now Tonya say that Phoenix updates and support should be dropped. I’ve heard from a couple of sources that the development team does not like to work on Phoenix code. So, while the team has continued to support Phoenix after saying they wouldn’t, it is looking more and more likely they will stop spending time on the Phoenix Viewer.
Avatar Baking
Along with a change in the HTTP parts of the viewer comes another change, Avatar Baking. This is going to be a bit of a bumpy change over… little bumps.
You may or may not know that the viewer ‘bakes’ a composite avatar texture made from the skin and clothes textures. That single composite texture is sent to the SL servers and the servers send it to you and each person that can see the avatar.
This process will change. The Lab is going to stand up a Compositing Service. The viewer will continue to use its compositing process to give us interactive appearance editing. When we are done the viewer now sends the composite texture to SL. In the future it will send a request to the Compositing Server (CS). The CS will then look in our Current Outfit folder and bake that information into a composite texture. It will put that texture in its cache then hand out that texture to us and anyone that can see the avatar.
When we see our avatar go blurry the second time what we are seeing now is our viewer downloading and rendering the texture we just sent and which the SL servers sent back to us. The idea is it gives us a check on how others are seeing us. Unfortunately that has not been working well. In the future when we go blurry for the second time we will be downloading the texture the Compositing Server made. Again we will be seeing what others see. But, then it should work and be accurate.
In some third party viewers the returned image may not be an exact match with the composite the viewer made. It depends on the compositing code the viewer uses. I doubt this sill be an issue, unless one perv-cams with a microscope.
For a time viewers will need to support both processes. Regions will support one or the other. As the service rolls out we will have some RC to non-RC region problems. If you are in an RC running the new code that uses the CS, you will see avatars in the adjacent region that does NOT use the CS as gray and they will see you as gray. That problem will go away when all regions are rolled to the new code.
After the code is rolled out to the main channel there will be a grace period while it is tested and tweaked. Sometime after that, the old services will be shut down and the servers likely repurposed. Once shut down any viewer that has not been upgraded to use the new service or lacks the Current Outfit folder will see avatars as gray. They will never rez no matter what one does… other than updating to a newer viewer.
We won’t be replacing all uses of UDP – there are still plenty of things for which it is and will remain the right thing. For example, position updates for things in the world make more sense to send via UDP – if one is lost, the next one corrects it anyway, so having the underlying protocol resend is a waste of time and makes successful deliveries less timely.
But for things like transferring image files, HTTP is significantly better when used well, so we’re going to transition those uses that make sense.
Thanks for the correction.
I kept reading “Composting Service” —– some kind of Freudian expectation slip I suspect.
You are right about the crying and wailing, “SL has run perfectly well on this computer I bought for $400 in 2006, why have the Lindens forsaken me?” and such.
LOL… I didn’t even notice. It is a typo, but I suppose typos can Freudian.
A more efficient solution to using the Current Outfit folder has been proposed by Henri Beauchamp of the Cool VL Viewer : http://sldev.free.fr/forum/viewtopic.php?f=5&t=858
Another thing I would like to point out is that both Jessica and Tonya have never really liked updating the Phoenix Viewer and that it was carried out mostly by LordGregGreg and a few others on the Phoenix/Firestorm team. There website in fact, is still The Phoenix Viewer website, not The Firestorm Viewer website. I would wait until an official announcement is made before jumping to conclusions that The Phoenix Viewer is dead.
You wouldn’t jump. I probably would.
There are hold outs that keep working with converting V1 and Snowglobe code to work with new V3 code. That may well happen with Phoenix. But, those viewers are falling behind and I think they will likely continue to fall behind. I think Henri’s Cool VL Viewer is probably a unique exception. His is V3 code based with a V1 interface. He waited for the Lab’s development direction to stabilize then made Cool VL. He seems to stay current. If one wants to stay in a V1 interface, Henri’s is a good if not the best choice, IMO.
As far as I understood it Henri’s viewer is Viewer 1 based but includes various elements that are Viewer 3 based – most notably the rendering stream. Of course Henri has modified much so maybe such definitions are not so useful.
Henri has been vocal on the point. So, unless I’m misunderstanding him, it is V3 code with a V1 interface.
Starting with v1.25.0.0, The Cool VL Viewer was based off Snowglobe v1.5 and some of the v2 code (alpha and tattoos, inventory links, etc) where backported to it (in fact, some code was already backported to the Cool SL Viewer v1.23 and even v1.19.2, which were based on LL’s v1.23 and v1.19.0.5 respectively).
With v1.26.0, more and more v2 code was incorporated, replacing the corresponding Snowglobe code. This was particularly true of almost all the project libraries (all the ll* directories in the source tree that are not inside newview/ but along it), but also of many classes in newview/ (texture fetching (HTTP) and caching related, for example, but not only).
With v1.26.1/2, things went even farther since it saw the inclusion of all the rendering code from v2.6 (with further improvements/fixes coming from v2.7, 2.8 and 3.0). More newview/ v3 code was also backported (new web search, inventory changes (HTTP fetches, marketplace support…), etc, etc…).
The mesh versions of Phoenix are in fact based off the Cool VL Viewer v1.26.2 (at least for some of the ll* project libraries needed by the mesh code, and of course, the mesh renderer).
With v1.26.3/4, the whole texture layers, parameters and avatars compositing/rendering code was backported from v3.2 together with more inventory code changes (which brought multi-layers clothing support) and even more code was updated/backported from v3.2/3.3.
With v1.26.5, I’m currently backporting the v3.3 renderer…
And the story continues and will continue as long as I am intested in SL/OpenSim…
One thing is sure: I’ll keep the Cool VL Viewer up to date with LL’s viewer while keeping the v1 UI (unless LL comes up with another UI that can beat v1’s efficiency, but even the v3 FUI is still *very* far of that !).
So, yes, the Cool VL Viewer is *mostly* a v3 viewer with a v1 UI, even if the UI-related code often goes deeper than just the way the UI elements are drawn on the screen (the inventory, for example, is dealt with in the v1 way, which presents quite some differences from v3), meaning there is still some non-UI-only v1 code in the Cool VL Viewer…
I am very glad to hear that the lab is pushing forward with changes to the infrastructure. You can only hold on to the past for so long. Microsoft spent far to many years fighting to maintain compatibility, and it hurt them. I am happy that LL is moving forward even if it does mean that some of these older viewer will cease to function. I am very happy to hear as well that consideration is being given to each function to pick the best protocol to deliver that functionality. I am very, very excited to see what happens over the next 4 – 12 months in SL.
Me too! 🙂
In this context, the word “exciting” scares me.
I want the way the Viewer talks to the servers to be boring. I don’t want to be surprised. I don’t want to notice things happening, or not happening.
I hear that one or two bad decisions were taken in the original use of HTTP, involving the keep_alive option, and current viewers have adapted to cope. It’s that adaption which is straining routers.
It would be simple for Linden Labs to make sure that keep_alive was turned on for existing servers, but the Viewer adaptions could then backfire badly. A large number of HTTP Sessions would be opened to get around the lack of keep_alive, and if they requested keep_alive anyway, they would stay open.
That’s the story I heard. It makes some sense to me.
Fixing this mess needs good communication on the part of Linden Labs. They do seem to talk a bit more to the developers than they do to us ordinary residents, but fixing this needs the developers to produce viewers that don’t behave badly when keep_alive is active, and it needs residents to be confident they should use them, and all this lined up for when the Lindens push the big red button.
Linden Labs do not have a good reputation for communication. And residents do cling to the old, the familiar, and the predictable. (I didn’t switch from Phoenix to Firestorm at the first opportunity). There might be horribly complicated ways of making the Viewer switch automatically when it notices keep_alive is working. Even if that is simple, it will need testing.
This isn’t going to be fun.
Well… the Lindens in general exhibit better communications skills than the community of users does.
As the Lab moves their product to use more multi-threaded processes the HTTP communications will have become fastidious about closing connections.
I mean… why all this time wasting? The V3 interface is amazing. Minimalistic, professional looking (The gray tone matches the most advanced UIs like by Adobe, and nowadays many others are starting to adopt this kind UI. No confusion, no fancy elements. A contestual menu is faster than a pie menu.
It’s not my opinion – otherwise Apple and Microsoft should be crazy to prefer it, don’t you agree?
Plus, you need more hand gestures, more clicks to achieve simple task. Tabbed IMs? Tabbing could be great for web browsing, not for a multiple chat, otherwise all the most popular social networks whould be crazy to adopt separate IMs popups, don’t you agree? It’s paranoid to get used to something and don’t even try to update yourself. I mentioned just these few examples but there are more. When I joined SL, I wasted 2 weeks with V1 trying to figure the basics, and I gave up. When I switched to viewer 2, in less than a week I realized all the basics, and more. For oldbies of course it’s different, but the learning curve with the lastest viewer UI for new users it’s several times faster -and following the experience of users and new users I know- I have proofs of this).