I love visiting castles. We have a rich heritage (reflecting a bloody history) of castles in the UK, of which the most common variety beloved of picture postcards and Hollywood directors are the great Norman Castles.
I particularly enjoy visiting Northumberland in the North-east of England, as there are some famous examples of castles there: Warkworth, Ford and Etal, Norham (one of my all-time favourite ruins), Dunstanburgh, Chillingham, Bamburgh, Langley, Lindesfarne – and of course Alnwick. Some are in ruins, such as the aforementioned Norham or Dunstanburgh out on the coast; others are still in use today – notably Alnwick, which has perhaps most famously been used to represent parts of Hogwarts, together with Chillingham, Langley (today a glorious luxury hotel), and Bamburgh (which makes for a stunning backdrop to the beach which it overlooks and has agin been the subject of many a film and TV production, even if inside it is something of a let-down).
This being the case, I thought it time I visited the castle ruins at Frisch.
Described as a “German castle ruin” in the Destination Guide, Frisch offers-up a Norman-style set of ruins which are suggestive of a castle which saw much use over time, with some modernisation to reflect the needs of successive generations, prior to finally falling into abandonment, disrepair and collapse.
Fisch is interesting as it is owned by Governor Linden and it is actually an old orentation spot for new users, which has itself fallen into disuse – although evidence of its purpose can still be found; there are information givers, a few signs, including one with a LM to Help Island and one with LMs for the old Welcome Areas – not that I recommend you try the latter!
The castle build itself looks old in the SL sense of the word, but offers a lot of potential for the machinimatographer and photographer wanting an interesting and “historical” back-drop – although judicious use of Draw Distance is advised (or your viewer’s derenderer, if it has such a beast); there are a couple of eyesores which can stray into view if you’re not careful.
The castle is easy to explore, and a pleasant way to spend an hour; there are paths to follow through the ruins, and the surroundings (eyesore excepted) provide some prime vantage points from which to take-in the ruins themselves.
This isn’t a state-of-the art build, to be sure, but it is one celebrating the power of the humble prim. It’s also a quiet place to visit and just wander around. There are no windlight presets, and the lie of the land and style of the build mean that both are open to a range of interpretations – something which again makes the ruins an ideal candidate for SL photographers.
All-in-all Frisch and the castle offer an interesting visit; don’t expect to do much her other than wander, relax and enjoy. This may not be a historical representation of any single castle, but there is some history here.Why not go pay it a visit when you have a few spare moments?
Saturday November 24th saw the next release of Exodus hit the download page, and Ash Qin from the team was kind enough to give me the nod – I confess, I’d lost track of the nightly builds and so have fallen well behind with the viewer’s on-going development – and access to the beta release of the build.
Exodus 184.108.40.206 is based on the Linden 3.4.2 code base, so it includes the majority of the most recent updates from the Lab, including the new Group Services code for managing and editing groups with more than 10K members, and a host of other Linden goodness.
The Windows installer weighs-in at a touch over 34MB in size and contains absolutely no surprises during the install process – as one would expect. As per usual, I did a completely clean install, which brought me to my first surprise: on start-up Exodus displayed the Steam-related “Create Account” prompt.
This doesn’t mean Exodus is heading for Steam a-la the official viewer, just that the Steam code is now part and parcel of the SL beta viewer code, and the Exodus team didn’t see any reason not to merge it into their code, given it is only ever something established users are ever going to see once after a fresh install (and possibly not at all if they don’t perform a clean install or the team moves to an updater system – which is something they are considering).
This release brings with it pathfinding, which the team had originally hoped to release a lot sooner. This includes not only the build tools associated with pathfinding (Linksets and Characters floaters, attributes in the Build and Object Profile floaters, etc.), but also includes the Navmesh visualisation code, as Exodus becomes the latest viewer to sign-up to the Havok sub-licence agreement with Linden Lab.
This means that anyone who has been using Exodus to access OpenSim grids via –loginuri will no longer be able to do so when using this release. Similarly, the optional grid selector which can be displayed on the login splash screen only lists Agni (the main grid) and Aditi (the beta grid).
The move to the Havok sub-licence also means that with this release, Exodus moves to the official mesh upload code from LL, rather than using the HACD code which has been in common use within TPVs.
As mentioned above, Exodus gains the large group management and editing code from Linden Lab with this release, allowing groups with 10K or more members to load in the Group floater and which allow group owners and officers to edit and manage very large groups.
Again, just as a point of reference for those unfamiliar with the new code changes: these do not relate to group chat or anything related to improving group chat. That is an entirely separate project within Linden Lab (and one which may not be being actively progressed while other work is being undertaken). This is purely about using HTTP protocols (rather than the old UDP) to bring more stability to the downloading, viewing and editing of very large groups.
Alongside the updates and fixes from LL, Exodus 220.127.116.11 gets a number of updates all of its own:
The Flickr option on the Snapshot floater now includes an option to include the parcel name / SLurl in the description
You can now Paste as Link’ and Copy as Link using the right-click or CTRL-SHIFT-V and CTRL-SHIFT-C using Exodus’ built in “pastebin” functionality
A Copy as Link button added to the About Second Life Viewer floater, allowing the information in the floater to be viewed via the web
A Copy Key option added to the avatar right-click context menu, allowing for easy copying of the Avatar Key.
Fixes and Changes
Exodus 18.104.22.168 also includes a number of fixes and changes from the team:
MOTD should work now on OS X
Added copy key to gear menu for avatar inspection panels
Colouring of certain elements
BMP cursors on Linux
Higher compression of LZMA packages on Linux
Curl on OS X no longer defaults to trying to use IPv6 in Curl (related to MOTD issue).
Performance and Feedback
Performance-wise Exodus 22.214.171.124 again gives very similar results on my usual review system (see the panel on the right sidebar of this page) as recent viewer releases I’ve taken a look at in the last month:
Ground: 28-29 fps
370 metres: 36-38 fps
2875 metres: 43-45 fps
Deferred on + lighting set to Sun/Moon + Projectors; ambient occlusion off:
Ground: 9 fps
370 metres:15 fps
2875 metres: 18 fps
Like like Catznip R7 and the recent Firestorm beta, these figures dropped only very slightly (just 1 fps on average) if I also activated ambient occlusion in deferred; again marking the fact that for me, things seem to have improved recently over the start of the year.
Compared to other recently releases, this one from Exodus is relatively small and compact – which doesn’t lessen its overall impact; once again it places Exodus back among the leaders of the V3-based TPV pack. There are still a couple of things I’d like to see, one of them being my usual request of TPVs in general: the ability to left / right range the toolbar buttons at the bottom (or top for those that use that space) of the screen. Only one does it so far, and it is really handly having the option.
Nevertheless, nothing should be taken away from the Exodus team, offering as they do a pleasing and worthwhile update.
Week 47 marks Thanksgiving in the USA so as reported last time, there have been no server-side deployments for the Release Candidate or main channels, and no rolling restarts. This is liable to continue into week 48 (week commencing Monday 26th November), as there is unlikely to be any deployment to the main channel. There will, however, be deployments to the RC channels, details TBA.
HTTP Updates – Texture Fetching
After indicating that there would be no viewer releases during week 47 in the run-up to Thanksgiving, the Lab rolled out the first of the 3.4.3 beta releases – 3.4.3267135 – on November 20th. The major change to this is the inclusion of the first phase of Monty Linden’s new HTTP-based texture fetch capability, designed to significantly improve texture rezzing within the viewer. As the release notes state:
A new scheme for performing HTTP operations is introduced with this release. It is intended to reduce crashes and stalls while performing HTTP operations and generally enable performance and reliability improvements in the future. In this release, it is being used by the viewer’s texture retrieval code. Our expectation is that it will provide consistent and predictable downloading of textures. As well as the usual problem reporting, we’re also interested in confirmation of improvements where this release improves your experience.
The code for these improvements has already started appearing in some TPVs, and will doubtless be available across all flavours of the viewer in the near future.
Observable improvements in rezzing times have been reported by those who have used the project viewer releases of this code, so it should yield benefits for those using the beta. Monty Linden, who is handling this project is apparently now working on further improvements to the server-side of the equation, which should see additional improvements in the future.
Also pushed out during the week was a new version of the development viewer – 126.96.36.1997201.
It is currently not clear when the renewed roll-out od beta and development viewers will result in updates appearing with the production version of the viewer, I believe that this may be additionally delayed while other requirements are put in place related to the Steam link-up (the code for the Steam link-up already having been merged into the beta viewer).
Also during the Tuesday Simulator meeting on November 20th, the question of volumetric pathfinding came up, and how pathfinding might be extended into the air, to allow birds, etc., and under Linden water. There are a range of issues with doing this – perhaps the biggest being the actual demand. There is also the matter of keeping birds and the like from crashing into buildings and skyborne objects, or in keeping fish in the water.
During the meeting, Baker Linden passed a question on the subject to Falcon Linden and indicated that Falcon felt, “It’d be about 3 months of work to get volumetric pathfinding — and that still wouldn’t handle dynamic avoidance (which is the hard part). Theoretically, it’s not that hard — it’s having to rework some Havok systems to work with intermediate data.”
This doesn’t mean that the work is about to be undertaken in any way whatsoever – just that were LL to consider it, getting the basics going for volumetric pathfinding going would take around three months. However, even then, unless the issue of dynamic hazard avoidance, it is unlikely this is something we’ll be seeing in SL for a while yet.
Server-side Object Rezzing Performance
Baker Linden indicated that he has started looking at server-side object rezzing. This work isn’t connected to Andrew Linden’s Interest list work, which is related to which assets the simulator should be loading ready for rezzing, but is rather focused on reducing the server-side lag which is induced when an object physically rezzes in a region. As Baker explained during the meeting, “If you get a really complex object, with many large meshes, or large LLSD files, it takes a while to rez into the world. I’m trying to reduce that.”
There are no timescales associated with the work, although it is expected that it will include avatar attachments as well as in-world objects have less of a performance / fps hit on the region when rezzing complex items, particularly in Baker can get the parsing of large object files to work asynchronously, which currently does not occur. Whether this will translate to visible viewer-side improvements is debatable.
Homestead Performance / Memory Issues
There have been growing reports of region performance issues occurring across the grid. These primarily appear to be impacting Homestead regions – although it can be encountered on full regions as well.
Essentially the problem manifests itself (for most users) when they find they are unable to rez objects in-world and / or as attachments, while raw prims created in-world may rez, but are reported as turning phantom on creation. The issue appears to be large and abnormal memory usage by the region’s physics system, although the precise causes as to why it is occurring are currently unknown.
Regions are allocated a fixed amount of memory that can use. In the case of a full simulator, this is about 1GB, while Homesteads are allocated around 250MB. Generally, physics memory usage for a region – even a busy one – is around 40-80MB. However, on affected Homestead regions, the physics memory use is reaching or exceeding 200MB.
When the physics memory for a simulator gets abnormally high (close to or on 90% of the allowed maximum) internal region safeguards kick-in and prevent object rezzing in an attempt to limit further calls of the region’s memory and keep it alive. This is the behaviour people are witnessing in their regions. The safeguards themselves are designed to help prevent regions from becoming unstable during griefing attacks. However, the problems people are experiencing appear to be entirely unrelated to any form of griefing, and are thus causing a certain amount of head-scratching at Linden Lab.
Reed Linden, in responding to a support request from Motor Loon, provides clear guidelines on what to do if you have a Homestead and experience these issues. It is thought that the most likely culprit for the problem is an unidentified memory leak, but this has yet to be confirmed. Reeds comments regarding particle systems are fascinating. Particles tend to be more viewer-intensive than server, and as many commented at the Simulator User Group meeting on Tuesday 20th November, it would take something bizarre to be going on for particles to be impacting region performance; however, at least one region affected by the issue appears to have a large number of particle emitters in operation.
A further interesting twist came at the meeting itself, when a pathfinding snake and a number of pathfinding characters were rezzed, and the region suffered a severe performance hit (sharp FPS drop experienced by all attendees, sharp increase in both physics memory use and time taken to ping the region) which appeared to be linked with the snake (which was set to follow its creator around) re-calculating its path to both follow its creator and avoid other avatars / objects. However, when the snake was re-rezzed a short time later, no similar issue was noticed, with the region using around 116MB physics memory, with no other outward performance issues.
I the meantime, and as the Linden dev team continue to investigate the issue, if you experience this kind of problem, please ensure you raise a support ticket, supplying as much information as possible, including region name / simulator version (from HELP > ABOUT (either Second Life or the name of your viewer), the time the problem occurred, how it manifested and, if possible, information from the Statistics bar: memory used, FPS and physics performance details, etc.