Phoenix viewer appears set to continue (but not with SL)

PhoenixAs of January 1st, 2013, the Phoenix Firestorm team ceased support of the Phoenix viewer, bring a close to all further work on that viewer on their part.

While this signals the end-of-line for Phoenix where Second Life is concerned, it appears that efforts are underway to attempt to continue Phoenix development for the OpenSim / Aurora environment, under new leadership and a new brand name.

In a blog post dated 29th December, 2012, Virtual Reaility, the new developers for Phoenix state:

Over the past week the Jessica Lyon, Project Manager of the The Phoenix Firestorm Project, Inc. made an announcement that on Saturday, December 15, the Phoenix development team would no longer support the V1-based Phoenix virtual worlds viewer that has had a significant following of users in virtual worlds such as Second Life and OS Grid.  Ms. Lyon stated that support for the viewer will be dropped to provide development and support focus on their Phoenix-Firestorm viewer.

Though this may seem like a dark day for people who use and enjoy the Phoenix viewer, this cloud has a silver lining. Virtual Reality is pleased to announce that it will continue development, maintenance, and improvement of the Phoenix V1 viewer, which will be re-branded as the Virtual Reality Viewer. “I am excited to have the opportunity to fork this highly popular viewer for virtual worlds users who use it and desire to continue to use it.”, said, Virtual Reality owner and CEO, Sonic Boom Drillion. “The Virtual Reality viewer will continue to work within OpenSim and Aurora based grids, however we hope to update the viewer to address a number of technical advancements that are presently happening in virtual worlds.  We are eager to embrace this code base and develop it to support these changes.”

The post goes on to state that as of the 29th December, work was underway to move the Phoenix code to Virtual Reality’s own systems, however the work will not include porting outstanding / open JIRA relating to Phoenix, as these are related to Second Life, which will not be the target environment for the rebranded viewer.

virtual-realityVirtual Reality is an OpenSim hosting company focused on Aurora Sim side of OpenSim, and provides customers with grid space through its own  Virtual Reality grid, as well supplying private grids to customers.

Within the blog post / announcement is a request that any developer wishing to work on the rebranded viewer should contact Virtual Reality at

While this does not help those who have used Phoenix specifically with OpenSim, it does mean that potentially, the Phoenix legacy will live on, albeit under new management and a new name, on OpenSim.

Related Links


Calling all Phoenix users

PhoenixJessica Lyon has announced she and the Phoenix  / Firestorm team will be holding an Office Hour meeting, and all users are invited. Jessica is particularly keen to have users on Phoenix attend the meeting, commenting:

Everyone is invited and encouraged to attend but I especially want to see Phoenix Viewer users in attendance as the primary topic will be about Phoenix and its future. I also would like to see all you angry people who have been flaming and hating on us in our blog comments. I’d like to address your complaints so please at least be on the stream if you can. 

Because the lack of Phoenix Viewer development and in fact the future of the Phoenix Viewer itself needs to be discussed and your questions/concerns need to be addressed.

Firestorm users are also obviously welcome.

Event Details

Those wishing to attend / join the stream are advised to turn up around 30 minutes ahead of the meeting. As there are limited slots for both the in-world event and the stream, it would be advisable if those attending the event don’t also run the stream, as this could prevent others who are unable to get in-world from watching and listening on-line.

The event will be recorded for future playback.

Phoenix gets set for Direct Delivery

Phoenix has been released today. This has been expected since the recent updates to the TPV Policy required the removal of the on-line truth status from the profile floater.

More importantly, the update prepares Phoenix for the forthcoming roll-out of Direct Delivery, scheduled for this Wednesday, the 21st March. As such, it is very important for Phoenix users to upgrade to this release if they wish to be able to use the SL Marketplace to receive items once Direct Delivery is launched and merchants switch over to it. Additionally, the Viewer includes the V2 inventory fetch system.

Other updates include:

  • RLV updates (Kitty Barnett)
  • Optional support group viewer version identification (Zi Ree, Kadah Koba)
  • GPU table updates (TankMaster Finesmith)
  • Added CHOP, MAINT, EXP, SINV, PATHBUG, and DOC to jira parser (TankMaster Finesmith)
  • Option to show script time in either ms or µSeconds (Kadah Coba)
  • Allow /me’ when using viewer prefix (Inusaito Kanya)
  • Support for CreateInventoryCategory capability (Henri Beauchamp)
  • Backport of V3 inventory loading at login (Henri Beauchamp & Singularity Viewer)
  • Additional fast timers from V3 (Henri Beauchamp)

It is recommended that a clean install is performed for this release.

Related Links

Phoenix goes mesh

Yesterday, the much-anticipated release of Phoenix was made. Version 1.6.0 1591 brings with it the ability to render mesh objects.

This means that the majority of users in SL are able to see mesh objects rendered correctly in-world, if not import them. However, the release announcement from Jessica Lyon is liable to make difficult reading for some:

“We stated some time ago our active development commitment is now focused on the Firestorm viewer and that continues today. We still feel strongly that the end of V1 functionality is an inevitability, so it is more important to develop an alternative viewer for our users they will enjoy for when that time comes than to spend our efforts on a dying viewer and then leave our users with no alternative once it’s gone. However, we also promised we would try to keep the phoenix viewer alive for you until it is no longer feasible to do so. As you can see, we are not walking away from that promise, but it is important to understand that Phoenix is no longer our top priority. When necessary we will continue to keep it up to date with advances/fixes from other third-party viewers and provide them the credit they deserve for that work. But ‘we’ are no longer actively developing Phoenix on our own steam.

“Any future releases of Phoenix will be sparse and only if needed. I will not commit to saying this is the last Phoenix Viewer Release, but I will also not commit to saying it isn’t the last either. I will say… this is one of our last. As time passes we will determine if another release is absolutely necessary and/or sensible and make a decision then on whether another update is mandatory in order to keep our promise to you.”

While it may not be a popular move, one can hardly blame Jessica and the team for taking this position: maintaining an aging code base which itself is built on something LL no longer maintain (Snowglobe) is liable to become harder and harder as time goes on, and for a Viewer to remain functional and relevant, it needs to keep pace with the evolution of the grid and as the Phoenix / Firestorm project has made the step of producing a V2/V3 hybrid, it makes sense for them to focus on that work in order to do so, rather than splitting efforts (and doubling the workload) to try and maintain two sets of code.

As well as mesh rendering, this release also brings with it:

  • The Firestorm 3.2 log-in / splash screen options
  • Contact Sets
  • Removal of the Google chat translation API options from Preferences
  • A host of “small” fixes and changes

A signficant element not updated was that of RLVa – it was decided that Kitty’s time and focus is better spent on the numerous projects with which she is already fully engaged: her own Viewer (Catznip, reviewed here), working on bringing the spell checker to Viewer 3.x, her continuing support of RLVa for other V2/V3 TPVs, and so on). In the release blog, Jessica suggest that those wishing to update to the latest RLVa implementations should give either Firestorm or Catznip a try.

In the meantime, and if you haven’t already, you can grab Phoenix 1.6.0 1591 directly, or go to the Phoenix home page and use the Quick Download links.

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.


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.


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.

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.”


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.