Category: SL Tech

Firestorm Q and A, October 26th: video and transcript

Posted on by Inara Pey

firestorm-logoOn Saturday October 26th 2013, the Firestorm team hosted another informal question-and-answer session. While the meeting was recorded, the Firestorm team are aware that many of their users have hearing difficulties, and / or prefer to read text. It is because of this that this transcript has been provided.

When reading it, please remember:

  • This is not a word-for-word transcript of the entire meeting. While all quotes given are as they are spoken in the video, to assist in readability and maintain the flow of conversation, not all asides, jokes, interruptions, etc., have been included in the text presented here
  • If there are any sizeable gaps in comments from a speaker which resulted from asides, questions to other etc,, these are indicated by the use of “…”
  • Timestamps are provided as guidance should anyone wish to hear the comments in full from any speaker on the video
  • Questions /comments were made in chat while speakers were talking. This inevitably meant that replies to questions would lag well behind when they were originally asked. To provide context between questions and answers, questions in the transcript are given (in italics) at the point at which each is addressed by a member of the Firestorm team, either in voice or via chat.

Please note: This transcript is provided for informational purposes only. As such, questions on technical issues relating to Firestorm and  / or project-specific questions cannot be answered here unless one of the Firestorm team drops by.

The TL;DR Summary

The numbers in braces are timestamps which refer to the section of this transcript where more details can be read, and to the section of the video recording where the relevant comments can be heard.

  • The upcoming release will be a public beta. It will have a number of known bugs, some of which will be annoying [0:01:42-0:02:28]
  • There is a lot more coming from the Lab, so it is important the Firestorm team get a beta version out, so they can prepare for bug fixing and integrating the new code LL will be pushing out (and which is currently pending release by the Lab) including:
    • SSA updates (AISv3)
    • Group ban list
    • Interest list
    • HTTP updates
  • It will be a beta release, but it will be fully supported  [0:05:10-0:05:33]
  • The Firestorm team have been accused of “holding things back”, they are not. There are valid reasons for any apparent delays (such as the amount of work some code merges have required and code for newer projects has yet to appear from the Lab [0:05:33-0:07:43]
  • A full release is unlikely before February 2014 [0:07:43]
  • The beta will be accompanied by a Windows 64-bit version of the viewer [0:11:01-0:13:41]
  • Why feedback for the 64-bit version is being requested, what kind of feedback is sought, why feedback should be delayed for a week or more following the release, the placebo effect [0:11:37; 0:14:30-0:16:09; 0:32:52-0:34:13; 1:01:04-1:04:08]
  • 64-bit versus 32-bit: what to expect and what the differences are [0:16:09-0:18:22]
  • Linux 64-bit [0:28:50-0:29:34]
  • Why it is unlikely any viewer will have multi-screen support (tear-off panels and menus which can be moved outside the viewer window & between monitors) in the near future [30:09-32:52; 34:13-34:41]
  • Mac 64-bit [0:36:09-0:41:49]
  • The issues in building 64-bit versions of Firestorm [0:41:49-0:44:47]
  • Mac Maverick support [46:05-48:08]
  • Both Windows 32-bit and 64-bit can co-exist on the same PC [49:47; 57:29]
  • 64-bit and lack of Havok support [58:29]
  • A discussion on Firestorm on mobile devices & LL’s coming beta with OnLive [50:39-54-15]
  • Why clean installs are really, really necessary at times [1:14:47-1:18:39; 1:24:58-1:25:47; 1:32:50-1:35:24]
  • Important notes on the 64-bit installer / installation [1:19:20-1:21:29]
  • Why Firestorm should only ever be downloaded from the Firestorm website [1:22:14]
  • OTR is coming, but not a priority [1:23:48-1:23:54]
  • Questions on 32-bit and 64-bit throughout.

With thanks to North for the video.

Continue reading “Firestorm Q and A, October 26th: video and transcript” →

SL project updates: week 44 (1): server, viewer, interest list, anti-griefing

Posted on by Inara Pey
Simulator UG meeting (stock)
Simulator UG meeting (stock)

Server Deployments week 44

As always, please refer to the week’s forum deployment thread for the latest news and updates.

Main Channel

There have been no updates to the Main channel.

Release Candidate Channels

All three release candidate channels received the same new server maintenance package on Tuesday October 29th, which fixed some crash modes.

The reason for the RC channel updates being moved to Tuesday is because there was due to be a planned outage on Wednesday October 30th at the time the deployments usually take place to allow some database work to take place. This would have likely seen log-ins blocked for about an hour. However, Simon Linden believes the work has now been postponed for a week – although the recommendation is to keep a check on the Grid Status page – see the original notice for details.

SL Viewer Updates

A new release candidate appeared in the release channel  on Monday October 28th. Version 3.6.10.282997 has no functional updates, but includes an update to the GPU table.

About the GPU Table

The GPU table is used to define your graphics card to the viewer and the default graphics settings which are applied as a result when you first start the viewer (or if you never adjust them).

Graphics cards are defined by classes (currently 0-5), which can be defined as:

  • 0 – Defaults to low graphics settings. No shaders on by default
  • 1 – Defaults to mid graphics settings. Basic shaders on by default
  • 2 – Defaults to high graphics settings. Atmospherics on by default
  • 3 – Same as 2, but with lighting and shadows(now referred to as Advanced Lighting Model in the viewer) enabled
  • 4 – Same as 3, but with ambient occlusion enabled
  • 5 – Same as 4, but with shadows set to “Sun/Moon+Projectors.”

The table is a .TXT file which is located in a viewer’s installation location on your computer. For Windows, this means it can be found either in C:\Program Files\[viewer name] or in C:\Program Files (x86)\[viewer name] (if you are running a 32-bit version of a viewer on a 64-bit system).

It is not recommended that you amend this file in any way, unless you know what you are doing. You can, however, open it and use it to determine which class your viewer falls under, and the default settings it is given.

To make it easier for those wanting to quickly reference common graphics cards, Garvie Garzo has produced a .PDF file of the table. However, do bear in mind that the table is subject to updates (as the release candidate mentioned above demonstrates), so the PDF may become outdated over time. Also, some TPVs have been working on updating the GPU table themselves.

When perusing the table, cards are listed alphabetically by maker, and the first digit following the card name refers to the class it has been assigned to, while the far right column defines the overall family of GPUs the card belongs to (you may find when viewing the table that the columns do not align well).

The settings within the GPU table are subject to some debate, as they are used to determine which graphics cards present a “reasonable” enough performance in order to have ALM enabled by default. Linden Lab consider anything qualifying as a class 3 or above is capable of adequately running with ALM enabled; some TPVs do not agree.

The problem here is how “reasonable” is defined; it’s a subjective term, and everyone will have their own opinions on the matter. As I reported back in week 39 and week 34, the Lab had statistics to show that class 5 cards GPUs (e.g. ATI Radeon HD 7800, 7900, 8900, 8950 + similar, nVidia GTX 460/460SE, 465, 550TI, 580, 660/660TI + similar) actually performed better with ALM enabled than with it off, while class 4 GPUs showed little difference between having ALM enabled and disabled. However, because measurements do tend to be subjective (again, frame rates, etc., can take on different levels of importance depending upon what you are doing in SL), Oz Linden had been hoping to establish a means by which more controlled testing could be undertaken within the Lab; it’s currently unclear how far this has progressed, if at all.

Interest List Viewer

Andrew Linden revealed that the interest list RC / project viewer (however it appears) is now unlikely to debut before November 12th. “There was a performance regression that we’re working on — lower FPS in project interesting,” he informed the Simulator User Group meeting on October 29th, “Probably because it is rendering more objects — more small objects in view get rendered (that’s my theory anyway).”

Andrew Linden: Anti-griefing Work

Andrew Linden
Andrew Linden

Andrew Linden is back working on various pieces of anti-griefing work.

For obvious reasons, he doesn’t want to go into specifics, but he did indicate that he’s looking to address new griefing modes that are aimed at estate managers. He’s also been thinking about ” raising the arms race against landbots”, although he admits he is “still in the planning/discovery phase on that.”

There are a number of other items in his list as well he may well be taking a look at.

Other Items

Slow loading Sculpts?

Some people are reporting they are seeing sculpts loading a lot more slowly since the last set of server-side interest list updates. It’s not clear how widespread this might be or if it is a possible placebo effect. For his part, Andrew Linden felt that sculpts potentially download faster with the interest list viewer code (which, as noted above, has yet to make a public debut), but again he caveated why this might appear to be the case. Andrew indicated he’ll look a little more into this.

Last Owner / Previous Owner

Many TPVs expose details of the “last owner” of an object through the build floater. A request has been passed to make this information, which is stored as a field in the object data, accessible through scripts. Both Simon and Andrew Linden didn’t see why this could not be done, with Andrew stating he’ll see what’s involved and will look to someone to nudge him about it next week.

Viewer release summary 2013: week 43

Posted on by Inara Pey

This summary is published every Monday and is a list of SL viewer / client releases (official and TPV) made during the previous week. When reading it, please note:

  • It is based on my Viewer Round-up Page, a list of  all Second Life viewers and clients that are in popular use (and of which I am aware) and which are recognised as adhering to the TPV Policy
  • By its nature, this summary will always be in arrears
  • The Viewer Round-up Page is updated as soon as I’m aware of any releases / changes to viewers & clients, and should be referred to for more up-to-date information
  • The Viewer Round-up Page also includes comprehensive links to download pages, blog notes, release notes, etc., as well as links to any / all reviews of specific viewers / clients made within this blog.

Updates for the week ending: October 27th, 2013 (with extras)

Official LL Viewers

  • Current Release updated on October 23rd to version: 3.6.9.282535 (formerly the”ShareStorm” RC viewer combining SLShare functionality with request teleport feature, et al) – release notes
  • Release channel cohorts (See my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself):
    • Removal of Google Breakpad RC
  • Project viewers:
    • None at present

LL Viewer Resources

Third-party Viewers

V3-style

  • Black Dragon updated on October 28th to version 2.3.4 Alpha – core updates: prim alignment tool; ability to derender objects and avatars, fullbrights; SLShare (release notes)
  • CtrlAltStudio Experimental updated on October 23rd to version (Occulus Rift): 1.1.0.34332 (Alpha 4) – core updates: initial pass at implementing UI elements in “Riftlook”, updated set-up options for Oculus Rift (Preferences > Graphics > Display Output (release notes)
  • Kokua updated on October 22nd to version 3.6.8.30064 – core updates: code base to SL viewer 3.6.8 (incl AMD / ATi Catalyst drivers hot fix), legacy search with shortcut Ctrl-Alt-F & access via menus; initial Area Search with shortcut Alt-A; UI enhancements (change log)
  • UKanDo updated on October 21st to version 3.6.8.27869 – core updates: addition of Quick Tools and Area Search; context menu updates; improved UI; RLV updated to latest version (release notes).

V1-style

  • Cool VL updated on October 26th to:
    • Stable version: 1.26.8.35
    • Experimental version: 1.26.9.35
    • Release notes (both) core updates: provisional support for the new Export permission flag in OpenSim, Improved inventory item permissions floater; Kitely added to OpenSim grid list; code backports, improvements and optimisations

Additional TPV Resources

Related Links

SL Projects update week 43 (2): server and viewer notes

Posted on by Inara Pey

Things are in something of a lull server-side in terms of deployments and projects at the moment, so the news from the Lab is a little light.

Server Deployment

With just the one deployment to the Main channel in week 43, the entire grid is currently running on the same server release.

Commenting on the released package at the Server Beta group meeting on Thursday 24th October, Maestro and Simon Linden provided further information on the performance issue fix which is aimed at the experimental interest list viewer (which has yet to formally appear, but can be self-compiled by those with access to the code repository).

“The bug was about avatars not loading for ~70 seconds when you visit an area with ten or so avatars nearby, Maestro explained. “And by ‘not loading’,  you wouldn’t even see name tags.”

“I think the problem was when those viewers used new methods to download or check the cache state of some data … it would over-load the network and thus the avatar updates were really slow,” Simon added, before continuing, “Since the current viewer doesn’t do that, they don’t have the bug. Clubs and large crowds are always a problem because when you arrive you just get a ton of data to fetch and load.”

Week 44 should see what Maestro described as a “minor maintenance release” for the server appearing next week, which includes “a few miscellaneous crash fixes”. At the time of writing it is not clear if this will be the only RC deployment or whether anything else might also pop-up when the deployment thread is published.

SL Viewer Updates

The “Sharestorm” release candidate, version 3.6.9.282535, which combined the updates from the Snowstorm contributions viewer featuring the request teleport functionality with the SLShare release candidate, was promoted to the de facto release viewer on October 23rd. This leaves just the Maintenance release candidate viewer 3.6.9.282553 sitting in a release cohort, which will be updated in week 44, once it has been rebuilt using the release viewer code base.

Group Ban List

Baker Linden’s Group ban list work remains on internal testing within the Lab (with Maestro and Caleb Linden volunteering as Baker’s guinea pigs). The project has also apparently been awaiting internal QA resources.  Baker hopes to have a detailed update on progress in week 44, but as he said at the Server Beta meeting, “I’d rather take the time to do it properly than rush it out the door and have it be worthless! :).”

Other Items

As reported in week 42, A problem had been noted following-on from the recent updates to prevent people from using recursive rezzing which means some engaging in combat have found combat vehicles in regions with short auto-return times can have their ordnance immediately returned when a weapon is fired, and any temp vehicles are unable to rez attachments, even when sat upon. Maestro confirmed that as a result of a feature request having been raised, Andrew Linden is now looking at introducing a special exception for temp-on-rez / auto-return timer inheritance when the rezzer is a vehicle.

“When I’m sixty-four”: discussing the 64-bit version(s) of Firestorm

Posted on by Inara Pey

firestorm-logoOn October 18th, Jessica Lyon poked me about an upcoming blog post she was preparing for Firestorm which would make mention of a 64-bit Windows build, offering me the opportunity to talk to her about it ahead of the announcement going public.

At the time, my schedule was such that I couldn’t get back to Jessica immediately, so by the time we did get things worked out, the official blog post announcing both the team’s immediate plans for their next release and the arrival of 64-bit flavour of the viewer had been published. However, this didn’t stop me from taking the opportunity to sit down with Jessica and members of the team at the Cheeky Tiramisu Café late one afternoon in order to find out more about the promised “Firestorm 64”.

Meeting with some of the team: Miro (centre-left), Lassie, Ed, Whirly, and Jessica.
Meeting with some of the team: Miro (centre-left), Lassie, Ed, Whirly, and Jessica.

64-bit versions of SL viewers have been in demand for a considerable period of time. There has been some degree of resistance to them in the past, although there are a number of developers and self-compilers who have produced their own 64-bit versions of one viewer or another. The resistance has been for many reasons; Windows viewers are already Large Address Aware, for example, allowing them to use the additional memory common to computers using the 64-bit version of the operating system, thus helping to negate one of the biggest reasons for developing a 64-bit build.

Given that 64-bit builds have been seen as potentially problematic in the past, I started by asking what had prompted the Firestorm team to decide to go ahead with one.

“Our Windows 64-bit code was developed by Nicky Dasmijn as a sort of side project she wanted to do to scratch an itch she had,” Jessica informed me. Nicky, who started-out contributing code to the project, is now the project’s Lead Developer. Sadly, she’s also a little camera-shy as well, and managed to successfully escape my conversation with the team, hence why her profile picture appears here.

Nicky Dasmijn - Firestorm's Lead Dev and Win 64-bit coder
Nicky Dasmijn – Firestorm’s Lead Dev and Win 64-bit coder

Jessica went on, “None of us were expecting her to drop the code into the repo when she did; but since she did, and since we had already decided to do a public beta, I figured, ‘Why not? Let’s get it out there in alpha form to see public reaction, and to see what the cost versus benefit might be’, neither of which we know for sure yet.”

I noted that when discussing 64-bit viewer builds at a recent Firestorm Q&A, there were concerns from the team about potential issues with maintenance, such as bugs and additional regressions, and for how it might negatively impact support were they ever to try for 64-bit viewer versions. I wondered what else had changed, other than Nicky working on the code herself, to persuade the team to push ahead on the 64-bit front.

“The expectation is that the 64-bit version won’t have different bugs than the 32-bit,” Jessica replied. “In fact the hope is that it may have better performance and fewer crashes, which if true, should actually take some load off our support team. But we don’t know for sure as we’ve only tested it on a dozen or so computers.”

Miro, Lassie and Ed
Miro, Lassie and Ed

I wondered if trying to offer a 64-bit version of a viewer might be the proverbial catch-22 / can of worms situation: the viewer needs to be put to public use in order to see what the response to it is like, but if it is put into public use, it’s going to be awfully hard to prevent it becoming an accepted and expected version of the viewer.

“Well, the feedback will determine whether we move forward with it, but I think chances are good,” Jessica said, before giving me a wry smile, “As for the can of worms; yes, we’ve opened it, and we’re not going to be able to get those worms back in it now. Folks are going to want it, many will want it even if there is no noticeable benefit.

“But other TPV’s are also working on 64-bit windows too, I spoke to Latif [Khalifa] from Singularity and found out he also has coded up Windows 64-bit for them. So to add another metaphor to the mix: the cat is out of the bag, and x64 for Windows is going to happen with or without us, and due to user demand it will likely become a standard presence going forward.”

Whirly, Jessica and Cinder
Whirly, Jessica and Cinder

Continue reading ““When I’m sixty-four”: discussing the 64-bit version(s) of Firestorm” →

CtrlAltStudio: Bringing the UI to your Oculus Rift

Posted on by Inara Pey

CAS-logoStrachan Ofarrel (Dave Rowe in RL), has issued an update to the experimental version of his CtrlAltStudio viewer with Oculus Rift support. It’s an update those with the Rift SDK and headset are likely to find interesting, as it includes some initial work on bringing the viewer’s UI to the Rift.

Version 1.1.0.34332 (Alpha 4 release) of CtrlAltStudio appeared on Wednesday October 23rd, and Strachan was kind enough to poke me about it.

It’s important to note that this is only a first pass at things, so if you have a headset, keep in mind what you see of the UI may change as Strachan  tweaks things further. Commenting on the work, Strachan himself says:

I originally wasn’t intending to do any UI as I thought Linden Lab’s viewer with Rift support would have been released by now, but it hasn’t been and there’s a pressing need for at least some UI so I’ve added some as a stop-gap measure.

The viewer UI in Oculus Rift: preliminary work undertaken by Strachan Ofarrel in CtrlAltStudio (image courtesy of Strachan OFarrel / David Rowe) – click to enlarge

There are some limitations with this first pass in that the menu bars and toolbars are not yet displayed in Riftlook, and for those who prefer the Pie menu, right clicking on in-world objects will only display the context menu (no Pie). Even so, this is an impressive start to the work of enabling the UI, and does much to increase people’s ability to interact with the world when using the Oculus Rift.

In order to use UI elements effectively with the headset, Strachan recommends users:

  • Turn on Show User Interface In Mouselook and Enable Context Menus In Mouselook (both under Preferences > Move & View > View)
  • Consider enabling Show Chat In Bubbles Above Avatars (Preferences > Chat > General).

He notes that with the above settings enabled, shortcuts can be used to show / hide dialogue boxes (e.g. CTRL-I for showing / hiding inventory), which again significantly adds to the usability of the viewer when in Riftlook. He also reminds people to use the cursor to left-click interact with windows and right-click interact with in-world objects, and that cursor movement can be defined / refined in Preferences > Graphics > Display Output.

The Display Output options for when Using Oculus Rift: note the new depth slider and the options to define / refine camera / cursor movement
The Display Output options for when Using Oculus Rift: note the new depth slider and the options to define / refine camera / cursor movement

As well as adding preliminary UI capabilities to Riftlook, this release of the CtrlAltStudio Alpha version also brings with it a range of updates and fixes, including:

  • Some adjustment of the depth at which the Riftlook UI is displayed
  • Enabling the display of avatar toasts and floating text in Riftlook
  • Esc in third-person Riftlook will return you to Riftlook first-person (instead of having to exit then re-enter Riftlook)
  • Esc in flycam Riftlook with SpaceNavigator will return you to Riftlook first-person
  • Entering / leaving stereoscopic 3D display mode now recorded in the program log
  • Work-around added to get stereoscopic 3D working with AMD Radeon on Windows
  • Added “–riftlook” command line parameter that toggles into Riftlook after a successful login
  • Fixed OpenSim “4096 bug” that limited the range of hypergrid teleporting
  • Fix to ensure view remains in Mouselook when TPing or when an alert dialog pops up, if UI is turned on in Mouselook
  • And more: please refer to the release notes for this version for a complete list of updates, changes and fixes, together with the correct attributions for those contributed by others.

Sadly, I don’t have the Oculus Rift SDK, so can’t speak first-hand has to how things look. So if you do have a headset, why not pop over to the CtrlAltStudio website and download this version of the viewer and take it for a test run? Strachan would doubtless appreciate all constructive feedback received!

At the time of writing, the viewer is only available for Windows, but the Mac OSX  version is promised soon – so be sure to check back with the CtrlAltStudio website if you’re a Mac user.

Related Links