Technical Notes

The updated Bentley, by Luna Fatale. I had the pleasure of contributing to its improvement. Click on any image to go to its full-size version. Links always open in new tabs.

The updated Bentley, by Luna Fatale. I had the pleasure of contributing to its improvement. Click on any image to go to its full-size version. Links always open in new tabs.

I’d stated before that I don’t drive in Second Life, and I usually don’t even incorporate cars as props in my builds and photoshoots. There are many reasons why I typically avoid them like the plague, and I’ll get – once again – into some detail below.

For starters, the vast majority of cars in SL handle like a drunken pig on ice skates. They steer in a completely unrealistic, twitchy and vague manner, not least because of the lack of integration with simulator-style controllers, such as steering wheels or analogue joysticks, that would make in-world cars steer progressively and with the precision and fluidity we’ve come to expect from a real-world vehicle. Also, in-world vehicles are – and will continue to be – plagued by the vagaries of region crossings, which can cause all sorts of trouble, from camera issues to the vehicle continuing its course without its occupants, or even crashes. These issues take much of the enjoyment of going for a ride on an automobile, a motorcycle, a boat, an aeroplane out of the experience. Read Full Article


I had written about the issue of lag before, and before me, Penny Patton had done the same, and I think very little has changed for the better since then. Most of the “lag” we experience in Second Life is blamed on Linden Lab, whose engineers are always accused of basically not knowing what they’re doing. Rarely does it cross our mind that we, the users – from consumers to content creators – are doing something wrong.

Read Full Article


The Build Tools floater – Firestorm’s version; the official viewer’s doesn’t really differ significantly. Please click on the picture for a larger version.

Whether you live your virtual existence in Second Life or OpenSim, the viewer’s build floater (right) is, in all likelihood, an integral part of your experience. From simply adjusting your worn attachments to putting together intricate and complex builds, using the build floater is practically inescapable.

As I’m pretty sure everyone in SL and OpenSim knows, to put several (or many) prims, sculpts and / or meshes together, you need to link them. Now, imagine the following scenario: You’ve been working on a complex build for weeks, and you’re near its completion – you’ve even made scripts to control parameters of its various parts. And you accidentally click the “Unlink” button, which is “conveniently” placed right next to the “Link” button. And you’ve just unlinked everything. Yes, I know. You can re-select everything and link the items again. But everything will be out of whack; different root prim, different link order, and don’t get me started on the extra work you’ll have to do on the scripts. Or the LI discrepancies under the new accounting system.

I was discussing the matter with Inara Pey recently, and she said we should be asked to confirm we really want to unlink the selected object(s) – just like we’re asked to confirm that we want to log out.

It actually makes sense. Quitting and logging in again doesn’t really cause much inconvenience. It’s usually just a matter of minutes before we’re back in-world, usually where we were when we logged out. But unlinking a complex, scripted object can be a royal pain. So, I have decided to file a feature request JIRA on SL’s official bug tracker system, and (after being prompted by Whirly Fizzle) another one on Firestorm’s.

The proposed functionality is as follows:

When you click on the “Unlink” button, a pop-up window (accompanied by the typical sound alert) will appear, with the prompt “Are you sure you want to unlink the selected object(s)?”. Underneath, there will be the option for you to never be shown this message again (“Do not show me this again”). It’s quite simple, really, and would help us avoid frustrating and time-consuming mistakes.


We’re asked to confirm we want to log out of SL or OpenSim, so why not get a notification of this kind when we’re about to unlink a linkset?

If you think such a new feature would be useful to you and you’d like to help bring attention to these two JIRAs, watch them on their respective bug tracker systems (at least in LL’s case, voting doesn’t really do much). Of course, there can be more ways to further improve things: Different colours for the two buttons, for instance, and / or a confirmation for when you click the “Link” button.

UPDATE: The Firestorm team responded quickly to my feature request; Ansariel Hiller added this notification facility, and it will be available in version 4.7.0 of the popular viewer.


With thanks to Inara Pey and Whirly Fizzle


See also:



A little over a month ago, I wrote about how various animations don’t play well when we wear high heels: The default avatar’s feet end up looking like our ankles were broken. This behaviour is observed both when we’re using the default avatar’s feet and when we’re using rigged mesh feet and / or footwear.

Back then, I theorised that this has to do with the way the “foot shaper” is created by the system, i.e., when the “foot shaper” is created, what’s performed is not a downwards (i.e. around the transverse axis of the avatar) rotation of  the ankle, but a stretch of the foot. So, to the system, your avatar still has its feet lying flat, which in turn allows it to take these unrealistic angles.


As you can see, the ankle was not rotated to create the foot shaper for the high-heeled foot in the “relaxed” position (in the background). Instead, the foot was simply stretched downwards, while the articulation remained flat. Please click on the image for the full-size version.

Of course, animation and pose makers generally can’t be bothered to provide versions of their animations for avatars that are wearing high heels and for barefoot avatars; they just make all their poses and animations using a barefoot avatar model and get done with it, leaving the user to sort out the mess by themselves. And sort it out they did, usually by hiding the default avatar’s feet inside unrigged (prim-based, sculpted or mesh) shoes or feet / shoes combinations, or by employing special, localised animation overriders which locked the ankles in place.


And here, you see the “broken ankle” effect with the Slink Mid feet on. The same problem plagues all rigged mesh feet, regardless of designer, and is also evident in rigged mesh bodies that have integral feet. Please click the picture for the full-size version.

The advent of rigged mesh, however, brought the problem back into prominence, causing people several headaches. One workaround is to rig the shoes differently, so that they’ll effectively ignore the ankle joint. But what happens if the shoe is an add-on for a set of rigged mesh feet? In that case, things are a bit different: the localised animation override method emerges as the preferred one.

One such localised animation overrider is the “Slink Ankle Lock”, which is offered free by Siddean Munro at her mainstore. You can find it above the feet vendors – unfortunately, it’s not available on the SL marketplace. Now, how does it work? You just add it to your outfit and it takes care of the rest. It’s a transparent attachment, which contains the animation override script and a high-priority animation that locks the ankles in place.

The Slink Ankle Lock

The Slink Ankle Lock offers a workaround to the “broken ankles” problem. Being effectively an animation overrider, it’s compatible with all rigged mesh footwear and feet. You can get it for free at the Slink mainstore. As always, please click on the image for the full-size version.

Now, you’ll ask… Will it work with my fitted mesh body that’s not made by Slink? Will it work with my rigged mesh feet that aren’t made by Slink? Yes, it will. And it also works with the default feet as well It’s just a very simple animation overrider, after all; no HUDs or controls to think about. The only downside is that you can’t bend your ankles forward (like we do when we crouch in RL), but I’m afraid this is a compromise we’ll have to put up with. Let’s hope LL will get the avatar skeleton right in their next-generation platform.


See also:



The advent of materials processing (normal and specular maps) in Second Life brought about a number of changes to the way things are rendered, compared to how they used to be – at least for those of us whose graphics cards allow us to enable the Advanced Lighting Model (formerly known as “deferred rendering”. For a detailed coverage of this capability, please go over to Inara Pey’s blog. Now, when this new capability was added, many people started jumping up and down about how “irrelevant” or “useless” it was, about how only… twenty users in total would be able to see materials, how it would really kill the performance of everyone’s viewer, etc.

I’m going to speak from my own experience. Up until this month, my main machine for using Second Life was a laptop. A 2009 midrange model, with a dual-core Intel T4300 CPU, 4GB of main RAM, and an ATI (now known as AMD) Mobility Radeon HD4500 graphics card. Those in the know understand that this was hardly “high end” even then, and it became antiquated relatively fast. I can’t vouch for how other people with older, and probably lower-spec, dedicated graphics cards, or with integrated Intel chipsets, would fare, but, ever since the 2012 updates to the rendering pipeline were made, I was able to run in deferred (ALM) practically all the time – without shadows and ambient occlusion. Yes, I know my computer’s performance wasn’t much. It was usable, though, and the in-world pictures I once envied so much were now within my reach. So, I believe that ALM, which is a prerequisite for viewing materials, is within the reach of more people than was believed back then.

Nowadays, I’m the happy owner of a laptop with a fourth-generation dual-core i7, 8GB RAM and an NVidia GeForce GT840M, as well as a desktop with an i7-4770K CPU, 16GB RAM and an ASUS ROG Poseidon GTX780 graphics card. As one would expect, my machines’ performance in SL is a few orders of magnitude above what I once was used to. Still, I have the feeling that, as beautiful as SL looks right now, it could be even more spectacular, had some rendering capabilities (i) not been removed with the advent of materials processing, (ii) been added.

Read Full Article