Niran’s Viewer 1.23.5 and more: daring to be experimental

NrianV Dean has been putting in a lot of work on Niran’s Viewer over the past couple of months, with new versions rolling-out fairly regularly. Many of these have experimental functions added to them – so much so that NiranV has taken to jokingly referring to the development work as coming from Niran’s Lab. He’s been keeping me appraised of updates and changed almost daily, but in-world projects and real life concerns of late have meant that I’ve not really been able to take Niran’s Viewer for a proper spin since release 1.13.

Releases 1.24 (Feb 14th) and 1.25 (Feb 15th – gives you some idea of the speed of updates!), have given me cause to play a little bit of catch-up. Release 1.24 was itself essentially a series of fixes and tweaks to the 1.23.5 release (also made on the 14th February), while version 1.25 adds version 0.2 of Qarl’s Parametric Deformer to the Viewer and includes some graphics related tweaks. You can therefore take this review as more-or-less a n outline of the key elements from all three of these releases (1.23.5 through 1.25).

If you’ve previously installed Niran’s Viewer – particularly 1.23.5, it’s probably best that you opt for a completely clean install of either 1.24 or 1.25, although I do comment on a couple of pre-1.23.5 updates as well.

There are two flavours of the Viewer EXE on offer – dedicated 32- and 64-bit variants. As Niran’s is compiled Large Array Aware, I’m not entirely clear on the difference, but I gather the 32-bit version of the EXE was a special request.

On start-up, there are no overt changed to the Viewer’s UI: as is common for Niran’s, the buttons are split between the left and right sides of the screen, the Navigation / Favourites bars are on, and the Destination Guide initially opens by default, as is common for most V3.2-based Viewers.Which is not to say the changes aren’t there.

Navigation Bar: Now You See Me, Now You Don’t

For those that both like to use the Navigation / Favourites Bar but at the same time find it slightly intrusive on their world view, Niran’s now includes a nifty auto-hide function. Enabled through PREFERENCES->VIEWER->UI SETTINGS, this will automatically hide the Navigation / Favourites Bar when the mouse isn’t positioned over it, and replace it with the Mini-location Bar. hovering the mouse at the top of the screen automatically displays the Navigation / Favourites Bar once more. Neat!

“Are you lookin’ (down) at me….?” – Camera Updates

On the subject of views, the Camera options have been altered. NiranV is keen to introduce more game-like elements to the Viewer – we’ve seen it with the experimental “Main Menu” (F1 – of which more below). Now with the camera, he’s replaced the traditional Front view with an overhead view. As a slight aside: does anyone actually use the Front View? I always tend to find myself orbiting the camera around myself.

Looking down on oneself

To me, the initial view is somewhat high, so many using the option are liable to find themselves using the Camera View Angle slider (PREFERENCES->ADVANCED-> CAMERA) to close the distance between themselves and their avatar.

Staying with the Camera and Preferences, 1.24 introduces something I’ve been waiting for in Viewers for a goodly while: the ability to alter camera offsets without the need to twiddle about with Debug options. As many know, I’m a firm convert to Penny Patton’s Camera Offsets for SL (if you haven’t tried them, you should), so it’s great to see a Viewer that includes the ability to change offsets on-the-fly through Preferences. Kudos, NiranV!

Camera offsets within Preferences

Staying with Preferences

Regular Niran’s users will noticed as well that the entire Advanced tab has been revamped in this release, with Camera, Movement and Mouselook options separated into their own button-activated sub-tabs. This also marks a departure from the more usual “sliding panel” approach seen to date within Niran’s Viewer with regards to sub-tabs (and which can still be seen within the Viewer tab, for example. Referring to this re-vamp in his blog, NiranV states the new button approach may be added to the Viewer and Advanced Graphics tabs should it prove popular with users.

Also new to the Viewer (from version 1.22 onwards), and found in the Advanced Graphics tab are control from the new Visual Auto-mute function, complete with colour-codes guides to possible settings.

Visual Auto-mute controls

Avatar Animations

Work has been done around avatar animations with this release. Most notably for those developing animations, release 1.24 of Niran’s provides full support for uploading .ANIM files, as supplied by Jonathan Yap (see STORM-1803). Niran also adds his own touches in the form of options to control how your avatar reacts when being rotated. NiranV has included a couple of videos to demonstrate the functions, and I’ve taken the liberty of embedding one of them here.

Build, People and Rendering

Having just completed a vast amount of work on an obsession of mine, which involved working with some relatively small cross-section prims, I found myself constantly annoyed at the way in which the white stretch anchors repeatedly blocked access to the red, green and blue X, Y, Z stretch points on a prim. NiranV offers a solution to this problem: providing WASD is set to movement (rather than starting chat), you can press and hold the X key to eliminate the white “corner” anchors to ease access to the X, Y ands Z stretch points.

NiranV has also revised the People floater with this release, replacing the FRIENDS tab with an ACQUAINTANCES tab, his argument being most people we have on our lists are more like acquaintances than true friends, and one cannot fault his logic on this in many respects. Also with this release, the Acquaintances List will show the full set of permissions you’ve set for friends (ability to map you, etc.).

Finally, and also coming out of Niran’s Viewer Labs, is a new rendering option that may have potential use in the future. NiranV explains it thus on his blog: “One thing big has been done here except Tofu´s new project which has been merged, it’s called worldspace semi-random macro-dappling, which creates random big darkness spots on a SIM and your Avatar depending on the sun position. Later this could be combined with the cloud X and Y movement to create a good but faked cloud shadow effect!” At present only the depth / darkness of the effect can be altered – but it will be interesting to see where this goes.

The Main Menu

Finally, Niran has been working on his Main Menu idea for the last few releases. I first covered this in my review of release 1.13. Back then I commented on the fact that using ESC to invoke the menu wasn’t perhaps the best choice, given that key is traditionally associated with the Camera. NiranV took this on-board, and the menu has, for the last few releases, been accessed by pressing F1. The style of the menu has also been changed, as shown below.

Main Menu – “compass”

The look is apparently borrowed from a popular video game. I’ll be honest and stay that while I have no idea how well it has gone down with regular Niran’s users, I actually find it jarring and incongruous compared to the rest of the Viewer, factors that tend to make me shy away from using it.

Performance

Niran’s Viewer is intended for high-end machines and continues to get tweaked in that direct and further releases come out. As such, it’s a little unfair of me to comment on performance in some respects, because my hardware is well below the recommended hardware specifications for the Viewer (the closest I get to meeting them is that I’m running a quad-core CPU). My graphics card in particular now struggles mightily with Niran’s if I attempt to use deferred rendering & shadows, a factor that has, sadly, prevented me from using the Viewer quite as much as I might otherwise like.

That said, I’ve put the Viewer to several hours of reasonable use, bouncing around the grid, trying different environments, playing with the settings (as some of the screen caps here will show!) and generally poking and prodding, and the Viewer has taken it all in its stride (albeit without deferred rendering). The changes NiranV is introducing to the Viewer are both novel and leading-edge. There are some that are very practical – for me, the camera offsets in Preferences are a great addition, and those wishing to make use of the Visual Auto-mute option will find the inclusion of both that as a set of sliders and the annotation for settings that goes with it as being of benefit. Other additions – such as the top-down camera view are potentially more specialised, and it’ll be interesting to see how popular these prove to be for a wider audience of user.

Related Links

5 thoughts on “Niran’s Viewer 1.23.5 and more: daring to be experimental

  1. Two interesting things that come to my mind while reading the post:

    1. If you compile with LAA flag (“64-bit”), there is exactly 0 need for a version with LAA flag (“32-bit”). LAA and non-LAA binary files are exactly the same except for a single bit, the LAA flag. Windows versions not being able to take advantage of the additional virtual process memory will simply ignore that flag.

    2. The color marks for the visual muting threshold sliders appear to be just arbitrarily chosen – the same kind of forcing a standard onto the grid as the unspeakable script memory boards. Especially by defining green, yellow and red areas, this has the potential of becoming a drama source.

    Like

    1. Visual mute is somewhat arbitrary – as LL point out. Providing some guidance may / may not be helpful (given a lot will depend on what else is going on at the viewer end of things – such as what else the user is running alongside the Viewer). Personally, I’d opt for some basic guidance more than no guidance – it helps people who wish to use a feature feel a little more comfortable.

      Sadly, drama around the issue of “lag” is a common factor of SL – be it via ARC or it’s more recent incarnation ADW or perhaps even VAM (Visual Auto-mute). I’m not sure much at all can be done about it – although trying to define something that is more intrinsic to the *individual’s* personal experience is more of a step in the right direction compared to the likes of ARC/ADW and the finger-pointing / foot-stomping they have tended to unfortunately lead to.

      As to the two different versions – I’m in agreement (and so, I think it fair to say is NiranV). However, as I understand things, the request for a 32-bit specific build came as a user request (as commented upon in the article), and NiranV *is* very responsive to user requests, even those that apparently seem a little off-the-wall. Given people are routinely slamming LL for “not listening” to users, I’m not about to poke NiranV for doing the reverse when it actually harms no-one.

      Like

      1. The problem are not those “features” or functions itself, but most often those users with the least knowledge on the topic use them as if they are the holy grail. As long as LL does not provide some reference information about the values, providing arbitrary, especially non-officially provided ranges is IMHO dangerous as it gives peoples the apparent reason to harass other users. This has been the case with ARC already, ARW and script memory already – latter even increased by the unspeakable fact that Mono scripts always report as 64kb even if they most often use less than the 16kb LSL2 scripts always use and people don’t have a clue about that. Don’t understand me wrong, I don’t care if somebody adds sliders for those values, but defining green/yellow/red ranges out of the blue is a really bad idea.

        Like

        1. The problem with ARC/ADW has always been the fact it flags a figure that anyone can see when the feature is enabled. So if you have a figure of 124,500 – that’s what everyone enabling ADW around you will see – and that encourages people to to form cliques and start shouting / picking on you as a result.

          So far as I’ve seen, VAM is much more hardware-dependent – ergo, what *I* see on enabling the feature is not necessarily what *you* see by way of what can be displayed above avatars. This would seem to make outright finger-pointing difficult. Given that LL *don’t* (so far) provide more detailed information on suitable settings for the function, I don’t have an issue with TPV devs doing so. Sure, the colours could be a little more neutral – but some guidance is better than no guidance at all.

          That said, the sad fact is that there are times where drama will be had in SL, guidelines from LL or otherwise. Time will tell if VAM falls the same way regardless of who provides the guidelines…

          Like

  2. those values are like Inara said , simple guidance values , i run through a few SIMs and took average values of Avatars , i checked them visually , compared them to each other , looked at the ARC and both Attachment Bytes and Surface Area , compared it to my Avatars (cycled through a few) and came to the conclusion that those set values would have been a good start , but soon i will raise them 10k will go up to 15k and 6 up to 8 aswell as 2 will go up to 4 as it seems a bit more forgivable , but again you cannot only go after those values , as Avatars can have lots of both and still eat up visually no performance depening on if they are made with Mesh , Sculpts and/or Prims and what they use (Glow , Alpha etc)

    Like

Comments are closed.