Category: V7 Style

Direct Delivery beta

Posted on by Inara Pey

Direct Delivery (DD) – the mechanism that will replace Magic Boxes for merchants using the SL Marketplace and which should bring improvements to the overall delivery of items purchased on the Marketplace – is in open beta for people to try on the Beta (Aditi) grid.

Direct Delivery has been subject to many ups and down over the last twelve months, but this beta should bring it a step closer to reality. Given LL’s overall track record on the delivery of new Marketplace services, this is something that has merchants understandably nervous and concerned.

Documentation relating to the new system has also been updated, including the release notes and a set of getting started instructions – both of which are worth a read, although the latter are somewhat irritating (see below), and will be rationalised and clarified prior to DD going live.

For those (merchants especially – although it would seem those curious as to how purchasing goods using the new system can also have a bit of a go) wishing to try-out the system:

  • You’ll need to have the Direct Delivery Project Viewer (version 3.2.7.247349/dated 10th Jan or later), complete with its funky blur-tinted UI elements (new to this Project Viewer, or sign of another change coming to the UI?)
  • You’ll need to have an active account on Aditi and should log into that first if you’ve not done so in a while (indeed, you might want to change your password as per the linked instructions & force an account update if you haven’t)
  • You’ll need to be able to log-in to the Aditi Marketplace (this may throw up a security certificate warning, depending upon your web browser settings).

Testing Purchases

For those simply curious as to how they’ll be affected when purchasing goods, it’s very straightforward:

  1. When logged into the Beta Marketplace, simply purchase any item commencing with “DD”.
  2. Open your Inventory panel and click on the RECEIVED ITEMS tab at the bottom of the Inventory panel to expand it – and your purchased items should be in a folder, ready to be moved into the location of your choice in your Inventory.

Note: Items purchased on the Beta grid will only be available in your Beta grid inventory and purchasing them will not impact your Main grid L$ account balance. If your Beta grid account does not have a L$ balance, you can raise a support ticket. Funds cannot be transferred between the Beta and Main grids.

Direct Delivery: from the Marketplace to you (some Marketplace steps omitted) – click to enlarge

Testing Uploads (Merchants)

Items using Direct Delivery no longer need to be boxed-up – part of the idea being that people receiving goods will no longer need to rez a package in-world and unpack it (although if you wish to box items still (and some of the limitations of the system actually mean you may still need to), you can.). Nor do they require a Magic Box; instead they use a new addition to the Viewer – the Merchant Outbox – to upload goods to the Marketplace.

You can organise your items either in your inventory itself, or within the new Merchant Outbox panel (located in the ME menu on the Project Viewer) prior to uploading. Of the two options, the former is probably the preferred, given that anything organised solely in the Merchant Outbox will vanish as soon as it has been uploaded.

The basic steps are:

  1. Open your Inventory and the Merchant Outbox (ME->MERCHANT OUTBOX).
  2. Drag the items from your Inventory panel to the Merchant Outbox panel.
  3. If required, organise items by folders in the Merchant Outbox (individual items dropped into the Merchant Outbox will automatically be placed in their own folders).
  4. Click the SEND TO MARKETPLACE button.
  5. You should get an on-screen confirmation when all items have been sent.
  6. Log into your Marketplace account on ADITI.
  7. When logged into the Marketplace:
    1. Click on My Marketplace (top right) and select MERCHANT HOME.
    2. On the MERCHANT HOME page, click on MANAGE LISTINGS on the left (or click on INVENTORY at the top and then select MANAGE LISTINGS from the drop-down).
    3. Your listings are displayed, with unassociated items at the top.
    4. Use the ACTIONS option to the right of each item to create a new Marketplace listing in the usual way.

Obviously, multiple items can be uploaded via the Merchant Outbox, I’m using a single item purely for demo purposes.

From you to your Marketplace store & ready to be listed: Direct Delivery (click to enlarge)

Irritating

The tests themselves are easy to carry out. What is irritating is the lack of attention paid to the “getting started” instructions. Vis:

  • The instructions wibble on about downloading a Magic Box (this is testing Direct Delivery, right?) – a Magic box isn’t required for a basic test of the DD functions – either when purchasing goods or uploading them
  • They direct you to place the Magic box at one of two locations on the Beta grid  – one of which is – or was during my testing – (wait for it) NO REZ (virtuatrade Campus S).

If mention of Magic Boxes is included for those who wish to carry out more involved testing (such as comparing what happens on uploading, how the system handles  / differentiates items uploaded via either mechanism, etc.), then this should really be made clear in the instructions. Also, and as a minor quibble, why isn’t the Magic Box itself set-up as a DD item? That would kill two birds with one stone (get a Magic Box for more involved testing and test the receipt of DD items in a single pass).

There is also an error in the Selling in the Marketplace instructions which might lead some to get a little confused. These direct people to their MERCHANT HOME page, and then to click on MANAGE INVENTORY, when in actual fact the required link is MANAGE LISTINGS, which is located under the INVENTORY heading.

Feedback

I’m not entirely sure why this level of testing is now required, as it all seems very basic. But then, I wasn’t involved in the closed beta testing and I haven’t been keeping up with discussions on DD via the Merchant’s forum. As it stands – and leaving aside the inevitable amount of work required to shunt stuff from Magic boxes to the DD system, this process seems straightforward and easy to understand for merchants and consumers alike (“getting started” instructions for the Beta notwithstanding).

My tests here are, of course, pretty basic. It’ll be worth keeping an eye on the Merchants’ forum and the Beta thread to see if any major issues come out of the beta process, as well taking a read through the documentation listed below.

Links to Documentation

“Strewth! There’s a bloke down there with no strides on!”

Posted on by Inara Pey

Oz Linden has announced that due to a change to the inventory transfer protocol, a new inventory patch has been issued by LL.

Commenting on the patch, Oz states: ““We’re going to be deploying changes to the inventory backend soon that improve robustness and performance, but in testing those changes we found that existing viewers relied on certain things being strictly ordered.  With the new backend, that assumption does not always hold true.

“Changeset d327dcc8ae51 from viewer-development implements the viewer change needed to avoid race conditions.  It should be straightforward to apply to any viewer, and is safe to release before the changes are deployed (it is compatible with the services as they are now).”

The exact deployment date for the actual change to the inventory transfer protocol is unclear – longer than days, but less than a month. However, TPV developers are being encouraged to implement the patch sooner rather than later.

Commenting on the impact of not implementing the patch, Oz says, “I believe that there is no known risk of inventory loss or damage without the patch, but it is true that some operations can result in accidental nudity, which some users might be unhappy about.”

One side effect of this is that the patch will not be applied to the official 1.23.5 Viewer code by LL, and so that Viewer has been removed from the Viewer download page of the wiki. However, developers supplying Viewers based on the V1 code base will be able to port and apply the patch to their own code.

With thanks to Tateru Nino.

Comparative Viewer frame rates

Posted on by Inara Pey

Last week, Pserendipity Daniels left a comment on comparing Viewer performances which got me thnking. As I said in my reply, coming up with an objective means of comparing the performance of various Viewers is a little difficult, as so much as client-side dependent (hardware) while some is also down to your network connection.

However, I decided to take those Viewers I’ve actively used over the last 12 months (as opposed to reviewed and put to one side), and see what I could come up with by way of a very basic and simple means of comparing Viewer performance that might address Pep’s question without me getting bogged down in anything complex (which would probably go right over my head anyway…).

So, the two tables below represent my findings based on Viewer frame rates – which I appreciate aren’t the only measure of a Viewer’s performance (but they are the one most looked at). There are further notes below the tables on how I set-up and ran my “tests”.

Jan 6th: Tables updated to reflect the fact that Niran’s Viewer has been using the 3.2.6 code base since release 1.01. Also, Nalates Urriah has carried out further analysis on these figures.

370m altitude – click to enlarge

Average ping rate for sim: 167ms (averaged across all eight Viewers)

22m altitude – click to enlarge

Average ping rate for sim: 174ms (averaged across all eight Viewers)

Key

  • “High” = graphics set to the SL “High” setting (Ultra in the case of Phoenix), shaders ON, all Deferred Rendering options for lighting & shadows and ambient occulsion (or equivs) OFF
  • Deferred  = deferred render ON, but ambient occulsion / shadows OFF
  • Ambient = deferred render ON, ambient occulsion ON, shadows OFF
  • Shadows = deferred render ON, ambient occulsion OFF shadows ON
  • Ambient + Shadows = deferred render on, but ambient occulsion / shadows ON
  • Numbers in brackets refer to the official Viewer release I believe each TPV is based upon.

Test Environment

To try and give as level a playing field as possible for the tests, I attempted to create a “test environment”, namely:

  • Tests were run after a completely clean reinstall of the listed Viewers (original installation and all associated files / folders uninstalled / deleted)
  • All Viewers were configured alongside my nVidia Control Panel in accordance with this tutorial from the Shopping Cart Disco blog (with thanks to Innula Zenovka for pointing it out)
  • All other major graphics and network settings within the Viewers were set to the same criteria (e.g. Draw Distance set to 300m; network bandwidth set to 1500kbps, etc.)
  • Where possible (and with the exception of Firestorm and Phoenix) the UI was set-up the same: same buttons, same locations, and not other floaters / panels were open, and any group chat sessions active on logging-in were terminated
  • The same avatar with the same attachments was used with each test (with a Draw Weight of 112,986), with the same camera defaults
  • I used the same regions for all Viewers tested, each with 4 other avatars in the regions during the tests. One region was a skymall shopping area, the other a residential sim at ground level (which actually had the same 4 other avatars present in it for all tests!)
  • The same test was used for each case: Teleport to an arrival point; allow rez time, then walk a set route for around 3 minutes, monitoring fps rates
  • Recorded frame rates are based on a roughly-calculated average, rounded up or down to the nearest whole number, as appropriate.

Hardware and network connection

The hardware used for the tests comprise my usual PC and nework connection:

  • Windows 7 32-bit with SP1; Intel Q6600 CPU 2.4Ghz; 3Gb RAM; ASUS motherboard (no idea of the model); nVidia Ge9800GT with 1Gb on-board RAM (driver: 8.17.12.8562 15-10-2011); Viewers running on 320Gb SATA drive @ 7200rpm
  • Netgear DGN2200 (wireless between PC and router)
  • Internet connection averaging a ping of 43ms to the preferred test server, with a download speed of 9.55Mbps and 1.02Mbps upload (speedtest verified).

Notes

  • I don’t pretend that either the methodology or the results are particularly scientific, and underline that they are at best indicative – and even that’s strongly caveated
  • Frame rates varied somewhat from those recorded in my reviews (obtained using a basic alt avatar & on a variety of sims)
  • On my home sim, when alone, SL 3.2.6, Exodus and Milkshake all exceed 60fps in “High” mode at altitudes above 300m; on the ground all achieve rates in the high 40s
  • Niran’s Viewer has achieved higher rates in Beta then with release 1.03, which Niran notes as being a “test” release. Unfortunately, the 1.02 release will not run on my PC at all, so I’ve been unable to test it
  • SL 3.2.6, Exodus, Milkshake and Niran’s all demonstrate considerably faster sculptie rendering than the other Viewers on my PC (sculpties rarely initially rez as a sphere or disk, but simply “pop-out” fully formed a few seconds after other prims).

Obviously, there are other factors that weigh-in on Viewer choice, and it is actually possible to have a worthwhile in-world experience with what might be regarded as low frame rates (I’ve been running Firestorm with shadows enabled since before Christmas, with an average frame rate probably around 12fps (allowing for averages between locations) for example). In the case of Niran’s Viewer and Exodus, the graphics enhancements may well provide more of an incentive for use than straightforward frame rates. Certainly, the quality of rendering on Niran’s Viewer is signifcantly better when optimised than the majority of other Viewers (although it really hits my GPU hard!).

So, in conclusion, you’re free to interpret these results as you see fit; how much value they represent is questionable. As always, individual experences may vary wildly from my own (particularly those of you fortunate enough to run a higher-specfication CPU / GPU combination). However, as a finger-in-the-air reference point for my own reviews, the tables may have value, and I may maintain them…

Again, to be clear: I’m not claiming the test is designed to be either empirical or scientific – please do not take it as such.

Viewer 3 release: snapshot floater in and installer fixed

Posted on by Inara Pey

Viewer 3 has had a release slipped out. Version 3.2.4.246439, dated December 8th, brings with it the long-awaited (for those not using a recent TPV or either the Beta or Development versions) updated snapshot floater, allowing you to send snapshots directly to your web profiles feed.

I’d actually missed this release, if it did surface around the 8th, which is a little ironic, as I’ve been trying to keep a weather eye on Viewer 3 updates, but admittedly have had my attention elsewhere in the run-up to Christmas and also trying to put a few upcoming blog posts in order as well.

Installer loses Viewer number

Another change that should make Tateru a little happier 🙂 – is that the installer now simply calls the Viewer the “SecondLifeViewer” (on Windows at least, I can’t speak for other O/s versions of the Viewer) and installs into a folder of that name – the version number is now gone. I can’t speak for the issues on disconnects or those of grpahics issues, but I am assuming it has the OpenGL fixes included (which would, I believe, roughly fit the release date).

Sadly, the click-to-walk still results in mouse steering being, as we say in England, arse-backwards.

I’ve not looked too deeply at the release for other updates, but those using it should have been prompted to update if running an older version; although (again with Windows release at least), because of the install location name change, you need to uninstall the prior version yourself afterwards.

Snapshot floater makes it to a release version of the Viewer, complete with profile feed option

 

Kirstens: “And finally…”

Posted on by Inara Pey

The crowdfunder effort to keep Kirsten’s Viewer alive did not reach the required target of £25,000.

Kirstenlee (Lee Quick) posts a sad message today on the subject, confirming that the end of the road has now been reached, saying:

I will no longer have the time ( or inclination ) to develop any more, on January the 1st I start a new job, and will be busy looking after my nearest and dearest.

Given all they are facing, a move back to England, getting into a new home, Dawny’s health and the need for full-time work, one cannot help but extend both Lee and Sylvia (Dawny) love and best wishes.

It’s easy to dwell on what might have been in terms of the crowdfunding effort, and not to feel regret that Kirsten’s Viewer will not longer be under development. However, I’d like to remember some of what Kirsten’s gave us.

It may not have been my primary Viewer, but it was the one I always looked to when I wanted to take really good photos in SL – simply because it was so good, it made anything I took look good.

It was the first Viewer (indeed, the only Viewer for a long time) on which I could experience shadows in SL.

Kirsten’s goes V2

It was the first Viewer to demonstrate what Viewer 2 could have been and that the V2 UI could actually be made into something usable.

It was the first Viewer to give us DoF in a usable degree and the first hybrid TPV to bring us both mesh rendering and mesh uploads.

Kirsten’s and mesh

It remains the most comprehensive viewer made available for photography and machinima.

Kirsten’s goes 3D

It was the first – only, to date – Viewer that dared to go 3D.

To Kirsten and Dawny, and on a personal note, I hope that Second Life continues to bring you both fun, friendship and enjoyment throughout 2012, and I’d like to wish both Lee and Sylvia a happy and bright Christmas and a prosperous and healthy 2012.

Thank you to both of you, and to everyone involved in Kirsten’s Viewer.

Phoenix / Firestorm Q&A, December 17th, 2011- video

Posted on by Inara Pey

On Saturday December 17th, a Phoenix / Firestorm Q&A was held at the Rockcliffe University regions, where Jessica took questions on both Viewers from the audience and which had been posted beforehand either to her directly, or via the Phoenix blog.

Jessica and host Nigma Sterling at the Q & A session

The event, hosted by Nigma Sterling, was recorded for those who could not attend, and the video has now been released on YouTube. The video is some 2hrs 30 mins long, and covers a lot of ground.

This is an honest and open response to the many criticisms the team have faced from their user community, and for those that have concerns about Phoenix and / or Firestorm it is a worthwhile spending time watching it.

I’ve not been privy to much of the situation that is alluded to in the video – the heated discussions regarding Phoenix and the perceptions that the team are somehow “abandoning” their users in “forcing” them into the V3 world through Firestorm – and i’m not about to embroil myself in it.

However, I do emphasise very much with Jessica and the team – indeed with all TPV developers in that they all face a difficult hill to climb, whether they are attempting to stay current and work within the constraints of the new Viewer code base or whether they are trying to work within the constraints of a code base (Viewer 1) that has been effectively frozen by LL for a year now, and which LL have themselves indicated is only going to get more and more broken as time goes on.

It’s a thankless task, however you look at it, and one that is never going to please everyone, be it for genuine technical issues or simply because of people’s unwillingness to take the time to work with a new UI. This being the case, I’m going to take a moment and lift a metaphorical glass of mulled wine to all TPV developers and say “thank you” for all of your efforts over the years.

Sadly, I cannot embed the Phoenix / Firestorm Q&A, as it is locked from doing so. However, you can see it here.