Jump to content

Tools and Technology

  • entries
    91
  • comments
    916
  • views
    141,289

Contributors to this blog

About this blog

Entries in this blog

Yoz Linden

As we described a little while ago, we're taking some major steps to improve our bug-tracker, jira.secondlife.com. We're making it faster and easier to use, more revealing of our ongoing engineering work, and - most importantly - better at helping us find and fix bugs.

Today we completed the largest single milestone on our bug-tracking roadmap: the upgrade to JIRA 4.1. This was more than just a simple upgrade: as well as all the improvements that JIRA 4.1 brings, we've moved to new, more powerful hosting infrastructure. We've integrated the same login system used by the rest of secondlife.com. And we've installed the Greenhopper project management plugin so that open projects, such as Snowstorm, can expose far more of their roadmaps and schedules. It'll take a few days for the first projects to make their Greenhopper pages available, but once a project has one, you can get to it through the "Agile" item on the navigation bar.

If you're interested in our bug-tracking process or already contribute to it, please go take a look. We hope you'll find it significantly better than what we had before. However, there are still tweaks to be done and problems to be fixed. If you find anything in the new setup that doesn't work as it should, you can file an issue about the bug-tracker in the bug-tracker, specifically in the WEB project, jira.secondlife.com component. (Using the bug-tracker to report on itself may seem dangerously recursive, but don't worry; we've hardly ever caused any wormholes in the space-time continuum.)

One more thing, for JIRA regulars: As mentioned previously, we're also making changes to some of the workflows with which we categorise and process issues. Some of those changes were made two weeks ago. With this upgrade, we're moving towards another little tweak: renaming the Priority field to Severity and using it to describe the seriousness of effect that an issue has. This is for a couple of reasons: firstly, to reduce edit-war arguments by making the field topic a little more objective. (You can read the descriptions and criteria for the Severity field values on this wiki page.)  Secondly, because Priority is meaningless as an attribute of a single issue; rather, an issue's Priority is its relative position amongst its peers, which is decided during project backlog review. The renaming of the field hasn't happened yet, since it requires tweaking of the underpinnings to be done after dust has settled on the upgrade, but in the meantime we've renamed the values that the field takes.

Once again, we'd like to thank everyone who works with us through the bug-tracker to report and fix problems. With these and future JIRA improvements, we aim to give you a clearer view of how your contributions make Second Life better for everyone.

Edited to add: Our screencast wizard, Torley, has created a couple of video tutorials which show off some new features that make JIRA use considerably quicker. Check out How to search the bug tracker and How to report a bug.

Oz Linden

As part of launching our new more open viewer development process, we changed the open source license for the new viewer code base from the GPL with an exception to allow use with certain other open source licenses (the "FLOSS Exception") to the LGPL.  Some people have been asking about what this change means, and what our intentions are in making it.  In particular, the LGPL requires that the code first be compiled into a library and then may be used in an application.  Since the open source we make available does not directly provide for building this way, some people have speculated that the new license may actually be a barrier to other viewer developers.  I'll try to answer this as clearly as I can.

At Linden Lab, our intent is to enable the development of third party viewers and the improvement of our own viewer through mutual sharing of the requisite common technology.  We think that LGPL is a better license to accomplish that sharing. Even though it was originally written to apply only to libraries, there is significant room for interpretation when using it.

Our interpretation is this: modifying the build procedures provided in the source code to produce a library containing a subset of the licensed code is a minor programming exercise.  The result of linking that library (which may be either a static library or a shared one, and either is allowed) with whatever other code is used to build a viewer is again a minor problem. The results are essentially indistinguishable from those in which the developer just modified the build procedures in place to produce an executable application.  Essentially, the details of the linkage procedures used are a matter of packaging and have no end user effect.  In practical programming terms, a library is just a convenient package - the requirement in the LGPL is like requiring that a grocery store sell a product only if it is first placed into a shopping cart while inside the store.  Essentially a library is just that - a shopping cart full of individually compiled modules, so there's no real difference between using a library and just using the modules separately (one could build a library containing exactly one module, or build an application that had only one module and one library).

It is our intent that developers be able to use the components that we have licensed under the LGPL to produce viewer applications, regardless of the linkage procedures used, so long as they make available any changes to those components as specified in the license.

Esbee Linden

Today, we’re releasing Viewer 2 (Version 2.2.0 Beta) on our Beta release channel. This is an exciting release for us for two reasons. First, this release marks the first Viewer download since we announced the Snowstorm Team at SLCC in August. The Snowstorm Team has been working in the open to share our design and development process and directly engage with open source developers. Second, this beta release also marks the beginning of a new approach to our release process. Since we kicked off Project Snowstorm, we’ve made the latest Development Viewer available to Residents nightly so they can see our day to day progress and try out new things as soon as they’re in a build.

In our Beta and Release channels, we will make Viewers available to you more frequently. Our plan is to update Betas weekly with new official releases happening every 3-4 weeks. This lets us get new ideas and features into your hands faster and it gives us the ability to react to your feedback more quickly.

This latest beta release of Viewer 2 (Version 2.2.0 Beta), is mostly focused on bug fixes, but also includes some great user interface customization options. Here’s a quick run-down of what you’ll find in this release:

  • Sidebar Tabs can now be undocked and turned into regular floating windows.
  • The buttons on the Bottom Bar can be reordered.
  • Right-click on your avatar and select “Sit Down” to sit anywhere.
  • Parcel property icons (found in the Location Bar) are now on by default.
  • Selection beams are working again.
  • Language translations in local chat (via Google Translate API).
  • Group permissions now work via the Snapshot tool.
  • Turn off scripted particles and lights.
  • Builders can more easily align textures across linked prims using planar mapping.
  • View profile inspectors via the Mini-map.
  • Pan the mini-map with shift-drag.

Many of these features came to the official Viewer through resident contributions, both directly by way of the Snowstorm team, as well as indirectly through past contributions to the Snowglobe project. Thank you to all of you who have contributed code, testing, and commentary. Please keep it up!

To view a full list of changes, see the Release Notes.

Download the Beta Viewer : Windows | Mac | Linux

Please note that, as always on the beta channel, we only support one beta viewer at a time. If you’re using an older Beta Viewer, then you will be asked to upgrade on your next login.

Thank you!

Sea Linden

Search Update: Feeds

This morning, we had a small release that we believe will make a big impact on the quality and consistancy of Search. We have moved from a crawl system to a feed system. In our previous crawl mode, the GSAs handled discovery and indexing inworld data with its own schedule and rules. With the new feed system, we generate and push content to the GSAs for indexing and have more control over when it is updated.

Please see our release notes!

Expect that ranking will be changing, and will settle by end of day. We have also published an update to the Search FAQ.

Jack.Linden

As previously blogged, I’m very excited to announce that the Beta for Mesh Import is now open to all Residents. Mesh Import allows you to bring models into Second Life from the many popular 3D tools such as Blender or Maya(t), using the COLLADA file format. We see this as an important step to empower content creators to make the inworld experience an even richer and more creative one than it is today. You can read more about Mesh Import here and in my last blog post.

Join the Mesh Import Beta

In order to take part, you will need to first download the Project Viewer for Mesh Import, based on the Viewer 2 code base, available below. This special Mesh viewer will take you to the test grid that we call Aditi. This is a separate grid from the one you normally use for Second Life -- so any changes you make there will not be preserved nor transferred to the main grid. Whilst the Mesh Beta is open to all Residents, it is possible that accounts created within the last few weeks may have trouble logging into the test grid as they won’t have been migrated across yet; so if you have trouble, then here are instructions for updating your account info on Aditi.

Getting Started with Meshes

So that you can get started straight away, we have prepared a few simple walkthroughs for you to follow once you’ve logged in. You can find them on the main Mesh wiki page along with various other pieces of information. They should give you a good idea of how the Mesh Import tool works before you import your own meshes. Remember that we are using the COLLADA file format, so you’ll need to use a tool that can create COLLADA files such as the free, cross-platform Blender. Over the coming weeks, we will continue to add information to the Mesh wiki page, so do check back often.

Please note, that the Second Life Terms of Service applies on the Aditi test grid, as it does on the main grid. That means that you should not import any content for which you do not have the appropriate rights. But, For more information, see our Intellectual Property Policy and if you’re in doubt over a specific object, then it’s probably best not to import it.

What to Expect on the Beta Grid

Although the base technology that drives mesh is in good shape, we still have some way to go before this is production ready. We wanted to get it into your hands sooner, versus later, to get your feedback. You should only take part if you’re comfortable with beta software that may crash or cause content that you’re working on to break in unexpected ways. In addition, the product design piece -- the user interface -- still needs some work so you can expect that the interface for mesh will change and improve over time. The Mesh Project Viewer will auto-update as we ship updated versions, so when there’s a new version, then you’ll be prompted to install it.

Another change, that many of you will notice right away for this beta test, is that we have changed the maximum size of a prim, for both normal prims and mesh prims. The maximum for each dimension is up from 10m to 64m. Our hope is that this change will also be available on the main grid as well once Mesh Import ships. But, we need to assess how these larger prims perform during the beta period to ensure that they will integrate seamlessly into the main grid environment.

Releasing the Viewer Code for Mesh

To give our third party viewer developers as much time as possible to work with the Mesh code base, and so that we can get additional feedback and support from the opensource community, the code base for the Mesh Project Viewer will be released by the end of this week. It will be made available on the Snowstorm wiki page.

Giving Feedback on Mesh Import

If you believe that you’ve found a bug, or have a suggestion for how to improve the feature, then please use our public Jira issue tracker to let us know. Before you file an issue there, please do search to ensure that someone hasn’t already filed the same issue before you. If they have, then by all means add your comments there.

Anticipating a Few of Your Questions

Yes, you have questions. Let me anticipate a few. Feel free to ask more in comments and we’ll answer what we can.

  • Q: How will Mesh objects look if you’re viewing them from an older viewer, such as those based on Viewer 1.23?
  • A: They will look like flat shapes and will not resemble the real mesh objects. See the Mesh wiki page for examples.

 

  • Q: What are the prim costs for importing Meshes?
  • A: Aspects of this are still being worked out, but the latest info is on the Mesh wiki page.

 

  • Q: Will you be charging upload fee for meshes?
  • A: Yes we will charge an upload fee in L$ when mesh launches into production. For the beta test on the test grid, there will be no fees.

 

  • Q: Will you have Mesh office hours?
  • A: We are holding Mesh Import office hours tomorrow, October 14, at 3pm PDT (6pm EDT) at the four corners of Mesh Headquarters on Aditi (SLurl: secondlife://Aditi/secondlife/MeshHQ 1/238/238/26). We will have more office hours in the future, so keep checking the Mesh wiki page as they are scheduled.


Finally, I’d like to thank you all in advance for taking part. We’re looking forward to seeing the amazing mesh creations and hearing your feedback.

Resources:

  • Download the Mesh Import Project Viewer   
  • Read the last blog post on Mesh Import
  • Read more at our Mesh Wiki Page
  • Share your thoughts on the Mesh Forum or the Mesh section of SL Answers
  • Log bugs on the public Jira
  • Twitter your feedback on #slviewer2
  • Please upload pictures of your mesh creations to Flickr with the #slmesh tag. You'll be able to view the resulting collection here.
Linden Lab

Latest Update on Mesh

With the initial release of mesh in August, Linden Lab introduced an entirely new way to measure the impact that objects have in Second Life. Since then, we’ve seen that providing customers with this additional insight has allowed them to design with more performance efficiency.

Now, with this new release of mesh, creators get a more detailed understanding of the actual impact of objects on the world around them. Being able to see Resource Weights, as well as how they drive Land Impact, helps creators more easily build responsive and low-lag locations, improving the overall resident experience.

To better show what effect an object will have inside Second Life, we have developed four weight values: Download, Physics, Server, and Display. Each of these values can be used by creators to determine the impact that a given object will have on performance from different perspectives (e.g. client vs. server) and under different circumstances.

 

CjyEHUwDoHSOINwa9Fg-n6wm8nhJqqDcVkBcYMfXKOLMQ8jbbxdUzqdjpJnD76JDUT5aYhwice4earHwql79zA1vWlPyEMBBJe7nY2orIAm9l0lDSus

Here’s how they break down:


  • Download measures how much bandwidth we need to send out the information about an object so that everyone can see it.
  • Physics is a value that shows how difficult the object is for the physics and Havok processes to create, track, and update the object.  
  • Server is a value that shows you how difficult the object is for the server processes to create, track, and update the object.  
  • Land Impact (formerly PE or Prim Equivalence) is the highest of the above server-side weights. It defines a theoretical limit under which performance remains acceptable for residents.

 

  • Render is a value that shows you how difficult it is for the client renderer (your viewer) to draw the object. Because it’s related to the client, this is informational only. This is the same calculation used to create Avatar Rendering Weight.


    Knolwedge Base Article on Weights and Impact.


How you see it in the viewer:


WH_NdAFmN4D9wDfs78LgyW5CO8IUZxrgRWWVve5KdV1ROknnqtM1YwrWZgTI9LALwAA9LgTA6dyHQzStdBq6IJIxcJOm_NcknH-1NCLw66QUJM3S5nw



We hope understanding the relationship between objects and performance will help land owners and creators make even more efficient content. As always, we welcome feedback to help us make this information even easier to understand.


FJ Linden

As  we head into the fourth quarter, I wanted to share some of the progress  that we’ve made since we realigned engineering and created our Platform  team. The team is comprised of simulator, services, and viewer  developers and testers (Platform Development), as well as our  operations, IT, data warehouse and customer support teams (Platform  Operations). The focus of the teams will be to drive “back to basics”  improvements across the grid and evolve our current architecture into a  scalable set of services and APIs. Let’s take a look at our progress  over the last few months, delivering against the goals that Philip set  at the Second Life Community Convention (SLCC), in August.

I’m  happy to report that we have already delivered on a number of those,  and are making good progress toward the rest. A few of them may take  longer than we’d originally anticipated, but we plan on completing all  of them.

Below  you’ll find a list of projects and initiatives we’ve delivered on in  the two months since SLCC, as well as some back-up performance data. A  number of these projects will have a major impact on the Second Life  experience, as we currently know it. Expect to see further posts from  some of the Platform team, focused on how we are improving Second Life  in terms of faster performance, increased stability, and a generally  smoother experience for all.

Reduced Lag
Here’s  an interesting factoid: there are about two million teleports in Second  Life every day. Previous to our recent release of Server 1.42, when an avatar teleported or crossed into a new region, everyone on the  destination sim would experience a “lag” event as the simulator stalled  while processing the incoming avatar. This was often experienced as  “jitter” on the sim, especially evident when many avatars arrived at the  same time, such as for a live event. In the new simulation code, this  slow point has been moved to a separate thread. Our simulator  performance profiling tools show that this lag pain point is almost  entirely gone, greatly improving performance for highly trafficked  regions.

Faster Texture Loading
In August, we made some changes that improve the speed with which textures are loaded in a scene. Our release of HTTP Textures changed the way textures are delivered to, and loaded in, Viewer 2,  resulting in less waiting around for the scene in front of you to come  into focus. This change will also serve as the foundation for a series  of bigger improvements, including the deployment of a new asset system,  which will improve texture loading and object rez times even more. For  the real techies, here’s the back story: Last month, we moved away from  the Isilon storage clusters, as our primary storage for assets. Most  assets are now stored on Amazon’s S3 platform, and we have deployed a  “middle-layer” caching service, which is where most asset calls will be  served from. The time to complete asset “puts” and “gets” (the times  that the viewer requests assets and times those assets are delivered)  has improved significantly. We reduced the average PUT latency by over  60%, from 1.3 seconds to 0.6 seconds, and our GET latency by 20%, from  0.25 seconds to 0.20 seconds. What does this really mean? Well, when you  add up the cumulative time saved in asset latency across the millions  of requests a day, there is a net savings of over 4,000 hours of time  shaved off of asset latency per day! That translates into less load on  the simulator processes and better rez times in Viewer 2.

The next step here is to get the simulator out of this process,  and that will happen in early 2011. At that point, we’ll have extended  our asset services and can begin enabling a content delivery network  (CDN), bringing latency-sensitive assets (objects and textures) closer  to Residents for even faster rez times.

New Chat Service Coming Soon
We’re  finally going to tackle the group chat problem that has been a Resident  complaint for a long time. Group chat can often be confusing, with  “chat lag” causing responses to appear late, or sometimes not at all.  You should start to see real improvements in this early next year. Over  the last few months, we’ve completed a number of development sprints to  prototype an XMPP service and have decided to move forward with an ejabberd deployment.  We’re targeting to have a test deployment of the new group chat service  by the end of this year, and full production deployment in early 2011.

Group Limits Will be Raised to 40
Another  big pain point for Residents is the current limit that lets you be a  member of only 25 groups. We plan to raise this limit to 40 by the end  of this year. In the past, our biggest concern about raising group  limits was potential performance degradation, with additional stress  placed on our central database. After completing some internal analysis,  we now feel comfortable enough to extend group limits up to 40. I’ll  put a qualifier on the group limits increase, however, and state that if  we see a decrease in performance (i.e., more lag), then we may decide  to roll back to the 25 limit again.

Snowstorm Driving Viewer 2 Improvements
At SLCC, we announced Project Snowstorm,  our new open development program for Second Life’s Viewer 2 client  software. Snowstorm is already incorporating Resident input,  particularly around a more customizable user interface, has produced a  number of beta releases, and is deploying daily open-source code  releases. You’ll see the first fruits of their efforts in production  very shortly, with the release of Viewer 2.2.

New Main Grid Deployment Process
It  was pretty clear that if we were going to make velocity improvements,  then we needed to be able to update our server software more than three  to four times per year.  As Lil Linden discussed last month,  we have significantly changed our deploy process and are now deploying  code on a weekly basis to the main grid (Agni). This means that bug  fixes will be deployed faster and new features and functionality don’t  have to pile up and wait for the next major “release train.”  It also  means that if we do encounter problems, then we are able to quickly back  out the changes, without affecting other code that is working properly.  This process also works much better with the agile development  practices that we have formalized internally over the last three months.

Display Names and Mesh Public Betas Available Today
While  we’re focusing our resources for the moment on platform improvements  designed to make Second Life faster, easier to use, and more fun for all  Residents, we are also testing two new features that had been in  development for some time before SLCC. The new Display Names feature is in public beta, and will enable more freedom of expression in Second Life. We have also just launched the public beta of Mesh Import,  which will revolutionize content creation in Second Life. So I  encourage you to download the Project Viewers and share your feedback.

I’ll  share more with you on our “back to basics” technology projects in  coming weeks and months. In the meantime, I’m looking forward to hearing  your thoughts on our recent progress in the comments below. And, as  always, thanks for all of your passion and participation.

Esbee Linden

Viewer 2 (Version 2.2.0) has been released today as the main Second Life Viewer! This is an important release for us because it marks the first big release using the Snowstorm process. A few months ago, we formed the Snowstorm Team as a dedicated Viewer team who works with the open source community and entirely in the open to make user experience improvements to the Viewer. We've been holding almost all our meetings in public, working with open source developers to integrate their work, sharing our backlog with the community, and releasing daily development Viewers which are available for anyone to download.

Over the last few months, we've improved the velocity of our teams and shortened the release cycle. The Version 2.2.0 release today comes after a three-week beta cycle during which we released Betas weekly and focused on stabilization and crash fixes on the Beta Viewer. Your feedback, crash, and bug reports during our beta cycles are crucial - so thank you to all who participated in that process.

Version 2.2.0 introduces some new features, usability enhancements, and crash fixes. Here are a few highlights:

  • Sidebar Panels can now be undocked and turned into regular floating windows: Simply click on a Sidebar Tab and drag it away from the Sidebar to undock it. You can also click the undock icon in the top right of a panel. To redock a sidebar panel, click the redock icon in the top right of the panel. Once sidebar panels are undocked, they behave like any other floating window in the Viewer.

  • Buttons on the Bottom Bar can now be reordered: In the last Viewer release, we added a few optional buttons to the Bottom Bar. In the 2.2.0 release, you can now reorder buttons on the Bottom Bar, so they’re arranged just the way you like them.

  • Right-click on your avatar and select “Sit Down” to sit anywhere: A great feature that came to the Viewer, by way of Snowglobe, allows you to right-click on yourself and select “Sit Down” from the context menu to make your avatar sit anywhere. To stand back up, just click the “Stand Up” button or right-click on yourself again and select “Stand Up” from the context menu.

  • Parcel Property Icons are now on by default: Parcel property icons indicate what users can, or can’t, do on a particular parcel. The icons can be found in the Location Bar and are now on by default. If you’d like to turn them off, you can do so by right-clicking the Location Bar and unchecking “Show Parcel Properties” from the context menu.

  • Selection Beams are working again: In Viewer 2, there was a bug that hid selection beams. This made it hard for people to see when you were building or the object you were currently editing. This has been corrected!

  • Language translations in local chat (via Google Translate API): Another great feature that came to the Viewer via Snowglobe is local chat translation. Simply click the “Translate chat” check box in the upper left hand corner of the local chat window. Language preferences can be set at the bottom of the Chat tab in the Preference window.

  • Group permissions now work in Snapshots: This corrected a bug in Snapshots which prevented you from sharing a Snapshot texture with a Group.

  • Turn off scripted particles and lights: This feature allows photographers and machinemists to turn off scripted lights by accessing the Debug Setting, “EffectScriptChatParticles” and setting it to FALSE. To turn scripted particles and lights back on, simply go to the Debug Setting window again and set “EffectScriptChatParticles” to TRUE.

  • Builders can more easily align textures across linked prims using planar mapping: This feature allows builders to align textures across faces so that several prims can look like a single prim. Simply select the faces of a set of linked prims, then open the Textures tab of the Build tool, make sure your Mapping setting is set to “Planar”, then click the checkbox labeled “Align planar faces.”

  • View profile inspectors via the Mini Map: When you hover over the little dots (people indicators) on the Mini-Map, you’ll see the familiar “i” icon pop open with a user’s name. Clicking the inspector allows you to view that user’s Mini Profile.

  • Pan the Mini-Map with shift-drag: If you hold down the <SHIFT> key and then click and drag on the Mini-map, you can now pan the map to view other areas.

As I mentioned in the blog post announcing the Version 2.2 beta, many of the features included in this release come directly from Resident contributions - via the Snowstorm process, as well as through past contributions to the Snowglobe project. Thank you to all of you who have contributed code, testing, and commentary. Please keep it up!

The Viewer 2 (Version 2.2.0) release is not a mandatory upgrade at this time, but will be the default download for the Second Life Viewer on the downloads page.

You can view the full release notes for Viewer 2 (Version 2.2.0) here.

Download Viewer 2 (Version 2.2.0)
Win | Mac | Linux

Jack.Linden

Today, we are excited to launch the latest version of Viewer 2 -- Viewer 2.3 Beta -- that makes it even easier to connect to friends and relevant experiences in Second Life. We’ve come a long way since we first launched the first Viewer 2 Beta in February. We’ve dramatically increased performance and stability while adding cool new features like Shared Media. We’ve also made many usability improvements, based on your feedback, that make it easier for content creators and developers to build in Second Life.

With the Version 2.3 Beta, Viewer 2 takes another big leap forward. This Beta not only includes many performance enhancements and bug fixes, but it also allows you to more freely express your inworld identity with Display Names, introduces helpful pop-up hints to make it easier to learn Viewer 2, and gives group owners more control of SL Events.

Display Names Arrives on the Main Grid

Display Names, as you know, gives all Residents two names: a unique username and an optional Display Name that you can change on a weekly basis. Display Names gives you the ability to use Unicode characters and multiple words so you can use your current SL Name, your real name, a pseudonym, or a gamer tag. It’s your choice!

Since we originally blogged about Display Names, and subsequently launched the Display Names Project Viewer on the test grid, we’ve made a range of changes to the feature that address the Resident concerns and feedback we received around impersonation and griefing. If you want to learn more, there’s a video below showcasing the enhancements and a full list detailing each change. We have also compiled a Frequently Asked Questions wiki page and two Knowledge Base articles, one on Display Names and another on usernames, complete with video tutorials from Torley that show you how to use this new feature.

Check out this video to see Display Names in action:


 

Because we need to ensure that Display Names operates correctly, we will not enable Display Names for the entire grid immediately. Today, it will work in a few thousand regions; once we see how it performs,  we will dial that up over the next few weeks until the whole grid is enabled. If you want to try using Display Names, then head to Blake Sea and Bay City, as those areas will be enabled first.

Group Owners Can Now Control Event Scheduling

The Viewer 2.3 Beta now allows group owners to control events scheduling on group-owned land. Please read more and see our step-by-step instructions on the SL Events wiki pages.

Viewer Hints Make the Switch to Viewer 2 Easy

We understand that there’s a bit of a learning curve when you make the switch from Viewer 1.23 to Viewer 2. So, we have added helpful pop-up hints for newer users around commonly used features, such as walk and chat. These disappear when the user takes the appropriate action, or dismisses the hint, and then you’ll never see them again.

Download the Viewer 2.3 Beta today, try it out, and Twitter your thoughts using the #slviewer2 hashtag.

Helpful Links

Jack.Linden

At Linden Lab, we recognize that SL Search is an aspect of the Second Life experience that is a top “back to basics,” priority to improve. So, over the last few months, the SL Search team has been working hard to make Search results more accurate and prepare for the Teen Second Life migration to the Main Grid. Here's a brief overview:

 

New Filters for Search with General or Moderate Ratings

Until now, we've had both land and language filtering in search results. However, there was no real difference between General and Moderate content filters. We're tweaking the content filters, both by defining a "Moderate" set of keywords and by altering some of the teen-related language in the adult filters. If your parcel or profile does not appear at the maturity level you expect it to, then edit your text. You will usually see your edits reflected in Search within six hours.

 

Classified Ads Now Get Extra Level of Rating Validation

Classifieds have always allowed Residents listing a Classified to self-declare the maturity rating of their ad. With teens gaining access to the Main Grid, we've added content filtering to provide another level of rating validation. If you list an ad and don't see the maturity level you're optimizing for in search results, then just edit your text. You should see the edits reflected in Search in about an hour.

 

New Functionality Automatically Builds in Keyword Variations

We’ve also added new functionality (stemming and stop words, for all the industry professionals out there) into Classifieds, which means that advertisers don’t have to stuff their descriptions with every variation of a keyword. For example, a search for “Dance” will return descriptions with “dancing,” “dances,” and “danced."

 

More Sophisticated Filters to Identify Spam and Optimize Search Results

We've moved from the more rigid "past this point and you get dinged" method of calculating boost to one that balances several features of your page. These aspects include how often words are repeated, the nature of the objects on your parcel, the size of the parcel, unique descriptors, and the use of symbols and ALL CAPS. It is important to note that the filter takes into consideration many things. Depending on the combination used, your score could be impacted negatively or not at all.

A note about the perceived "size boost": We want to promote all relevant locations in Second Life -- big or small. Larger stores, with bigger inventories, are more likely to be mistakenly downgraded in Search for repetition in their descriptions and objects. So, we give larger parcels a minor buffer to allow for that. We’ve also adjusted this buffer so that it should be less noticeable. In addition, we now apply a negative boost for parcels that are below the minimum size permitted in search.

All of these factors are now rolled into the one visible spam boost rating on each parcel. It’s worth checking it over the next two weeks as we roll out changes and make the appropriate updates to your information. Edits are typically reflected on the World page in a few minutes and up to six hours in Search.

 

Destination Guide

Finally, we’ve made some changes to the Destination Guide to reflect each listing’s parcel maturity. This will ensure that teens have access to all of the Destination Guide listings they see in the Find window and all Residents will now see Destination Guide entries filtered by maturity level.

 

Let Us Know What You Think

We hope that these changes benefit everyone in Second Life -- inworld businesses and Residents alike. Keep an eye on Search release notes for ongoing updates. Try it out and let us know if you notice the improvements. We look forward to your feedback in comments below!

Note: Edited to fix spacing and headings on new platform. - Sea

Linden Lab

From time to time, incidents occur that our operations team needs to quickly fix in order to keep all of Second Life working well 24x7 for users around the world.

How does the Linden Lab ops team collaborate to quickly tackle these incidents? Our VP of Operations and Platform Engineering, Landon McDowell (Landon Linden), has written a great description of an early experience he had with our approach as well as some thoughts on why it works so well. This is a bit outside the usual “Tools & Tech” topics for this blog, but we thought Second Life users familiar with how operations teams work would appreciate the inside look at our team’s approach: 

Two weeks into my tenure in the Operations group at Linden Lab I was confronted with my first major incident there. It was early afternoon, and I was well into a post-ramen food coma when alarms started popping off in IRC. All of our major charts were taking a header - logins, concurrency, etc.

The call went out in #ops for hands, but I had already jumped in. This wasn’t my first rodeo. I was primed to hop onto a conference call or pile into a room to marshall a response. But that never happened.

Instead, responders starting piping up in IRC with, “Hands.”  Soon I was completely overwhelmed by a stream of text flying across my screen as engineers were reporting back and discussing findings.

The problem was quickly narrowed down to a particular load balancer. I was barely into the box before an engineer chimed in, “It's running out of ports.” From there the resolution was straight-forward: some quick TCP tuning and adding another backend to the pool to quickly stabilize things before proceeding to long-term fixes.

I, though, just sat there staring at the screen wondering what the hell had just happened, wondering what the hell I had gotten myself into. I thought I was a seasoned pro, but I had never ever seen an incident response go that smoothly or quickly. Panic started to set in. I was out of my league.

In the day that followed, I was able to review the incident by reading the chat log, referred to as the scrollback. My confidence slowly began to rebuild. I stepped through the incident response line by line, server by server, action by action. After we completed the postmortem, I felt that with more practice and experience I could do this. I also realized, to the initiated, chat-centric incident response is far and away the best, most efficient method of handling outages.

The speed of text communication is much faster. The average adult can read about twice as fast as they can listen. This effect is amplified with chat comms being multiplexed, meaning multiple speakers can talk intelligibly at the same time. With practice, a participant can even quickly understand multiple conversations interleaved in the same channel. The power of this cannot be overstated.

In a room or on a conference call, there can only be one speaker at a time. During an outage when tensions are high this kind of order can be difficult to maintain. People naturally want to blurt out what they are seeing. There are methods of dealing with this, such as leader-designating speakers or “conch shell” type protocols. In practice though, what often prevails is what one of my vendors calls the “Mountain View Protocol,” where the loudest speaker is the one who’s heard.

In text, responders are able to hop out of a conversation, focus on some investigation or action, hop back in, and quickly catch up due to the presence of scroll back. In verbal comms, responders check-out to do some work and lose track of the conversation resulting in a lot of repeating.

Responders never all show up simultaneously. Often they have to be pulled in mid-incident. The power of the chat log really comes through here as latecomers get an automatic up-to-the-second sitrep. “Reading scrollback” is our standard entrance letting everyone know someone new has engaged and needs a minute to catch up. Even in cases when a quick briefing to a newcomer is necessary, one person can break off into a separate channel or in private message without having to disengage from the main conversation.

Other kinds of text sidebars are of course useful in incident responses. For example, emotions run high during outages and occasionally you have to ask someone to cool their jets. This is done quickly and effectively in private chat message without embarrassing them in front of the rest of the team.

At Linden Lab, we use a designated Incident Commander to orchestrate incident responses. Chat systems give an easy way to flag whoever is running the show by chat handle and/or in the channel topic. Anyone jumping in knows immediately who is in charge without having to distract the response team by asking.

Running an incident response in a chat channel is also an incredibly effective way of passively disseminating information to a wide audience. A large number of people can quietly lurk in a chat channel unlike in a physical space. More formal status updates to various parties, like support, are of course sometimes necessary but enabling those parties to follow along in real time gives them context that would not otherwise be conveyed in a terse status report.

As a final bonus, we are able to respond to a problem at peak efficiency regardless of where anyone is at that moment. Issues don’t wait for office hours to crop up. Being a distributed team, this is really our only option, but it rocks that being distributed is an advantage in incident response.

The benefits of chat-based incident responses don’t end with the incident though. Having a detailed log of events is invaluable in conducting postmortems. People have a terrible memories, especially during high stress events. The log gives a history of events with precise times that could never be achieved by relying on responders' recollections.

Likewise, the chat log for an incident is potent teaching tool. New hires can use them to learn about the particulars and eccentricities of systems in a way that is rarely captured in documentation or direct instruction. But in general, the log gives a remarkably clear picture of what went right and what went wrong in an incident response, letting the team better iterate and improve on their process over time.

Chat-based incident response isn’t easy. It requires group discipline and commitment as it runs counter to our instincts about communication. It can be nerve-racking for newcomers to the practice. Not everyone can hack it. Extremely smart people can and do wash out from not being able to keep up. But when it works it is a wondrous thing to behold, a ballet in a war zone, beautiful, terrifying, and glorious.

 

 

Esbee Linden

Viewer 2.4 Released!

As of today, SL Viewer 2.4 is the default Second Life Viewer download for new Residents! As was mentioned in the Viewer 2.4 Beta blog post, this is largely a maintenance release focused on improving user experience, stability, and performance. This release does, however, have a few important changes and additions, including the following:

A Cleaner User Experience and More Customization Options in Preferences

Throughout 2010, we’ve added many new Preferences to the Viewer and it was time to not only reorganize and clean up the layout, but also add popular customization options, such as:

  • Color and transparency options that allow you to change the look of Viewer windows
  • Options to easily enable the Advanced and Developer menus
  • A new preference that you can use to turn group and IM chat pop-ups on or off whenever you like
Support for External Text Editors when Working with LSL

Here’s a good one for content creators and developers. Now, you can use your favorite script editor to edit LSL scripts outside of the Viewer. In  Viewer 2.4, enabling the new ‘ExternalEditor’ debug setting will allow you to specify the path to your own text editor (for example: /Applications/TextMate.app/Contents/MacOS/TextMate). When the setting is enabled, just open the Script Editor in the Viewer and click the “Edit” button, and the text editor you specified in debug settings will then open with the script you have open in the Viewer. Any changes you make and save in the text editor will automatically appear in the Script window in the Viewer.

Graphics Improvements

We continue to make numerous improvements to Viewer graphics as we move closer to integrating Mesh Import into Viewer 2. You can see more detail in the Release Notes, but we’ve improved antialiasing, anisotropic filtering, snapshots, and we’ll see even more in upcoming releases.

Performance Improvements

Viewer 2 performance is improving, as shown by steadily decreasing crash rates that are now close to those for Viewer 1.23, but we know there’s still more to do. So if you do crash, please be sure to send us a crash  report, as they are essential to helping us understand where issues occur, which allows us to better prioritize our work.

An Auto-Updater Tool

We now have an auto-updater for Viewer 2! This means that whenever a new Viewer is released, the next one being Viewer 2.5, it automatically  downloads the newest software in the background and offers you the  ability to upgrade when it’s ready. You can still decide whether you want to install the new version or not, but the auto-updater will help ensure that you’re always using the most up-to-date version of the SL Viewer. Keep in mind, the auto-updater will only work with optional updates. Mandatory updates will continue to work as they have in the past.

Finally, to those of you who gave us feedback on previous versions of Viewer 2, we offer a heartfelt thank you for all your bug reports, forum and blog comments, and Tweets using the #slviewer2 hashtag. Your input is invaluable as we continue to prioritize our 2011 Viewer 2 roadmap.

So download Viewer 2.4 -- and keep that feedback coming!

Helpful Links

Linden Lab

As of today, several projects have reached the Project Viewer stage, and we wanted to share a bit about how you can expect to see your Second Life experience improve with these initiatives.

Graphics Settings Benchmarking:
This is a new way of figuring out the best default graphics settings. Maybe this has happened to you: you got an awesome new graphics card, fired up SL… only to discover your graphics settings are set to Low, and can’t be changed? No more! This Viewer does away with the old GPU table and instead uses a quick benchmark measurement to detect your GPU to assign appropriate default graphics settings on startup. The settings on shiny powerful hardware should really let that hardware shine. Get a Project Benchmark Viewer today and help us gather metrics!  Please file bugs in JIRA if you find them.

Installation and Login screen changes:
A new look for the login screen is coming in stages. We’re tweaking the login screen and A/B testing the results. We’ve simplified the new user login screen to remove distractions, and we’re adding instructions for new downloads and installs. We’re also streamlining the returning user login screen to help you get where you’re going faster - or find a new place to visit. You’re likely to see some incremental changes continue over the coming weeks.

Performance Improvements:
Two complementary projects are going in neck-and-neck:

  • A new texture and mesh asset service (a CDN) is in testing on a limited set of regions, and so far it’s showing encouraging results. Particularly for those who login from places far away from our US data centers, this has the potential to significantly improve how quickly textures and meshes load. In the coming weeks, we will expand the number of regions using this new service as the next step in our testing.

  • We’re also taking the next step with the HTTP project - Pipelining. We will soon put out a viewer that will pipeline HTTP requests for texture and mesh fetches, improve inventory folder and item fetches, and have some general adjustments for using a CDN-enabled grid.

Separately, each of these will improve texture and mesh loading performance, but put together, you should really see some exciting improvements in how long it takes to load new areas and objects - making touring the many fabulous places in Second Life you have not yet visited even better!



Q Linden

In addition to many grid enhancements that FJ shared last week in his technology update blog post, the Viewer 2.5 beta cycle begins today. Viewer 2.5 Beta 1 is now available and includes several new features, usability improvements, and bug fixes.

Improved Web and Viewer Resident Profiles
The biggest change in Viewer 2.5 Beta 1 is that we've replaced the Viewer-based profiles with web-based profiles. You can access the redesigned profiles on the web using your Second Life user id and in the Viewer itself. For example, here’s mine. In the Viewer, profiles now open in a web browser and you can open as many profiles as you like at the same time. And, if you wish, you can even connect other social identities from Twitter, Facebook, and LinkedIn to your profile.

Logging In to your Favorite Locations
A long-standing feature request has been the ability to access some of  your favorite Landmarks from the login screen, so you can quickly teleport to places inworld. In the Viewer 2.5 Beta, we've added a preference that gives you access to the Landmarks on your Favorites Bar from the Login Screen. To use this feature, go to Preferences > Privacy and select the check box labeled, "Show my Favorite Landmarks at Login." If you log off and then restart your Viewer, then you'll see a list of your Favorite Landmarks in the "Start At" drop-down box on the login screen. Also, when this feature is enabled and you share a computer account (login) with other people, they will see your list of Favorites if they run the Viewer 2.5 Beta.

Decompression Performance Improvements
For a long time, we’ve used an older version of the Kakadu library known as KDU to load textures and images in the Viewer. The KDU Library has been updated to version 6.4 in the Viewer 2.5 Beta, which allows the Viewer to take advantage of significant decompression performance gains; our preliminary measurements gauge the performance gain at 30% for decoding images, which should translate to a visible improvement in rezzing time for complex scenes.

Please note that per our support policy, we’re also deprecating Viewer 2.1.1 today. If you’ve been running Viewer 2.1.1, you’ll be prompted to download the latest Viewer release. To stay up to date on future deprecation announcements, please subscribe to @secondlife on Twitter.

As  always, we want to know what you think of the latest beta so please keep that feedback coming. Share your impressions with us on Twitter and use the hashtag #SLViewer2.


Helpful Links

Linden Lab

Somewhere below the regolith in the Linden Lab secret lunar base, some of the Lab’s top minds have been tackling performance issues in Second Life. The areas of focus range from infrastructure improvements to server-side texture compositing to object caching.

This year, Linden Lab is making the single largest capital investment in new server hardware upgrades in the history of the company. This new hardware will give residents better performance and more reliability. Additionally, we are converting from three co-locations to two co-locations. This will significantly reduce our inter-co-location latency and further enhance simulator performance.

The Shining project is the name given to a recent Lab effort to identify and measure delays and other problems with streaming avatars and objects and to propose and implement solutions. During the Shining project, several small improvements have been identified and deployed. The next small improvement from Shining to be deployed will be pre-rendering the starter Avatars to improve the new resident experience.

As a result of the Shining investigation, the project has been split into three larger performance projects: Project Sunshine, Object Caching, and HTTP Library.

All together, the hardware upgrades and the Shining projects should improve avatar and object streaming speeds significantly. Depending on your unique situation, your mileage will vary.


Project Sunshine (Server-side Baked Texture Generation & Storage)


Currently, all client viewers are responsible for compositing their own Avatar textures, then sending the results back to the Sim for other viewers to access. This method can lead to slowdowns and errors. The actual calculations for compositing textures are straightforward and not particularly time-consuming. However, in order for the viewer to do the calculations it first has to download a lot of individual assets from the Sim, and must then upload large results back to the Sim. This pushes a lot of bits through the Sim / Viewer connection, which can be slow and unreliable.

Depending on client hardware to do the compositing and uploading of the resulting baked textures can introduce erroneous results (like way too much pink). In order to handle these errors, a number of retry and fallback mechanisms have been put in place. This adds further load and overhead to the whole system.

Project Sunshine stands up a Texture Compositing server that is separate from the Sims servers. When a Viewer needs to render an Avatar, it sends a message to the Sim, which in turn sends a message to the Texture Compositing Server. The Texture Server then performs the texture compositing and sends the results back to the Viewer.

The Texture Server has access to a database of previously generated Avatar textures. If the Sim is asking for the baked textures for an Avatar that has been previously calculated, the Texture Server can pull the results out of the database instead of recalculating. Even if it’s not the same Avatar, but the set of clothes is the same, the Texture Server can use the previously calculated results.

An additional advantage of having a Texture Generation server is that the heavy HTTP communication about the individual assets that make up an Avatar will happen on reliable, fast internal network connections instead of external connections.

Object Caching & Interest Lists

Caching objects on a resident’s hard drive is intended to provide faster drawing of objects that are most likely to be redrawn later in a resident’s session or in the next session.

The current object cache implementation has room for improvement. Currently, the viewer only caches objects at the point the resident disconnects from a region and only objects currently in view are cached. The current caching communication between Sim and Viewer when a scene is initially being loaded is inefficient and resource intensive.

The new system is designed to make sure that a viewer never has to download object information that it already has and is still valid. This will reduce the load on the Sim and on the Sim / Viewer connection.

With the new system, when the Viewer connects to a region, the Sim first says to the Viewer, “Here’s a list of all my object groups by UUID.” The Viewer checks its cache and replies, “Here are the timestamps for the object groups that I found in my cache.” (If an object group is not found in the cache, the timestamp is 0.) The Sim checks the Viewer’s timestamps against its own data and responds, “Here’s a list of object groups in your cache that are still valid.” While the Viewer starts drawing valid objects from its cache, the Sim starts streaming the new object data that the Viewer needs, based on the particular Viewer’s object priorities.

HTTP Library

Top performance for the Shining initiatives depend on the speed and reliability of HTTP messages initiated by both the Viewers and the Sims. The third part of the Shining project, the new HTTP Library, implements modern best practices in messaging, connection management, and error recovery.

Linden Lab

HTTP Project Recap

Earlier this year we blogged about the HTTP project and how, step-by-step, the project is overcoming various limitations. Viewer release 3.4.3 introduced a new HTTP library that made better use of network resources. Texture fetches were the first operations to take advantage of this library, which improved throughput while using fewer connections. But the viewer was still constrained by a one-request-per-connection model.

Changing that model required back-end modifications. Those shipped early in 2013 in the DRTSIM-203 simulator release. For the first time, texture fetches could re-use existing HTTP connections. And for most users, this doubled the theoretical maximum texture request rate.

But all the world is not textures, and mesh fetches were next to receive attention. Meshes required quite a bit more work. Both back-end and viewer engineering was needed, culminating in viewer release 3.7.2. This release brought mesh fetching into behavioral parity with textures.

req.png

These releases have brought the viewer up to the request rate limits of region 'C'. Here, the limits are dictated by serialization, distance, and the speed of light. We are preparing to move beyond this region with changes to concurrency and locality. HTTP request concurrency will be vastly increased by the introduction of HTTP pipelining. Locality will be changed by the use of a Content Delivery Network (CDN) to move texture and mesh data nearer to most users.

 

Pipelining

Common HTTP communication is a simple back-and-forth exchange of requests and responses. A request is issued, a response is returned, and only then is another request issued. As distance increases between endpoints, the time to perform this ping-pong increases, which lowers the effective request rate. Pipelining attacks this distance-induced loss by issuing multiple requests at once without waiting for responses.

The pipelining viewer will use this more aggressive request model for both texture and mesh fetches. This viewer is currently in QA and is expected to go to RC soon after the 3.7.16 release. It has also had trials outside of North America and the results have been very good. The effective request rate has approached the limits imposed by our servers and has exceeded the download rate of UDP texture fetching.

 

CDN

As for those server limits, the operations team at Linden has been making rapid progress on the CDN project (DRTSIM-258). This project will replicate the Linden services that supply meshes and textures to a CDN's PoPs (Points-of-Presence). With PoPs on multiple continents, request service time will be reduced for most users.

Combined with pipelining, CDN experiments are producing results that have only been dreamed about. How fast?  Well, the engineer's universal response of "It depends" applies. But several 100's of fetches per second have been seen far from the USA. This takes us into never before encountered performance territory.

 

And one more thing

The HTTP Project has focused on textures and meshes. But the inventory system, which maintains item ownership, is often described as... sluggish. So as an exercise in expanding the use of the new HTTP library, the pipelining viewer was modified to use it for inventory fetches. As with textures and meshes before, inventory is now fetching in the 'C' region of its specific performance graph. The difference can be surprising.

For several years, HTTP has figured prominently in Linden's plans for Second Life. "HTTP will give you speed and throughput, consistency and robustness."  A promised land, but never quite realized. These next steps are payment on that promise. HTTP done well can support an amazing experience. And you'll have no reason to look back to the V1 world of UDP textures and inventory.

Nous sommes embarqués,

Monty (Linden)

 

Linden Lab

CDN Unleashed

11.07.2014: An update on performance improvements and adjustments is available here.

 

Second Life was originally designed for nearly all data and Viewer interactions to go through the Simulator server. That is, the Viewer would talk almost exclusively to the specific server hosting the region the Resident was in. This architecture had the advantage of giving a single point of control for any session. It also had the disadvantage of making it difficult to address region resource problems or otherwise scale out busy areas.

Over the years we’ve implemented techniques to get around these problems, but one pain point proved difficult to fix: asset delivery, specifically textures and meshes. Recently we implemented the ability to move texture and mesh traffic off the simulator server onto a Content Delivery Network (CDN), dramatically improving download times for Residents while significantly reducing the load on busy servers.

Download times for textures and meshes have been reduced by more than 50% on average, but outside of North America those the improvements are even more dramatic. That is great news, but the most amazing improvement has been on the simulator servers themselves. The following chart graphs servers on a production release-candidate channel with high HTTP load conditions before and after we rolled the CDN code onto them:

CDN.png

The high load conditions almost completely disappeared! We knew that we would get a major drop in load with the move, but this blew us away. At first we didn’t believe it and spent two days trying to figure out what we did wrong. There was nothing wrong; this was real.

The results of all of this are faster scene loads, quicker object rezzing, far fewer problems with fuzzy or cloudy avatars, fewer teleport failures, and more! The feedback from Residents has been fantastic. We’re loving it, too! Everything is just so much snappier.

We have finished rolling the CDN code out to the grid, and the results have remained extraordinary. This week, we are also fully releasing our HTTP Project Viewer, which will make the CDN change even better by taking advantage of the elimination of server-side rate limiting. We have been extremely happy with the results so far (psst, we’re talking an 80% reduction in content download times).The CDN benefits are available to everyone regardless of which Viewer you choose to use. All users of the official Viewer will also be able to enjoy the results of the HTTP improvements, and third party developers are able to adopt these changes in their Viewers as well.

We are very happy to be finally releasing these improvements to everyone. Give it a try and let us know what you think!

Samuel Linden

Today, we’re releasing a new feature with the SL Viewer Beta, available only in Advanced mode--Enhanced Avatar Physics. In this viewer, you can now configure the amount of movement that you would like for your avatar’s soft body parts, making your avatar much more (ahem) realistic. Since the physics are controlled by a wearable object, you have the ability to easily customize and personalize your settings just as if you were editing any other clothing item. So whether you want lots of movement, or only a bit, you can adjust your settings and they will apply only to your avatar’s targeted body part.

Of course, we continue to smash bugs and make strides in viewer stability and performance, but we figured that you would be much more interested in avatars bouncing and jiggling. Please check the SL Viewer Beta Release Notes for system compatibility and known issues. So, download the new SL Viewer Beta today and give it a try.

See you inworld!

Helpful Links
    •    Download SL Viewer Beta (v2.6.3) with Enhanced Avatar Physics:
         Windows  |  Mac  |  Linux
    •    SL Viewer Beta Release Notes
    •    SL Viewer JIRA for Bugs Click on the "bugs" button on the upper right.
    •    Knowledge Base Article on Enhanced Avatar Physics
    •    Feedback Forum on SL Viewer
    •    Twitter hashtag #slviewer

 

UPDATE ON 4/26/11: SL Viewer with Enhanced Avatar Physics is now out of beta and generally available as the default Viewer for new users. Download it today on the main Second Life Downloads page. Then, let us know what you think on the SL Viewer Feedback Forum and in Twitter using the hashtag #slviewer.

Linden Lab

We are making some improvements to how we release new Viewer features. Our goal is to accelerate the pace at which we bring new features and improvements to all Second Life users by removing what had previously been a bottleneck in our release process.

 

In a couple of weeks, we’re going to begin following a process similar to what we already do with the simulator. We’ll release more than one new version at the same time in parallel to subsets of users for final validation, and then promote the most important of the best of those to the default Release Viewer when that testing shows it to be ready.

 

In the past, we have used the 'Second Life Beta Viewer' channel for this final user validation, but because we had only one Beta channel, some features and fixes have been significantly delayed waiting for their 'turn' in the channel. We will now be able to put those Viewers in the regular Release channel to a smaller randomly chosen group, allowing us to test and release new features more quickly.

 

If a development project wants to put out an early version for testing prior to it being ready for the Release channel, a channel specific to that project (either 'Project <project>' for very early versions, or 'Beta <project>' for more mature ones) will be created, just like we do today. These will be shut down when the project is ready to move to final testing in the Release channel, and users in the early project test channels will automatically be upgraded to the corresponding Release candidate version.

 

Because several different beta Viewers will be tested concurrently in the Release channel, the ‘Second Life Beta Viewer’ channel will no longer be used; there will be a web page where users who want to try early versions can find them. The existing inworld 'Second Life Beta' group is not affected.

 

Following a similar process has enabled us to accelerate the pace at which we release improvements to the simulator, and we’re looking forward to using this new process to more quickly introduce new features to the Second Life Viewer.

Linden Lab

Keeping the systems running the Second Life infrastructure operating smoothly is no mean feat. Our monitoring infrastructure keeps an eye on our machines every second, and a team of people work around the clock to ensure that Second Life runs smoothly. We do our best to replace failing systems proactively and invisibly to Residents. Unfortunately, sometimes unexpected problems arise.

In late July, a hardware failure took down four of our latest-generation of simulator hosts. Initially, this was attributed to be a random failure, and the machine was sent off to our vendor for repair. In early October, a second failure took down another four machines. Two weeks later, another failure on another four hosts.

Each host lives inside a chassis along with three other hosts. These four hosts all share a common backplane that provides the hosts with power, networking and storage. The failures were traced to an overheating and subsequent failure of a component on these backplanes.

After exhaustive investigation with our vendor, the root cause of the failures turned out to be a hardware defect in a backplane component. We arranged an on-site visit by our vendor to locate, identify, and replace the affected backplanes. Members of our operations team have been working this week with our vendor in our datacentre to inspect every potentially affected system and replace the defective component to prevent any more failures.

The region restarts that some of you have experienced this week were an unfortunate side-effect of this critical maintenance work. We have done our best to keep these restarts to a minimum as we understand just how disruptive a region restart can be. The affected machines have been repaired, and returned to service and we are confident that no more failures of this type will occur in the future. Thank you all for your patience and understanding as we have proceeded through the extended maintenance window this week.

 

Linden Lab

Today, we released the latest version of the SL Viewer into general availability with Voice included in Basic mode. All that new users have to do is click on a simple microphone button--a well-understood symbol for voice/sound. For those seasoned Residents, the microphone button is where the Speak button is in Advanced mode.

SLViewerBasic-voice.jpg

Look for more improvements to the SL Viewer coming soon. In the meantime, download the latest SL Viewer and give Basic mode a try.

Helpful Links
    •    Download SL Viewer with Basic and Advanced:
    ◦    Windows  |  Mac  |  Linux
    •    SL Viewer Release Notes
    •    Feedback Forum on SL Viewer Basic Mode
    •    Twitter hashtag #slviewer

Linden Lab

 

pr3AP_DADAY

 

One of the challenges that virtual world creators face is the trade-off between rich visual detail and geometric complexity. Ideally, by adding more and smaller faces to an object, a designer can model different surface textures and create realistic variations in the interplay of light and shadow. However, adding faces also quickly increases the size of the model and its rendering cost. Normal and Specular Maps are ways to address this by allowing for the appearance of a complex surface without actually modeling fine scale geometry.

A Normal Map is an image where the color codes indicate how the renderer should reflect light from each pixel on a surface by modifying the direction that the pixel "faces" (imagine that each pixel could be turned on tiny pivots). This means that pixels on a simple surface can be rendered so that they appear to have much more detail than the actual geometry and at much lower rendering cost. Light and shadow are rendered as though the surface had depth and physical texture, simulating roughness, bumps, and even edges and additional faces.

Similarly, a Specular Map allows each pixel to have its own degree of reflectivity, so that some parts of a single face reflect sharply, while adjacent pixels can be dull.

The open source developers of the Exodus Viewer are contributing Viewer support for Normal and Specular Maps, as well as some additional controls for how light reflects from faces. Linden Lab is developing the server side support so that this powerful tool will be available in Second Life.

Design and development are under way. Watch this blog and the Snowstorm Viewers page for information on when test Viewers with these new capabilities become available.

For additional information, or to learn more about how you can participate in the open source program, please contact Oz@lindenlab.com.

 

Linden Lab

User-submitted bug reports help improve the Second Life experience for all Residents, so we greatly appreciate all of you who take the time to provide this invaluable information to us.

Because we want to make it even easier to report bugs, today we are making some changes that will streamline the bug reporting process, allowing us to more quickly collect information and respond to issues.

Following is a summary of the JIRA changes:

  • All bugs should now be filed in the new BUG project, using the more streamlined submission form.
  • Second Life users will only see their own reported issues.  When a Bug reaches the "Been Triaged" status, they will no longer be able to add comments to their issue.
  • Once a Bug reaches the “Accepted” or “Closed” status, it will not be updated. You can watch the Release Notes to see when and if a fix has been released for your issue.
  • Existing JIRAs will remain publicly visible. We will continue to review and work through these.


To those of you who have taken the time to alert us to bugs and provided the information we need to fix them -- thank you! We hope that you will continue to help us improve Second Life, and this new process should make it easier for all of us. Ideas about how we can continue to improve the bug reporting process can be shared here.

For more information, visit:
How to report a BUG (Knowledge Base Article):
Bug Tracker (wiki page):
Bug Tracker Status/Resolutions (wiki page):

Linden Lab

Many of you may have read about the Heartbleed SSL vulnerability that is still affecting many Internet sites.

You do not need to take extra action to secure your Second Life password if you have not used the same password on other websites. Your Second Life password was not visible via Heartbleed server memory exposure. No secondlife.com site that accepts passwords had the vulnerable SSL heartbeat feature enabled.

If you used the same password for Second Life that you used on a third-party site, and if that third-party site may have been affected by the vulnerability, you should change your password.

Supporting sites such as Second Life profiles are hosted on cloud hosting services. Some of these sites were previously vulnerable to Heartbleed, which may have exposed one of these servers' certificates. As an extra precaution, we are in the process of replacing our SSL certificates across the board. This change will be fully automatic in standard web browsers.

Thank you for your interest in keeping Second Life safe!

Linden Lab

Engineering and Operations at Linden Lab are constantly striving to make performance improvements to Second Life and we want to share the results of a recent one.

An optimization on a single query against the read pool of one of the main core database clusters has resulted in nearly a 75% reduction in load on that cluster, improving numerous systems including group functions and teleports. There has been a 7% improvement in teleport performance in peak concurrency hours and an 86% reduction in group query times.


fRE4LDTWduZqaLaP-HSqdvKpDkl21ROVRMjjmcOtlx27AXWtnocRPwLcoG5UXXIEao_N5GuEaOkroy6VUUK_FN_28LBcYalWiRpjnQG-atCftlHECgM


This is only one of the performance changes we will be making over the next few months, so keep an eye out.

×
×
  • Create New...