Linden Lab has gone to a lot of effort to provide mesh. Some of it perhaps hasn’t been handled too well at times (given the problems around Prim Equivalency, the weakness of the uploader, etc., would it really have hurt to delay the launch by a month so that some of these issues could be address as they are being already in the latest Mesh Project Viewer?).
One of the biggest issues around mesh is clothing. Simply put, the way mesh works means that options to resize worn items are limited. In some cases very limited. Even with alpha layers, it can be a case of modifying your shape to fit the item – and there are times when alpha layers aren’t suitable…leading to more and bigger issues.
Maxwell Graf suggested a means of handling the problem – a parametric deformer. He’s blogged about the idea – so have many others. He’s raised a JIRA on the subject and received the support of just about every mesh clothing designer in SL. It’s generated a lot of discussion.
It appears to have been universally ignored by Linden Lab.
Charlar Linden has commented elsewhere on the subject and suggested there might be alternative methods to employ, etc., but the lack of open commentary is confusing.
And now the JIRA has been downgraded to someday / maybe – a stance that doesn’t sound too hopeful.
Theories have been put forward as to why the JIRA has been downgraded – some have cited the recent code breakages for attachments and PRIM_PHYSICS – the suggestion that these and other issues have higher priorities, et. But such explanations really don’t make sense: this issues are under the control of a different team at LL.
Are the Lab generating an alternative? Do they simply think this is a non-issue? It’s impossible to say.
Only one this is clear right now – the stubborn silence evidenced from linden Lab isn’t winning them any favours. We’ve long been promised better and more informed communications (wasn’t that, after all what all the hoo-ha with the Lithium “Community Communications Platform”?) Rod Humble himself has promised (via Twitter) that the silence would end some time back – yet the fact remains that outward communications from Linden Lab are sporadic and frequently noteworthy for telling us what we’ve already discovered for ourselves.
Of course, one doesn’t expect LL to inform users of absolutely everything that is going on – but given the ballyhoo around mesh, the concern over limitations on mesh clothing / body attachments (which otherwise have the potential to be a huge market in-world), it would really help matters if someone, somewhere inside Battery Street actually stood up and said something on the matter of what on Earth is going on.
Rodvik? Over to you.
In the meantime, if you are cuious about mesh clothing – limitations and all – I recommend a read of Couldbe Yue’s excellent overview and guide.
The next update to Firestorm is still a little way off, in part due to the fact that the team is currently awaiting various fixes to known issues to filter through from Linden Lab.
In the meantime, the team are hard at work and, as well as fixing various Firestorm specific bugs and incorporating features that didn’t make it into the mesh beta release, are focused on addressing adoption issues – those things people have indicated are effectively show-stoppers where their adoption of Firestorm is concerned.
Missing in the mesh beta
While no date has been set for the next release (see comment re: Linden Lab fixes, above), here’s a summary of what to expect by why of Things to Come:
The Firestorm betas (both mesh and otherwise) currently tend to reset any Windlight settings following a relog or teleport, but a fix will be in the next release
The Contacts List (not the new Contact Sets feature) displaying both user name and display name in separate columns (something I reported on myself) in the mesh beta is in fact a bug, and will be corrected in the next release
The WORLD button for the ruler was removed from the Build floater during the beta mesh merge with LL’s code. This has proven unpopular among builders and the button (right) will be returned to the Build floater in the next release
The spell check feature, delayed from the mesh beta release, will be in the next release
Spell Check coming to Firestorm (Phoenix shown)
Further updates to the AO should be available with the next release
Web Profiles: with the increased functionality in Web Profiles, Firestorm will include an Preferences option (under the FIRESTORM -> GENERAL tab):
The option will be off by default for the V1 (“Phoenix”) mode of the Viewer
The option will be on by default for the V2 / V3 modes of the Viewer
Personal note: I assume this refers to displaying ones own Web Profile, given Firestorm already includes a link to other people’s Web Profiles as a part of the in-world Profile display
The inventory “jump” issue – whereby the cursor bar jumps within the inventory window (usually to the top) on receipt of a notification, etc., is being investigated but may not be completed in time for the next release
Mesh uploads: work is progressing on enabling mesh uploads in Firestorm. The code is the work of Nicky Dasmijn, who has contributed code to the Firestorm project over time, and the uploader will be available for other TPVs as well. Some additional points:
The upload most likely won’t be in the next release. It is still a work-in-progress
Even with mesh rendering coming to Phoenix, Jessica is not committing as to whether or not the upload will be ported to Phoenix.
The adoption issues the team are specifically addressing for the next release are:
Mouselook zoom will be incorporated into Firestorm (go to Mouselook, press & hold right mouse button and zoom in/out with mouse wheel) – this will be especially useful for those involved in combat games in SL
Text search in Notecards will be included
For the V1 (“Phoenix”) mode of the Viewer, the team are trying to get all dialogue boxes to display in the top right corner of the Viewer window by default. This includes Group notices and anything else that in a V1.x Viewer would appear in the upper right corner of the screen
A longer term aim is to possibly have the V1 (“Phoenix”) mode of the Viewer display a more Phoenix-like top menu when selected. This is not a high priority for the time being, and isn’t strictly seen as an adoption issue.
Again, no release date is available for the next update to Firestorm, as so much depends on Linden Lab providing fixes to known issues at their end. Also, not all of the above will be in the next immediate release, as per the notes.
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.
The 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.
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.
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.”
Inara Pey: Living in a Modemworld 