Month: December 2019

Product review: the WALT Sea Roo in Second Life

Posted on by Inara Pey
The Piaggio WALT Sea Roo in its box

It’s taken a while to reach the market place since I first wrote about it under the prototype name of WaveHopper (see Previewing a little wave hopping in Second Life), but Ape Piaggio’s WALT (Walter, Air Land, Technologies) branded SeaRoo has reached the market. The delays in the release have been due to some final fine-tuning of the vehicle and its scripting – and have also allowed Ape to add further animations as well as a number of further options for the vehicle.

Based on the physical world Innespace Seabreacher, a two-seat semi-submersible personal watercraft that is shaped like a Dolphin and mimics its movement on and under the water, the SeaRoo behaves like a speedboat and can make short dives (up to 60 seconds at a time) underwater. It can be piloted in both Mouselook (the dashboard has working instruments) and third-person views, making it an all-around leisure craft.

Priced at L$3,000, the SeaRoo is delivered in a package that comprises the vehicle, a system to build one or more SeaRoo mooring points (and which includes a fuelling station), an obstacle / race course building set, the SeaRoo Key (described below), a tool kit for adding custom animations (it comes with a range of single and couple animations for when it is not being piloted) and a comprehensive set of manuals, the main user guide of which includes a link for downloading a set of .PST files should you wish to create paint schemes for the vehicle.

The SeaRoo can be touched for a menu system. If touched when outside the vehicle, the menu is more limited in scope (l) than when seated in the vehicle (r). When seated, the full menu is displayed, providing access to all of the vehicle’s options and settings. Refer to the SeaRoo’s user manual for full details

I’m not going to run through absolutely everything with the SeaRoo – the user guide is comprehensive in that regard, but it is worth covering come of the highlights.

SeaRoo Controls and Operation

By default, the SeaRoo’s controls match those of an aircraft:

  • The ◀ and ▶ or A and D keys turn the SeaRoo left or right when in motion.
  • The ▲ and ▼ or W and S keys pitch the nose down (dive) or up (surface / jump)
  • The PAGE UP and PAGE DOWN keys or E and C increase and decrease the throttle respectively, with PAGE DOWN / C putting the vehicle into reverse from 0% throttle.
    • A double tap on PAGE UP / W will set the throttle to 100%.
    • Pressing PAGE UP and PAGE DOWN (or E and C) simultaneously will cut the throttle to 0%.

Those who prefer a boat-style layout for the main controls, with the ▲ and ▼ (W and S) keys controlling the throttle, can switch to this mode of operation via the menu → Settings → Tuning → CTRL Style. In this mode, the PAGE keys and E/C will control the SeaRoo’s pitch down/up.

To sit in the vehicle, right click on it and select Sit Here from the context / pie menu. Once seated, and as with most vehicles, the SeaRoo’s engine can be turned on / off using “s” in local chat, or “start” / “stop” – note that all of the SeaRoo’s chat commands are entered in lower case.

Zipping along above the waves

Key Vehicle Features

“Keyless Activation”

Enabled by default, this causes the canopy to open and the dashboard to engage when you are with a few metres of your SeaRoo. Similarly, when moving away from the vehicle, the dashboard will turn off and the canopy canopy automatically close. This option can be disabled / enabled via the menu: Settings → Keyless.

The HUD

The Sea Roo HUD

By default, those sitting in a SeaRoo (pilot or passenger) get offered a HUD. It is not vital to piloting the SeaRoo, but provides an informational display (shown on the right) for fuel, speed, heading, engine temperature and power settings. It also includes three buttons:

  • Resize: increase / decrease the HUD’s size via a dialogue box.
  • Menu: access the main menu.
  • Colors: set the colours for the SeaRoo’s dashboard.

Note that the HUD is inactive whenever the SeaRoo’s engine is not running, and further details can be found in the user guide.

Hovertext Information

When the SeaRoo’s engine is on, information on the vehicle’s speed, engine power level and temperature, and the fuel level is displayed over the SeaRoo’s tail. It can be disabled / enabled by typing “hud” in local chat.

General Handling Notes

After any trip, the SeaRoo can report a set of statistics for you. Toggle off via the button, if required

Like many vehicles, the faster the SeaRoo goes, the more responsive it becomes. As such, I recommend handling it at low to mid-range speeds to get familiar with it, rather than leaping in and going flat out; but keep in mind some capabilities work best at mid to higher speeds, such as diving / staying underwater, and performing jumps and acrobatics.

As speed is increased, the SeaRoo also takes on a nice Dolphin-like movement as if responding to the waves as it moves. Also, like a real boat, if it is moving at speed and you press both throttle keys to drop the throttle to 0%, it may take time to come to a complete stop.

The vehicle’s time underwater is – as noted – limited to 60 seconds. This is because the air intakes must be closed when submerged. A timer is displayed with the stern hovertext to help keep track of submerged time, and an audible alarm will sound when 20 seconds of submerged time remains. Try to stay underwater beyond 60 seconds, and the engine will cut out to prevent damage, and the SeaRoo  automatically surfaces. Once there, and providing the AutoRestart option has not been disabled, the engine will automatically restart.

Jumps are achieved from underwater by making sure you have sufficient speed, then pitching the nose up by about 30-45°. As you clear the water, gently pitch the nose forward to re-enter the water. Note that if you are moving too slow or pitch the nose up too high, the SeaRoo might either stand on its tail and fall backwards into the water, or perform a belly flop. You can also use SHIFT+ ◀ or A to roll left or SHIFT+ ▶ or D = roll right for both underwater acrobatics and to help level the SeaRoo after turning.

Taking a dive under the sea – note the bow light will, be default, come on automatically when underwater and turn off when on the surface

Refuelling

The SeaRoo has a limited fuel supply, and can be refuelled in a couple of ways:

  • Using the fuel pump supplied with the SeaRoo dock system or any Bandit / TMS compatible gas station – see the user guide for details.
  • Using the SeaRoo’s fuel canister when at sea: with the engine stopped and type “f” in local chat (no quotes) to trigger the refuelling animation. Note you may have to repeat this to completely fill the tank.

Continue reading “Product review: the WALT Sea Roo in Second Life” →

Lambie in Second Life

Posted on by Inara Pey
Lambie, December 2019 – click any image for full size

Update, December 29th: Lambie has closed!

Lambie is a new Homestead region design by marinestella that offers something of an escape from the deep snows of winter, with a minimalism that – at the time of our visit – was still so new it was still being worked on, so details may have changed a little between what you see on a visit and what is noted here.

The simple aesthetic of the design in some ways offers a distant echo of one of SL’s popular and missed regions: Roche, in its original form (see this article from 2012 and this one from 2015); although this echo is purely coincidental, rather than anything deliberate.

Lambie, December 2019

This echo comes from the lay of the land: the large central lake surrounded by a path running around it bordered here and there by buildings. However, It is only in this similarity of the design that the echo of Roche can be found; for the rest, Lambie is its own design.

Sitting between the path, with its smattering of snow, and the lake is a ring of denuded trees, their lack of leaves and the colour of the water pointing to this being something of cold place, if not one caught in the depths of winter. The trees are broken in four places by broad gaps that sit almost like the cardinal points of a compass to allow unhampered access to the waters of the lake.

Lambie, December 2019

The buildings around the ring of the island comprise a little farm hut, an open-sided barn and outhouse and a bus stop shelter. To the east of the island is a small, time-worn beach, little more than a ribbon, the fence-like line of concrete flood barriers separating it from the rest of the landscape (other than for a single gap), while just offshore stand the remains of overhead power cable pylons. These are mirrored on the west side of the region by more broken pylons, the positioning of each set suggesting the land once extended much further outwards than is now the case.

The overall setting is both suggestive of cold air and passing gusts of light snow, and also of warm times and sunlit opportunities for photography. It’s the kind of place that encourages people to cuddle up to share one another’s warmth – or perhaps share a warming drink of hot chocolate or similar.

Lambie, December 2019

There’s also a feeling of age to the setting: the building look careworn, the grass and trees have a sense of being long used to the changing seasons, while the lake offers its own detritus to match the broken outlying pylons: a Ferris wheel car long separated from its wheel, an old pier with a broken section that lies canted and partially sunk a few meters away.

Lambie does suffer from some issues in its design: the track around the island doesn’t feel like a natural part of the landscape and has physics disabled, causing visitors to sink into it for example. However, finished with a subtle sound scape and with a smattering of sea birds wheeling in the sky, this is a region that is easy on the viewer as well as on the eye. For those in the mood, a pedal boat rezzer is available on the west side of the island for trips around it.

SLurl Details

  • Lambie (Miranda, rated Moderate)

Space Sunday: Starliner’s first orbital flight

Posted on by Inara Pey
Ignition: the United Launch Alliance Atlas V topped by an uncrewed Boeing CST-100 Starliner vehicle lifts-off from Space Launch Complex 41 at Canaveral Air Force Station on its uncrewed Orbital Flight Test mission. Credit: ULA / Boeing

On Friday, December 20th, 2019, NASA and Boeing, together with launch partner United Launch Alliance (ULA), attempted to undertake the first flight of the Boeing CST-100 Starliner commercial crew transportation system to the International Space Station (ISS).

I say “attempted” because while the first part of the mission went precisely to plan and the Starliner successfully reached orbit, a software issue left it unable to reach the ISS. However, while this prevented a core mission objective from being met – that of rendezvousing and docking with the ISS – it did not leave the mission a failure: the ascent to orbit was successful, with a lot of data gathered on the vehicle’s performance, and further data could be gathered while on-orbit and during the vehicle’s return to Earth – also a critical part of the test.

The vehicle was uncrewed for this test flight, but is carrying a range of cargo – including Christmas gifts for the ISS crew; tree seeds that will be planted on Earth after the mission to mark it; a mannequin fitted with a host of sensors to measure the stress placed on a human body during the flight to orbit (the mannequin is called “Rosie the Rocketeer” in reflection of “Rosie the Riveter”, the iconic role model for U.S. women working in factories and on production lines in WWII, and a Snoopy soft toy “zero gee indicator” – Snoopy is the mascot for NASA’s Artemis programme to return humans to the Moon.

The Atlas V, dual Centaur and CST-100 vehicle stack. Credit: ULA

Things started off well enough: following a near-perfect count down, the core booster of the Atlas V and its two strap-on  solid rocket motors ignited precisely on time at 11:36:43 UT (06:36:43EST) on the launch pad of Space Launch Complex 41 at Cape Canaveral Air Force Station, and the vehicle lifted off smoothly into the still-dark early morning sky.

Due to the need to keep the vehicle within a 3.5 G limit during ascent, the Atlas V rose into a “flat” trajectory during its climb, the two solid rocket boosters being  jettisoned some 2 minutes into the flight, the core stage motors continuing to burn for almost three more minutes before BECO – Booster Engine Cut-Off – was called. Shortly after, the core stage of the Atlas V separated from the Centaur upper stage, allowing it to fire its twin RL-10A motors – marking the first time a twin-engined Centaur had been used with the Atlas V booster. Again, the additional power provided by the additional motor was required to push Starliner toward orbit, running for seven minutes in the process.

It was after the Starliner has separated from the Centaur upper stage that the major problem occurred. At this point, the vehicle was supposed to orient itself and then fire the main engine on the service module to push itself into an initial orbit that would allow it to complete further engine burns to both raise its orbit and circularise it, allowing the Starliner to catch-up and rendezvous with the ISS.

However, that initial burn failed to occur on time. Instead the vehicle continued to fire its attitude control thrusters while ignoring commands from Earth to fire the the service module’s motor. Some seven minutes passed before the engine was ignited, allowing Starliner to achieve its initial orbit – but by that time its was “off course” in relation to where it needed to be in order to catch up with the ISS, and had used too much attitude control system fuel to be able to make necessary course corrections and achieve any form of rendezvous with the ISS.

The Boeing Starliner space vehicle experienced an off-nominal insertion. The spacecraft currently is in a safe and stable configuration. Flight controllers have completed a successful initial burn and are assessing next steps. Boeing and NASA are working together to review options for the test and mission opportunities available while the Starliner remains in orbit.

– Kelly Kaplan, Boeing’s spokesperson, after the planned automated engine burn failed

According to initial investigations, it is believed that the mission clock aboard Starliner overseeing all of the vehicle’s automated flight operations – including triggering the engine burn – had incorrect data, causing it to believe the service motor had fired, and thus triggering the use of the attitude control system.  While the issue left Starliner unable to reach the ISS, mission controllers were able to order the vehicle to complete two additional engine burns to put it into a near-circular 250km high orbit, where a range of tests on the vehicle have been made, and from which it could complete its planned EDL – entry, descent and landing.

A couple of important points to highlight here is that had the vehicle been carrying a crew, they would not have been in any danger – in fact, they would likely have been able to correct the initial burn failure, allowing the rendezvous with the ISS to take place.

The stages of a Starliner’s return to Earth. Credit: Boeing

With the issue understood – if not the cause known – the decision was taken to complete the planned orbital tests and then bring the Starliner back to Earth  and a landing at the White Sands Missile Range, New Mexico on Sunday, December 22nd. These orbital test included testing the navigation systems and the vehicle’s flight handling, and communications (including establishing a link with the ISS).

Landing commenced with Starliner turning itself around and using the service module’s motor in a de-orbit burn. This took place at 12:23 UT (06:23 CST at the White Sands landing ground) on December 22nd, slowing the vehicle sufficiently for it to start a decent into the denser part of the Earth’s atmosphere. Three minutes after this, the service module was detached and left to burn-up in the upper atmosphere.

The capsule, protected by a double heat shield system – referred to as the forward heat shield (protecting the upper part of the vehicle: the airlock and the landing system parachutes) and the base heat shield (at the base of the capsule and designed to protect it from the full heat of atmospheric entry) and covered in a thermal protection system – reached “entry interface” some 20 minutes later. This is the point where the atmosphere becomes dense enough to generate friction around the vehicle, both heating up and slowing the vehicle down. At this point, Starliner was some 15 minutes away from landing.

Continue reading “Space Sunday: Starliner’s first orbital flight” →

Sansar Product Meetings week #51

Posted on by Inara Pey
Bryn Oh, Hand – blog post

The following notes were taken from the Twitch stream recording of the December 19th (week #51) Sansar Product Meeting.

Point Releases for R38

There have been three point releases for the R38 “Rediscover the Party” since December10th, none of which have had release notes posted to the Sansar website.  The core element of these point releases was bug fixes and performance improvements.

Linden Lab and IP

There has apparently been a lot of discussion about (and confusion over) the Lab’s approach to IP protection on Sansar. As a result, Lacie Linden has published A Word About IP on the Sansar blog. This specifically references Linden Lab’s

Both of which can be found on the Lab’s corporate website, and which apply equally to all of the Lab’s platforms.

Plans for 2020

Emotes

  • Updated emote (gestures/ animations) system coming “soon”. This will include the ability to obtain an emote from the Sansar Store and immediately use it and assign a keyboard short-cut to it.
  • Emotes will also be per account in the future, not per avatar – a move intended to remove the need to re-apply emotes to each avatar a user creates.
  • A downside of this is that when first introduced, the new emote system will mean script will no longer be able to access the number keys without triggering an emote.
    • However, a means for users to re-bind keys to whatever they want will be provided, so scripts will not longer be pointing at a specific key, but rather an identifier, which can have any key assigned to it.

Animations

  • Synchronised dancing for music events – probably built into the dance floor, which they set avatars dancing, rather than using emotes.
    • API will allow for both full body and upper body looping and / or single play. This won’t interfere with people wanting to use their own dances.
    • This system will also support other uses with animations.
  • The default idle animation is to be improved.

Backpack

The Backpack is to be extended so that individual scenes (worlds) can define what the Backpack contains. This will include a scripting API to define the state / content of the Backpack at different points in a world (e.g. reach a point in a quest where you have obtained an item, and it is unlocked in the Backpack and available for use).

New User Experience / First 10 Minutes in Sansar

This is to be entirely re-thought, with changes to the initial on-boarding quest experience. This is to align the on-boarding experience more with music and live events – the current focus for Sansar development and audience acquisition.

Moderation Tools

These are to be enhanced, initially for Lab staff but then for world creators – e.g. muting people more easily, removing them from a world, etc. Together with in-client improvements to managing whitelists, etc., and for raising tickets.

Avatar

  • The ability to upload and use custom skins will hopefully be one of the first early avatar updates for 2020.
  • A lot of work has been completed on the full body deformation capability, but it is not clear where the work sits in the work order for 2020.

UI Re-design

There will likely be a “comprehensive” client UI redesign in 2020, aimed at things like reducing the number of clicks required to get to certain capabilities, improving the information available in certain panels (e.g. local chat), with options to use this information to access other panels (e.g. access a user’s Profile from local chat and then adjust the volume at which you hear their voice chat).

This work is forming the “tail end” of a lot of “other, bigger changes”.

Q&A Session Summary

  • There have been reports of issues with the Look Book – items not updating what changing an avatar; saving updates taking a long time. There has been some work going on with the look Book, and this may have caused a few bugs, which are being / have been addressed by the Sansar team.
  • Nexus sounds: the background sounds (referred to as the “old sounds” are interfering with the music, etc.. These are to be removed.
  • The bug by which a blocked individual can continue to harass in local text chat is being investigated.
  • The Sansar team is looking at a lot of the pain points within the content creation process in order to try to smooth the process end-to-end and make it easier for content to be brought into Sansar and used to create scenes and worlds. This work may encompass things like UI improvements and allowing creators to version their worlds.
  • Will there be an AFK indicator when people are absent their computer? Being considered, but not clear if this will be SL-like or something like returning an avatar to their Home Space after a certain amount of time inactive has passed.
  • Tipping: is also being looked at, but may be driven from tipping “official” performers rather than a generic person-to-person exchange of Sansar Dollars.
  • A Sansar mobile client is still on the road map, but no significant updates at the moment other than it is being worked on.
  • Why is is still necessary to run events in a copy of a world, rather than the original? This actually goes back to the way in which the ticketing system works – and this is frustrating for the Lab and world creators, as it is still inward-facing (creators cannot as yet make use of it for generating revenue off of their own events).

Sorcha and Ninna at Monocle Man in Second Life

Posted on by Inara Pey
Monocle Man: Sorcha Tyles

Now open in the sky gallery at Monocle Man (take the teleport disk to the gallery if delivered to the ground) is a joint exhibition by Sorcha Tyles and Ninna Dazy, with each artist split between the lower and upper floors of the gallery, allowing visitors to enjoy a natural mix of their art.

Sorcha is both a Second Life photographer and a gallery owner – she runs the Artful Expressions Gallery – and so she might be more familiar to some in hosting exhibitions by other photographers, particularly those who may just be starting to exhibit their work or have been overlooked by “established” galleries.

Monocle Man: Ninna Dazy

Ninna joined Second Life some 13 years ago, enjoying the platform for its creativity. As a result, she discovered photography and started taking picture of herself and friends before moving on to capturing the places she visited – although maintaining a focus on her avatar.

For this exhibition, Sorcha and Ninna present what is very much a linked exhibition – they are both close friends – with images provided by each of them that complement one another’s selected portfolio. Both demonstrate extensive skill with the SL camera capabilities and with post-processing techniques to produce images that are rich in detail, tone and with a strong ribbon of narrative running throughout all of them. In particular, soft focus, depth of field, angle and colour.

Monocle Man: Sorcha Tyles

These are photos that are at once – by virtue of being on display – public statements of Ninna’s and Sorcha’s time in Second Life, and also personal in tone and content. Through them, we’re given insight into their Second Lives.

Each has what might be a defining element in her photos that also sets the two apart, making their respective exhibits individual as well as linked. With Sorcha, this is perhaps her use of camera angle, with notable and effective use of both overhead and low angle shots that add both depth and a certain about of intimacy: through her use of a particular angle, we’re being invited to share in her thoughts and actions. With Ninna is is the use of soft focus and depth of field. Both encourage us to focus on the avatar(s) present in a shot, but also suggest a broader story through what is intentionally only partially revealed beyond the avatar.

Monocle Man: Ninna Dazy

Having opened on the 15th December 2019, this joint exhibition will remain in place until around January 3rd or 4th, 2020. Recommended.

SLurl Details

2019 Content Creation User Group week #51 summary

Posted on by Inara Pey
Last Dove, November 2019 – blog post

The following notes are taken from my audio recording of the Content Creation User Group (CCUG) meeting held on Thursday, December 19th 2019 at 13:00 SLT. These meetings are chaired by Vir Linden, and agenda notes, meeting SLurl, etc, are available on the Content Creation User Group wiki page.

The majority of this meeting was a generic conversation of ideas such as moving Second Life to support PBR, what might be done to improve Pathfinding, etc., none of which are on the road map for Second Life at present; as such these notes keep the the current projects that are in progress at the Lab.

SL Viewer

A new Maintenance viewer, code named Xanté, was released on Thursday, December 19th. Version 6.3.6.533748 contains around 30 fixes for reported issues and bugs. All other viewer remain as per my Current Viewer Release List.

With regards to viewers:

  • The Lab’s focus has been on transitioning their Bitbucket viewer build repositories from Mercurial to Git – see my week #50 TPVD meeting notes for more.
  • As well as the current pipelines of viewers, work is also in hand to ensure the viewer is ready to manage Name Changes when that capability is deployed in early 2020.

Environment Enhancement Project

Project Summary

A set of environmental enhancements (e.g. the sky, sun, moon, clouds, and water settings) to be set region or parcel level, with support for up to 7 days per cycle and sky environments set by altitude. It uses a new set of inventory assets (Sky, Water, Day), and includes the ability to use custom Sun, Moon and cloud textures. The assets can be stored in inventory and traded through the Marketplace / exchanged with others, and can additionally be used in experiences.

Due to performance issues, the initial implementation of EEP will now likely not include certain atmospherics such as crepuscular rays (“God rays”).

Resources

Current Status

  • Bug fixing continues, notably around alpha rendering issues.
  • The hope is that of the remaining issues, some my be related, and so solving one will help to solve others of a similar nature.

ARCTan

Project Summary

An attempt to re-evaluate object and avatar rendering costs to make them more reflective of the actual impact of rendering both. The overall aim is to try to correct some inherent negative incentives for creating optimised content (e.g. with regards to generating LOD models with mesh), and to update the calculations to reflect current resource constraints, rather than basing them on outdated constraints (e.g. graphics systems, network capabilities, etc).

Current Status

  • Vir is working on getting things to a state where he can do so practical testing over the holiday period to ensure the relevant data is being collected. This is dependent on whether he has the time to confirm the internal version of the viewer is logging everything it needs to be logging.
  • The work is still very much focused on the data collection aspect, rather than doing anything with the data that is gathered.
    • The kind of data being gathered includes: what are the graphics and geometric properties of the objects in a scene, what rendering settings are being used, poly count for different LODs with a model, what are the graphics properties in use (materials, texture + texture size, etc.), plus the time required to generate a frame successfully given the work required to render the scene.
  • Once the data has been gathered, the idea is to run the viewer on multiple hardware configurations (GPU, CPU, etc.), and gather data on the the impacts of changes those various properties.
  • The aim is to get a more accurate feel for how performance is impacted, and how significantly changes impact performance (e.g. what’s the impact of enabling Full Bright compared to enabling materials? Which is genuinely better: properly optimised mesh or plain faces with materials or a combination of low-resolution mesh + materials?
  • As well as allowing the complexity calculations for avatar attachments and in-world objects to be better refined, the data gathered might, further down the line in the project, enable LL to make plausible forecasts of what might be seen by way of performance improvements in relation to suggested constraints being put on objects as a part of the creation process.
  • Textures are still proving a problem in terms of measuring impact (e.g. is it more a total threshold limit being hit, rather than the number of textures used within an individual object?).
  • Anther limiting aspect is the number of different bottlenecks users can experience quite outside of the Lab’s control (e.g. their network connection, what else is going on across that connection at the same time, etc)., and bottlenecks within individual systems that can vary.
  • One attempt to improve things that has been made in Firestorm is for the matrix calculations for worn mesh to be cached the the bones to which the mesh has been rigged hasn’t moved between frames. This can save up to 7 sets of calculations for a mesh with 8 faces that the viewer may not actually need to make. This may be contributed to LL for evaluation.

** The next Content Creation User Group Meeting should be on Thursday, January 9th, 2020, but check the wiki page for confirmation **