Increasing your Zen: Viewer updated

Update January 27th, 2013: The Zen viewer has been discontinued by its creator.

Zena Juran released a new version of the Zen Viewer over the weekend – something I almost missed due to being busy with other things in-world (of which I’ll say more another time). As mentioned in my original review earlier in the month, Zen is aimed at bringing an enhanced build experience to the V3.2 environment.

Currently still only available for windows, this new release ( remains based on LL 3.2.8 Development / Project Viewer code, but sees some major changes and additions in terms of the TPV code that has been merged.

Installation and Start-up

The EXE retains more-or-less the same size as the release, and the Viewer installs the same, complete with dedicated user folders and cache locations (rather than using the SL defaults).

Logging-in reveals little in the way of changes between and earlier releases – other than the fact that the UI buttons are no longer transparent (more on this in a moment), the layout is the same as and prior releases. However, open up Preferences, and the updates immediately make themselves apparent.

New Preferences Tabs

In my original review, I commented that Preferences were little-changed from V3.2, but Zena would be adding to the list of capabilities over time. Well, she has – and massively so! At the same time she’s also re-arranged things somewhat.

Expanded Preferences

Release sees one tab in Preferences removed (LSL Pre-processing), and five new tabs added, together with an overall re-ordering of things which may initially catch used to operating by wrote a little off-guard (Graphics, for example has gone from near the top of the tab list to fairly well down the order of things). This shouldn’t interfere with overall usability, however.

The five new tabs are (in the order displayed:

  • Name Tags: Pulls together the V3.2 (usually found in the General tab) and popular TPV options relating to name tags (setting colours, etc.) together into a single tab
  • Shadows: pulls-in the shadow options popular among TPVs, and which can be found in a variety of locations (a sub-tab under graphics, for example)
  • Camera: pulls-together “standard” options such as view angle & distance (from MOVE & VIEW),  disabling camera constraints (from the Advanced menu), depth of field on/off (duplicated from Graphics), and camera / DoF sliders again found in other TPVs
  • Build: presents  the Build enhancement tools first seen in the likes of Emerald / Phoenix, and now widely used in TPVs

Visual Auto-Mute

This is perhaps the most interesting change within Zen (and potentially the most drama-risk feature to pop-up in the Viewer code in general for a while), and is the first merge I’ve seen of a new functionality from LL that was recently released as a changeset (my apologies to other TPVs if they’ve in fact merged it as well, I’m still trying to catch up on 3 days of missed blogging and updates).

Visual Auto-mute

Essentially, this functionality allows you to set thresholds above which avatars with a very heavy load (high-res textures, complex attachments (multiple prims, flexi prims, sculpts, and what have you), etc., – but not scripts, which are a completely different kettle of fish) will not be rendered by your Viewer. Instead, they will appear as “grey ghosts”, similar to when you’ve muted someone; however, you will still be able to IM them and chat with them. This should theoretically reduce the load placed on the Viewer and your system in terms of rendering, and lead to an improved SL experience.

I’ve covered Visual Auto-mute elsewhere, so will not dwell on it further here.

Graphics Preferences

The Graphics tab in Zen’s Preferences has also been updated, with an improved overall layout, largely due to the removal of the low-med-high-ultra slider from the top of the tab (itself no real loss), although a full screen option has yet to appear.

Graphics tab updates

UI Skins and Button Transparency

This release sees the range of skin options (colours) expanded, with gold, purple and red being added to the original LL teal and Zen blue. It also appears that Zena has taken-up the comment I made in my original review about having the transparency of the UI buttons user-adjustable. This release sees an opacity slider for the buttons added to the UI Skinning tab – so while the buttons are initially solid on first-time start-up, you can adjust them to a level of transparency to suit your needs.

Zen Menu Updates

Zen menu

The Zen menu sees a couple of updates. The Notifications to Top for moving incoming notifications to the top right of the screen has gone (it can now be found in PREFERENCES->NOTIFICATIONS). This moves the Pie Menu option (on by default) to the top of the menu, while an option for accessing Preferences slips-in at the bottom.

I’d still prefer to see a button added to simplify accessing preferences, but this is still a logical addition that streamlines access to frequently used menu options.


This release moves Zen up a notch. While performance is unchanged on my usual system (no surprises there given it’s still effectively the LL 3.2.8 Development / Project Viewer code base), the additional preferences options help make the Viewer more accessible and potentially feature-friendly to SL photographers who prefer something closer to the “official” Viewer rather than plunging into Exodus or Niran’s (although Zen does not have the advanced capabilities of either of these two Viewers, obviously).

The Build heritage for Zen is clear – drawing heavily on Firestorm in terms of floater layout and the availablity of popular tools. I’d personally still like to see the camera floater get some button functionality, and still am undecided on the complete removal of button-based functions from some of the menus. Some might find it feature-light compared to other TPVs (the list of what’s not there is still pretty much as it was for, but I don’t count this against Zen in any way. Overall this is still a Viewer that presents something of the best of both worlds – good, solid building capabilities wrapped up in LL’s 3.2 code. With it now listed in the TPV Directory, it’s worth a look by anyone who might be considering easing away from the official Viewer to take advantage of TPV-originated tools, but who doesn’t necessarily want to get swamped with additional features and options.



Visual Auto-mute: a farewell to ARC/ADW upsets?

A new set of functions has been released by LL as a changeset, and is starting to find its way into SL Viewers.

Essentially, this functionality allows you to set thresholds above which avatars with a very heavy load (high-res textures, complex attachments (multiple prims, flexi prims, sculpts, and what have you), etc., – but not scripts, which are a completely different kettle of fish) will not be rendered by your Viewer. Instead, such avatars will appear as “grey ghosts”, similar to when they’ve been muted; however, IMs and chat can still be exchanged. This should theoretically reduce the load placed on the Viewer and a your system in terms of rendering, and lead to an improved SL experience.

It’s important to note that the functions only affect how such avatars are rendered in your world-view; they will still render normally in their own view, and for anyone who hasn’t set thresholds / has higher thresholds than you. Also, your avatar will remain visible in your view, no matter how you set the limits.

The thresholds are governed by two functions, initially released by LL as a set of debug settings:

  • RenderAutoMuteByteLimit – Maximum bytes of attachments before an avatar is automatically visually muted (0 for no limit)
  • RenderAutoMuteSurfaceAreaLimit – Maximum surface area of attachments before an avatar is automatically visually muted (0 for no limit)

These currently require numerical values to be entered. However, it is possible that they’ll find their way into at least some Viewers as Preferences options, possibly using sliders. Zena Juran has already opted for this approach with the latest release of the Zen Viewer (below).

Visual Auto-mute as presented in the Zen Viewer

The functions are supported by a new addition to the Develop menu: Render MetaData->Attachment Bytes. When active, This displays a set of figures over / near avatars, which can be used to help you to determine the byte and area thresholds you should set.

Rendering Metadata->Attachment Bytes display enabled

The approach has already come in for considerable discussion on the SLU forum, where opinion seems to be weighted towards the favourable.

Certainly, it can’t be denied that avatars can impact Viewer performance enormously, so any moves that enable the user to have a greater degree of control over what is hurting their SL experience is potentially a good thing. But lag is a very sensitive subject – as anyone who has encountered upsets in the past due to people using ARC as a Big Stick can testify.

This approach would appear to be a lot more beneficial than something like ARC and its successor, Avatar Draw Weight (or ADW) are concerned, as it should hopefully reduce the amount of finger-pointing and hostility that goes on when people have arbitrary figures in red floating over their heads like a glaring accusation of wrong-doing.

It’s also somewhat friendlier than the other alternative to “blocking” “overloaded” avatars: that of audio mute, which denies any communications capabilities where some might be preferred and which can, if done on a group basis, leave a poor soul ostracised in silence with no idea why.

There are, however, some drawbacks. On the minor side, it is possible that setting the options when entering a popular venue may well result in you finding one or more friends around you turn into grey ghosts  – or that you end-up greyed-out in their view. This might in turn result in strained relations, but shouldn’t really be anything reasonable people can get past – and even joke about privately.

This isn’t necessarily a “one size fits all” solution as well; it is possible that, depending on the type of venues a person visits (in terms of popularity popularity, nature of the activities carried out, etc.), the thresholds may need adjusting from time-to-time in order to gain the best benefits / compromise in terms of performance benefits and visual appeal. This may limit the scope to which the new functions are used, as people are not always willing to fiddle around with sliders as they teleport around SL.

It also needs to be remembered that avatars aren’t the only load placed on the Viewer, and using functions like these might not help tremendously when moving around an environment that has dozens upon dozens of high-resolution textures all over the place (such as a store or mall). In this regard, the effectiveness of the system needs to be balanced against alternative approaches (such as the use of avatar imposters, or by simply turning-down your draw distance and turning down / off various options within the Viewer Preferences) in order to improve one’s in-world experience.

The biggest question-mark over the new controls, however, is that of effectiveness. If the results of playing with the new options is an improvement of a couple of fps in overall performance and/or a very slight improvement in rendering time, then it is unlikely that they are going to gain a lot of traction. But if people see a demonstrable improvement in their overall experience, then it is liable that the functions are going to prove more popular.

That said, anything tha moves us further away from the finger-pointing extremism that has been the plague of ARC /ADW, has to be a step in the right direction, doesn’t it? One possible benefit from this approach is a greater awareness and consideration of just how one’s own avatar might be impacting other people’s experience within SL, simply by seeing that it exceeds the thresholds one is setting against other avatars.

Well, one can hope, can’t one?

Dranopia: here be dragons – and a quest!

Second Life isn’t a game – or at least, that seems to be the 2011/12 mantra. Well, it may not be – but it is a platform wherein games can comfortably exist, as I’m all too fond of pointing out.

And a new game is set to be added to the list of attractions in SL: Dranopia: The Quest.

Many will probably be familiar with the Dranopia range of breedable dragons, which come in a range of forms to reflect the elements and more, and which have a unique back story into which owners are encouraged to immerse themselves. The dragons are the brainchild of Timmi Allen, Leni Galli and Ciaran Maktoum and can be found at Sculptie Wonder.

Chatting with Leni (far right) and the “bare bones” (!) Timmi Allen (centre)

Dranopia: The Quest adds a new dimension to the Dranopia “legend”, presenting a sim-wide airborne quest which can be enjoyed by anyone, whether they own a Dranopia dragon or not. And I have to say, it’s actually a lot of fun. It’s located on Virtual Services, located immediately adjacent to the “Sculptie” sims.

Like the dragons themselves, the game has a back story: deep in a lonely gorge lie gems of different colours – the souls of ancestral dragons, lost after a catastrophe, and now threatened by marauding groms – spherical creatures with broad mouths and spine-covered ski. These roam through the deep landscape, devouring the gems, feeding off the energy of the souls within. It is down to you, riding upon the back of a dragon, to save the souls, by flying around the sim and gathering points for each gem you touch, while avoiding the groms and other obstacles.

Looking down into the Dranopia Quest sim

While the theme may sound familiar in the wake of Linden Realms, the game is actually very cleverly executed and requires not a little concentration.

To play, you need the game HUD – available from the “how to play” section of the arrivals area, located high-up towards the middle of the sim. You will also need a dragon. If you have a Dranopia dragon of your own, you can use that – there is a rezzing area available. Otherwise you can choose one of the dragons standing close to the start area, or if none are available “hatch” a fresh one from the rezzing egg…

Fly with your own dragon, use one of the available dragons, or “hatch” one to use

Each dragon has its own characteristics and all fly a little differently to one another. Those unfamiliar with flying a dragon are advised to take the Air dragon for its agility. Once you have chosen / rezzed your dragon, it is a case of grabbing hold and taking to the air – use the WASD or arrow keys for direction, and PAGE UP/PAGE DOWN (E/C) for climbing / descending. Just make sure that you pass through the “starting gate” (clearly marked START GAME) to commence the game.

Once through the gate, the sky is yours. You have four minutes per session to collect as many points as you can by locating gems and flying through them (the value of the gems varies according to their colour – so make sure you read the guidelines!); after that, any gems you fly through will not be counted in your session score. Points gained are recorded on the HUD and, if you have sound on, you will also hear a chime.

Heading for a gem

Your HUD will also keep track of the time remaining in your current session of the game; when you’re out of time, you can either end the game (land and dismount – your dragon will de-rez, or return to the start area and land), or you can fly back through the start gate and commence a new session. But don’t keep flying the same dragon too long – they do get tired.

In addition to the screen HUD, you have a hovertext HUD reporting on your dragon’s performance – speed, power, etc. Use this to watch your performance – you may find that slower speeds are more advisable that fast speeds – and don’t forget that dragons can fly backwards (negative numbers) and can hover!

Take care, however – the floating island, the trees and other flora are all solid – hit them, and you’re liable to affect your dragon’s airborne balance and lose some flying control as a result. Most importantly of all where obstacles are concerned, watch out for the gem-hunting groms themselves. Several of these weave their way around and through the sim, hunting gems and trying to stop you; touch one, and you’ll lose all the points you’ve accumulated in your current session, and will have to start again.

Avoiding a grom

Points and Prizes

Points obtained by players are recorded and saved on a scoreboard, and there will be periodic cut-off dates, after which the top three scorers will received prize vouchers of up to L$20,000 which can be redeemed at either the Dranopia or Timmi Allen shops. A further 7 runners-up will each receive a Dranopia starter kit valued at L$1850. The first cut-off date for prizes has been set for the 9th February. All winners and runners-up will be notified by Leni Galli.


Dranopia may not have the expansive feel of something like Linden Realms (which benefits from 12 regions per “island”) – but keeping things confined to the one sim and adding the three-dimensional element of flight makes it fun to play – especially when racing against others to grab your points.

Flight with my dragon…

The flying pose is a little alarming – you’re essentially clinging-on to the little dragon’s eyebrows rather than occupying a saddle or anything, which makes me feel a little sorry for the little fellows – especially when faced with avatars of a larger size!

Gameplay-wise, a lot of the sim is mesh, and so lag shouldn’t be a major issue – indeed, I was playing alongside members of the team and a couple of others and had deferred rendering active, shadows on and the snapshot floater open and still managed to fly with little exposure to lag. I did get a little too low at one point and clip a couple of trees – and did find I lost a degree of flight control, as I’d been warned.

Beware the groms!

The game HUD is not too obtrusive and uses the top left of your screen as the default attach point, although you can obviously move it elsewhere. There are some nice touches to the game as well – the different flight characteristics with each of the dragons and the fact that they can get tired of hauling you around the sky. The groms aren’t too hard to avoid – but snagging a gem may not always be as easy as it sounds, especially when trying to manoeuvre between rocks and plants…

Game HUD

Overall, this is a fun little quest to play – and a very clever means of promoting a product. Kudos to the team on both counts for coming up with the idea. With the new creativity tools arising from Linden Realms in the offing, I do wonder as to how the game might yet develop – one can well imagine the groms becoming somewhat more aggressive if one gets too close!

But even without the AI and other bells and whistles offered by LR, I enjoyed my time being able to preview Dranopia, it was fun to play, whether hunting for points or simply flying around the sim and having a little fun. Doubtless, I’ll be back to see how it develops, or simply to have more fun flitting around the sky on a dragon!


Qarl updates on the mesh deformer

Qarl Fizz (Karl Stiefvater) has provided further commentary and feedback on the developing mesh parametric deformer project via a You Tube video. In it, he specifically addresses a number of questions and concerns, as well as providing further explanation on the current alpha of the deformer and how things are developing, and why some options and ideas are unlikely to make an appearance in the first release of the code (but may appear down the road).

Providing Feedback

Initially, feedback was requested via the deformer JIRA. However, given some of the issues raised as to the appropriateness of discussions on the JIRA, Qarl suggests that future comments on this video and the project in general should be made directly to his website for the time being.

Here’s the video in full: