Category: V7 Style

Restrained Love, Dolphin 3 and Niran’s updated

Posted on by Inara Pey

This week has seen a number of TPVs updated. Rather than dwell interminably on each of them, here’s a rapid rundown, based on the individual blog entries for the three Viewers.

Restrained Love Viewer

Release 2.8.3 brings with it many bug fixes and:

Added

  • New keyboard shortcuts for builders (they are also added to the Build > Options sub-menu):
    • – Alt+W to edit linked parts
    • – Alt+T to set to stretch textures
    • – Alt+B to set to stretch both sides
    • – Alt+R to set to set grid mode to World
    • – Alt+F to set to set grid mode to Local
    • – Alt+V to set to set grid mode to Reference
    • – Alt+G to set to set current selected object as Reference and set grid mode to Reference
  • Debug setting “RenderMeshDeformed” to switch Qarl’s parametric alpha mesh deformer on and off (it is off by default
  • LL’s patch for the new inventory features (i.e. no accidental nudity)
  • Allow to click in-world while in Mouselook mode, even when your controls are taken, but only while pressing Alt

Fixed

  • Inventory offers were unreadable (the Show button used to overwrite the URL), same for teleport offers
  • Shift+Right-click on an object in world failed to open it
  • In Mouselook mode, we could only click on something or fire with a gun once
  • RLV_50: Fix to the alignment tool in the Build floater is broken (thanks given to Lance Corrimal and Jonathan Yap)
  • RLV_52: another avatar sitting down while in ML resets my camera (with thanks to Lance Corrimal)

Changed

  • Unable to be force TPed when in Busy mode.

Links

Dolphin Viewer

Version 3.2.4.22939 brings with it:

  • The main inventory tab can now show or hide links, or show only links (the recent and worn tabs always hide links). Switch it on via the Inventory gear icon
  • The use of private memory pools has been switched off. If you notice more crashes than before, switch it back on with the Debug setting “MemoryPrivatePoolEnabled” and let Lance know (via a post on the forum)
  • This version of the Dolphin Viewer 3 does not send “LookAt” data anymore, if you switch on “Do not point at objects” (Preferences->Dolphin Viewer 3->Miscellaneous). Lance notes that, “The options to have the LookAt / PointAt crosshairs on-screen will be gone in the next release, unless someone points out good use cases for having them that are not based on drama or paranoia.”
  • The inventory patch recommended by Oz Linden has been implemented – no “accidental nudity” for Dolphin Viewer 3 users
  • Updated to RLV 2.8.2.1
  • When you take a Snapshot to disk using the keyboard shortcut CTRL-SHIFT-D, it uses the file format that you selected for your last “snapshot to disk” from the snapshot floater
  • The check boxes for switching AutoCloseOOC and AllowMUpose are back in Preferences->Dolphin Viewer 3->Miscellaneous
  • The linux version of the Dolphin Viewer 3 now uses dbus calls in the secondlife: handler script to send SLurl to whichever viewer is running at the time. Lance comments, “This is not available on 64-bit Windows, so please vote for VWR-28073 and VWR-28074. Thanks.”
  • The Windows installer should not use the term “Second Life” anymore anywhere in any language. It should read “The Dolphin Viewer 3″
  • Some Windows build issues have been addressed.
  • Fixes:
    • The tips of the handles of the Align tool in the Build toolbox point in the right directions
    • Sharing inventory items with more than one inventory window is open is now working correctly
    • The hovertip on the local chat bar mentions whispering as well
    • Previews of textures show the checkerboard pattern again under transparent areas. Lance notes: “This version still does this with the old deprecated OpenGL calls. The next version of Dolphin Viewer 3 will do it “right”, thanks to Shyotl from Singularity”
    • Fixed: the “Preview As” dropdown in the texture upload preview is not covered by the texture anymore.

Links

Niran’s Viewer

Release 1.12 brings with it:

  • New Build floater
  • Ability to select the use of your right arm when selecting / pointing / building
  • Revised pie menu
  • Ability to see UI when in Mouselook
  •  Shining updates.
Niran’s: UI visible in Mouselook (note ML crosshairs in the centre of the image)

The UI-in-Mouselook is interesting – NiranV mentions it as coming via Dolphin, but I’ve failed to notice it in that Viewer (or any other V3-based TPV) – not that I’m a major user of ML at the best of times and so may well have missed it if it is a debug setting (or I managed to skip the option in Preferences). It’s an interesting addition to direct 1st person use of the Viewer, especially given UI options can be accessed using the Alt key. For those who prefer a more traditional Mouselook view, the UI can currently be hidden using a debug command: AllowUIHidingInML.

As a semi-regular user of Niran’s Viewer, I have to say, I’m not totally convinced with the build floater changes (which need a small amount of tidying-up) on two counts. Firstly, because Niran’s is one of three Viewers I routinely use, and so the layout cuts against the other two – this is admittedly more *my* problem than the Viewer’s.

Secondly – and more importantly – while the “traditional” builder floater is getting increasingly crowded (and one could argue it does need a bit of a re-think), it does have a certain logical flow in the way information is presented – and scanned by the user. This is something that appears to have been lost in this initial presentation within Niran’s Viewer.

Links

Lab fails to align itself

Posted on by Inara Pey

Update 16th January: Charlar has added a comment to the JIRA that clarifies LL’s position on the alignment tool and puts concerns into perspective. The comment further makes it clear that from LL’s position, the opportunity to see the tool included in the official Viewer is far from closed, and Oz indicated in his comment from yesterday.

Update 15th January: The JIRA mentioned below has been re-opened, and Oz has requested any developers willing to take the alignment tool further to contact him directly. This clearly shows that the Lab is aware of feelings on the matter and are trying to meet people half-way, and full kudos to them on this. Qarl (Karl) has declined to update the code, but has stated it’s in the public domain, and others are welcome to do so.

Earlier in the month, Karl Stiefvater (do I still need to introduce him as the creator of the parametric deformer?) submitted an earlier piece of code he’d created – the prim alignment tool – to Linden Lab under a code contribution agreement.

I didn’t cover the contribution at the time, as Tateru had it very well covered. However to recap: Karl, formerly Qarl Linden, now Qarl Fizz, submitted the code to LL by way of a “Thank you” for a generous donation someone made towards the deformer project, as you can read on his website as well as Tateru’s blog (Tateru having steered the donation in the right direction).

The alignment tool does precisely what it says on the box: it aligns prims, as Karl’s own video demonstrates:

No fuss, no bother. It’s not a one-size-fits-all solution that is designed to fit every possible situation where prims (or linksets or objects)  may need to be aligned, and it is not intended to be. However, it does provides a major benefit for builders in dealing with a specific set of issues that can  otherwise be time-consuming to overcome. As such, it has been adopted by a number of TPVs, where it has proven to be highly popular.

But it has been rejected by Linden Lab under the original JIRA raised on it some 2 years ago by Nalates Urriah. As Lance Corrimal (himself the developer of the Dolphin TPV which uses the tool) and Tateru on her blog point out, the reason for the rejection appears to be primarily because the tool doesn’t perform tasks it was not designed to do and is thus “incomplete”.

The rejection notice as posted on the JIRA reads:

Thanks for making this effort. Alignment and snapping are an area where there are useful enhancements to be made.

However, we are not able to accept this contribution as it is.

These are the primary issues we found which resulted in that decision:

  • The feature should support the same modes as the other manipulation modes.
    • It does not work for non-mod permission objects. This functionality should work for all objects that the user can manipulate in-world.
    • It only supports World snap mode, not Reference and Local modes, unlike all our other manipulation modes
  • It packs and aligns to the face of the object bounding box. If objects are not cubes and do not share the same alignment, or aren’t aligned with the world coordinates (see above), the result of the operation is unexpected. Ideally the operations would use the actual shape of the object for aligning and packing.
  • There are also some coding implementation style issues that would need to be addressed. These can be covered in more depth after the functionality is dealt with.

In it’s current form, this is usable for purely prim-based builders under specific circumstances. It’s less useful for building with non-cube prims, mesh, sculpties. It’s minimally useful for building when the structure is not facing a global direction (ex: North, South, East, West). It’s not usable by non-building residents who need to place and organize purchased items.

LL obviously have the right to reject code that they feel is not in their best interests, or in the interests of the Viewer or their users. That’s a given and is fair enough. As such, and being of a generous nature, I have to say that there might be some mileage in some of the reasons given for the rejection (Jonathan Yap actually raises a couple of points within the JIRA). But, and again being fair to all, the rejection equally comes across as little more than nit-picking.

Take, for example, the remark that, “It’s minimally useful for building when the structure is not facing a global direction (ex: North, South, East, West).” On the surface, this might appear reasonable – until one remembers that the same is pretty much true for building as a whole in the Viewer at present – as anyone who has encountered prim drift can ably testify.

Then there is the comment, “There are also some coding implementation style issues that would need to be addressed. These can be covered in more depth after the functionality is dealt with.” This reads as not only nit-picking, but also to be putting the cart before the horse.

If Karl is in fact committing some basic errors in his approach to coding for the official Viewer, surely these should be addressed before embarking on any major functionality changes (were they to be agreed upon), in order to circumvent the risk that such “style issues” don’t lead to yet another rejection down the road?

Some have commented that the entire rejection smacks of a “not invented here” mentality. That may be the case, equally, there may be issues within the code as submitted we’re not privy to and which the note in the JIRA isn’t really helping to make clear. Even so, seeing this rejection I have to confess to being left with an uneasy feeling as to how the deformer tool is to be judged by the wider audience within LL. Time will tell on that, however.

As far as the alignment tool is concerned, I’m with Tateru on the matter and calling “time” on any hope of seeing it incorporated into the official Viewer, for precisely the reasons she states.

With thanks to Tateru Nino

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