When 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.
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 effectsWith deferred rendering active – note the local lights from the ships and the quays reflected in the waterWith deferred rendering active, plus high precision options of gamma correction and tone mappingDeferred 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.
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.
Update 4th January 2012: Due to some issues with gamma correction, etc., the Exodus team have issues Beta 7. Core changes are listed here.
The New Year brings with it a new release of the Exodus Viewer. Version 12.01.02.1 (Exodus run a release number system based on the day/month/year of the release, so in this case the release is the first release made on the 2nd January 2012), also known as Beta 6, brings with it a host of new features. Among them:
New graphics functionality
The parametric deformer Alpha
Mesh upload
New FUI options and improved chat bar
V1-style chat console
Ability to save or load position and rotation information of a object into it’s description (something I’ve been wanting for years – so YAY, EXODUS!)
AZERTY keyboard support
The new V3.2 snapshot floater
A range of options imported from other TPVs
RLV/a
Bug fixes.
Exodus is available in Windows, Mac and Linux flavours – this review is based on the Windows release.
Installation
The installer weighs-in at 28Mb – the same size as the official V3.2.6 Viewer. Installation offered no surprises, with the installed Viewer taking-up around 108Mb of disk space – again, the same as the official 3.2.6 Viewer.
On start-up, the Viewer bucks the recent trend in using all, or part of the V3 log-in/splash screen, and instead opts for a clean design with links to the Grid at War Blog, the Exodus Twitter feed and the SL Grid Status page. I’d personally prefer more from the V3 log-in screen, but that’s purely a personal view.
Cool blue splash screen
Once logged-in the Viewer displays the familiar V3.2 Flexible User Interface (FUI), and as Cilla Black might say, there are a lorra, lorra buttons, particularly on the left side of the screen – which we’ll get to in a moment.
Other than the buttons, the UI offers little in the way of major surprises on first looks, presenting pretty much the standard Menu bar, Navigation / Favourites bars layout. Your region co-ordinates are included in the Navigation Bars – which is not to say things haven’t changed. Unlike recent Viewers using the 3.2 code, the Destination Guide isn’t opened by default in Exodus.
Menus
Popular menu options in yellow
The menus offer some nice nips-and-tucks: those options that are Exodus-specific / rated to combat use / are popular options are coloured yellow, immediately drawing the eye to them. Where these options are toggle on/off, toggling them on will cause both the familiar tick to appear alongside them and the item colour to revert to white, a nice touch to prevent visual distractions with items you don’t want to reset.
There are a couple of nice additional touches in the Advanced menu – double-click teleport is included as an option, and camera constraints are disabled by default.
The Me menu includes an additional option to access Exodus’ dedicated Preferences. In earlier releases, these could be found in a Sidebar panel (Exodus having been released just before Rodvik gave word of the coming new FUI), and are now displayed in a dedicated floater panel, accessed wither through Me or via CTRL-SHIFT-P.
The Build menu has a nice addition: you can select an object or linkset and use the BUILD->SCRIPTS->REMOVE SCRIPTS option to remove all scripts from the object / root prim of the object.
Buttons Galore
Exodus, being feature-rich even before the FUI appeared, has a lot of buttons in order to cater for the wide range of options / dedicated functions it contains. With this release, it becomes the Viewer with the most buttons displayed by default on starting-up. These are:
The Customise Toolbar floater reveals further options, including Exodus’ Mini-radar, Mini-statistics, Statistics, and Visuals buttons.
Button options
This is a very comprehensive set of buttons; however, some might find the similarity between some of the icons – the Map and Raid Advisor or the AO and Move, for example (when only using icons) to be initially a tad confusing, leaving them reliant on tool tips until familiarity kicks-in.
Button Placement and Labels
Exodus draws on Niran’s Viewer, in that buttons can be located to the left, right, bottom and top of the screen, and introduces additional display options (left). The FUI has been critique by people who don’t like icons, it’s been critique be people who like icons; it’s been critiqued by those that don’t like icons and text….
So Exodus now gives you the best of all worlds – display your buttons as icons only; reduce the size of the buttons if you find them too big; display your buttons with text and icons or with text labels only. However, note that with standard V3.2 FUI functionality, buttons placed on the left and right sides of the screen automatically default to icons only (regardless of setting), and so text options are limited to the buttons placed at the top / bottom of the screen.
AO Button
Among the buttons there are a couple worthy of additional mention. The first of these is the AO button. Initial solutions for including the AO in the FUI have been to provide two buttons – one for AO settings, one for turning them on / off. Exodus has a single button, with a smaller integral button in the top right corner. Click the main part of the button to access AO settings, click on the inset button to turn your AO on (inset button turns blue, as per the screen capture here), click it again to turn the AO off. Quite simply the most elegant solution to client-side AO integration into the FUI I’ve yet seen.
Redraw
Exodus does not have a texture refresh option, as is starting to appear in other TPVs, but it does have a Redraw button, which will temporarily drop your draw distance to zero, before resetting it to your default, forcing the Viewer to re-draw everything and re-render all that is in line-of-slight. This can actually be alarming when it first happens, as your in-world view can clear of all detail (see below) for a few seconds before everything re-renders.
Where did everything go? Redrawing your view
If this happens to you, don’t panic, everything will reappear. I can’t say how effective this is for sorting out unloaded / rendered textures, as Exodus has rendered everything so fast for me fast and perfectly.
NiranV has released two further updates to Niran’s Viewer for the New Year.
Version 1.02
Version 1.02 brings with it enhancements to shadow rendering – what NiranV calls multi-level shadowing, which sees alpha objects casting shadows (something I’ve actually recently noticed in V3.2.6 and specifically Milkshake, wherein the decorative glass panels I used a a house build now render shadows…).
The version also incorporates Nicky Dasmijn’s mesh uploader code, making Niran’s the second TPV to adopt her code.There are also a number of bugfixes and tweaks that address minor issues withing the Viewer.
Mesh uploads using Nicky Dasmijn’s code
Another noticable change is with the loading screens – gone is a snapshot of your last in-world view together with the MotD and progress bar. Instead, there’s a mandelbrot-esque design in the lower left corner, images from NiranV’s in-world explorations and assorted hints and tip displayed with the load progress bar. All-in-all a refreshing change.
Niran’s: new loading screens
Version 1.03
An experimental release, version 1.03 brings with it the parametric deformer alpha release, so those who wish to try-out the deformer (particularly clothing designers) can do so. Note that it might not work in all instances; a lot depends on how the mesh is weighted.
Given it is experimental, NiranV informaed me that the code would likely be removed from the next release of the Viewer (which currently does not have a time frame).
The news broke via a Metareality podscast, and follows-on from the previous weeks’ podcast in which Karl Stiefvatar (Qarl Fizz in SL, formerly Qarl Linden) was about to make an Alpha push of the code.
In discussing the release, Karl states, “I should specific immediately that it’s not done; but the heavy lifting part of it is – the tricky 3D math, the place to integrate into the render pipeline,etc, etc, is … So I’ve giving it to you now in this form so that you can give me feedback, because there are decisions that need to be made now that we should make together.”
Karl has released a video demonstrating progress to date, which is available on his website and YouTube:
The video itself is both informative and impressive; demonstrating the deformer working on a standard avatar and on “mesh avatars” human & non-human (so using it, you can now increase the body fat of a mesh avatar if you so wish). Additionally, the deformer works with the Linden-Lab implemented avatar physics as well – again including non-human avatar meshes.
The code does have a couple of additional caveats at present, one of which is that changes applied to an avatar are applied to all meshes attached to the avatar; this is fine where clothing is concerned; but as Karl points out, if you have something like a gun attached to your avatar, you don’t want it to resize as well; so he suggests boolean function may be required to determine which meshes are affected by the deformer – and this may additionally require input from Linden Lab.
Karl openly encourages LL and TPVs to incorporate the code in order to allow users such as clothing designers to experiment with it, as feedback is now the key.
Those wishing to add the code as it stands – and bearing in mind Karl’s warning that this is only an Alpha release can also find it on his website.
A JIRA (SH-1716) has been opened to deal with the deformer code itself, on which a number of baseline questions on the deformer are asked and answered by Karl himself (to reference frame for the project), and within which further questions and feedback is encouraged. Karl specifically asks that you use this JIRA, and not his website for feedback – and as an extension to this, it is suggested that the original parametric deformer JIRA is not used for feedback relating to the code.
SH-1716 already has interesting discussion-points within it, relating to preferred models on which to base the deformer, how to address the question of a boolean function to handle “rigid” attachments (such as the aforementioned gun) – and indeed whether any boolean is in fact required, or whether the matter can be handled via other means. Therefore anyone with a technical interest in the project would do well to give the JIRA a look, bearing in mind Oz’s pleas on the subject of wider discussion (although given the complexity of the subject, one would think that forcing a split in questions & feedback & wider issues could result in something of a fracturing of information on project).
Niran’s Viewer
Those really keen to see the deformer in action might want to download version 1.03 of Niran’s Viewer, which already incorporates the code, but note that NiranV regards this as an experimental release, and the code will likely be removed from the next release.
Milkshake is the new Viewer from Cinder Roxley, who originally provided the Frontier Viewer. Unlike Frontier, which was a V1 TPV, Milkshake is a V3.2-based Viewer, and offers some very interesting options and additions.
Commenting on the switch, Cinder informed me, “[The] Snowstorm codebases allow much more flexibility to a developer. So it’s a lot more fun to hack on than antique snowglobe.”
The Viewer is currently only available for Windows, and this review covers release 3.2.6(2).
Installation
The installer is pretty compact compared to some Viewers: just 26Mb in size (although the latest 3.2. Development Viewer installer is only 28Mb), and the Viewer requires just 99Mb of disk space, once installed.
Logging-in reveals a little of Cinder’s sense of humour: forget the MotD, it’s the by-lines as the Viewer loads and connects to the servers that raise a smile. It’s certainly the first time I’ve been told to buckle my seatbelt when connecting to SL – although there have been times in the past when I’ve metaphorically done so!
Milkshake: raising a smile on logging-in
There’s also a little message related to “dressing your avatar” – is this a slight pause in the log-in process to ensure avatar textures get to download before the in-world view loads? If so, nice touch!
Once running, the UI resembles the standard V3.2 layout; the skin is roughly the same dark tone, but the buttons have a nice green tint to them that makes them look a little less “flat” than those of the official Viewer. The Navigation Bar also includes your location’s co-ordinates by default and incorporates an ABOUT LAND button alongside the HOME button. The menu bar includes an Avatar Offset slider (to adjust your avatar’s position relative to the ground(or prim)) as well as the Draw Distance slider now found in most V3-based TPVs.
Milkshake UI, default appearance
Button-wise, the default load for Milkshake keeps to the V3.2 standard – buttons to the left and bottom of the screen, with only the HOW TO button absent. Most interestingly, the buttons at the bottom of the screen are slightly offset to the right, providing space where the chat bar can be located, for those accustomed to having it V1-like in the lower left side of the screen. It’s still not ideal as the chat bar placement is a little off – but that’s a fault with the V3.2 code, not Milkshake.
Also, if you like to have labels and icons displayed on your buttons and keep all your buttons at the bottom of the screen and have a lot of buttons available, Milkshake will neatly wrap your buttons over two or more lines in the panel without compromising the space “reserved” for the chat bar. This does compromise the chiclet bar, if displayed at the bottom of your screen, but it is a nice touch.
Multiple buttons and the chat bar
Menus
Useful Tools
Milkshake offers a slightly revised Me menu, which includes an additional Useful Tools option. This provides quick access to a range of popular functions and options (right).
The Communicate, World and Build menus are as presented in V3.2, although World includes the option to revert back to Estate Time on the Sun menu, again in keeping with several other TPVs and providing greater convenience to users.
As Milkshake is based on V3.2, it includes the mesh upload option on the Build menu, which works as expected.
Film
Film menu
An interesting addition to the Viewer is the Film menu, which brings together a range of options that should be of assistance to machinima makers. These include avatar and graphics options, so avoiding the need to jump back and forth around Preferences. Changes made to options in this menu are reflected back in their Preferences, where appropriate.
The Advanced menu includes an option to enable RLV for those that use it (on by default); with Help and Develop showing pretty much the same options as V3.2 (with a couple of Admin options absent from Develop).
Buttons, Buttons, Buttons
Milkshake provides, to date, the most comprehensive set of buttons yet found in a V3.2-based TPV. Some of these appear to have been pulled-in from other TPVs, most appear to be Cinder’s own work.
Buttons galore!
Joining the LL-supplied buttons, we have: the AO buttons and Area Search button, which I assume have been pulled across from Dolphin; About Region (shortcut to Region/Estate floater – handy for Estate Managers / Sim owners); Go Home (teleport to your home location – useful if you don’t use the Navigation Bar), Grid Status (opens the Grid status page in your designated browser); Statistics (opens the Statistics floater), and Translate (opens the Google Translate web page in your designated browser).
It’s a good selection, although I wonder at the effectiveness of the Translated button. I can understand why it is included; I’m just not sure people are going to want to either cut & paste back & forth between a browser page and the Viewer, or have the built-in Viewer open on their in-world view when chatting.
Preferences
Milkshake sees some changes to Preferences; some of which are long overdue with various options now “built-in” to the Viewer and “on” by default). These include:
Flight limit disabled – fly high without the need for either a flight assist system or a bridge mechanism
Mu* poses (use “:” instead of “/me” at the start of emotes) on by default
Region / Chat range radar notifications are on by default
LookAt privacy is enabled by default
Elsewhere in Preferences, Cinder has been hard at work with some interesting tweaks and changes.
General
Has been tidied-up to present just the general settings for the Viewer – items that are tag-specific have been moved as have the typing / WASD options, while the option to run multiple copies of the Viewer has been added (good move; this is all too often buried in other Viewers). Somewhat interestingly, the default language option has been removed.
Graphics
Includes the sub-tabs for Hardware, Rendering, DoF, etc., that can be found in other popular TPVs, but includes some rationalisation of options.
Sound and Media
Presents the V3.2 options with the addition of a checkbox to Display Music Information in Chat. The media filter system currently isn’t implemented, but Cinder informed me that it is very much on her to-do list.
Chat
Chat options
The Chat tab includes the following sub-tabs:
General: include the majority of the “standard” V3 chat options, although the bubble chat option has been removed (does anyone use that?), and two “IM Enhancement” options added: the first will display “is typing” alongside their name in the IM window, the second will prevent your Viewer broadcasting the fact that you are typing to any Viewer
Chat Notifications: presents the chat pop-up check box, together with sliders for setting toast duration times and button flashes
Translate: presents the V3.2 translate options
Spell Check: presents the spell check options
Move and View
Has been overhauled to comprise two sub-tabs, as shown below.
Move / View & Display options
Colours and Tags
This tab combines (and extends) the colour options for the Viewer and includes sub-tabs for name tags (from the General tab) and their colours, and client tag colours.
The Custom UI Colours in the General sub-tab are an adjunct to the use of skins, drawn from the Starlight FUI. Rather than just applying a pre-defined skin, options are included which allow you to re-colour elements of the UI as well (see the screen capture below, and note the button / tab text colours compared to other screen captures in this article).
Colour tab: note the UI colour options (top)
The system isn’t perfect – button labels can be coloured, but not button icons; floater panels can be recoloured, but not the menu bar, Navigation & Favourites bars, etc. However, the approach does allow for an additional degree of customisation.
Privacy & Setup
Provide access to the V3 options found under Privacy, Setup and Advanced, and adds a number of TPV options as well (options to select history logs, etc., to be cleared under Privacy, for example).
Milkshake
As with many TPVs, Milkshake has its own Preferences tab. This comprises four sub-tabs, all of which contain some nice touches:
Milkshake Preferences tabs
The general tab includes fields to set the default SAVE location for snapshots and the ability to pre-define the name of each picture you take (the default being the standard “snapshot”). You can also use a series of short code to add further information to the name: %r will add the region name and %p the parcel, for example
Chat includes a range of useful options (multi-line chat bar, dock the chat bar in the Conversations panel (so it is displayed tabbed alongside IM conversations); arrange tabs in the Conversations panel vertically or horizontally; allow IM tabs in the Conversations panel to be rearranged by dragging them; turn the profile icon displayed in IM tabs on/off (will only affect new IM conversations; conversations already open will be unchanged)
Inventory: includes options to set what a double-click on an attachment or wearable in your inventory will do (either ADD it to anything already worn at the same point / layer or REPLACE what is already being worn at the same point / layer) and other goodies
UI: allows you to set where and how various elements are displayed (e.g. chiclet location, whether profiles are displayed as a floater or as a web profile in Viewer’s browser, etc)
More: a range of other options (show muted avatars as a cloud, Mu* poses (for those who would prefer them off), OOC etc.) – together with a warning they may well be moved elsewhere in future releases.
Debug Options
Milkshake includes a range of debug options, all commencing with “Milkshake”, which allow you to toggle a range of features. These include items that are not currently found within Preferences, such as radar notifications (“MilkshakeRadarMessages”). Note that some of these are global actions (so setting MilkshakeRadarMessages to FALSE will disable all radar notifications, for example).
Other Options
Milkshake includes a lot of recent additions to the TPV world, including:
The ability to right-click on an object / avatar and REFRESH TEXTURES
Right-click on LMs in Notecards to teleport directly to them (no need to open the LM in PLACES and use the TELEPORT button)
Mouselook Zoom is included (go to Mouselook, press and hold the right mouse button and use the mouse wheel to zoom in / out on an object / avatar)
The Map includes the ability to “hide” the Legend
Radar is included, as mentioned above, but is range-limited to 512m, and excludes some of what might be regarded as the more “invasive” options – such as the ability to teleport directly to someone within range
Also as mentioned above, LookAt privacy is enabled by default – your LookAt crosshairs will appear to move no further than a metre or two from in front of your avatar when viewed in any Viewer.
The Inventory panel also grabs a few noteworthy revisions from Catznip:
Right-clicking on an item of clothing in Inventory that is to be worn on the same layer as another item of clothing already being worn, will display an additional WEAR ON option in the menu. This allows you to select whether the additional items is to be worn “under” or “over” the existing layer
For example,suppose you have a jumper and a blouse that are both shirt layers – you can wear the blouse, then right-click on the jumper and use WEAR ON to wear the jumper “over” the blouse
Worn clothing items toggle the WEAR button at the bottom of the panel to TAKE OFF
Similarly, worn attachments toggle the ATTACH button (displayed in place of WEAR) to DETACH.
Performance
On my usual test system, Milkshake produced some surprising results compared to other 3.2-based TPVs I’ve run of late – probably a reflection of it appearing to be built on the latest V3.2 development release (3.2.6). When on my own on a sim, I can comfortably hit an average of 50fps; when at home (at 360-ish metres), this climbs to just over 60fps. Even on a sim with several others, frame rates hold at 38-40fps. With shadows enabled this drops to around an average of 22fps – again faster than I’ve achieved with other TPVs of late.
Opinion
I’ve encountered zero crashes in running the Viewer over that past few releases up to this one. In fact, Milkshake is one of the smoothest-running V3 Viewers I’ve used, and is fast on its way to becoming my Viewer of choice.
There are still elements to be refined / added to the Viewer, and a few more bits and bobs I’d like to see. Autocorrect is, I believe, coming (it was in earlier releases, but has been removed from this one, presumably awaiting a small bug I encountered in testing). The media filters are also on the “TBD” listas mentioned, and I assume additional skins are coming, given there is a Skins tab in Preferences. I’d personally like a couple of Quick Prefs buttons / floaters for things like avatar physics & objects LOD, Windlight settings, etc., and for sound settings (a-la Firestorm), but these aren’t showstoppers for me.
I still find the chat bar within the 3.2 UI cumbersome in terms of its look and how well it can be “fitted” into the bottom of the Viewer window. While not a fault with Milkshake per se, it does put me off 3.2-based Viewers, even with the ability to hide the chat bar when not in use, simply because it is so bloody clunky-looking. It comes across as V3.2’s equivalent of the original Sidebar in Viewer 2.
These niggles aside, Milkshake is, as I said, really growing on me – and is potentially the first Viewer to seriously challenge Firestorm as my Viewer of choice. In fact, it’s very possible that another release or two could very well see me swapping over completely….