#SL news #3 Week 51

It is the Christmas Season and in the merriment some news is leaking out about things to come.

Avatar Baking

I think most of you have heard a public countdown clock is running on Third Party Viewers (TPV) being able to deliver this service. Those that don’t change over will render avatars as grey or clouds.

Yuzuru Driving to User Group Meeting

Yuzuru Driving to User Group Meeting

What is less known is the new service only uses the HTTP protocol to deliver baked textures. In most ways this is a good thing. However, a number of people in Japan are seeing problems with HTTP texture being slow. Most of the rest of the world outside of Asia is NOT seeing that problem. They see a speed up. So, if you are in Japan and you are seeing a slower HTTP delivery of textures, get in touch with Monty Linden. But, be sure you know it is not your computer and be sure you can add information to the discussion before contacting Monty. 

Viewer Side Baking

Even more of you know that the viewer bakes the composite image of clothes. It is that action that is being moved to the server side to avoid ‘bake fail.’ But, that part of the viewer will stay in place. It is needed to show you changes to your avatar appearance without waiting on the server to bake up a change. At some point the viewer will send a Bake Request to the service. Presumably when it decides you are finished editing appearance.

What will eventually be removed from the viewers is the code that compresses and uploads the baked texture to the asset servers.

Temporary Textures

Several Third Party Viewers (TPV) have a temporary texture feature that allows one to do a temporary upload of a texture on the main grid for free. The process uses the Avatar Bake and Send processes to make that work so others can see the temporary texture. That ability is going away with the addition of server-side baking.

The Lab was interested in temporary textures because so many people were using them. Plus the load on the ADITI – Preview Grid was filling up the hard drives. So, making temporary textures available was a feature that helped users and the Lab. The result is Local Textures are replacing Temporary Textures.

If you texture an object you have the choice of a texture on the server or your LOCAL computer. So, you can experiment and upload only the texture that works or is needed AFTER seeing how it looks in world.

The problem is others can’t see the LOCAL texture. So, it is a hit to collaborative building. I don’t see it as that big a deal because I tend to experiment with textures in ADITI where I can upload for free. Also, I’m not into any collaborative building just now. But, some anticipate it as a serious annoyance. Whatever, plan to wave bye to temporary textures around the end of February 2013.

Mesh Deformer

We are still short test garments.

Oz Linden has mentioned that he has a new Linden to help him evaluate the Mesh Deformer. But, he doubts they will do anything before the end of the year. At which time they will also be working on STORM-1800The vertex weights of the default character mesh could be better.

In the mean time some creators are starting to do pants and skirts using the Collision Bones or Volume Bones weighting discussed in previous articles. Since that doesn’t work for breasts… shirts and jackets are not good candidates for that process. Also, at some point the process may break as it is not a ‘Linden supported’ method.

SL Viewer

Mac Cocoa

Oz says the first round of changes for the Mac are in the Beta Viewer, which will come out as 3.4.4 Real Soon Now™. No performance increases are expected. The Lab is just catching up with what Apple is doing.

Materials

The viewer side of the Materials system is ‘coming along nicely.’ The server side is mostly done and running in some regions of ADITI.

Graphics

Geenz Spad says there are some nice things happening in the viewers rendering pipeline. Gamma Correction is coming to the SL Viewer. You can preview it in the Exodus Viewer now. This is less of a setting you would use than it is a process the render pipeline uses to make things look right on your computer screen. Geenz says, “…what the viewer’s getting is technically better than what Exodus already has.

Also, the viewer’s SHINY is being improved. The new version is a bit more physically based. But, it only works in deferred rendering, with Lighting & Shadows enabled. Full scene reflections is being worked on too, but that is separate from the Shiny improvement project.

That physically based means at different view angles relative to the light, reflected light will seemingly become stronger much as it does on objects in the real world. I am taking to make that mean shiny will change depending on where the sun is and you are. I doubt point lights will be part of this change.

Geenz says it is based on a microfacet model. I’m doing another article on all the rendering features in SL. So, I’m not going into microfacets here.

Normal map precision is being improved. The current normal maps can render a bit jagged.

Summary

From the Lab’s side of things they can see a number of large projects coming together. Because those are not announced by management, they can’t talk much about them. So, we try to piece it together by collecting bits here and there.

I think we will see some nice things arriving in 2013.

9 thoughts on “#SL news #3 Week 51

  1. The new physically based shiny will effect all light sources; not the sun.

    The theory behind the new shiny is that for all surfaces in the world, light reflectance is perceptually stronger at at high incidence angles (such as when a table’s surface is almost flush with your perspective) for every light source.

    The results when combined with gamma correction are really quite stunning. I really can’t wait to put some final screenshots of this stuff up when I feel comfortable with the final implementation.

  2. As is the way of things, i always think up questions AFTER the meeting. With the Mac viewer finally moving to Cocoa, i was wondering wether this would pathe the way to better OpenGL support and possibly a 64bit viewer at last… Guess ill have to ask Oz next year 🙂

    • Definitely ask.

      As yet the Lab has no plan for a 64-bit viewer, so says Oz. I think mostly because the libraries they depend on have not all moved to 64-bit. So, they are seeing the change as a big task. But, someday. To get a more realistic answer, you might ask Geenz Spad and see what he says.

      As for better OpenGL… Apple has been weak supporting it, or so I hear. So, there is a part of the problem out of Linden Lab’s hands.

      I would like to see better OpenGL support in the SL Viewers. Jessica in the Phoenix Hour explained that viewer performance is a mystery. The same viewer on seemingly similar machines produces very different performance results. Also, there is the problem of supporting older computers that can only use older versions of OpenGL.

      It seems only the Exodus and Linden developers have much clue about the render pipeline and OpenGL. So, I am very eagerly waiting for the project viewer for the Materials System that Geenz is working on. My hope is more of the OpenGL features from newer versions will be used.

      It is hard to know whether DirectX or OpenGL is winning the technology race. See John Carmack finally prefers DirectX to OpenGL from last year and Valve: OpenGL is faster than DirectX — even on Windows. However, Carmack did stay with OpenGL for id Tech 6, see John Carmack on id Tech 6, Ray Tracing, Consoles, Physics and more. Whichever is winning probably doesn’t matter as changing over is gigantic messy process and unlikely to happen for SL. But, I do think the race shows that competition between DirectX and OpenGL is very active. I think that SL could preform better. I think that will take a rewrite of the render pipeline. I am hopping developing the Materials System is somewhat rewriting the pipeline.

  3. Hi, I have been reading up your posts and many hours of search I am interested in testing. I am not sure if I have issues but no matter what versiions I have downloaded for the Mesh Deformer projects, I cannot seem to make it work.
    Are there some specific settings that I can check to see if it is enabled? A tutorial on this?
    If it is too much I’ll hush 😉

    Ginger

    • I assume you mean versions of the Deformer Project Viewer. The latest one is on the Project viewers’ page in the wiki. I have a link to it in the left column.

      In addition to the viewer, you need a mesh object that was uploaded with the latest viewer, which is why the test clothes in Hippo Hollow don’t work. They are from older versions.

      Only mesh uploaded with the latest project viewers that support multiple base shapes and that have Deforming enabled will work and only in the project viewer.

      • Thanks for your quick reply Nalantes,
        What I am trying to do currently is making sure the latest version ( 3.4.1.267522) is working correctly on my end the way it should and if so then I’ll start testing recent samples or do my own.
        I did see on one youtube video from Darien Caldwell at the 15 second frame that there was a switch to enable or disable ‘Mesh Deformer’ in Advanced-Rendering? I know this was an old version he had at the time but was wondering if it still should be there?
        This is the YouTube video I am reffering to..
        http://www.youtube.com/watch?v=XuSQmxRXXaM

        This is what I see on my end. As well as my settings…
        http://gingerssecondlife.blogspot.ca/2012/12/current-settings.html

        I have a HP ProBook 4720s 4GB RAM less than 3 years old. Graphic card info is in the settings pic.

        What I think is that on my end I may have an issue but want to make sure.

        Ginger

        • The setting in the Linden viewer is only for upload. The individual mesh objects are enabled or disabled, not the viewer. The Deformer is active in the project viewer all the time, afaik. I think it was Niran’s Viewer that had an off on switch that allowed disabling the Deformer code in the render pipeline, which was great for testing.

          If you have an older computer and a high poly count mesh, you may see a significant delay before the Deformer kicks in. The Deformer JIRA thread discusses the problem. Some were seeing delays measured in minutes. I think I recall someone saying there was over 5 minutes, which sounded excessive to me. I personally have some HIGH poly boots that take 20+ seconds to rez. With other test clothes I noticed a 10 second or so to rez and then almost another 30 to 60 seconds delay until the Deformer kicked it.

          I only have things I’ve made recently to test with. I’m not seeing long delays on my Core2-Quad and GTX560. Everything happens in about 5 to 10 seconds.

Leave a Reply

Your email address will not be published. Required fields are marked *