Category: Viewers

Exodus Viewer: dedicated combat Viewer with mesh

Posted on by Inara Pey

Update January 2nd, 2012: A new Beta of Exodus has been released, and I have an overview available. As such, comments on this page are closed. Please feel free to read, but comments are best related to the latest release, and posted on that page.

A new Second Life Viewer has been launched with an emphasis on in-world combat gaming and which includes mesh rendering capabilities.

Exodus has been developed by Clix Diesel, Genz Kitten and Ash Qin – all of whom are combat veterans in Second Life, and involved in ARK, a cyberpunk-oriented combat environment. As such, a lot of emphasis has been placed on the Viewer’s performance – something that is vital to the gaming world in Second Life.

The Viewer is currently classified as a Public Beta, so if you give it a try, remember that it may not be entirely stable, and your experience may differ from mine.

Installation and First Looks

Exodus is based on Viewer 3, and is available for Windows (32-bit and 64-bit versions), Mac and Linux. The installer will be familiar to anyone who has installed a Viewer, and offers not surprises. System folders are created and a shortcut added to the desktop a-la most Viewers.

Starting the Viewer displays 3.x-style login screen, complete with BASIC and ADVANCED modes (defaulted to ADVANCED). The Viewer doesn’t include the new Viewer 3.x log-in display for the Main grid, with its Destination Guide options etc; instead, the splash screen is a black background upon which is displayed the Viewer’s stylish logo and recent update notes.

On logging-in, the Viewer presents a Viewer 3.x look and feel with a few subtle differences.

Exodus UI

The Sidebar includes two tabs dedicated to Exodus, one of which replaces the HOME tab, and has a stylised E as the tab logo. This provides access to the latest news from the Exodus team and displays the current Version number (in my case, 11.09.28.2), and a link to the Exodus blog. The second tab, bearing a familiar gears icon, provides access to the Exodus Preferences, of which more anon.

The toolbar button at the bottom of the UI has, by default: the Voice button, a client-side AO ported from Firestorm, a gears button providing access to a number of Quick Preferences somewhat similar to the Quick Preference found in Firestorm; and the familiar Gestures, Move, View, Snapshot and Search buttons. Unlike other V3 TPVs, Exodus has the Navigation Bar turned off by default, together with the Favourites Bar, and opts to use the Mini-location bar. The Advanced menu is displayed by default, as is the option to run multiple copies of the Viewer; and there are some dedicated menu options (see below).

Preferences

The main Preferences floater (Me -> Preferences) offers few differences to the standard V3 Viewer – although it does include Kitty Barnett’s Spell Checker, first seen (for V3.x) in Catzip.

There is a further interesting – and experimental – addition to the Graphics tab. Where, alongside the HARDWARE and ADVANCED buttons, there is a SPECIAL button. This will display the High Dynamic Range (HDR) settings (currently called the Advanced Graphics Settings in the actual floater). HDR should be of benefit to machinima makers and photographers, as it allows for enhanced colour correction, etc. As Geenz explains in the blog post on the subject:

“HDR stands for ‘High Dynamic Range’. HDR doesn’t necessarily increase rendering quality on its own (after all, HDR is only adds a higher dynamic color range for us to do nifty things with later on), but it does allow us to add different effects into the render pipeline like, color correction, gamma correction, and scene brightness that’s completely independent from the rest of the environment.”

HDR Options

A further enhancement to the Viewer that is not so obvious (given it is automatically activated), is the FXAA, or “Fast approXimate Anti-Aliasing” function. This provides an alternative to the “standard” anti-aliasing process used with deferred rendering, and it is intended to make the process a lot faster and should present smoother results. FXAA is apparently a feature that Linden Lab are developing for the official Viewer, but the Exodus team have implemented it through their own efforts.

You can read about both FXAA and HDR in Geenz’s blog entry.

Combat players may also like the fact that Exodus has the Mouselook zoom functionality included, making target sniping, etc., a lot easier. The function works identically to v1.x viewers that include it: enter Mouselook, press and hold the right mouse button and use the mouse scroll wheel to zoom in / out (with the wheel depressed).

Sidebar Preferences

exodus-2The Sidebar preferences can be accessed by clicking on the tab with the gears icon, or by clicking on the >> tab. This comprises a number of drop-down lists (see right) which provide access to a range of settings, some of which will be familiar to users of the likes of Phoenix and Firestorm, others of which are quite unique.

By default, the tab tends to open with the Chat Command Settings displayed by default (although on my version, the tab would sometimes switch between this and opening with all the drop-down lists closed).

The Chat Commands provides a breakdown of the chat command shortcut (“/dd” for setting draw distance, for example), defaults, together with an explanation of each shortcut – which can be set to any personal preferences.

After this, things get rather interesting. The next tab is Interface Settings. This reproduces a number of options commonly found in combat HUD systems. Given the intended use of the Viewer, this is a very good idea, and like the built-in AO, helps move functions from a reliance on server-side code execution directly to the Viewer.

Settings are available to customise your crosshairs, rangefinder and threat indicators. I confess, I’m no combat specialist (I’ve only ever visited one combat sim to my knowledge – and that was on Avination), but these look to be the kind of options combat players will find useful.

Coupled with this are the Minimap Settings, which provide a range of customisable options for tailoring the mini-map to suit your specific combat requirements (such as making it easier to identify friends and foes).

The remaining drop-downs provide access to specific Viewer functions, bringing them together under logical groupings: rendering teleport and sound settings (reproducing those options found in Preferences -> Sound & Media, and additional chat and display options that otherwise tend to be spread around a number of different tabs in Preferences.

Continue reading “Exodus Viewer: dedicated combat Viewer with mesh” →

Firestorm: updates ahead

Posted on by Inara Pey

The next update to Firestorm is still a little way off, in part due to the fact that the team is currently awaiting various fixes to known issues to filter through from Linden Lab.

In the meantime, the team are hard at work and, as well as fixing various Firestorm specific bugs and incorporating features that didn’t make it into the mesh beta release, are focused on addressing adoption issues – those things people have indicated are effectively show-stoppers where their adoption of Firestorm is concerned.

Missing in the mesh beta

While no date has been set for the next release (see comment re: Linden Lab fixes, above), here’s a summary of what to expect by why of Things to Come:

  • The Firestorm betas (both mesh and otherwise) currently tend to reset any Windlight settings following a relog or teleport, but a fix will be in the next release
  • The Contacts List (not the new Contact Sets feature) displaying both user name and display name in separate columns (something I reported on myself) in the mesh beta is in fact a bug, and will be corrected in the next release
  • The WORLD button for the ruler was removed from the Build floater during the beta mesh merge with LL’s code. This has proven unpopular among builders and the button (right) will be returned to the Build floater in the next release
  • The spell check feature, delayed from the mesh beta release, will be in the next release
Spell Check  coming to Firestorm (Phoenix shown)
  • Further updates to the AO should be available with the next release
  • Web Profiles: with the increased functionality in Web Profiles, Firestorm will include an Preferences option (under the FIRESTORM -> GENERAL tab):
    • The option will be off by default for the V1 (“Phoenix”) mode of the Viewer
    • The option will be on by default for the V2 / V3 modes of the Viewer
    • Personal note: I assume this refers to displaying ones own Web Profile, given Firestorm already includes a link to other people’s Web Profiles as a part of the in-world Profile display
  • The inventory “jump” issue – whereby the cursor bar jumps within the inventory window (usually to the top) on receipt of a notification, etc., is being investigated but may not be completed in time for the next release
  • Mesh uploads: work is progressing on enabling mesh uploads in Firestorm. The code is the work of Nicky Dasmijn, who has contributed code to the Firestorm project over time, and the uploader will be available for other TPVs as well. Some additional points:
    • The upload most likely won’t be in the next release. It is still a work-in-progress
    • Even with mesh rendering coming to Phoenix, Jessica is not committing as to whether or not the upload will be ported to Phoenix.

The adoption issues the team are specifically addressing for the next release are:

  • Mouselook zoom will be incorporated into Firestorm (go to Mouselook, press & hold right mouse button and zoom in/out with mouse wheel) – this will be especially useful for those involved in combat games in SL
  • Text search in Notecards will be included
  • For the V1 (“Phoenix”) mode of the Viewer, the team are trying to get all dialogue boxes to display in the top right corner of the Viewer window by default. This includes Group notices and anything else that in a V1.x Viewer would appear in the upper right corner of the screen
  • A longer term aim is to possibly have the V1 (“Phoenix”) mode of the Viewer display a more Phoenix-like top menu when selected. This is not a high priority for the time being, and isn’t strictly seen as an adoption issue.

Again, no release date is available for the next update to Firestorm, as so much depends on Linden Lab providing fixes to known issues at their end. Also, not all of the above will be in the next immediate release, as per the notes.

Related Links

Frontier Viewer: Singularity with mesh rendering

Posted on by Inara Pey

Update 30th December: Work on Frontier has been abandoned in favour of Milkshake, which I’ve reviewed here. Because of this, download links for Frontier have been removed from this piece.

Frontier is another Viewer 1.x TPV that incorporates mesh object rendering. Based on the popular Singularity Viewer code base (itself a branch of the (now defunct?) Ascent Viewer), and is managed by Cinder Roxley. The Viewer isn’t currently self-certified against Linden Lab’s Third-party Viewer Policy, although I understand the paperwork is in-hand.

So what is it like?

Installation and First Looks

Installation is standalone – no requirement for Snowglobe to be installed first – as with most Viewer 1.x TPVs. The installer I used had a slight problem in that a .dll file from Microsoft Visual C++ Redistributable Set-up was missing, which caused the Viewer to fail on start-up.This has been reported to Cinder, who will be updating the installer. In the meantime, those wishing to use the Viewer right away can download the Redistributable Package direct from Microsoft. Once installed, it’ll resolve the issue.

On start-up, Frontier displays the familiar black / dark slate look of Singularity, complete with the pop-up that the Advanced menu is active by default – no need for CTRL-ALT-D.

Preferences-wise, Frontier offer the same options and presets as Singularity – including RLVa being on by default. Other features familiar to, and popular with TPV users include:

Singularity / Frontier: familiar options
  • The official multi-attach for prim, etc., attachments
  • Alpha and tattoo layer support
  • A built-in AO option, following the Phoenix approach
  • A Quick Preference pop-up for draw distance, bandwidth, max avatars, environment settings, etc., again a-la Phoenix
  • Vertical tabs display for IMs a the chat window in the COMMUNICATE floater – the vertical tabs are on by default, unlike most other 1.x TPVs
  • Phoenix Command Line shortcuts (e.d. “dd” to set the required draw distance, etc.)
  • Radar
  • Object area search
  • Display Name support
  • Asset blacklist
  • Media Filter (Preferences -> AUDIO & VIDEO -> ASK FOR PERMISSION to enable, View Menu to access Media Filter lists)
  • Spell checker – with a full range of languages – found under the ADV. CHAT tab of Preferences, and (a little confusingly) called TEXT OPTIONS
A popular TPV tool: the Spell Checker
  • Security options (turn off SHOW LOOKAT, etc.)
  • etc.

A rather interesting element in both Singularity and Frontier is the support of both the worn layer of Avatar Physics and the legacy “Phoenix” Avatar Physics. This may be due to the fact that using the “official” Avatar Physics results in a large yellow system message being displayed warning about possible compatibility issues.

The UI presentation for Singularity / Frontier is very neat, and has something of the Viewer 2.x look to it with the black / slate approach. A lot of the buttons and drop-down list have a nice 3D effect, which is aesthetically engaging. As an alternative, the legacy SL blue skin can be selected via Preferences -> SKINS, and requires the usual Viewer re-start.

When it comes to clothing, Singularity and Frontier suffer the same problem as all V1.x TPVs: only one item of each layer of clothing can be worn at any one time (one shirt layer, one pants layer, one tattoo layer, etc). I have to admit, after using V2.x TPVs, I find this one of the biggest drawbacks of 1.x TPVs, particularly when it comes to wearing multiple alpha layers.

Shadow Rendering

Shadow rendering is the “experimental” option familiar to most V1.x TPVs, and I did encounter a couple of issues with it enabled on Frontier.

Shadows 1: rendered  at midday on Singularity

While Singularity provided crisp, clear shadows with the options enabled – shadows actually rendered a lot better than I’ve experienced with Phoenix on the same PC – Frontier had problems. Shadows failed to render as well as with Singularity, and no matter what time of day was set, the viewer would render with a mist-like greying effect (see images above and blow for comparisons).

Shadows 2: Same location, same time of day, rendered on Frontier

I checked this against Astra 1.5.10 as well, also forked from Singularity, and didn’t encounter the same issue.

Mesh Rendering

Mesh rendering: crisp

Frontier appears to use the same code as Astra experimental 1.5.10 (2) release for mesh rendering, using the same prim / count measure found in the Astra experimental.  Frontier had no problem rendering mesh objects individually or in multiples, and handled me bouncing across a mesh sandbox on the Beta grid without any issues or problems. Indeed, when visiting locations on the Main grid where mesh has been mixed with sculpts and prims (such as is the case with Mesh Mellows), I found the mesh elements rendering a good deal faster than their sculpt / prim cousins, a trend I found with Astra 1.5.10 (2) experimental, but not so much with Firestorm or the official Viewer.

I particularly like the approach to the prim / PE count taken with the Astra experimental / Frontier Viewer. It is concise and goes a small way to avoiding issues around prim count and prim equivalency (while they remain so), although having two numbers relating to objects will most likely still cause confusion for some unaware of mesh objects and their impact.

There is no upload option for mesh objects, unsurprisingly, given the usual reasons. However, as with other TPVs, this isn’t a major drawback at the moment – most people are more interested in seeing mesh objects than they potentially are in uploading them.

Performance

Frontier performed well on my usual PC (Intel quad-core Q6600 2.4Ghz, 3Gb memory, nVidia GE9800 GT with 1Gb memory). On a sim on my own it averaged around 28-30fps, and would drop to around 15-18fps with up to five avatars on-sim.

Enabling shadow rendering tended to (unsurprisingly) cause a performance drop to around 8-9fps – but this was still somewhat better than some V2.x TPVs (albeit they use the “official” code for shadows), and when on my own on a sim, the lag was more than manageable.

A rather interesting element with Frontier is that with Viewer reporting enabled on avatar tags, it displayed both to itself and other Viewers as “Milkshake”, rather than “Frontier” (or even “Singularity”). An earlier working title for the Viewer, perhaps?

Frontier and Other Grids

Frontier works well with other grids, having the familiar V1.x Grid Manager. I used it to pay a visit to InWorldz, and encountered no major issues in terms of moving around, teleporting, etc. Frame rates were significantly down over the likes of Imprudence and the InWorldz Viewer, however. I averaged 12-16fps for Frontier (and Singularity), as opposed to around 26-28fps for both the Imprudence 1.4 experimental and the InWorldz Viewers. I also encountered a crash issue repeatedly on logging-out – something I’ve experienced when trying Phoenix elsewhere as well.

Opinion

Frontier incorporates minimal changes to the look and feel of Singularity, and as such, is a good, solid performer offering all that Singularity has to offer together with the added benefit of mesh object rendering. It’s hard to say whether the release incorporates and additional bug fixes from the last major release of Singularity itself (July 2011), as there are currently no detailed accompanying notes.

Catznip goes mesh

Posted on by Inara Pey

catznip logoThe Catznip Viewer has been extensively updated in a new 2.8 release (2.8.0 (3)). Not only have the RLV capabilities been updated and a host of new features added and others enhanced, Catznip becomes the latest SL Viewer to support mesh object rendering.

Installation and Start-up

Like all Viewer 2.x /3.x Viewers, Catznip installs direct from the box as a standalone Viewer, and offers no changes or surprises along the way.

On start-up, Catzip joins Dolphin 3 in becoming one of the first Viewer 2.x/3.x TPVs to display the new SL log-in screen with the Destination Guide, etc., options. It’s good to see this option gaining wider traction – and it would be a joy to see it in Firestorm. Departing from the official Viewers, but in keeping with Viewer 2.x TPVs, Catznip dispenses with the Basic mode and keeps both feet firmly planted in the Advanced mode.

Once logged it, the UI looks very similar to that of Viewer 2.x/3.x with a modified toolbar.

Catznip toolbar (top) and the current Viewer 3.x toolbar

Interestingly, there in no Speak button by default on the Catznip toolbar – because Voice is off by default. However, the toolbar does include an inventory button which, as with Dolphin 3, opens an inventory window floater independent of the Sidebar (which can also be open at the same time).

Another nice touch with Catznip is that media is turned off by default on logging-in – a wise move given there is, unfortunately, no media filter.

Given its heritage, Catznip also has the RLVa menu displayed in the menu bar by default, although as with most RLV-capable Viewers, RLV  itself – updated to 2.7 – is disabled on such time as it is turned on through Preferences.

A full list of updates is available from the Catznip website (see the note at the end of this piece on Catznip 2.6), but here are the most visible / user-related changes / differences to the official Viewer.

Preferences

Within Preferences, Catznip has everything common to the official Viewer, plus a few little tidbits and nips and tucks of its own:

  • General Tab: The SHOW MY FAVORITE LANDMARKS AT LOGIN option is moved from the Privacy tab to the General tab, just under the START LOCATION drop-down
  • Privacy tab: adds options to select whether you wish to clear one or more of the following: web cookies, teleport history, Search history and / or Navigation Bar history before you click on CLEAR HISTORY
  • Spell Check: allows you to enable the spell checker (words incorrectly spelt underscored in red, right-click to select options for correction / adding to dictionary). Language can be set to one of four options: British-English; Canadian-English, Australian-English and US-English
  • Skins tab: provides Starlight and Stardust skin options in a choice of colours
  •  Crash reports tab: allows you to select whether or not crash reports should be sent to catznip.com, and the information the reports should contain
Crash report options
  • Catznip tab:
    • General: allows you to: use legacy multi-attach support (i.e. non-Linden “Emerald” system for multiple attachments); activate RLV support; adjust avatar offset; toggle object inspector on / off; toggle full screen windowed mode on / off
    • Chat: set your chat / IM preferences. An interesting item here is to enable a multi-line chat input option to the Nearby Chat floater
Multi-line chat input option
  • Inventory: allows you to: select the format preference for saving scripts (LSL or Mono); direct inventory you decline directly to trash; set notecard / texture options
  • UI: allows you to: display Group information either in the Sidebar or as a window floater; display an avatar’s Profile as a window floater or their Web profile (an additional nice touch is Web Profiles open on the ABOUT tab, rather than the person’s FEED tab – far more relevant); change the way in which script dialogues are displayed in the bottom tray; alter your My Outfits tab display between “Inventory” and “accordion” displays.

Continue reading “Catznip goes mesh” →

Kirsten’s Viewer: Jabba speaks

Posted on by Inara Pey

Jabba Aabye has posted over at Kirsten’s Viewer blog, on behalf of the entire team. The message is one of hope and thanks for all the support offered over the last few weeks.

On the Viewer in particular he states:

A lot of people have stepped forward to help, contribute and/or volunteer in a future plan for the Kirstensviewer-project. And not only the project, also for all the hard work that has been already done. But there might be some light on the horizon. Tho it is not official yet, there is some hope growing it will work out and benefit all of us. Details will come out in the coming weeks. Keep this website close to your mousepointer…

This is very encouraging feedback / news. Hopefully the team can find a way to keep the Viewer going and moving forward, especially after all the hard work they have put into things.

You can read Jabba’s post in full here. To him and the team as a whole, I’d again like to pass on my thanks for all of their efforts over the years. To KL and Dawny especially, I offer every best wish for now and the future.

Mesh, Phoenix and the future

Posted on by Inara Pey

Jessica Lyon has issued a statement on the Phoenix website concerning the future of the Viewer. It makes interesting and clear reading.

On Mesh

A release of Phoenix will be forthcoming that can render mesh objects in-world. Jessica makes it absolutely clear that credit for this largely goes to Henri Beauchamp and his work in backporting the Viewer 2.x/3.x rendering code into Cool Viewer. She also makes it clear that the Phoenix implementation pretty much is Henri’s code as is. In the post, Jessica states:

“I don’t want you all thinking we’ve changed our focus back on phoenix, truth is we haven’t. Ansariel handled all the work of pulling Henri’s work into phoenix, LGG has helped. Aside from Tonya and Tech fixing some of the bugs.. That’s it.. essentially we’ve only had two developers working on this, and there are no plans to increase development on phoenix beyond that. However, mesh in phoenix will accomplish two things. It will complete [the] adoption of mesh in SL, which is pretty cool actually. But equally important, it will also fulfill our promise to keep phoenix going until it’s dying day.”

She also gives a stark warning on Phoenix with mesh rendering:

“Speaking of QA, don’t expect phoenix to be just like the last release only now it has mesh support. This work effectively makes Phoenix a Ford Pinto with a diesel engine from a school bus duct taped into it. Not only will it have all the existing mesh related bugs, but it will have plenty of its own bugs specific to having a diesel engine in a Ford Pinto. It will have a negative effect on crash rates no doubt, will be a performance drop for some, an increase for others. It will not be perfect, as it is not designed to support mesh.”

On RLVa

Jessica has also indicated that the next Phoenix release will have an update to RLVa as a result of Kitty Barnett’s hard work as well. Details aren’t clear, but one assumes this will bring it into line with the updated RLVa seen in Firestom.

On the Future

Jessica is unequivocal as to the future however: Viewer 1.x is, in her opinion, on its deathbed where SL is concerned, and as such, trying to maintain the Phoenix code on a par with Viewer 3 is going to be too much of a headache. As she points out:

“Consider this.. it took over 9 months to get mesh to work in a v1 viewer.. it took us just over 2 weeks to merge mesh into Firestorm once we started the merge. This will be the pattern with all new things LL releases, making it work in Firestorm or a v2 based viewer will be far easier to adopt faster than making it work on a v1. Maintaining v1 long-term is just not being realistic.”

No date is given for a release of Phoenix with mesh rendering capabilities, other than it will be released once it has passed QA.

The release is also liable to mark the end of the road for Phoenix where non-SSE2 capable computers are concerned. The release for such machines will not include mesh rendering support.

Overall, this news is liable to be met with approval from Phoenix users not yet ready to make the jump to Firestorm and might, conceivably ease some of the pressure on the Firestorm team to get some of the current bugs and issues with the latest Beta release ironed out.

And on the subject of Firestorm, Jessica did offer a small tease: “Mesh upload capability is also under development and making some promising advancements thanks to Nicky Dasmijn.”

Read the full blog post.