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
Snapshots
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).
Performance
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.”
Opinion
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.
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!
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.
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.
Suggest you ask on the support chat
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.
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.
“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).
Geenz,
Many thanks for dropping by & providing the explanation; I’m a self-confessed non-techie, so it’s appreciated
.
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.
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.