Exodus: updates and the future

The combat-dedicated Exodus Viewer received a series of updates this month, as did the Exodus website. This article outlines the most recent, for releases 11.10.10 (b) through to 11.10.31 (b).

Most of the changes take the form of small tweaks and additions, but which themselves all bring Exodus even closer to matching the capabilities of more established TPVs. These include:

  • MU* poses (i.e. use “:” instead of “/me” for emotes)
  • Out-of-Character (OOC) auto close (so the closing “))” is automatically added when you commence typing with “((“)
  • Option to display emotes from yourself and others in italics on your screen
  • Option to disable Viewer tag detection (Sidebar Preferences tab, under VARIOUS PREFERENCES)
  • Additional chat line commands added:
  • The “rezplat” command has been added to the command line shortcuts, and supports prims up to 64m in size (so “/rezplat 64” will rez a platform 64x64x0.5)
  • Active gestures are now listed in Inventory in terms of their key assignments (where applicable) – such as “XXX Active on F12”
  • The THREAT INDICATORS option (SIDEBAR -> EXODUS PREFERENCES -> INTERFACE SETTINGS) now includes options show / hide Friendly and Hostile indicators
  • The Raid Advisor (ALT-R) now has working import / export buttons which allow the details of raids to be exported (backed-up) either to a file on your computer, or to your Inventory (where they are located in #EXODUS -> #RAID ADVISOR BACKUPS)
    • Raids are exported individually to either a file or an inventory item
    • Exported raids can be deleted if required & restored using the IMPORT button
    • Raids exported to inventory can be passed to friends; double-clicking on a raid stored in Inventory will restore it to the Raid advisor
  • The mini-location bar will be displayed when using Mouselook (and will toggle on/off automatically when entering / leaving Mouselook if the full navigation bar is displayed in third-person view)
  • The “i” icon in the navigation bar / mini-location bar now open the ABOUT LAND floater
  • Display names are now disabled by default
  • Nearby chat window auto-resize feature
  • Edit menu item on worn attachments, to automatically select/edit attachments that are hard to select
  • Exodus now uses a dedicated cache location, rather than the default Second Life location
  • Support for the new Neck attachment point has been added
  •  Syntax highlighting for /* */ style comments added

There are also a number of issues and bugs that have been squished, details of these can be found on the Exodus website itself for each of the releases made this month.

Help Updates

One of the more noticeable additions to Exodus comes in the form of a new Help option – and which harks back to the days when we actually had live, in-world help available to everyone in SL. This is the ability to launch an IRC connection to the Exodus Viewer Support Chatroom. clicking on the link with open a window prompting you for a nickname (your avatar’s name is automatically entered, but you can change this if you wish). Clicking CONNECT opens the support chat:

Exodus Support Chat

The chat applet supplies a warning that support may not be monitoring the channel all the time, so replies may take a few minutes – which is fair enough – but I found enquiries were responded to very rapidly once a question was asked.

The IRC chatroom includes the option of private messaging others who are logged-in: left-click on a name and select the PM option from the menu that appears. Icons are used within the chat window to distinguish support personnel:

  • White spanner on a red circle – Viewer developer
  • White question mark on a blue diamond – Viewer support

This is a major step-up from “traditional” means of in-world support, and is doubly useful given that the chat applet is also embedded in the Exodus website – so if you don’t want you in-world view blocked by the chat floater, you can simply log-into the chat. Considering the issues inherent in using Group chat, etc., this move on the part of Exodus really raises the bar on providing support. There is currently a slight bug in the chat client when displayed in the Viewer, however; pressing “/” or SHIFT-? causes the cursor to re-focus on the local chat in the Viewer, but other than that the integration of the IRC client and the Viewer is very smooth.

Advanced Graphics Presets

Another major change with the latest release is the inclusion of both a presets option and the ability to import / export presets in the Exodus Advanced Graphics option (PREFERENCES -> GRAPHICS -> SPECIAL).

This allows personal presets to be created and saved and easily reloaded. Additionally, the export options allows you to back-up your personal presets to your computer or save them to your inventory. Presets saved to Inventory are stored in #EXODUS -> #ADVANCED GRAPHICS PRESETS and can be shared with others.

Exodus Advanced Graphics presets

Saved presets can be deleted, if required. The IMPORT button will allow you to restore any saved presets saved on your computer, while double-clicking presets in your inventory (either saved there or passed to you by a friend) will automatically restore or load them to your preset list in the Advanced Graphics floater.

In a further move to make the newer graphics options accessible, the Exodus Advanced Settings have been re-written so as not to required deferred rendering being enabled.

Sidebar Preferences Options

Inventory & Script formats (click to enlarge)

The recent releases bring a couple of noticeable new Sidebar Preferences updates. In the initial release of Exodus, inventory and the script editor each used a custom style. Users now have the option of reverting to the “default” SL approach to both: the traditional icons for inventory, and a white background for the script editor.

The options to change the styles can be found in SIDEBAR -> EXODUS PREFERENCES -> INTERFACE SETTINGS and comprise a pair of buttons for each.

With the inventory style, a Viewer restart is required in order for the change to take effect; with the Script options, you need to close and re-open any script windows in use in order for the change to take effect.

PDT or Local Time?

An interesting tweak with Exodus is the ability to display the time in the top right of the Viewer in either SLT (Pacific Daylight Time) or in your local time. This is toggled using a Debug setting, EXODUSPDTCLOCK. When se to TRUE (default), the Viewer will display the time in SLT/PDT; when set to FALSE, your local time will be displayed.

SLT (PDT) or local time display


Snapshot floater issue

Another tweak is the “double resolution” option in the snapshots floater.

I’m unclear as to the advantage in using this option; the image resolution remains constant, as does pixel pitch, although higher resolution images did require more disk space when stored (a 1440 x878 image with the option turned off required 643Kb (PNG format) when stored on my PC, but 727Kb when using the “double resolution” option).

The option is enabled by a check box, although there is a slight layout issue in the current release – display the snapshot floater in its minimal mode, and the “double resolution” check box remains visible (see left).


Not much to report on here; things are pretty much as they were on my usual test PC when I tested the 11.09.28 (2) release I reviewed in September. This puts it as being somewhat faster than Firestorm with the twiddly bits I like (shadows, etc.), enabled, and comfortably matching Firestorm in all other respects.

The Future

There are still some popular Viewer options that are missing from Exodus, and as we know, Linden Lab have recently introduced the FUI – Flexible User Interface – into Viewer 3. In reviewing the latest updates, I took the opportunity to chat with Ash Qin from the team as to some of their plans for the future.

The UI question in particular must have additional thorns for the team – they’ve put considerable effort into making better use of the Sidebar; so I kicked-off by asking Ash if they’d given any thoughts as to how they’ll be handling the new UI and the departure of the Sidebar.

“UI wise, we’re going to adopt the new FUI interface because we don’t believe in creating yet another user interface deviation,” Ash replied. “We’re probably going to go in the direction Linden lab takes with the interface, which isn’t  very clear at the moment because Linden lab don’t really know the direction themselves. Makes it as you said, somewhat of a headache.

“I can’t really say just yet how the preference sidebar is going to be handled, there’s much debate internally on how to approach this.” That said, Ash is also confident the team will be adopting the Viewer 3.2 UI with their next major release.

In my original review of Exodus, I lamented the lack of RLV and the likes of MU* poses and OOC auto-closure. The latter two have been addressed with these updates, so how about RLV making an appearance? Ash was cautious in replying.

“The problem with RLV is that it’s really a lot of work to merge in with every viewer release. It’s one of the reasons why other TPVs take so long to release. As a tiny developer team, we’d probably end up spending more time integrating RLV than anything else in a release – It’s not really in our best interests to do RLV since it would slow down our development of new features. In the future, I couldn’t say yes or no to supporting RLV support. I can say that I don’t believe it will be available in the near future.”

That doesn’t mean that elements of RLV-like functionality will not be appearing in Exodus. “We have instead started working on a API system that has certain functionality from RLV, while introducing our own functionality called eAPI, that shouldn’t be so much work to merge with each release,” Ash informed me. “It’s mostly general functionality that has many uses outside of the kinky scene. Like, telling the viewer to sit on an object or to teleport to a destination, manipulate your graphical gamma settings etc.”

As to other common Viewer features, such as the media filter, Ash was clear on where the focus for Exodus lay. “No specific plans [for the media filter], but probably. Our development process right now is more in line of, what unique features can we work on rather than what existing features can we copy. A bit later down the line when we’ve reached our ‘feature’ target, we’re going to be looking at more common UI and common features.”


Given all that the team has achieved so far, it’s hard to argue their stance on incorporating features and functions. Exodus already has some truly unique features, and offers a unique approach to Viewer functionality and capabilities and which offers some exceptional performance to boot. It’s remarkably stable given it is still in Beta, and Sidebar reliance notwithstanding, I put it as my number 2 V3-style Viewer after Firestorm; truth be told, I like the good use the Viewer puts the Sidebar to  – in some ways it will be a shame to see it go.

That said, and given the creativity put in to Exodus in terms of feature and function access, it’ll be interesting to see what the team come up with vis-a-vis making use of the new FUI and, particularly, the button toolkit.

Definitely one to watch.

Note: Exodus 11.10.31 (b) should be available via the Exodus website on general release later today, Monday October 31st, 2011.

Related Links

10 thoughts on “Exodus: updates and the future

  1. fxaa + HDR = major win. I find myself logging in with this for taking pictures or when I want shadows and deferred rendering on. FXAA combined with the ability to edit and save exposure, offset and gamma settings produces a visual you just cant get from anything else. Kudos to the work being done on this, and hey, without asking for 41K$ for it first. Rock on!


    1. If Ash and the team can put up with more of my innane questions, FXAA + HDR are the possible subject for an upcoming blog post…

      This really is an outstanding Viewer.


      1. While you’re at it could you ask them where their HDR code is. I’ve looked all over their source code and I can’t find any shaders to do tone mapping and they still use an rgba8 framebuffer. In other words it doesn’t look like they’re doing HDR at all, just a simple color correction filter.


  2. But I don’t need support. They claim their viewer does X but after looking over their code it doesn’t appear to me that their viewer is actually doing X.

    If you want to believe every claim they make without trying to verify it go ahead. Who knows, maybe I just missed the HDR stuff, I’m not that familiar with the viewer source code.


    1. The reason I suggest you ask on the support chat is because that is where the Exodus developers hang out (they are the people who have the little spanner icons next to their names). Ergo, that is where you’re likely to get an answer to your question vis-a-vis where the HDR code resides within the Viewer source. As you said, you’re not familiar with the source code, so going straight to those who are strikes me as the most direct way of solving the mystery.


    2. “HDR” as it’s typically called, tends to come in a variety of different formats. But Really, at the end of the day, it all ends up coming out as RGBA8 for the purposes of displaying the data your monitor, even if it’s being stored offscreen in an RGBA16F framebuffer.

      Our HDR implementation is based moreso off of Valve and a few other’s methodology of handling color correction and similar directly in the shader, as shaders work with floating point precision as-is, regardless of what the actual output buffer is.

      Admittedly, the HDR implementation isn’t 100% complete (keep in mind our viewer is in beta afterall!), so it’s still likely to change and evolve as time goes on (such as moving our color correction calculations from a post processing effect, to the actual lighting shaders themselves in the case of deferred, which would increase the quality of FXAA as well). Do also note, that color correction, what’s currently in place for HDR, is just one part of HDR, and things like tone mapping and similar are also typically associated with the term as well. These are things I intend to implement over the course of the beta, as we get closer to something more feature complete.

      We have experimented using RGBA16F render targets internally, but in the end the added memory consumption just proved to not be worth it in the end (as due to various driver quirks, we have to actually make _every_ render target that’s part of our Framebuffer Object RGBA16F to maintain compatibility, even for the targets that don’t actually need it like the UI).


      1. Geenz,

        Many thanks for dropping by & providing the explanation; I’m a self-confessed non-techie, so it’s appreciated :).


  3. I wish i could state more about the combat elements of this viewer, as it was the primary target market for this viewer, but I am unable to do RP and combat while running my business in SL. I can say that a number of people I know who have tried it for combat have raved about it. In one particular instance, two admins that were unable to battle due to the amount of lag they experienced on the older machines they have were, for the first time, able to run and fight with the exodus viewer. They couldn’t believe what a difference it made for them in terms of performance.


    1. That’s where I’m no help…I don’t play computer games, and combat is something I’ve never really tried (OK, I did try one of the Halloween zombie shoots as they were all over the LL blog, but that’s it). I think someone into combat should review the Viewer and provide insight into that side of the capability. All I can say is that while performace was largely the same fps-wise between Exodus and Firestorm on my main machine, Exodus was generally a smoother experience (given both are beta), with no lock-ups, etc. Plus it ran better than just about every V-3 Viewer I’ve tried on my little netbook.


Comments are closed.