Category: Second Life

Bakes on Mesh – a basic primer

Posted on by Inara Pey

Updated with an overview of “Bakes on Mesh appliers” for Mesh bodies and head yet to be updated to support BoM.

Monday, August 26th, 2019 saw the formal release of Bakes on Mesh (BoM) for Second Life, and with it, an attempt to make system wearables (skins, tattoo and clothing layers) usable on modern mesh avatar bodies, utilising the avatar Bake Service and without the need for a dedicated applier system.

While Bakes on Mesh has been in development for over years, and much of it is known to many users, this article has been written to provide something of an introduction / overview of BoM, covering things like system wearables, the Bake Service, that changes that have been made, where to find information on using BoM, and what it may mean for Second Life users in the future, depending upon how well the capability is received by creators.

Some Basics

System Wearables and the Bake Service

System wearables as they appear in inventory

Without going too deeply into specifics for those unfamiliar with them, system wearables are a special kind of inventory asset (some of which are shown on the right) that can be directly worn / added to the system avatar to produce a “dressed” look.

These wearables come in a number of “layers”- skin (which must always be worn on the system avatar), tattoo, undershirt, shirt, and jacket.

The naming of the layers isn’t that important – a creator could be assign a bra or a shirt or a pair of pants to any one of the tattoo, undershirt, shirt and jacket layers, depending on how flexible they want their clothing to be. What is important is that the always follow an hierarchy: skin is always at the bottom and so “covered” by the other layers, which are in turn “covered” by the next (so undershirt wearables always apply “over” tattoo wearables; “shirt layers “over” undershirt wearables, etc), with the avatar able to wear up to 62 wearables in any combination of layers at one time.

This might sound very complex, but for those familiar with the system, it is very easy to grasp; however, what is important is what comes next. When an avatar’s look is complete, the information about all these wearables are sent to the simulator and then to a back-end set of servers called the Bake Service over a series of channels called the “bake channels”, which define where the layers appear on the avatar. These channels are:

  • BAKE_HEAD, which defines all the wearable elements that have been applied to the head (e.g. skin, and tattoo layers used for make-up)
  • BAKE_UPPER, which defines all the wearable elements – skin plus any tattoo, undershirt, shirt and / or jacket layer(s) that have been applied to the avatar body above the waist and below the neck (with the left arm mirrored from the right).
  • BAKE_LOWER, which defines all the wearable elements – skin plus any tattoo, undershirt, shirt and / or jacket layer(s) that have been applied to the avatar body from the waist to the feet (with the left leg mirrored from the right).
  • BAKE_EYES and BAKE_HAIR (both pretty self-explanatory).
  • BAKE_SKIRT, which defines skirt / dress style wearables.

The Bake Service then composites (bakes) the layers received on each of these bake channels into a single texture, and sends the results out to every viewer able to “see” the avatar. So, for example, facial / head skin and any make-up tattoo(s) received via the BAKE_HEAD channel are baked to become a texture seen on the avatar’s head, while the layers received over the Bake_Upper channel are baked into a texture seen on the avatar’s upper body, and so on, ensuring the avatar consistently appears to everyone dressed at the user intended, while also removing the need for individual viewers to manage the complex layering and rendering of all the individual wearable layers on other people’s avatars.

Mesh Bodies and Complexity

Since their introduction, mesh bodies have not been able to leverage this approach. Instead, they require a dedicated “applier” mechanism to achieve the same ends, together with the use of an alpha layer to hide the system avatar.

Further, to enable clothing items to be layered – so you can have an applied shirt / blouse appearing to be “under” a jacket, for a example, mesh bodies have had to be constructed in a complex manner, with several layers closely packed together (colloquially called “onion layers”) that effectively mimic the system wearable layers. This actually makes the avatar a lot more complex than they otherwise might be, resulting in their relatively high rendering costs.

Enter Bakes on Mesh

So, Bakes on Mesh has been developed to allow system wearable to be applied directly from inventory to worn mesh faces (e.g. avatar bodies and wearables) that have been correctly flagged by the creator to support Bakes on Mesh. Through Bakes on Mesh, Linden Lab hopes:

  • Users can avoid the need to use appliers, but can add wearables to their mesh avatar directly from inventory.
  • Creators will be able to simplify avatar mesh bodies and heads by removing the need for some of the “onion” layers. This should – if done – reduce the rendering complexity for bodies and heads, thus hopefully improving people’s SL experience (as avatars won’t be quite so resource intensive or require quite so much “assembly time” when encountering them on logging-on or after teleporting somewhere).

Notes:

  • As with all new features, use of Bakes on Mesh will only be apparent to those actually using viewers running the Bakes on Mesh code; anyone not on such a viewer will likely see something of a mess.And as with new features, it will take time for the Bakes on Mesh code to be implemented by all TPVs.
  • Bakes on Mesh does not mean user “have” to go back to using system wearables nor does it mean that applier systems can no longer be used. It is simply a means of making system wearables work with mesh bodies and heads, hopefully with the benefits given above. Those who wish to can continue to use applier-based clothing as they always have.
Bakes on Mesh adds new options for applying suitable textures to the baking channels for application on a mesh body by the Bake Service

An introduction to using BoM can be found in the Bakes on Mesh Knowledge Base article. This includes information on trying BOM using a test mesh body – the best way to do this is to use Aditi, the beta grid. I’m not going to go into specifics here, simply because there are multiple resources available to assist users and creators – some of which are noted at the end of this article, and I want to keep this as a more general, easy-to-understand primer.

When considering Bakes on Mesh it is important to remember it is not necessarily intended as an outright replacement for appliers and current mesh bodies from the get-go. Rather, it is initially an alternative – although if the popularity / take-up among creators and users are sufficient, then over time it could obviously become the system of choice over appliers and more complex mesh bodies. However, existing mesh bodies / heads and applier systems will continue to work as they always have.

Key Points of Bakes on Mesh

This list is not exhaustive, but is intended to give a feel for Bakes on Mesh and its use:

  • System skin layers, tattoo layers, clothing layers and alpha layers all work – the mesh just needs to be flagged by its creator as supporting Bakes on Mesh and correctly set-up for alpha layers to work as intended.
    • As an alternative, there are assorted “BoM appliers” designed to work with mesh bodies  / heads that have not (yet) been updated with Bakes on Mesh support – see below for more.
  • You do not need a full body alpha to wear a Bakes on Mesh flagged mesh. If the flag is present when you wear the mesh, the body section it is flagged for disappears. So, if you wear a lower body “Bakes on Mesh ready” avatar part, then entire lower body of the system avatar will disappear.
  • The Bake Service has been updated to support 1024×1024 resolution textures, so it offers the same texture resolution for wearables as offered through applier systems (prior to Bakes on Mesh the maximum resolution for wearables was 512×512).
    • Obviously, the wearable must be made at this resolution in order to utilise it; a 512×512 wearable will not magically appear to be 1024×1024 resolution when applied.
  • In order to be fully effective, mesh bodies using BoM and BoM wearables should match the system avatar UV map as closely as possible.
    • Fortunately, most of the current range of avatar bodies sold under brands such as Maitreya, Slink etc., do tend to stay close to the system avatar UV map. So any new BoM-specific versions / updates should continue to do so.
  • Alpha support means that  layers means that mesh bodies should no longer need to be split into multiple pieces for individual alpha-masking to prevent a body clipping through clothes. Alpha requirements are back in the hands of the clothing creator, and should be made alongside the clothing, so that when used and providing the body is correctly set-up they should just “work”. In addition, clothing makers may not longer need to include auto alpha scripts.
  • Changing mesh body parts should be easier, providing both bodies are flagged to use Bakes on Mesh. The body takes whatever is worn on the system body – skin and make-up instantly appear on each change of head, for example.
  • Skin makers will be able to offer more options by including tattoos with their skins, allowing for a variety of make-up options, whilst there will no longer be any limitation on the use of tattoos (one per zone).
  • Applier support will still be required for the following: nails; eyelashes; standalone ears, hands, feet, lips, bust implants, etc.; lip gloss; materials finishes (see Some Possible Points of Contention, below); neck blenders, anything not intended to look “painted” on.

New with Bakes On Mesh

To provide full “wearables” support, Bakes on Mesh introduces some new elements that will be of key import to creators:

  • The introduction of 5 new bake channels – LEFT_ARM_BAKED, LEFT_LEG_BAKED, AUX1_BAKED, AUX2_BAKED, AUX3_BAKED:
    • These can only be used with Bakes on Mesh, and are not available to the system avatar.
    • LEFT_ARM_BAKED and LEFT_LEG_BAKED are intended to help with making mesh avatars where the left and right limbs have different textures (and so can be asymmetric, as can currently be achieved with applier systems).
    • The AUX channels are general purpose, and could be used for body regions not possessed by system avatars (such as wings) or for other purposes.
    • This means BoM has 11 possible channels for wearables to use for textures, and for the baking service to produce.
    • However, the new channels listed above do not have alpha support like the other channels, and so cannot have “holes” cutting through the mesh face they are worn against.
  • BOM also adds a new wearable type called Universal.
    • While specifically added to allow the wearing items that use the new  channels described above, the Universal wearable has slots corresponding to all 11 of the bake channels, offering extensive flexibility of use. In layering order, universal wearables go between the tattoo and body layers.

Note that for others to see your avatar correctly when you are using Bakes on Mesh they must also be using a Bakes on Mesh viewer. If they are not, they will see your avatar as a mesh of red, blue and yellow colours showing through your mesh parts.

Left: Bakes on Mesh when seen via a non Bakes on Mesh viewer: the system avatar will show through the mesh body parts, covered by default system-supplied BoM marker textures. Centre and Right: using a “Bakes on Mesh applier” on a non-BoM body and head and via a Bakes on Mesh capable viewer. The centre image shows the “before” avatar state: the system layer skin and clothing are worn, but do not conform to the mesh body and head (which must be worn without their corresponding alphas for this type of applier to work), and so “poke through” (highlighted in places by the red circles). The right image shows how things look after the”Bakes on Mesh” appliers have been used – the system layer clothing and skin now mostly conform to the mesh head / body, with the exception of fingers and toes (highlighted) which will generally require an additional “glove” or “mask” fix.

“Bakes on Mesh Appliers”

During the testing of Bakes on Mesh, at least two experimental applier systems were produced to allow BoM to be tested on non-BoM flagged bodies and heads. For example, Omega produced an experimental BoM applier system, with instructions here.

Since then, and given that several mesh body and head creators have yet to produce BoM flagged updates to their bodies / heads, several more such “BoM appliers” have been produced, some of which are available for free, some are provided by the mesh head / body creator, and others are available at a nominal cost, and may be for specific purposes (e.g. the Bakes on Mesh skin applier (Omega) by Conor Shostakovich at L$125).

These essentially work by allowing you to dress your system avatar with the required system wearables, then wearing your mesh body / head without their alpha masks, and then using the applier to apply the system layers to the mesh body / head in a similar manner to “traditional” appliers – but again, as a single composite layer when baked.

  • How effective these systems are can be variable.
  • Due to differences in the way skin skin textures / UV maps work and the way mesh bodies tend to be put together, such appliers may not work particularly well around feet and hands.

Note: links to products does not constitute endorsement. Always check the Marketplace for products and reviews.

Such appliers are intended as an interim “fix” for using Bakes on Mesh until such time as the major head and body creators provided full Bakes on Mesh support.

Some Possible Points of Contention

However, there are what might be regarded by some as “negatives” around Bakes on Mesh, a couple of the more prominent ones being:

  • The Bakes Service – and thus Bakes on Mesh – does not support materials (normal and specular maps). How much this impacts people’s acceptance of BoM is open to debate. However, when needed, materials still can be added manually (if the mesh / mesh face in question is editable) or via a suitable applier.
  • Appliers are convenient, as they are an all-in-one solution requiring only one or two items in inventory – the outfit applier HUD and possibly an intermediary relay tool like Omega.
    • With Bakes on mesh, wearables are all individual inventory assets, which could lead to inventory growth, some of which might be quite extensive as a result of creators providing multiple options / layers (although in fairness, some applier systems can be like this – I have seen a Hugo’s Design outfit with no fewer the 40 individual items, both system layer clothing and multiple applier options).
    • Some of the inventory “bloat” BoM might cause can potentially be managed via the use of the viewer’s Outfits capability (although this obviously also adds to bloat with inventory links) or via a new form of applier system that utilises system wearables created at 1024×1024 resolution.

How much these may impinge on consumer’s willingness to adopt BoM remains to be seen.

Closing Remarks

Like all new capabilities, Bakes on Mesh will take time to gain understanding and traction. Also like all new features, it has its outright fans, and those who have – even before really getting to work with it in earnest – decided its is bad / wrong / pointless / a step back, etc.

I’m personally sitting in the middle. If it does what is claimed on the tin, and if it gains traction among mesh body and head creators (and several have been working on BoM for the 12+ months its been in development) and clothing creators, then it could do its own little bit towards a better “optimisation” (quotes used intentionally, as there is still a lot more than can be done in terms of optimisations cross SL), and make things a little better for everyone.

But it will take time for Bakes on Mesh to mature in terms of general use – creators need to update their heads / bodies (although Slink is apparently ahead of the curve, and their new bodies are said to work with existing appliers, and other creators may also be providing products / updates, I’ve just not encountered any as yet). Those making system wearables are going to need time to update to the 1024×1024 where preferred (if they haven’t already, and so on. And, most obviously, it will take a little time for the Bakes on Mesh code to percolate out to all TPVs.

In the meantime, some links to useful resources.

Resources

 

Lab notes updates to SL simulator deployments

Posted on by Inara Pey

It has long been a tradition in Second Life that the main grid simulators and the regions they support are split between a number of channels:

  • The main channel, called Second Life Server, or SLS, which has the majority of simulators / regions running on it (roughly about 70%).
  • Three core release candidate (RC) channels, code-named BlueSteel, Magnum and LeTigre – each of which may account for roughly 10% of the simulators / regions.
  • Assorted smaller RC channels (such as Snack and Cake), that come and go according to needs – they may draw their simulators / regions from the SLS channel or the main RCs or a combination thereof.

This division is designed to allow a flexibility of approach to deploying updates, particularly those that may contain new features or have specialist updates such a new throttles or security changes, as these can be deployment to one or two of the RC channels first to test how they work under fully 2live” conditions (which the Lab, with the best will in the world cannot possibly fully test prior to deployment), and then removed with minimal grid disruption should anything untoward happen.

These RC deployments generally take place every Wednesday. If all goes well, and depending on how many different simulator updates are on the larger RCs, one will generally be “promoted” to the SLS channel the following Tuesday, having spent a week on one or more RCs. there are some variances in this, depending on what is going on (significant changes or new feature might be gradually deployed from one to two to all three RCs over a period of time, and then to the SLS channel, for example), but you should get the general idea from this, if you weren’t previously aware of how things work.

These (generally) weekly deployments are reflected in my Simulator User Group updates, where I list the deployments in terms of the SLS channel and the three core RC channels (the Lab doesn’t always acknowledge when a very small RC is being used).

However, on Monday, August 26th, Linden Lab announced upcoming changes to how simulator changes are going to be handled, and while the deployment methodology will remain the same (SLS channel deployments on Tuesdays, RC deployments on Wednesdays), there will be some differences, notably:

  • Starting with a deployment to one of the RC channels, the channel name will no longer be visible through the viewer (Help > About) nor will it be open to LEL query  – the channel name will simply be listed as “Second Life Server”, the same as the “main” channel. Over the next couple of weeks this will be true for all RC channels.
  • This means that when reporting simulator issues, just referencing the channel name will no longer be sufficient – users must use the simulator version number. This is displayed in Help > About, alongside the channel name:
Going forward from week =35, simulator issues should be reported using the simulator code version number, not the channel name (“SLS”, “BlueSteel”, etc.).

The reasons for making these changes are defined as being twofold:

  • To provide the Lab with better data on the performance and reliability of the server updates, and allow for better monitoring (presumably via the additional tools and internal changes the Lab has been making to the simulator code for the last few months).
  • To avoid spurious associations between the RC channels and capabilities. For example, the idea that one RC channel runs on better (or worse) hardware than another or the SLS channel; or that issues being experienced *must* be the result of an RC deployment, purely on the basis that that was either the last deployment made, or the user happened to be on an RC channel when they encountered an issue (regardless of whether the code may actually have caused the problem or not).

It is also noted in the official blog post that while simulator code version numbers will be the preferred means of reporting issues, channel names will continue to be recognised by Support for matters of testing:

Future improvements will make each RC channel a better model of the Grid as a whole. Support will continue to be able to accommodate Region owners’ requests that a Region be in the RC for a particular feature or fix they want as soon as possible, or that it be excluded from any RC.

It’s currently not clear if these changes will also impact the channel reporting capabilities in TPVs like Firestorm (which can pop-up the name of the simulator channel when moving from one to another) or not.

A final note in the official blog indicates that simulator release notes will be moving to the same system as is now used for viewer release notes. When this happens, I can only hope it is managed better than is currently the case for viewer release notes, where updates viewers may be references on the Release Notes page OR the Alternate Viewers page OR the Available Viewers Index on what seems to be the flip of a coin.

Please refer to the official blog post for full details of the changes.

An Autumn’s Cherishville in Second Life

Posted on by Inara Pey
Cherishville, August 2019 – click any image for full size

Shawn Shakespeare suggested we make a further return visit to Lam Erin’s Cherishville over the weekend, noting it had been redesigned in readiness for autumn’s arrival in the northern hemisphere. So we hopped on the Second Life express and alighted at St. Bronxton Railway Station, a quaint little end-of-the-line station that is one of Cherishville’s many new features to capture the eye and the lens.

The region is now centred on a channel that cuts it neatly in two from east to north-west. With the stone-built banks topped by paved footpaths and spanned by a single bridge, the channel is bordered on either side by an assortment of buildings; so much so, that despite facing open water at either end, it has the look and feel of being the mouth of a small but navigable river, and the buildings on either side are the result of a estuary township, the people drawn here for the open seas and the opportunities for fishing and coastal commerce.

Cherishville, August 2019

This little township is distinctly of two halves. The west bank of the river, which includes the landing point and the aforementioned railway station (set back from the river’s edge) has – to me at least – a very English feel to it. With the buildings crowding the waterfront, I was immediately put in mind of a small river estuary in Cornwall or Devon; the stone-built houses and shops speaking of a place that had in the past grown up as a result of commerce along the coast. In fact, such is the look to that side of the river, I wouldn’t have been surprised if during our visits, Aram Khachaturian’s Adagio from Spartacus welled up in the background as the Charlotte Rhodes hove into view, James Onedin at the helm (Yes, a (possibly obscure) British TV series reference thrown in as well!).

Across the stone bridge, the east side of the river has a more American look and feel to it: posters advertise Connecticut and New England lobster, Martha’s Vineyard gets a mention and the fuel prices are in USD. Even the wooden buildings have the look and feel of rural Americana.

Cherishville, August 2019

But no matter what influences have been drawn into the design, both sides of the river have one thing in common – something also common to both sides of the Atlantic in the autumn: rain. To say this is coming down in buckets would be an understatement; for those so inclined, brollies, coats and wellies are the order of the day for a visit! Although truth be told, the rain (mesh elements places along the line of the river) add considerable atmosphere to the setting. It pounds the footpaths and board walks, given both a sheen that reflects lights (if you have ALM enabled!), while puddles set golden, red, orange and yellow leaves drifting under the influence of a gentle, rainy breeze.

Beyond the river and town, the land undulates in low, wooded hills or spread in flower-rich ground before dropping away to the water once more. A lighthouse raises a finger into the sky to the north-east, adding to the feel of this side of the river being  more American in setting, whilst on the west side, the land is cut in part by the tracks curving out from Bronxton Railway Station, whilst also easing its way to a shingle ribbon of coast looking south and out towards two smaller islands, each topped  by  a cabin.

Cherishville, August 2019

These cabins appear to be open to the public – at the time of our visit, the larger was unfurnished as well. However, as there are no obvious means to reach either of them save by swimming / flying, we didn’t venture any closer than the beach to find out, as we didn’t want to invade any privacy should either be for private use.

Not that any visit really is necessary: there is more than enough to see and photograph around the river front town and immediately behind its rows of buildings without every need to cross the water to the smaller islands. There are also plenty of spots scattered around when sitting and passing the time can be enjoyed – particularly along that southern ribbon of beach.

Cherishville, August 2019

There are admittedly one or two rough elements in the design. Some of these are somewhat down to the nature of the mesh beast – it’s possible in places to find yourself walking in raindrop splashes hovering at waist level. Others may well be because Lam is still tweaking the design – on my return run for photographs, he was shuffling buildings, sorting out hovering trees and carrying out some general furnishing.  Certainly, none of the is enough to completely spoil the setting or the autumnal feeling it imbues whilst wandering and exploring.

All told, another classic design from Lam, very different from its summer iteration (read here for more), but well in keeping with the upcoming seasonal change in the northern hemisphere (climate change allowing!), and very much worth the time to visit – as always, and photos welcome at the region’s Flickr group.

Cherishville, August 2019

SLurl Details

2019 viewer release summaries week #34

Posted on by Inara Pey
Logos representative only and should not be seen as an endorsement / preference / recommendation

Updates for the week ending Sunday, August 25th

This summary is generally 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 Current Viewer Releases 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. This page 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.
  • By its nature, this summary presented here will always be in arrears, please refer to the Current Viewer Release Page for more up-to-date information.
  • Note that for purposes of length, TPV test viewers, preview / beta viewers / nightly builds are generally not recorded in these summaries.

Official LL Viewers

  • Current Release version 6.2.4.529638, formerly the Love Me Render RC viewer dated August 5, promoted August 12th – No  Change.
  • Release channel cohorts:
  • Project viewers:
    • Project Muscadine (Animesh follow-on) project viewer, version 6.4.0.530100, August 19..

LL Viewer Resources

Third-party Viewers

V5/V6-style

V1-style

  • No updates.

Mobile / Other Clients

Additional TPV Resources

Related Links

A touch of horror, sci-fi and fantasy in Second Life

Posted on by Inara Pey
Seanchai Library

It’s time to highlight another week of storytelling in Voice by the staff and volunteers at the Seanchai Library. As always, all times SLT, and events are held at the Library’s home at Holly Kai Park, unless otherwise indicated.

Sunday, August 25th: Live from Innfest

2019 marks the 129th anniversary of the “Grandfather of Cosmic Horror and Weird Fiction”, H.P. Lovecraft, and the 10th anniversary of the founding of Innsmouth, the region dedicated to celebrating the genre Lovecraft created.

To celebrate both, Seanchai Library will be a part of the Innfest celebration that marks both anniversaries through until August 27th (read more here), with Caledonia Skytower, Corwyn Allen, Kayden Oconnell, and Finn Zeddmore sharingstories from the Lovecraftian canon over 90 minutes. Included in the series will be:

  • The Hound
  • The Moon Bog
  • The Music of Erich Zann.

So why not join them at the Miskatonic University Library at Arkham?

Monday, August 26th 19:00: Arthur C. Clarke’s Rendezvous with Rama

Gyro Muggins reads one of the greatest science fiction novels of human first contact with alien intelligence.

In 2131, a fast-moving object of extremely large size is detected beyond the orbit of Jupiter travelling on a course that will see it pass through the inner solar system to swing around the Sun, before heading out into space. An automated probe launched from Mars reveals the object to be a perfect cylinder, 50 km long and 20in diameter rotating regularly along its long axis and clearly artificial in nature.

The deep space survey vessel Endeavour, her crew untrained for first contact scenarios, is the only vessel that can intercept the cylinder as it uses the Sun’s gravity well to accelerate and bend its path onto a new trajectory. After a high-speed chase, the Endeavour reaches the cylinder – christened Rama by those who first identified it – and finds one of the end caps has curious triple chamber airlock systems within it. Through one of them, the crew gains access to the object.

What they find within stuns them: the cylinder is hollow, a 50x16km “tube” the inner surface of which forms a circular world of three parts: a large plain, with six city-like groups of structures scattered around it, a central band of frozen water the crew call the Cylindrical Sea with a single long, thin island (which they dub “New York” due to its superficial similarity to Manhattan island). Beyond the sea lies a landscape of split into cubes and squares, dominated by a group of massive cones extending inward along the cylinder’s long axis from southern end cap.

Initially in darkness and frigid when the Endeavour’s crew enter, the cylinder gradually comes to life, revealing its strange alien nature, where everything appears to be done in triplicate (or multiples thereof). And then, as tensions among the human civilisations across the solar system rise, the “Ramans” appear.

Tuesday, August 27th 19:00: Chitty Chitty Bang Bang

So, you think you know the story because of the film? Well, guess again! Disney’s famous 1968 film can best be described as being loosely based on the children’s story by Ian Flemming, the creator of James Bond.

Flemming’s last novel, Chitty Chitty Bang Bang was published posthumously, and initially in three volumes, two months after his death in August 1964. He took his inspiration for the titular car from a series of post-War World I aero-engined racing cars called “Chitty Bang Bang”. They were built by Count Louis Zborowski at Higham Park, in Kent, England, and one of them, the “Higham Special” went on to take the land speed record in 1926 with a speed in excess of 170 mph, after it had been purchased by racing driver J.G. Parry-Thomas specifically for that purpose.

In the book, the car is a Paragon Panther, a powerful 1920s touring car that is restored by Commander Caractacus Pott. At first the car is just that – a powerful 4-seater tourer Pott uses to transport himself and his wife and children around. But then the car starts to exhibit a “personality” and abilities beyond those of any normal motor vehicle. Some of these will be familiar to those who have seen the film, but where the latter options to introduce jealous barons and a wicked Child Catcher, the book offers a more down-to-Earth but equally engaging series of adventures of Commander Pott and his family.

Join Caledonia Skytower to discover the real Chitty Chitty Bang Bang!

Wednesday, August 28th: Library Closed

No events.

Thursday, August 29th 19:00: The Blue Salt Road

An earthly nourris sits and sings
And aye she sings, “Ba lilly wean,
Little ken I my bairn’s father,
Far less the land that he staps in.

– Child Ballad, no. 113

So begins a stunning tale of love, loss and revenge, against a powerful backdrop of adventure on the high seas, and drama on the land. The Blue Salt Road balances passion and loss, love and violence and draws on nature and folklore to weave a stunning modern mythology around a nameless, wild young man.

Passion drew him to a new world, and trickery has kept him there – without his memories, separated from his own people. But as he finds his way in this dangerous new way of life, so he learns that his notions of home, and your people, might not be as fixed as he believed.

With Shandon Loring, also Also in Kitely – teleport from the main Seanchai World grid.kitely.com:8002:SEANCHAI.

Innfest: celebrating Innsmouth and Lovecraft in Second Life

Posted on by Inara Pey
InnsFest 2019 official banner

I almost missed this – largely because no PR material seems to have been sent out (or at least in my direction), but currently in progress through until the end of August 27th, 2019, is InnFest, a special celebration.

2019 marks the 129th anniversary of the “Grandfather of Cosmic Horror and Weird Fiction”, H.P. Lovecraft, and the 10th anniversary of the founding of Innsmouth, the region dedicated to celebrating the genre Lovecraft created. Thus, InnFest is a double celebration of both Lovercraft’s birth and Innsmouth’s 10th anniversary.

Innsmouth

The festival takes place on and over the Innsmouth region, which itself in modelled Lovercraft’s famous setting as it appeared in his 1931 novel The Shadows over Innsmouth, written in 1931, and which opened on August 20th, 2009, the 119th anniversary of Lovecraft’s birth.

Originally founded and operated by Darmin Darkes and her team, Innsmouth ran successfully for a number of years before hitting some financial difficulties that threatened it with closure (see: A new shadow looms over Innsmouth, September 2014). This prompted AriktheRed – who in 2012 had started organising the annual LoveFest in celebration of Lovecraft’s birth – to launch the Save Innsmouth campaign, which was both successful and saw Arik take over running the Innsmouth region.

This year’s very special celebration take place both on the ground at Innsmouth, and at various locations in the sky over it, and has featured / will feature both SL DJs and live entertainers, including: Archangelo Hellmann, AngelKitty Skizm, Bloodwain Arun, Rosedrop Rust, Larree Quixote, Wald Schridde and Vampink Cuddihy. Films are being shown at the region’s Arkham Theatre, and others evens featuring the likes of Seanchai Library and DRUM, at the Innsmouth Opera House and Miskatonic University (which forms the main lading point for the event). The festival will close with a Masquerade Ball on August 27th at 9:00 pm SLT.

Innsmouth

For details of all events at the festival, please refer to the InnFest event calendar and also to the new festival website.

SLurl Details