Category: V7 Style

Firestorm announces pathfinding support

Posted on by Inara Pey

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.

Stage 1 (next release).
Pathfinding Tools. Not to be confused with theHavok library, which is used to display Navigation Mesh (NavMesh), thePathfinding Toolsare what you will need to optimize your regions once Pathfinding goes live.

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.

Related Links

Lab offers snapshot “tiling” fix

Posted on by Inara Pey

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.

Firestorm 4.1.1.28744

Posted on by Inara Pey

firestorm-logoWednesday 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).
  • Build floater:
    • Now includes the Local Textures picker
    • Allows colours to be defined as hex values as well as RGB and will generate LSL vectors
Colours can now be defined using hex values, and have LSL vectors generated

Continue reading “Firestorm 4.1.1.28744” →

Kokua and Firestorm: moves and views

Posted on by Inara Pey

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.

Local Textures now part of the SL Viewer

Posted on by Inara Pey

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.

Related Links

Local Textures: coming to a Viewer near you

Posted on by Inara Pey

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.