Category: Viewers

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.

Milkshake ends

Posted on by Inara Pey

milk-1After a promising start, and with some great updates in release 3.2.6.7 (mesh deformer, Firestorm build floater, visuals and other elements from Exodus, etc.), Milkshake’s “public” development has ceased – which is a shame however you look at it.

I was in the middle of a review of the latest updates in 3.2.6.7, which included updates to Preferences as well as the inclusion of new code when word came in.I’d actually been discussing an issue with the release with Cinder when word came that, “Unfortunately, there will be no more public releases of milkshake, sad to say.”

I’m not privy to the exact reasons work has ceased on the public side of Milkshake and to pry into things to any great depth would not be fair on Cinder – she deserves her privacy as much as anyone else. But maintaining a Viewer *is* hard work – there are matters from getting time to develop / merge code options through to handling support and so on, all of which can take their toll. Cinder already has a busy in-world life, and it is clear that support issues were concerning her when the Milkshake User Support Policy was published. One cannot blame her for this; I seriously doubt that – even assuming I had the talent for Viewer coding – I’d want to pass over a large part of my in-world time to all the ancillary elements that go into maintaining a popular Viewer – not without a lot of help.

That said, there is no doubt I will miss the public Milkshake. It was shaping-up to be a handy Viewer with plenty of core features from other TPVs that strongly distinguished it from its core base of LL / Catznip. However, a little birdie tells me that it is not all sad news; the chances are, we may be seeing Cinder’s work adding flavour to Viewers elsewhere in the near future.

A Shining Dolphin 3.2.6

Posted on by Inara Pey

dolphin-logoIt’s getting to be hard work keeping up with Viewer releases!

Lance Corrimal has issued an update to Dolphin – 3.2.3 (22899), which he’s calling (a little tongue-in-cheek) the “Fellowship” edition in that, in quoting Tolkien, the development of this release is a “Tale that grew in the telling”!

Based on the latest release of RLV from Marine Kelley, and the official “Shining” 3.2.6 release from LL, the update brings Dolphin 3 bang up-to-date with the latest OpenGL fixes from the lab.

While conditions were not absolutely identical to my earlier “tests”, I made my usual Viewer UI and settings tweaks, and took the Viewer for a spin on my (now “standard”) “test” sims. The results were as follows:

  • High graphics, no deferred: averaged 46fps at 370m and 38fps at 22m
  • High with deferred ON: 21fps at 370m and 17fps at 22m
  • High with deferred and shadows ON (Sun + Moon + projectors): 12fps at both heights

On my home sim, and on my own, frame rates bounced around the 58-61fps mark while up at the house.

Updates

The core updates to the Viewer comprise:

  • Options to auto-accept / auto-open textures, photos and notecards (both via PREFERENCES->DOLPHIN VIEWER 3->INTERFACE)
  • Empty system folders (e.g. Objects, Notecards, etc) are hidden from your inventory list
  • The additional pop-up informing you that a landmark has been added to a folder can be suppressed (from Firestorm)
  • Firestorm’s inventory filtering options have been implemented in Dolphin, allowing inventory to be filtered by description, UUID, creator, name, etc; or can be filtered by combinations of words separated by “+”(e.g. Joe+Smith) (from Firestorm)
  • Debug level (verbosity) of log files can be configured (STORM-1790)
  • Default debug level has been changed to WARNING to make the logs less chatty

The ability to hide empty system folders is rather novel, and works automatically – once a system folder is empty, it is hidden (see right, and note there is no Landmarks or Notecards folder).

If you end up with an empty Body Parts, Clothing, Gestures, Notecards or Scripts folder, you can “unhide” it by creating a new item from the + button on at the bottom of the inventory panel – creating a new item will automatically un-hide the required system folder.

Similarly, creating a Landmark (or left-clicking on a Landmark in a notecard) will automatically unhide the Landmark folder, and so on.

Those who don’t use the system folders may find this capability useful to have and cuts down on the clutter in their inventory.

Selecting additional inventory search filters

In adopting the new Firestorm inventory filters, Dolphin appears to have adopted the accompanying issue that searching on creator, UUID, etc., isn’t particularly intuitive for the first-timer. To search by a specific additional criteria – UUID, creator, etc., – you must click on the gear button at the bottom of the Inventory panel and select the required option in SEARCH BY before you commence a search. It would be nice to see all the filters grouped into a single location in the future.

Lance notes a few other issues with the Viewer – so again, if you experience them, please don’t report them, as he’s liable to be already trying to sort things out where he can, or awaiting a fix from LL. He lists the known issues as:

  • “Textures with transparency have a grey background instead of the usual checkerboard pattern in any texture preview UI element (e.g. the preview window when you upload a texture, or when you open a texture from your inventory). Applied to prims, the textures will be fine. People, use the temp upload feature and check your new textures on a prim if you need to test something with transparency. This problem exists in all viewers that are based on the latest viewer-development code, even in the official Second Life viewer 3.2.4 from Linden Lab. There is already a JIRA for it: https://jira.secondlife.com/browse/VWR-28037. Please go and watch and vote.
  • “The alignment handles in the Build Tool all point upwards instead of inwards. The alignment tool still works the same way, it just looks funky.
  • “The automatic opening of incoming notecards and pictures is highly dependent on lag.
  • “There is still no Flickr uploader.”

Rendering

This release puts Dolphin back up in the list of “fast fps” Viewers for my system, and rendering on the whole is good, and I’m now getting a similar “pop-out” for sculpts already loaded in local cache (i.e. my furniture at home) on logging-in / teleporting home I get with some of the other recent Viewer releases. Shadows render well, although I’m still taking a bit of an additional performance hit with shadows and occlusion both active.

Overall, a nice set of updates that should please Dolphin regulars.

Related Links

Exodus Beta 7 released to address issues & I take some photos

Posted on by Inara Pey

exodus-4When reviewing the Beta 6 release of Exodus, I missed an issue with Alpha textures. This was reported to the team, who immediately set to work on fixing the problem and taking care of a few other issues. The result is that there is now a new release 12.01.03.1 – Beta 7) available for download.

Specific fixes comprise:

  • Water no longer renders black (white under AMD hardware) under certain circumstances
  • Alpha blended fullbright objects no longer render white under certain circumstances
  • Eyelashe rendering correct so they no longer show as white under certain circumstances
  • Fullbright on rigged meshes now gamma correct in Gamma Correction
  • Fixed alphas on fullbright requiring gamma correction
  • Fixed projected textures not being gamma corrected
  • Fixed rigged meshes not being gamma corrected properly under most circumstances
  • Fixed cases when using forward slash in chat played typing animation.

Further, the team have made the following changes / additions:

  • Changed default inventory icon style to the original icons
  • Modifications in attempt to clean up the preferences window and remove old UI preferences
  • Changed maximum shadow quality to 4.0, as requested
  • Sun/Moon light color is now gamma corrected when gamma correction is enabled
  • Added “refresh texture” feature from Firestorm Viewer
  • Added option to see threat indicators in third person
  • Added more adjustable settings related to glow, ambient occlusion and shadows to the visuals window.

Related Links

Photos

Exodus runs extremely well on my PC, and as there is a new release that fixes a few things, I gave it a quick spin photo-wise at Black Spot. I think you’ll agree, the results are impressive.

Shaders active, no deferred rendering or other effects
With deferred rendering active – note the local lights from the ships and the quays reflected in the water
With deferred rendering active, plus high precision options of gamma correction and tone mapping
Deferred rendering, high precision actrive and vigette set to .870

Beta 7 ran at 38fps on High at Black Spot, dropping to 11 with deferred active; turning on the high precision options did not further impact performance. I’ll attempt to run my “comparison test” on the release tomorrow.

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.