[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.
A part of the Shining project is to improve the underpinning HTTP messaging that is crucial to simulator / simulator and simulator / Viewer communications. As commented upon in the notes from the TPV/Developer meeting on July 13th, the initial focus on this project is to provide an initial texture fetch library for the viewer, together with a “wrapper” that will allow further http code enhancements to be added over time.
On Friday July 27th, Linden Lab made the initial code available within an LL project viewer (SL Alternate Viewers). The availability of the code, and LL’s plans / hopes for it were discussed during the TPV/Developer meeting also held on the 27th July. The discussion can be heard in full on the meeting recording, the key points from which have been summarised below.
During the discussion, both Oz and Monty Linden (who is leading the project) had the following to say:
The code is currently free-standing, although there will eventually be server-side protocol changes made to better support it (as well as further capabilities to be added to the libraries), which should further improve robustness and overall performance
Even without the server-side changes, the Lab hopes that the code itself will make things “a little bit better” for those using older routers, particularly Linksys WRT routers (Monty indicated server-side work would most probably be required to improve things for people using Belkin G-series routers)
While the libraries are close to what is expected to be the “final” code (barring bug-fixes, etc.), it is unlikely they will be integrated into the Development Viewer for at least the next two weeks. The reason for this is two-fold:
The code needs to be merged-up with 3.4.0
Integration is dependent upon what kind of experience is had with the code “in the field”
LL hope that people will use the project viewer, and TPV developers will integrate it into experimental releases of their own, so that greater feedback (via JIRA entries, etc.) can be obtained in terms of:
General experience reports – completeness, reliability, robustness, improved rezzing, etc.
Whether the new code is helping to ease the strain faced by the likes of Linksys WRT routers, and what (if anything) it is doing to people’s home networks
(From the TPV developers themselves) design comments on the code itself, whether it is felt things have been missed, if there are issues in integrating the code into TPVs, etc.
Again, note that the code is currently only related to textures; the “more ubiquitous” uses (as Oz has previously put it) of the new http library within the viewer have yet to be implemented, so HTTP inventory, etc., is currently unchanged.
Oz asked the question (of Monty), as to whether it would be a problem if TPV developers were to convert some of the additional HTTP functionality for use with the library. Monty didn’t see any major issues, other than the new library introduces the concept of a policy class, rather than the current global priority scheme, and this has not been fully implemented as yet, because it is not required in this first pass. However, additional functions could share the policy used for HTTP textures, and that would “still be productive”. Monty further indicated that there is a “to do list of intent” included in the code as a file, which TPV developers can look at if they are minded to look at committing to some of the work themselves.
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.
Pathfinding is drawing closer to a release across the main grid, and preparation work for the roll-out – which will constitute one of the biggest changes to SL – is underway on several fronts. This article is intended to be a high-level update on various elements of the project, gleaned from a variety of sources.
Magnum RC Roll-out
On Wednesday July 11th, the server-side pathfinding code was rolled-out to the Magnum Release Channel. There had been some predictions that this could lead to significant problems and issues as a result of the issues given within the release notes
Following the release, issues were experienced, notably with mesh vehicles, as reported on the forum thread discussing the releases for the week, and which have been rapidly responded to by Linden Lab personnel. there are still concerns around the roll-out and potential impact, and Linden Lab are continuing to monitor.
In discussing the RC toll-out at the TPV/Developer meeting held on Friday July 13th, Lorca Linden, the Associate Producer responsible for the project, commented: “OK, so pathfinding did go in RC on Magnum on Wednesday [July 11th]. As a whole, things are looking really, really good. We’re seeing very few crashes, the performance is working great we are seeing issues with some vehicles – definitely not all. That’s the only major hitch that we’re looking into, but as a whole the RC has been going quite smoothly.”
New Viewer Tools
As mentioned above, Lorca Linden (together with Stinson Linden and Prep Linden) from the pathfinding project attended the Friday TPV/Developer meeting on the 13th July, where they specifically discussed the viewer-side pathfinding tools. The tools are covered in detail in a new wiki page from Linden Lab, and may already be familiar to those who have been working on the pathfinding beta. They are currently in the Pathfinding Project Viewer, and will need to be incorporated in to TPVs as well. The wiki page provides comprehensive notes on the tools, complete with screen shots; the following in intended to provide a high-level summary and some background notes for those unfamiliar with the core elements of pathfinding, and to provide an overview of what this means for viewers going forward.
Navmesh and the Rebake Tool
For those not familiar with the term, navmesh is short for navigation mesh. This is a representation of a region’s geometry generated and used by the physics simulator to determine paths for pathfinding characters. The navmesh can be somewhat fluid in nature, depending upon what is going on in a region and what is being changed; a new path for a character, for example, will change a region’s navmesh. When this happens, the navmesh for the region needs to be updated, which can take some six hours if left to update automatically.
To overcome this when pathfinding is rolled out, one of the new tools that will be appearing in the viewer will be a Rebake Region button. This will automatically appear at the bottom of the viewer window of all users within a region when the navmesh requires updating – regardless as to who may actually have altered the navmesh.
Rebake region button for navmesh updates (with thanks to Linden Lab)
Once baking has commenced, the button will fade on all viewers on which is displayed, indicating that an update is in progress (and preventing someone else from initiating a rebake). Once the rebake is complete and the navmesh is updated, the button will vanish from viewers.
Object Attribute Tools
By default, a navmesh treats all resident-made objects within the region in which it is active as obstacles that pathfinding characters must manoeuvre around. Obviously, this may not always be the case; there will be objects (e.g. stairs, ramps, sidewalks, floors, etc.), pathfinding characters need to traverse, climb, etc. This is achieved by altering the pathfinding atrributes associated with an object, and some of the new viewer tools are to allow this to be done and to also allow users to examine in-world objects to determine their status vis-a-vis pathfinding and how pathfinding characters will react to them.
These tools take the form of menu options and additional panels located in the Build and Object Profile floaters.
Dedicated Floaters
Also included in the tools are three dedicated pathfinding floater panels:
Linsket floater: designed to give advanced users and builders the ability to customize an area to achieve interesting effects with pathfinding-enabled characters
Character floater: designed primarily to help users to locate characters moving throughout a region and to identify the CPU cost of characters affecting the performance of a region
View / Test floater: intended for advanced users who are building pathfinding-enabled objects and characters.
Pathfinding characters floater (with thanks to Linden Lab)
Tool Status and TPV Integration
As mentioned above, these tools are all currently available in a Project Viewer. However, it is anticipated that they will be appearing in a Linden Lab beta viewer in “one to two weeks” (Lorca Linden). The tools themselves are regarded as feature complete by LL, and Lorca encouraged TPV developers at the meeting to consider integrating them into their viewers sooner rather than later.
Integrating the new tools in TPVs is liable to be in two parts:
An initial release containing the tools required for setting object attributes, etc.
A follow-up release incorporating the use of the Havok libraries Linden Lab is establishing and which will be made available under the new sub-licence arrangement.
The reasons for this are two-fold:
The attribute tools, etc., are vital for optimising pathfinding within regions and ensuring everything works correctly (e.g. to ensure pathfinding characters can climb the stairs they’re supposed to by climbing or walk along the prim sidewalk they are supposed to walk along, etc.
The Havok libraries are not yet available, although Oz hopes to have them in a position where he can talk in more detail to TPVs about them “pretty soon”, and while it is nice to be able to visualise the navmesh, etc., it is not quite such vital part of the pathfinding process.
Universal Tools
Alongside the viewer tools, pathfinding will see a set of universal tools rolled-out in console format. These will be available to region owners and estate managers and will allow them to change an entire class of object in a region to have certain pathfinding attributes once pathfinding goes live. Linden Lab are approaching this in terms of having all non-scripted objects set them to be static obstacles that pathfinding characters must manoeuvre around, while anything that is scripted is set to “dynamic”, as it is thought to be moving.
This obviously doesn’t fit all cases – vendor boards, for example are scripted, but they are hardly what can be termed “moving” objects. Indeed, it might be argued that the majority of scripted objects within a region are non-moving, and therefore should have their pathfinding attribute set to “static”. However, LL feel they have no way of easily differentiating between a non-moving scripted object and a moving scripted object, and thus feel that setting all scripted objects to “dynamic” is the better option and allowing the attribute to then be modified through the viewer where necessary, as setting them to “static” could result in a worse overall behaviour case within a region.
Other Tools and Items
Alongside the above, Linden Lab have previously indicated that they will be making the following available as pathfinding rolls-out:
A set of script templates used for the creatures found in the Wilderness areas
A script for a “master rezzer system”.
The latter is a means by which region performance and the number of pathfinding characters rezzed in the region can be monitored, and which will reduce the number of pathfinding characters within a region in response to the region’s performance / number of avatars within the region.
Potential Timescales for Roll-out
During the TPV/Developer’s meeting, Lorca outlined some potential dates for pathfinding. note that these are currently potential, and shouldn’t be taken as tablets of stone:
The pathfinding tools should be available in one to two weeks in a beta viewer
The server-side release is dependent upon how well (or otherwise) the current release to the Magnum RC progresses, and may potentially come within the next two-to-four weeks, but certainly no sooner than two weeks.
Again these are not confirmed dates, and may well change in the next couple of weeks – particularly if major issues are found with the Magnum RC roll-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.
Update 14th May: My thanks to Oz Linden for pointing out that if you apply a Local Texture in-world, and then modify the original image file in a suitable editing tool and save it again, the viewer picks up the change and automatically applies it in-world (see Comments). I’ve also clarified that Local Textures can be used for clothing and skins within the text of this article.
Local Textures is a means by which textures stored on your computer can be applied to in-world objects on a temporary basis, allowing you to judge their suitability for use prior to uploading.
In this, it combines functionality currently found in many third-party Viewers (TPVs) in the form of the Local Bitmap Browser, with the added capability of being able to apply a selected texture directly to an object in-world within your own world-View.
The option, contributed by Vaalith Jinn, the originator of the Local Textures Bitmap, has been available within a number of recent Development builds of the official Viewer, and is now available in the latest Beta release (255742), so expect to see it in a mainstream release very shortly. (It should also be noted that the option is already available in both Dolphin and Niran’s Viewer.)
Using Local Textures
Local Textures is accessed from the Texture tab of the Build floater:
Texture picker: note the Local radio button (circled)
Note that there are now two new radio buttons on the Texture Picker itself – Inventory and Local. The former will, naturally, allow you to browse the textures within your SL inventory as we’re all familiar to doing.
Clicking on the Local option, however will change the Picker to display the following:
Local texture panel
This contains three new buttons, described below.
Add: Opens a window allowing you to browse your hard drive(s) to find textures.
An individual texture can be selected by double left-clicking on it or by left-clicking once on it and then clicking OPEN
Multiple textures within a folder can be selected using either SHIFT-left-click or CTRL-left-click (which can also be used to de-select individual items from a multiple selection
Selected items are added to the list panel to the right of the buttons
You can browse as many folders as you wish and add items to your list, but you cannot select folders themselves
Remove: (only available if a texture is selected in the list panel) removes an unwanted texture from the list
Upload: (only available if a texture is selected in the list panel) will open the usual texture upload panel, allowing you to upload the selected texture to your inventory with the usual L$10 fee and use it from there. Note that bulk uploads are not supported from the button.
When you have added one or more textures to the list panel, clicking on an individual texture within the list will apply it to the selected object / object face. Note that as these are only local file associations, the applied texture will only be visible to you; no-one else will see the texture (the object/face will remain untextured in their view).
Applying a local texture – only visible in your own world view
Textures added to the list panel will remain available to you until such time as you log-out of Second Life, at which point this list will be emptied.
Note that clothing and skins can be tested in the same way – just use the Edit Appearance floater and the New Clothes / New Skins options.
Local Textures and Temporary Textures
Local Textures might also sound like the Temporary Textures upload capability also found in many TPVs, but there are notable differences:
Temporary textures appear in your inventory, usually with the prefix “temp” for the duration of your current session in SL, then they are lost
Temporary textures can be see in-world by people other than yourself; this makes it ideal for things like collaborative building, where joint decisions need to be made prior to the selection and upload of textures
There have been rumours that LL are looking to “break” temporary texture uploads with the release of Local Textures. This does not appear to be the case at present; LL have so far given TPV developers no indication that they expect to see Temporary Textures removed from Viewers. Certainly, Dolphin is running with both Temporary Texture uploads and Local Texture; providing LL do not indicate they have a problem with this, it is likely that other TPVs will opt to do the same.
However, it might be worth noting that Temporary Textures do rely on using a feature in a manner in which it is not intended to be used, and which is specifically related to avatar baking. LL are currently looking into ways in which to make avatar baking more robust and less prone to problems such as bake fail (when your avatar fails to rez correctly). One of the options being considered in this regard is moving the bake process server-side.
If this does indeed happen in the future (and it is not a trivial change), then it may result in Temporary Texture uploads being “broken”; but again it is important to emphasise that no actually decision on how to deal with avatar bake issues has yet been taken.
In the meantime, expect to see Local Textures in your preferred Viewer in the near future!
With thanks to Innula Zenovka for raising my awareness that Local Textures had reached the Beta Viewer (forum post), and to Latif Khalifa and Trinity Dejavu for input to this piece)
ETA contributor’s detail, supplied by Mobius Ryba.
Inara Pey: Living in a Modemworld 