Frontier Viewer: Singularity with mesh rendering

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

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

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

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.

Dolphin Viewer 3: updates and issues

dolphin-logoLance has issued a couple of blog updates on Dolphin 3.

The first is that there is now an update available – 3.0.5 (20427) which sees:

  • Dolphin Viewer 3 now defaults to its own separate cache folder (users of previous versions need to reset the cache location once this version is installed, unless you already set it to its own location)
  • Restrained Love check box in preferences renamed to RLV to make it more consistent with all other RLV options
  • Chat bar hovertip now properly mentions whispering by using shift-enter
  • Linux build works for users of older Linux distributions

The update is available from his download page.

Additionally, he reports three known issues relating to the Viewer:

  • The performance on Windows can be slow, (lance suggests are one-third of previous performance)
  • Replacing a saved outfit that contains more than one of any one wearable type (two or more tattoo layers) does not take off all of those layers (e.g. one tattoo stays behind but does not show in “Current Outfit”)
  • Sending teleport offers to more than one person through selecting them on your friends list makes the viewer crash

Lance indicates that both of the second points reproduce on the original RLV 2.7, and that they are being worked upon. The first issue – Windows performance – is an issue with the original Linden code, and so is in their hands for a fix.

Obviously, as these are known issues, please don’t burden Lance by reporting them to him again.

Related Links

Mesh: Viewer changes coming

In the wake of the arrival of mesh, and in the hope of alleviating confusion / making things a little more understandable, there are changes coming down the road for Viewer 3. Some of these will undoubtedly make their way into TPVs as well, so here’s a quick overview.

The changes described below can be seen in the latest Mesh Development Viewer from Linden Lab (3.0.5 (240741)+), which can be obtained from the alternate viewer wiki download page. note that as this is a development Viewer, some elements may change in relation to descriptions provided here.

Prim Equivalence and Land Impact

For a general user perspective, this is probably going to be the most obvious change.

Prim Equivalence, or PE has been an issue on many levels, not the least of which, for consumers, is that it tends to be bracketed with a prim count value – and is frequently greater than the associated prim count (although there are items where the reverse is true). People therefore get confused as to which is the key value: prim count (which everyone is familiar with) or PE.

In order to try to solve these issues, the terms “Prim Equivalence” and “prim count” are set to be replaced by a single value: “Land Impact”. How this will work takes a little explaining on two fronts, as it relates to a couple of changes within the Viewer and how we need to view things. So bear with me while I attempt to explain.

The first of these changes is that land will no longer be referred to in terms of prim counts and usage, but rather in terms of its “capacity”. Essentially, this means that:

  • Full sims have a “capacity” of 15,000
  • Homestead sims have a “capacity” of 3,750
  • OpenSpace sims have  a “capacity” of 1,875.

Land parcels will also be referred to in terms of their “capacity”:

About Land today: prim counts (l); As it will be: capacity (r) (click to enlarge)

This might all sound like unnecessary semantics – but it does have a point in that it allows everything to be thought of equally, regardless of its origin – as we’ll see below.

Note as well, that nothing is physically being “lost” from your land. A 4096 sq m parcel that had a prim count of 937 prims before the arrival of the new Viewer will simply have a “capacity” of 937 after the new Viewer has entered general use, as shown by the figures highlighted in green in the above images.

To align with this, objects need no longer be through of in terms of their prim count or their PE – but simply in terms of their Land Impact – that is, how much of the available “capacity” on a sim / parcel they take up. This is reflected in changes being made to the Build menu floater:

Build floater: As it is with Prim count & PE (l); The new Land Impact values (r)

As can be seen, the prim count / PE values are being replaced with two simple figures:

  • The impact the rezzed object has on the land
  • The remaining capacity that is available for rezzing further objects.

So if an object has a Land Impact of 15, it will reduce the land capacity by 15; if it has an impact of 150, it will reduce the land capacity by 150, regardless as to whether the object itself is made of prims or is a mesh object.

For people who want more detail on individual objects, the new Build menu also includes a MORE INFO link. This opens an additional floater which provides:

  • Information on the object itself (including the prim count for those missing it!)
  • If the object is a mesh creation, the “weights” applied to it in terms of the bandwidth required to download it, the server resources it uses, its physics weight, etc.
  • The overall land impact: impact of the object itself, impact of all objects rezzed, remaining free capacity and total capacity for the land itself.
MORE INFO: for a prim object (l) and mesh object (r) – note the weights for th mesh object

There will also be a WHAT IS ALL THIS? link which will open a Help page that explains the various figures.

Replacing both prim count and PE with a single, easily understood value (Land Impact) makes sense, and at a stroke makes the impact of rezzing any object in-world easy to understand, removing any confusion between prim count and PE.

Of course, there are going to be voices that proclaim the change is about further “hiding” the “real” cost of mesh objects from the user, with the underlying implication that the users are somehow being hoodwinked by Linden Lab. But, c’est la vie. People are wont to make waves come what may.

It will be interesting to see how merchants react to the change – given that all vendors, etc., refer to prim counts right now, and getting wording changed to “Land Impact” (or simply dropping the word “prim” from displays)  is a nontrivial issue for many. Some may even opt to retain the use of “prim count” in their vendors for this reason.

And when considering merchants – one hopes that Linden Lab will actually remember to update the Marketplace so that listings also reflect the use of “Land Impact” (i.e rename Prim Count!).

Avatar Rendering Cost and Avatar Draw Weight

Alongside the changes around PE and Land Impact, the Viewer will also be losing another measure that has always caused controversy and angst: Avatar Rendering Cost, or ARC.

Always intended to be an indicative figure for the amount of potential Viewer-side lag avatars create, ARC quickly became viewed by some as the figure for determining whether or not an avatar was “creating lag”, which in turn lead to a lot of drama in some quarters – up to and including people being banned from venues / sims on the basis of their ARC count.

DWA: 197,484 – but don’t panic!

From 3.0.5, things will be totally revamped. ARC as a term is vanishing from the Viewer to be replaced by Draw Weight for Avatars (DWA). Furthermore, how DWA is calculated is radically different to how ARC has been calculated, as Nyx Linden explains.

DWA should be far more accurate  than the old ARC system; and therein, one cannot help but feel, lies the rub.

If the figure is indeed more accurate, it is likely to be pounced upon within even greater zeal by those already obsessed with ARC. As such, I can’t help but hope this is one value that Linden Lab don’t make a song-and-dance about when these changes to the Viewer are formally released for general use.

Mesh Uploader

Another source of irritation for content creators has been the mesh upload floater. At SLCC 2011, Charlar Linden himself admitted the current floater is isn’t overly user-friendly. As such, it is also being overhauled, as can again be seen in the current Mesh Development Viewer.

The current upload floater presents a basic set of modifiers that can be applied to a mesh object prior to uploading in order to optimise it. These tend to encourage a lot of trial and error / guesswork on the part of the creator in order to arrive at a desired result.

The current mesh object upload floater

The new upload floater offers a greater range of modifiers and the ability to better define the model itself in terms of what it represents (avatar shape, avatar attachment, moving vehicle, etc – see the drop down in the image below), which presumably apply suitable algorithms that help optimise the object and calculate its overall weight.

The new mesh upload floater as it appears in the Mesh Development Viewer

I understand that several of the changes in the new upload floater are as a result of consultations with / requests from mesh content creators, so hopefully they will go some way to easing the process of importing objects into Second Life.

More to Come

These are by no means the only changes coming to Second Life and the Viewer as a result of the arrival of mesh object support. For one thing, more needs to be done in the area of mesh clothing in order to make it easier to adjust clothing to fit the avatar, rather than the other way around as is currently largely the case. Therefore we can expect to see further changes in relation to this in the future (indeed, those interested in the issue should check Maxwell Graf’s JIRA relating to a parametric deformer).

In the meantime, the above should hopefully give insight into what is waiting just around the corner.