Viewer-Managed Marketplace update

secondlifeViewer-Managed Marketplace (VMM) is a new set of capabilities designed to enable merchants to manage the creation and management of Marketplace product listings through the viewer, bypassing the need to use the Merchant Outbox an have copies of items stored on the Marketplace inventory servers), or using Magic Boxes located in-world, as VMM fully supports the sale on No Copy objects.

As most (all?) merchants are aware, it has been undergoing beta testing since the end of 2014, initially on Aditi (the Beta grid), and more recently on the Main grid, and there have been several feedback session on the work, either directly with merchants and those involved in the beta testing, and / or through the Lab’s Third-Party Viewer Developer meetings (see my VMM updates in this blog for specifics, together with the main VMM discussion thread on the Commerce forum).

The general feedback on the beta is that it has been going very well, with reported issues being dealt with by the Lab.

Automated Migration Notes

As a part of the transition to VMM, the Lab is offering merchants an automatic migration of their existing Direct Delivery items to VMM (items in Magic Boxes must be manually migrated to VMM). It is this automatic migration process that has been undergoing the most recent and extensive testing, and details on the process are now beginning to emerge, which can be summarised as:

  • The automated migration process for all merchants will start no earlier than June 20th, 2015
  • The automated migration process is capped at a maximum of 5,000 items per merchant, and the Lab has been notifying affected merchants of this, and what actions will be taken for those with more than 5,000, namely:
    • Any unlisted items held by the merchant will be removed from the Marketplace as returned to the Merchant’s Received Items folder
    • If the above fails to reduce the item count to below 5,000, any listed items held by the Merchant which have not had a sale in the past year will be unlisted and returned to the Merchant’s Received Items folder.
  • Those merchants with more than 5,000 items on the Marketplace who do not wish to have their items pruned by the auto-migration process are being encouraged to carry out any pruning that may be required to get their numbers below 5,000 ahead of the start of the auto-migration process, or to carry out the migration of their Direct Delivery items manually and alongside any Magic Box items they may have.
VMM includes an option to manually associate existing MP listings with VMM items in your inventory, which will help ease part of the the migration process for those concerned over automated migration paths
VMM includes an option to manually associate existing MP listings with VMM items in your inventory, which will help ease part of the the migration process for those concerned over automated migration paths

For those who wish to do so, manually migrating Direct Delivery items to VMM is relatively straightforward. All you need is the VMM project viewer (currently version 3.7.28.300920, although this may update shortly – see below), and you can use the Associate Listings capability within VMM to easily link items in your Marketplace Listings panel with you existing MP listings without having the re-create the latter, as shown above.

One point to note when moving DD items to VMM is that if you use multiple sub-folders within a current Direct Delivery folder, you may have to re-arrange things to avoid VMM treating the sub-folders as individual versions of the product.

Additional Notes

Some concerns have been raised over goods from merchants which are still popular in terms of sales, even though the Merchant may no longer be active in Second Life. It would seem that if these items meet the criteria for automatic migration, then they should continue to be available following the migration process. However, if they are only available via Magic Boxes and are not migrated manually (or fail to meet the automatic migration criteria), then will cease to be available as the switch-over to VMM runs its course.

The UKanDo viewer is one TPV to have already implemented the viewer side VMM updates. Out of curiosity, I used them alongside the project viewer to convert my own Marketplace items
The UKanDo viewer is one TPV to have already implemented the viewer side VMM updates. Out of curiosity, I used them alongside the project viewer to convert my own Marketplace items

For those who would prefer to use the viewer they are most familiar with in order to migrate their items to DD, rather than use the LL viewer, it is anticipated that the latter will undergo a further round of minor fixes, and the updates version either issued as a release candidate viewer or promoted to RC status shortly thereafter.

Once at RC status, the VMM code will legitimately be available for incorporation into TPVs as well. However, some TPVs have already adopted the code – the v3-style UKanDo viewer being one, for example.

One additional point of note here as well is that just because the viewer code may go to RC status fairly shortly, it does not mean the Lab are suddenly going to declare VMM is “live”. Lead times have been promised and adhered to throughout testing, and as noted earlier in this article, the only time scale that is confirmed for now is that the automatic migration process for all Merchants will not commence before June 20th.

While my own feedback may be of limited value, as I only have a small store and do not classify myself as a Merchant, I have used both the project viewer and UKanDo to manually migrate my items (and have removed various items out of choice, even though my store was well below the automatic migration threshold). By using the Associate Listing capability in VMM, I found the entire process to be relatively issue free – the only problems I did have were the result of silly mistakes on my part will flicking back and forth between the project viewer and UKanDo to test the functionality of the latter against the former.

Related Links

Advertisements

SL project updates week 20/2: TPV Developer meeting, VMM

Miyagi; Inara Pey, May 2015, on Flickr Miyagi (General), May 2015 (Flickr) – blog post

The following notes are primarily taken from the TPV Developer (TPVD) meeting held on Friday, May 15th, and from the Server Beta meeting held on Thursday, May 14th. A video of the TPVD meeting is included below, with any time stamps in the following text referring to it. My thanks as always to North for the recording and providing it for embedding,

Server Deployments, Week 20 – Recap

As always, please refer to the server deployment thread for the latest updates / news.

There was no Main (SLS) channel deployment on Tuesday, May 11th. On Wednesday, May 12th, the three RC channels were all updated with a new server maintenance package, comprising internal server logging changes, back-end system bug fixes, reply-to email changed in postcard sends (see below for more).

Group Chat

The Server Beta User Group meeting on Thursday, May 14th, saw a test of a group chat update it is hoped will fix the issue of some people not seeing all or some chat when the group chat window is open (see BUG-9130). The test appeared to yield positive results, with Simon reporting no unusual event logging. The problem here is that the instances of the problem seem to be so rare, it’s hard to guarantee a small sampling of testers will catch any problems which might still exist.

SL Viewer

[00:15] It has been a quiet week on the viewer front. As noted in part 1 of this week’s report, the attachment viewer (Project big Bird) reached RC status, other than that there has been not additional movement with either the current selection of RC and project viewers.

A further update to the mesh importer project viewer (currently at version 3.7.28.300878) is with LL’s QA team and should be released relatively soon. Updates are also being made to the Viewer-Managed Marketplace project viewer (which is likely to go to RC status once through LL’s QA process) and the Oculus Rift project viewer.

Snapshots to E-mail

[02:22] Commenting at the TPV Developer meeting, Oz Linden gave a little more information on the “reply-to email changed in postcard sends” update deployed to the RCs, indicating this was indeed a fix aimed at preventing snapshot to e-mail being tagged as spam by ISPs and a/v software due to the way they handle the “from” field (see my TPV Developer meeting report for week #17), which had caused the Lab to consider removing the snapshot to e-mail capability.

“Instead,” Oz told the meeting, “we found we could get around that by sending the e-mail differently … So the way it’s changed now is that instead of sending the ‘from’ address as the sender’s address, we send the ‘reply-to’ address; and the ‘from’ address is ‘no-reply@secondlife.com’ … so that ducks the problem of us looking like spammers who are forging invalid addresses.”

This should hopefully negate any need to remove the snapshot to e-mail capability, and retain compatibility with sending snapshots to the likes of Snapzilla and the SLU forums.

Unified Snapshot Floater

[04:40] NiranV Dean, who submitted the unified snapshot floater to LL (and which has most recently been integrated into Firestorm among the TPVs) asked if there had been any feedback on it. Both Oz and Grumpity Linden indicated that overall, feedback has been positive, although some have complained at the amount of screen real estate it takes up with the preview panel open. As this allows the snapshot preview to match the aspect ratio of the user’s screen, there’s not a lot that can be done about it – and the preview window can always be closed / the panel minimised when initially setting-up shots.

The unified snapshot floater - further work is being carried out by TPV devs for contribution to LL, including the possible full integration of the Facebook, Flickr and Twitter upload options
The unified snapshot floater – further work is being carried out by TPV devs for contribution to LL, including the possible full integration of the Facebook, Flickr and Twitter upload options

Niran is proposing a further set of updates (one of which, a fix for auto snapshot, is in the works at the Lab), including possibly making the preview screen detachable from the main floater.  Cinder Roxley also indicated she is working on fully integrating the Facebook, Twitter and Flickr options into the main snapshot floater (they currently retain their own floaters due to the authentication workflow required for each. This work will be contributed to the Lab for consideration / integration when complete.

Viewer-Managed Marketplace (VMM)

[08:09] Over the last two weeks, as a part of the on-going beta of VMM, around 15-20 volunteers have had their stores migrated by the Lab from Direct Delivery to VMM. Brooke linden reports that the exercise has uncovered “pretty much minor issues” which the Lab can address. A further batch of volunteer migrations is planned to help further test the robustness of the process in the next week or so.

As noted above, the VMM viewer is now heading for an RC release once it has cleared LL’s QA testing. However,  the time frame on when this might happen is a little vague; it might be in the next week or so, or it might be longer.

Avatar Complexity

[17:34]  The next Snowstorm contributions viewer is progressing internally at the Lab. This is the viewer which includes the new Avatar Complexity (aka “Jelly Babies” or “rainbow avatars”) functionality which allows users to define a level of complexity (a weighting number) which will render any avatar exceeding that value as a solid colour, rather than a full avatar. The aim of this is to help reduce the rendering load placed on people’s computers, particularly in very busy locations. The value is adjustable, as so can of course be varied to suit your current needs.

Avatar complexity is intended to help those who may hit performance issues as a result of their GPU struggling to render complex (hight render cost) avatars, by rendering such avatars as solid colours.
Avatar complexity is intended to help those who may hit performance issues as a result of their GPU struggling to render complex (hight render cost) avatars, by rendering such avatars as solid colours.

A slight hiccup has occurred in that in making some changes to the code, Oz accidentally broke the code such that instead of rendering as a solid colour, avatars exceeding the limit are currently rendering as transparent, and this is yet to be fixed. Code has been added to the viewer to report how many people around you are rendering your avatar as a solid colour (should your avatar be complex enough to be rendered thus), but this has yet to be made visible through the viewer UI, and simulator support for this is now in place on the RC channels and will be rolled to the Main channel in the coming week.

Mac Updates

[19:36] Cinder Roxley has a set of contributions for using the viewer with Mac Retina displays ready to go to the Lab, and it seems likely these will flow into a further Snowstorm contributions viewer in development alongside the one containing the Avatar Complexity updates.

A question was also asked whether there were plans to update the Mac viewer to use a newer OpenGL core profile. The Lab is not working on this, as their rendering team believe there is little or no benefit to be gained from it. However, they would accept any contributions offered for consideration (subject to a “long, terrible QA process”). However, a good part of this would require working through some eight years of OpenGL code.

VMM meeting May 1st, 2015 – video and transcript

On Friday, May 1st, Brooke Linden chaired a Viewer-Managed Marketplace (VMM) feedback meeting to address any issues so far uncovered during the current beta testing and answer questions from Merchants.

The meeting was recorded by Chakat Northspring, and the video is embedded below, with a transcript of the Q&A session. My thanks, as always, to North for providing the video. The transcript picks-up after Brooke has made her opening comments thanking people for their attendance, etc. Questions / comments from attendees are show in italics, timestamps are provided at the start of replies so that those interested can jump to the relevant part of the video and list to the answers directly.

Note that during the meeting, there were some questions which were returned to as a result of additional comments. Where this is is the case, either: a) the question is given in the transcript at the point at which the major discussion on the subject took place, or b) subsequent comments and replies have been listed at the point at which the main answer to the question was given.

[01:34] Brooke Linden (BL): So I’m going to go over a little bit of how it works, and talk to you about some of the decision-making process and then I’d mainly like to focus on people who have experienced VMM and get feedback from them on the process and how it’s working for them, and then we can deal with high-level concerns.

So, what we had been doing with Direct Delivery is having people put items into a Merchant Outbox, which sent inventory items to the Marketplace, and then Merchants would then list those items, and those items would get delivered to their customers in-world. With Viewer-Managed Marketplace, we are getting rid of an extra step … and we are allowing deliveries to occur directly from the Merchant’s inventory.

Many of the Merchants we talked to are storing copies of the items they’re selling in the Marketplace in their inventory. Some of them are doing this in box form due to concerns over inventory sizes; and one of the things we did do is we spent a lot of time talking to out internal groups that have worked on and maintained large inventories for some of our customers to evaluate whether or not there was risk involved in increasing the size of some existing inventories.

The feedback we got from them is that the problems aren’t necessarily with large inventories, they are with situations where somebody has 10,000 folders or objects at the root of another folder [aka a “flat” inventory structure]. Now there are a handful of people on the Marketplace who have this many listings, and we’ll be working with them to help make sure that their old listings that are no longer in use get deleted.

One of the things that we changed with Direct Delivery is that we made it much easier to delete listings; so now if you want to delete a Direct Delivery listing, it will put your inventory back into your unassociated items folder, so you can return it to yourself in world … One additional thing we did as a part of Viewer-Managed Marketplace as a result of feedback … is that when an item runs out of stock [No copy items], it needs to be removed from the Marketplace … so we have changed the behaviour in Viewer-Managed Marketplace to unlist items that run out of stock.

We basically tried to fit-in related issues that made sense with the change to VMM. And one of the things we also did was to meet with some Merchants to talk about versions, and how they want to manage those versions, and how they typically manage them in their inventory. and we worked to create a hierarchy in the viewer-Managed Marketplace to support the ability to store more than one version under a listing and choose which one is the current active one.

So that’s a high-level overview with some of the thinking and some of the problems we tried to address while we were working on Viewer-Managed Marketplace. So, those of you who have tired Viewer-Managed Marketplace, are there questions or concerns or feedback that you have for us?

Why the sudden change when the Merchant Outbox is working fine?

VMM replaces the Merchant Outbox with the Marketplace Listings panel, which allows merchants to carry out a number of Marketplace-related tasks from within the viewer
VMM replaces the Merchant Outbox with the Marketplace Listings panel, which allows merchants to carry out a number of Marketplace-related tasks from within the viewer

[07:39] BL: The merchant Outbox isn’t working fine for everybody, and the Merchant Outbox also does not support  the group of Merchants who sell items that they do not have Copy rights on … in order to sell those, we had to make some changes to the way that Direct Delivery worked, and because we were going in to do this, we looked at the problems and feedback that we had received on Direct Delivery, and made some improvements there.

Overall, the number of times you move something between systems or people, the greater the risk of there being some kind of problem. And so we really wanted to minimise that. There are come people who have had their Merchant Outboxes stuck in initialising, and haven’t been able to put things on the Marketplace, and that’s something out support team is able to help with, but this is the kind of thing that we wanted to address.

Can you confirm the exact time line before auto migration starts so that we know how long we have to migrate ourselves if we wish?

[09:23] BL: We’re trying not to give exact dates, because one of the things we want to do is make sure that we have time to address any bugs or issues that come up before we start moving everybody.

So we will not be officially launching into production until the viewer is the released viewer. We’re planning to put the viewer into the release process hopefully in the next week or two [the viewer is currently a project viewer]. We’re working on getting the updates localised. So however long that takes  – and you all know it can take a month or so to get a new viewer out.

So at that point, will will have launched to production, and we’re planning to have users in production for probably about a month, to give them a chance to start moving things over manually if they would like to. We are going to be getting some volunteers who will let us migrate them early-on, and we might even want to migrate a couple of them during the beta period. We’ve already started testing migrations for some of our internal test accounts.

Once we’ve done those tests and dealt with any issues that come up, then we’ll begin the automated migration process.

[11:04] For very large stores [with] a few thousand or more listings, and if people are Premium members, we’re going to be allowing them to work with us to schedule a night where we can do the migration work. We’re going to do most of the migrations overnight Pacific Time, because that’s when our lowest traffic is on the Marketplace.

Other people who aren’t scheduled will get an e-mail at the start of the migration with an estimate of how long it will take for your store [to be migrated], we’re trying to be conservative, and then an e-mail at the end of the migration, letting you know that the migration is complete.

During the migration process your stores will not be available because there’s just so much risk for things to get messed-up. We expect it to be milliseconds per listing, 500 milliseconds at the most So hopefully that answered that question.

While transferring from the old system the new listings don’t automatically activate. They have to be listed even though it says “active”.

Kurt Linden (via chat): We are aware of this issue and working on a fix.

Continue reading “VMM meeting May 1st, 2015 – video and transcript”

SL project updates week 17/2: TPV meeting – CEF, Inventory

Fantasy Faire 2015: YoZakura; Inara Pey, April 2015, on Flickr Fantasy Faire – April 23rd to May 3rd, 2015: YoZakura (Flickr)

The following notes are primarily taken from the TPV Developer meeting held on Friday, April 24th,  a video of which is included below (my thanks as always to North for recording it and providing it for embedding), and from the Server Beta meeting held on Thursday, March 26th. Any time stamps contained within the following text refer to the TPV developer meeting video.

Server Deployments, Week 17 – Recap

As always, please refer to the server deployment thread for the latest updates.

  • On Tuesday, April 20th, the Main (SLS) channel received the server maintenance package deployed to all three RC channel in week #16, which comprises internal server logging changes and new flags for llGetObjectDetails()
    • OBJECT_BODY_SHAPE_TYPE – returned list entry is a float between 0.0 and 1.0. Anything > 0.5 is male, otherwise female; -1.0 if the avatar is not found
    • OBJECT_HOVER_HEIGHT – returned list entry is a float, -1.0 if the avatar is not found.
  • There were no deployment or restart on the three RC channels on Wednesday, April 22nd.

SL Viewer Updates

[05:50] The Tools Update viewer, version  3.7.28.300918, was promoted to the de facto release viewer on April 23rd – see my article here for details. During its run as an RC viewer, this release had around a 2% lower crash rate than the release viewer built using the “old” tool set and processes.

As a result of this, all the remaining RC and project viewers are being updated to match the release viewer code base, and updated versions should be appearing soon.

Attachment Fixes Viewer (Project BigBird)

[07:42] This viewer, current available as a project viewer – version 3.7.28.300856 – and which fixes a range of issues related to avatar attachment failures, is in the process of being updated to a Release Candidate status, and should be appearing in the release pipeline as such in week #18.

[29:28] The Lab believes that these fixes resolve all of the viewer-side issues related to attachment problems which are related to AIS v3. However, a number of the more noticeable issues  – such as problems with attachments being detached on teleporting – are server-side, and require further investigation / fixing.  Similarly, failures with requests to attach multiple items (such as during an outfit change) also appear to be simulator-related, rather than anything within the viewer or linked to AIS v3.

Oculus Rift Viewer

[07:55] The Oculus Rift viewer is now on the schedule to be updated and brought into line with more recent viewer code releases. There is no set time scale for this project (and the Oculus Rift itself, according to Oculus VR, is unlike to reach a consumer release in 2015), but the aim is to bring it back to a “more active” state.

Viewer-Managed Marketplace

[00:08] Brooke Linden gave an update on VVM – as this is of interest to a potentially wider audience than those interested in viewer development, I’ve provided a separate article on it.

Web Media (Webkit and CEF)

[08:41] The Lab is making “pretty good” progress on replacing webkit, an increasingly outdated third-party library used within the viewer for powering the built-in web browser, displaying web profiles and powering in-world media (TVs, MOAP, etc.), with the Chromium Embedded Framework. The Mac work is lagging a little behind this, but the Lab has now called-in external expertise to help move the project forward as a whole.

Request for TPV / Open-source Support for Linux

[09:17]  The Lab is seeking support from TPV developers and the open-source community to help maintain and move the Linux flavour of the viewer forward. For details, please see my  separate article in this blog, complete with an audio extract from the meeting.

Snapshots to E-mail

[12:27] The send snapshot as e-mail capability is in the process of being removed from the viewer.

The main reason for this is that wherever possible, snapshots are sent via the “secondlife.com” domain, but use the sender’s own e-mail address as the originating address in the “from” field of the sent e-mail which appears as if the “from” address is being forged. This, and other ways in which e-mails flowing out from “secondlife.com” are handled, has resulted in some ISPs regarding the domain as a spam domain, and have been pro-actively blocking it (Germany-based GMX is one such example).

To rectify these problems, the Lab is reviewing how e-mails from “secondlife.com” are being managed as a whole, and eliminating those uses which may conceivably lead to the domain In the case of the snapshot floater, the Lab’s perspective is that the easiest way to fix the problem is to remove the option from the snapshot floater; however as was pointed out to them in the meeting, this will break content such as wardrobe HUD systems which utilise the snapshots to e-mail functionality.

Other Items

HTTP and CDN Use Expansion

[20:35] The Lab is working on increasing the number of assets such as animations, sounds, and gestures, consumed by the viewer to being delivered via HTTP the CDN, and removing the reliance on UDP. This is for a number of reasons:

  • It further fees-up resources on the simulator to do what they do best – simulate the world around us, rather than using them for managing UDP file transfers
  • The use of UDP is not the most efficient or robust means of carrying out these transfers
  • UDP is bad for the network; there’s no flow control packet or congestion control behaviour, it can result in high packet losses which may occur anywhere between the the server and the viewer, and thus be hard to identify and prevent in future, etc.

As this work progresses, the Lab will be removing the server-side support for the UDP messaging currently used by such transfers. This has already happened with inventory fetching (and the option to disable HTTP Inventory is due to be removed from the viewer), and will be happening soon with texture fetching (which will also see the removal of the option to disable HTTP Textures in the viewer).

To help with this, TPVs are being encouraged to work with the Lab to identify specific / reproducible  issues users are encountering vis HTTP, etc., so that more work can be put into fixing them, and the Lab is asking TPVs not to recommend to users to switch back to the “old ways” of doing things when potential HTTP problems are encountered, as the 2old way may not be around for much longer.

Continue reading “SL project updates week 17/2: TPV meeting – CEF, Inventory”

Viewer-Managed Marketplace: brief update

secondlifeFurther to the recent launch of the Viewer-Managed Marketplace public beta test on the Main grid, Brooke Linden provided third-party viewer developers (who will need to integrate the viewer-side VMM changes into their viewers) with an update on the state-of-play with the project at the Third-Party Viewer Developer (TPVD) meeting on Friday, April 24th.

Her comments came at the opening of the meeting, which can be seen on a video provided by  Chakat Northspring, and are summarised in my overview of the meetings. However, as VMM is of interest to a broader community than viewer developers, this article is intended to provide a slightly more detailed summary of her comments. Timestamps to the relevant points in the video are further provided for ease-of-reference.

Follow-up Meeting

[00:08] The Lab is planning a follow-up meeting to the current Main grid beta activities. This has been provisionally scheduled for 11:00 SLT on Friday, May 1st, but is subject to final confirmation. Formal confirmation of the meeting will hopefully be given through the existing Merchants’ Forum post (or at least through a fresh post) nearer the time, and I’ll endeavour to post word on it when it is announced.

The aim of the meeting is to gain general feedback on the VMM from those who have been able to try it as a part of the beta and to hopefully update on the status of any issues so far reported and which are being addressed, and to answer questions.

Automated Migration

[00:53] A number of requests have been made through the forum thread for the automated migration process for Direct Delivery items (Magic Box items require manual migration) to be trialled among a selected group of merchants prior to being enforced for all merchants.

Brooke indicated that this would be the case, and will be seeking volunteers to help with this nearer the time.

VMM includes an option to manually associate existing MP listings with VMM items in your inventory, which will help ease part of the the migration process for those concerned over automated migration paths
VMM includes an option to manually associate existing MP listings with VMM items in your inventory, which will help ease part of the the migration process for those concerned over automated migration paths

Other Items

[01:27 and 02:58] The beta programme will be opened to broader access than the current sign-up process, allowing for broader testing as things progress towards a “full” release.

[01:54] The language-localised elements of the work are expected in a couple of weeks. In the meantime, those trying the beta are requested to keep filing bug reports on anything they find (and can preferably reproduce).

[02:06] Incoming bugs on the project JIRA are being watched and investigated, including a couple of edge-case crash situations. Further bug and issues reports are still welcomed on the JIRA.

[03:56] As an aside to the main points, the VMM code has been merged with the current viewer release code as a part of the Lab’s now viewer development process (although the code remains available only via the project viewer for the time being).

Related Links

SL project updates week 17/1: server, viewer, Avatar Complexity

221B Baker Street; Inara Pey, April 2015, on Flickr 221B Baker Street, circa 2012-2015, as seen in the BBC’s series Sherlock – and in Second Lifeblog post

Server Deployments, Week 17

As always, please refer to the server deployment thread for the latest updates.

  • On Tuesday, April 20th, the Main (SLS) channel received the server maintenance package deployed to all three RC channel in week #16, which comprises internal server logging changes and new flags for llGetObjectDetails()
    • OBJECT_BODY_SHAPE_TYPE – returned list entry is a float between 0.0 and 1.0. Anything > 0.5 is male, otherwise female; -1.0 if the avatar is not found
    • OBJECT_HOVER_HEIGHT – returned list entry is a float, -1.0 if the avatar is not found.
  • There will be no deployment or restart on the three RC channels on Wednesday, April 22nd.

This means there will be no Main channel roll in week #18, but there should be a new RC update, although this is still being worked on.

SL Viewer

The Avatar Layer Limits RC viewer updated to version 3.7.28.301019 on April 20th. This viewer allows users to wear up to 60 wearable layers (jackets, shirts, tattoo, alpha, etc.) in any combination and any number per layer up to the overall maximum of 60, rather than each individual layer being limited to a maximum of 5 items.

The Tools Update RC viewer has been performing very well since the last update (April 15th), and there has been something of a debate in the Lab as to whether or not to promote it to the de facto release viewer. While there is no hard-and-fast rule about when an RC is promoted to release status, very often the Lab prefers to leave two weeks between releases unless something is urgently required. Sticking to this would mean the viewer won’t be promoted until week #18 (week commencing Monday, 27th April); however we’re still early in the week, and things might change.

Viewer Managed Marketplace Beta

The Viewer-Managed Marketplace (VMM) officially started an open beta test on the main grid, which is scheduled to last for about a month for details see:

Avatar Complexity

Avatar Complexity is the term the Lab has settled upon for the upcoming functionality which provides greater control to user to define how other avatars are rendered in their world-view.

The idea is that as avatars can often be the single biggest impact on the viewer in terms of rendering, particularly in crowded places, so  Avatar Complexity will present a means by which avatars which require a load of render processing by your GPU can be rendered as a solid colour instead, which should help with performance on lower specification systems. Due to their solid colours, avatars rendered in this way have already been dubbed Jelly Babies or Rainbow People.

At the Open-source Developer’s meeting on Monday, April 20th, Oz Linden explained that “Avatar Complexity” has been chosen for the name of the capability to distinguish it from avatar imposter rendering, which will remain in the viewer alongside Avatar Complexity when it arrives. The difference between the two can be summarised as:

  • Avatar impostor rendering is a simplified and less frequent rendering of avatars further away from you, while those close to you remain fully rendered
  • Avatar Complexity renders any avatar exceeding the value set within your viewer as a single, solid colour, regardless of the avatar’s distance from you.
Avatar complexity is intended to help those who may hit performance issues as a result of their GPU struggling to render complex (hight render cost) avatars, by rendering such avatars as solid colours.
Avatar complexity is intended to help those who may hit performance issues as a result of their GPU struggling to render complex (hight render cost) avatars, by rendering such avatars as solid colours.

Oz further indicated that Avatar Complexity will be managed via the Advanced panel in Preferences > Graphics, and will initially be enabled / disabled in the official viewer based on your GPU’s benchmark (the value use to determine the viewer’s default graphics settings when first installed). Some TPVs may opt to leave the capability disabled by default (once the code is available for inclusion in TPVs), and allow users determine whether they wish to use it or not.

Currently, work at the Lab is focusing on a couple of aspects of the functionality:

  • Toning down the colours used by the viewer when rendering avatars in this way – as the functionality can currently be tested via two debug settings within the viewer, there have already been strong criticisms of that “Jelly Baby” rendering on account of the brightness of the colours
  • Server support is being added to pass on the counts of avatars that are and are not rendering to those using Avatar Complexity.

It is also probable that before the capability appears in a project viewer, it will also be set to  display notifications when you change your own complexity, and when the number of avatars not rendering you changes.

If you wish to experiment with the settings are they are at the moment, go to Advanced > Debug Settings and type-in RenderAutoMute. Select RENDERAUTOMUTEFUNCTIONS and set it to 7, then experiment with values under RENDERAUTOMUTERENDERWEIGHTLIMIT (start with 100,000, and increase or decrease it to alter the number of avatars around you rendered as solid colours (lower values = more avatars rendered as colours).