[Posted 8:30am PDT, 1 August 2012] Some residents may be experiencing problems opening the Second Life Viewer in a MacOSX Mountain Lion environment. This is due to a security feature of this operating system which is misidentifying some programs as potential security risks. While this is not indicative of any actual issues with our software, we are working on an update to our viewer which should address this. In the meantime there are instructions on how to bypass this feature temporarily, as well as an explanation of the cause of this issue, here:
Please note that this is not a problem with the viewer, and that we are not responsible for the workaround above – we are merely providing a link to a possible fix posted by a third party.
If you are experiencing issues using Second Life on Mac OSX, you might try the workaround noted above – but again, please note, as the report states, it is a link from a third-party, and Linden Lab (nor I) cannot be held responsible if the workaround fails or causes other unforeseen issues with your computer.
Following-on from the TPV/Developer meeting on the 13th July, during which pathfinding was discussed, and the recent roll-outs of pathfinding functionality to the Magnum Release Channel, the Firestorm team have announced that they will be adding pathfinding support to upcoming releases. The announcement reads in part:
What’s next…Pathfinding! We’ve decided to release LL’s Pathfinding work in Firestorm in two stages.
Unless LL changes the current plan, when Pathfinding goes live, all regions will have pathfinding enabled by default, and all objects that contain scripts will be treated as “Movable Obstacles.” Movable Obstacles will have an impact on region performance, so region owners will need tooptimize their regionsby setting scripted objects that don’t move to “Static Obstacles.” To do this, you will need Pathfinding Tools!
So our plan with our next release is to get Pathfinding tools out as soon as we can. This will be based on our 28744 release + post 28744 crash fixes + LL Pathfinding code. There have not been many new additions beyond that since the release, and this is for the best: we expect this code will destabilize the viewer to a degree, since it will be a large merge, and we’d rather base this version on a solid release than on a wild card.
Stage 2 (follow-up release). Release with the Havok Library for NavMesh. Havok will be used to enable viewing of NavMesh, display of object types and AI Preview of object paths.So the second Firestorm release from now will have Havok + stability fixes to the previous release + more of our own goodies.
The two-stage release is unsurprising, given Lorca Linden’s recommendations at the meeting on the 13th July. At this time, no time-scales are available for the releases, because, as Jessica points out in the post:
How soon? Great question, and a very tough one to answer since there are many factors involved that we have little control over. Like…
LL’s timeline to release Pathfinding;
How much Linden code we have to merge into Firestorm;
How many regressions and new bugs we pick up from that merge;
How long it’ll take us to fix them, etc.
But we want to get these out as soon as we possibly can once it’s live on the grid.
Phoenix
Phoenix will not immediately be getting pathfinding due to the amount of work involved in getting the capabilities integrated into Firestorm. Region holders using Phoenix will still be able to disable/enable pathfinding using a viewer-independent console, but for all else they will need to switch to a viewer that supports the full pathfinding tool set.
Update: The tiling fixing reached the SL viewer in December 2012, and has subsequently been incorporated into the majority of TPVs. Please refer to your preferred TPv developer for information on the fix (MAINT-628), if unsure.
The ongoing issue with taking high-resolution snapshots resulting in “seams” appearing in captured images may have a final fix on the way.
The issue was initially reported in JIRA MAINT-628 at the end of 2010, and has impacted viewer releases since then, becoming the subject to intense investigation by users and LL alike. The problem has tended to make itself known when taking images at a higher resolution than that of your monitor, resulting in lines breaking-up the captured image, as shown below.
The problem (image courtesy of Dil Spitz)
In reporting the fix, which has a couple of limitations, Runitai gave the following update on the JIRA:
Runitai Linden added a comment – 18/Jul/12 1:57 PM
Fixed in viewer-cat
Fix was to use a large render target for snapshots that are larger than the window, but only when lighting and shadows is enabled. Screen space effects will still show seams when lighting and shadows is disabled.
If the graphics card is unable to allocate a single render target large enough for the high res snapshot, the old method of tiling is still used. On my GTX 580, I could take artifact-free snapshots up to 3500 pixels wide, but could not allocate a full set of render targets at 4000 pixels wide, so the old method is used.
Changes involve an invasive set of changes to LLRenderTarget, so QA should be careful to check various shadow modes, ambient occlusion, depth of field, and anti-aliasing with lighting and shadows enabled. Running with Debug GL enabled will likely cause a crash now when taking high-res snapshots (expected and acceptable behaviour), since the driver reports “out of memory” when trying to allocate a large render target. When Debug GL is not enabled, the viewer handles this error condition gracefully and continues to function.
The code is in a changeset, and will be going through LL’s QA testing. If all goes well, it will hopefully progress through viewer release cycle soon.
Wednesday July 11th saw the release of Firestorm 4.1.1.28744. Using the Linden Lab 3.3.3 viewer code base and bringing RLVa support up to 1.4.6, the release includes and extensive range of updates, improvements and changes. I don’t propose covering all of these in detail – that’s what release notes are for – but will attempt to give a broad flavour of what are likely to be the more popular changes and outline where you can find them.
Download and Installation
The download is 32.9Mb in size for Windows, and installation threw out no surprises. As per usual, I did a completely clean install – something that is actually strongly recommended for the release. If you’ve not performed a clean install of a viewer before, the Firestorm team have some notes to help you.
Menus
There are a number of updates to the menus, which can be seen in the table below:
Firestorm 4.1.1.28744 menu updates (click to enlarge)
The World menu gets two brand new options, the Sound Explorer and Asset Blacklist:
The Sound Explorer displays all current sound sources within audible range. The list will continue to update as new sounds are played. Sounds can be located, played locally for you to hear and can be blacklisted. directly from the Sound Explorer. You can read more details in the Phoenix wiki
The Asset Blacklist works with an updated object de-render. With release 4.1.1, objects can now be “permanently” de-rendered (on previous releases, any object de-rendered would re-appear in your view following a teleport or re-log). With this release, all objects so treated are listed in the Asset Blacklist, from where they can be re-rendered if required. You can read more details on this in the Phoenix wiki
Vaalith Jinn’s Local Bitmap Browser has been removed from the Build menu because this release of Firestorm sees the incorporation of Vaalith’s Local Textures functionality, as contributed to Linden Lab (which is also available for clothing and skins uploads). However, all those who use Temporary Textures need not panic – that option is still available as well.
Preferences Changes
There has been further rationalisation of the various Preferences tabs. I’ve summarised the updates in a PDF file for ease of reference, and will focus on the notable changes here.
The most significant additions to Preferences are the new Crash Reports and OpenSim tabs.
New Crash Reports tab
The Crash Reports tab offers an enhanced means of supplying crash reports to the Firestorm team and includes a link to the team’s Privacy Policy.
The Firestorm team recently repeated their commitment to support of the OpenSim environment, and this tab can been seen as evidence of that. However, given Linden Lab’s requirements around the Havok sub-licence arrangement, this tab is liable to be vanishing from future “SL flavours” of Firestorm once the new sub-licencing comes into effect.
OpenSim Grid Manager
One important element in Preferences that needs additional emphasis is the option to Enable Lossy Texture Compression, found under GRAPHICS->HARDWARE SETTINGS. This enables texture compression during rendering, which can give improved performance and a smaller graphics memory footprint – but at the cost of lower quality rendered textures which may end up pixellated. As such, it is not recommended that this be enabled unless you have little video memory on your system.
Buttons
There are two new buttons making their début with this release:
Fly – a dedicated button to enable you to easily fly
Region/Estate button – provides access to the Region / Estate floater (WORLD->REGION DETAILS or ALT-R).
Additionally, buttons now display their keyboard shortcuts in their tool tips.
Floaters
In addition to the options that can be set for various floaters in the updated Preferences (see the PDF file linked-to above), a number of the floaters themselves have new or revised options:
AO floater: A new safeguard added to the DELETE THIS ANIMATION SET button so that everything that’s not an animation link is moved to “lost and found” to prevent accidental deletion
Appearance floater–>Edit Outfit – now includes the Local Textures picker (from the gears button) for testing self-made skins and clothes
Conversations floater
Contacts tab uses new coloured icons for options (Friends can see when you’re online, etc).
It’s been relative quiet on the Viewer front of late. However, there is now news emerging about two TPVs: Kokua and Firestorm.
Kokua
Nicky Perian has updated the Kokua code on Bit Bucket to release 3.1.1.22989(Beta-1), dated June 11th. Available for Windows and Linux, it is unclear as to how “official” this release is – there is no blog post associated with the release, nor does it appear on the Kokua wiki download page. Notice of its arrival has, however, been doing the rounds on Twitter.
I’ve not had a close look at it as yet, but it appears the release is more about bug-fixing and general enhancements of the current code (with fixes code that addresses both SL and OpenSim) more than prepping a major release and shouldn’t be treated as such – or even as a recognised experimental until the team release further information. As it stands, the release still references itself in places as the “Second Life Viewer” rather than Kokua, again indicative that this is very much still a work in progress. One thing it does do away with is the console window that would open on starting the Windows version of Kokua (and which you had to keep open while logged-in to SL in order to avoid the Viewer crashing).
I’m not recommending the release be put to general use – that is down to the Kokua team; rather I’m reporting that the version’s availability has been reported on via Twitter. Those wishing to know the exact status of the project should keep an eye on the Kokua blog, where hopefully there will be an update soon.
Firestorm
After an extended period of quiet from the Firestorm end of things, I recently noticed Jessica Lyon logging back in to SL once more after what appeared to be something of a period of absence. She’s provided a blog post at Firestorm entitled “Progress Report” , which indicates that the team had in fact eased off from development; with some taking an outright break from things, as burn-out was becoming a factor.
The announcement highlights three things:
The team has new developers in the form of Holy Gavenkrantz, who has been a regular code contributor to both Firestorm and Phoenix, and Armin Weatherwax who, co-incidentally enough given the information on Kokua above, was formerly a lead developer on that project
And update on the status of the Firestorm 4.1.1 release, which is still officially labelled “coming soon” but which will include various requested tools and capabilities including Growl support, an LSL pre-processor, additional Windlight effects an “improved build floater”, and a host of goodies
The news that the team is branching development for Firestorm between Second Life and OpenSim.
This last point is interesting, as Firestorm has been gaining popularity among OpenSim users (Kitely even set it as their default Viewer).
The use of Viewers to access both SL and OpenSim has been the subject of much debate in the last couple of months since Linden Lab announced they were sub-licencing elements of the Havok physics engine. This requires that any applicable Viewer using the licenced code to only connect to LL’s own servers. In May, Jessica gave a hint that the Firestorm team were considering their options vis-a-vis SL and OpenSim, commenting on SLU that:
There is the possibility that we could have Havok code disable when the viewer is not logged into the SL grid. I have asked Oz if this would be acceptable and he is looking into it. If it turns out this is NOT acceptable, we will provide two versions of our Firestorm viewer. One for SL and one for everything else.
While she has not followed-up the comment with further information directly, it would appear from the blog post that – for whatever reason – the Firestorm team has opted to take the route of developing two flavours of the Viewer. It will be interesting to see how this actually plays out.
Version 3.3.2.258114 of the official SL Viewer, released on May 29th, sees Local Textures officially reach the mainstream official Viewer. Previously, the option has only been available in Beta and Development releases of the Viewer.
Contributed by Vaalith Jinn, and an extension of his popular Bitmap Browser found in many TPVs, Local Textures allows users to temporarily apply textures from their computer’s hard drive to their in-world objects, including the ability to apply skin and clothing textures to avatars. Such textures are not physically uploaded to the SL servers, but are accessed locally; as such, they only remain “active” for your current SL session, after which they must again be selected once more. In this, they are functionally similar to the Temporary Textures capabilities found in TPVs – but with some important differences.
I’ve covered Local Textures in detail already, and refer you to that post for an in-depth look at using the capability when building. However, it’s worth highlighting the key points here for reference:
Local Textures works both with applying textures to prims and to applying skins and clothes to avatars – so clothing / skin designers can test their work using the official Viewer in the same way as they can using Temporary Textures on popular TPVs
If you use a local graphics editor to make changes to a texture that has been applied within SL using Local Textures, any changes you save in the editor will be immediately applied to the texture in-world
Local Textures does not physically upload anything to the SL servers – this means that the results of anything you apply can only be seen in your own world view; anyone else will see an untextured surface in their Viewer; thus the option cannot be used to test textures in collaborative build projects
Local Textures does not “break” Temporary Textures in TPVs, and TPVs currently are not prevented from offering the Temporary Texture upload capability; as such, both options may be offered by TPVs (as is currently the case with the Dolphin Viewer
As noted in my previous article on Local Textures (linked to above), enhancements to SL may eventually break Temporary Textures at some point in the future, but this is currently far from clear.
Local Textures and Skins / Clothing
As I didn’t cover using Local Textures with clothing and skins in the previous article, here’s a brief summary:
Select Edit Appearance by right-clicking on your avatar or going to ME -> APPEARANCE.
Click on the cog button at the bottom of the floater.
For skin tests, select NEW BODY PART -> NEW SHAPE
For clothes, select NEW CLOTHES-> the require clothing item / layer
The desired editor will open.
Click on the texture box (for skins, click on the required body textures selection box).
The Texture Picker is displayed – click on the Local radio button, and use ADD to local, select, apply the texture.
Selecting test skins using Local Textures
Again, the ability to make changes on-the-fly to applied textures and seeing the results immediately in-world, offers a powerful and unique capability to Local Textures that should assist creators and builders.
Inara Pey: Living in a Modemworld 