The magic of the convex hull and sculpts

Back in November I moved into a rock. This is SL after all, so why not? It’s been interesting, the house tucked away under a wooded garden, sekrit elevator and all. However, it did mean the wood and garden generally got ignored when I was home; the trees, campfire, gazebo and so on languishing without use.

Livin’ on a rock/Livin’ on a prim-based rock (with apologies to Livin’ in a Box)

So I decided it was time to return to a more normal style of living and try a few experiments to see what I could come up with. Essentially, I wanted to see what could be achieved using a new in-world tool I’d recently received and when using the convex hull physics shape to produce a reasonably detailed house build with a reasonably low Land Impact – preferably around the same as the house I was leaving (28).

Sunrise: a view from over the dance floor taking in the patio and lounge

The House

Given the house is in a wood…or copse, really….I wanted something that was fairly open-plan and which at least partially blended into the surroundings I also wanted something that allowed me to continue to enjoy SL sunsets when at home. The result is a west-facing, 2-room affair built on two sides of the small pond I already had in the middle of the copse, which also connects with my “dance floor rock” (what’s a house without it’s own dance floor?) via a stone patio whereon sits my beloved PrimPossible concert grand.

The lounge opens onto the patio, and provides enough room for sitting and conversation, focused on the view to the west (over the pond) or the fireplace (lifted and remodelled slightly from the “old” place. The bedroom sits to the north side of the pond, connect to the lounge, and provides enough room for a bed (not that I actually sleep in SL and pixel bonking is so passé!), and room for my cunningly disguised (and soon to be defunct) SLM Magic Box and not-so-cunningly disguised rental server.

The Lounge & bedroom beyond

I wanted the place to be fairly open to the surroundings – no doors or much in the way of windows between the “garden” and the house itself. This lead to a design that is relatively open-plan, with railings and open-slat wood panels as well as wood-framed windows to the back (east side), and stone walls and columns to add a little contrast to the place. In particularly, I wanted to have a roof, but not one that closed me off from the world or used skylights to give me a view of the stars.

Lounge rails

The Build

The total prim count / Land Impact for the house is 30, which I think is a pretty good figure, given the relative complexity of elements within the build (particularly the railings, wooden wall panels, roof and window frames). Had these been prim items, then the total “cost” of the house would have been massively higher. But they’re not – nor are they simply sculpt maps I’ve created externally to SL (I actually wouldn’t have a clue as to where to begin) or purchased elsewhere for re-use. They were created almost entirely in-world, allowing me to have railings, window frames, panels and roof sections all for a Land Impact of just 12.

Sculpt Generator

I created the “wooden” elements of the house using the “NN Prim Generator” by Naonao Watanabe. For those not familiar with it, this is a clever piece of scripting that allows prim-built objects to be used as models to generate sculpt maps which can be imported into SL.It comes in three flavours: one that can use prims to generate “regular” , “natural” (for rocks, etc), and a plant generator. I have the “regular” unit, which can create shapes suitable for building, which came to me as an unexpected gift (*hugs Mika warmly*).

Roof: from 32 prims to 1

There are limitations to using this tool; the total number of vertices within the resultant sculpt map must not exceed 32, for example. This means that you’re effectively limited to a maximum of 32 prims per item from which you intend to generate a sculpt map, and the number may actually be a lot lower depending on the complexity of the shapes (prims) used to create the item. This may all sound complicated, but the Prim Generator itself makes it easy for you by displaying the vertices counts for all available prim types.

Naonao Watanabe’s Prim Generator

To create an object, you simply click on the required shape on the generator, which will rez the required object (pre-scripted), and start building, selecting  and sizing new shapes as required.

The documentation supplied with the unit, together with one of the supplied examples, suggests that it is possible to pre-texture items as well. However, I confess that I’ve yet to try this out – assuming I’m understanding things correctly – as for my purposes, it was enough to be able to texture my constructs post-build.

When you have created an object you wish to “convert” to a sculpt, click on the GENERATE button on the Prim Generator. This performs a series of confirmatory checks to ensure your item is within the tool’s overall constraints and then pops-up a menu allowing you to generate / scale-and-generate the required sculpt map, which you can then obtain from an external web page and save to your hard drive. All that’s then required is for you to generate a default sculpt in-world, upload the map, apply it to the sculpt and size the item accordingly.

One thing I would recommend, however, is that if your Viewer supports temporary uploads, you initially use this to check that everything is fine with the resultant sculpt map when imported and the sculp properly sized, just in case you’ve missed any overlaps or have unexpected gaps in joins, etc.

Through the trees at sunset – the bedroom and lounge beyond

Using the Prim Generator enabled me to produce detailed roof, railings and window frames for a total Land Impact of 12.

Convex Hull

The other magical trick that people are starting to increasingly use in SL building, and which I employed in this house, is that of the convex hull physics shape. This was introduced as a part of the mesh roll-out, and in the right circumstances can dramatically reduce the Land Impact of a prim build / linkset.

Ciaran Laval has written an excellent piece on the use of the convex hull form, so I’m not going to repeat all the ins and outs here. Suffice it to say that so long as you are working with fairly simple prim shapes, and avoid the complexities of scripts, you can make some substantial savings on elements of the build.

In my case, the base, solid walls, fireplace, floors and “window glass” of the new house are all simple prims – 35 in all for a Land Impact of 35. However, by converting the linkset to a convex hull physics shape via the Build floater (by selecting CONVEX HULL from the drop-down menu in the FEATURES tab – see below), I could immediately reduce this to a Land Impact of 18.

From one linkset, 35 prims, Land Impact 35….
…to one linkset, 35 prims, Land Impact 18.

Who said mesh wasn’t good for SL? :).

Obviously, prim-to-convex hull conversion will not work in every instance – it is possible for the Land Impact to go up as a result of such a conversion. However, with a judicious application of the option within a build, it is possible to bring about a reasonable reduction in Land Impact in a lot of situations. Some things that should be avoided are: linking complex shapes in the linkset to be converted (such as sculpts) or including scripts (if you use a rez faux system, for example, be sure to delete the rezzing script in the convex hull shape linkset once you’ve rezzed a new copy of your build).

Sunset. The lights come on…

I’m pretty pleased with what I’ve achieved; I think the new place suits its location among the trees, and gives me space to entertain friends and the freedom to make sure the garden and dance floor are more properly used. As to the prim generator – I’m liable to be using that for one or two other ideas as well, while the use of the convex hull shape is already helping me to lighten the load some of my other builds have on Land Impact.

…and time to relax and chat with a friend…

Images captured using Exodus 12.01.03 with deferred render, shadows, ambient occlusion and DoF active, but no gamma correction.

Restrained Love, Dolphin 3 and Niran’s updated

This week has seen a number of TPVs updated. Rather than dwell interminably on each of them, here’s a rapid rundown, based on the individual blog entries for the three Viewers.

Restrained Love Viewer

Release 2.8.3 brings with it many bug fixes and:

Added

  • New keyboard shortcuts for builders (they are also added to the Build > Options sub-menu):
    • – Alt+W to edit linked parts
    • – Alt+T to set to stretch textures
    • – Alt+B to set to stretch both sides
    • – Alt+R to set to set grid mode to World
    • – Alt+F to set to set grid mode to Local
    • – Alt+V to set to set grid mode to Reference
    • – Alt+G to set to set current selected object as Reference and set grid mode to Reference
  • Debug setting “RenderMeshDeformed” to switch Qarl’s parametric alpha mesh deformer on and off (it is off by default
  • LL’s patch for the new inventory features (i.e. no accidental nudity)
  • Allow to click in-world while in Mouselook mode, even when your controls are taken, but only while pressing Alt

Fixed

  • Inventory offers were unreadable (the Show button used to overwrite the URL), same for teleport offers
  • Shift+Right-click on an object in world failed to open it
  • In Mouselook mode, we could only click on something or fire with a gun once
  • RLV_50: Fix to the alignment tool in the Build floater is broken (thanks given to Lance Corrimal and Jonathan Yap)
  • RLV_52: another avatar sitting down while in ML resets my camera (with thanks to Lance Corrimal)

Changed

  • Unable to be force TPed when in Busy mode.

Links

Dolphin Viewer

Version 3.2.4.22939 brings with it:

  • The main inventory tab can now show or hide links, or show only links (the recent and worn tabs always hide links). Switch it on via the Inventory gear icon
  • The use of private memory pools has been switched off. If you notice more crashes than before, switch it back on with the Debug setting “MemoryPrivatePoolEnabled” and let Lance know (via a post on the forum)
  • This version of the Dolphin Viewer 3 does not send “LookAt” data anymore, if you switch on “Do not point at objects” (Preferences->Dolphin Viewer 3->Miscellaneous). Lance notes that, “The options to have the LookAt / PointAt crosshairs on-screen will be gone in the next release, unless someone points out good use cases for having them that are not based on drama or paranoia.”
  • The inventory patch recommended by Oz Linden has been implemented – no “accidental nudity” for Dolphin Viewer 3 users
  • Updated to RLV 2.8.2.1
  • When you take a Snapshot to disk using the keyboard shortcut CTRL-SHIFT-D, it uses the file format that you selected for your last “snapshot to disk” from the snapshot floater
  • The check boxes for switching AutoCloseOOC and AllowMUpose are back in Preferences->Dolphin Viewer 3->Miscellaneous
  • The linux version of the Dolphin Viewer 3 now uses dbus calls in the secondlife: handler script to send SLurl to whichever viewer is running at the time. Lance comments, “This is not available on 64-bit Windows, so please vote for VWR-28073 and VWR-28074. Thanks.”
  • The Windows installer should not use the term “Second Life” anymore anywhere in any language. It should read “The Dolphin Viewer 3″
  • Some Windows build issues have been addressed.
  • Fixes:
    • The tips of the handles of the Align tool in the Build toolbox point in the right directions
    • Sharing inventory items with more than one inventory window is open is now working correctly
    • The hovertip on the local chat bar mentions whispering as well
    • Previews of textures show the checkerboard pattern again under transparent areas. Lance notes: “This version still does this with the old deprecated OpenGL calls. The next version of Dolphin Viewer 3 will do it “right”, thanks to Shyotl from Singularity”
    • Fixed: the “Preview As” dropdown in the texture upload preview is not covered by the texture anymore.

Links

Niran’s Viewer

Release 1.12 brings with it:

  • New Build floater
  • Ability to select the use of your right arm when selecting / pointing / building
  • Revised pie menu
  • Ability to see UI when in Mouselook
  •  Shining updates.
Niran’s: UI visible in Mouselook (note ML crosshairs in the centre of the image)

The UI-in-Mouselook is interesting – NiranV mentions it as coming via Dolphin, but I’ve failed to notice it in that Viewer (or any other V3-based TPV) – not that I’m a major user of ML at the best of times and so may well have missed it if it is a debug setting (or I managed to skip the option in Preferences). It’s an interesting addition to direct 1st person use of the Viewer, especially given UI options can be accessed using the Alt key. For those who prefer a more traditional Mouselook view, the UI can currently be hidden using a debug command: AllowUIHidingInML.

As a semi-regular user of Niran’s Viewer, I have to say, I’m not totally convinced with the build floater changes (which need a small amount of tidying-up) on two counts. Firstly, because Niran’s is one of three Viewers I routinely use, and so the layout cuts against the other two – this is admittedly more *my* problem than the Viewer’s.

Secondly – and more importantly – while the “traditional” builder floater is getting increasingly crowded (and one could argue it does need a bit of a re-think), it does have a certain logical flow in the way information is presented – and scanned by the user. This is something that appears to have been lost in this initial presentation within Niran’s Viewer.

Links

A unicorn’s enchantment

Update:Enchanted Unicorn and Enchanted Swansong have been separated and extensively redeveloped and no longer appear as described here.

Enchanted Swansong and Enchanted Unicorn are described as “a magical atmosphere in SL where the forests are filled with fairy tale creatures and romance is always in the air” and where you can, “Live your dreams here in the land of the faeres.” They are operated by the Enchanted Unicorn group, with the larger, full sim of Enchanted Unicorn rated Adult, and the Homestead sim of Enchanted Swansong, created by Andrek Lowell, rated Moderate. Both are enchanting places to visit, especially for those into photography and / or romance.

Enchanted Swansong (foreground left) with Enchanted Unicorn beyond

Both regions use Windlight presets set to sunset, and I’d recommend that you keep these settings when visiting.

Enchanted Swansong is a tall, verdant forest within which wind water ways that run between tall trees and past candle-lit gazebos, the air filled with the rich sounds of nature. There are also green pools of water masquerading as lush grass – so be careful as to where you tread!

Walking through the trees, one does expect to come across a Mallorn tree or to hear soft, sweet elven voices singing in the distance – Enchanted Swansong has that kind of Tolkien-esque feel about it in places, even with some of the more ominous sounds audible from deeper in the woods.

Glades, gazebos and harps

If you are able to explore with shadows enabled – and particularly with a Viewer like Niran’s or Exodus with the “extras” active, exploring Enchanted Swansong gains an added depth as sunlight filters through the trees, and you path is dappled  by shadows.

As you explore, you may come across a teleporter pad. Then leads the way up to the sky forest and the Roman baths, hidden overhead. For those romantically inclined, both offer quiet retreats in which to spend time. I particularly like the Roman baths, tucked inside a skybox; they remind me of a swimming pool at a country house hotel I like to frequent in summer here in the UK…

The Roman baths

Across the water to the west of Enchanted Swansong is Enchanted Unicorn, which also has a dedicated start-point. While still wooded, this is a very different enchanted land to that of Swansong. The music of the pan pipe hovers in the air together with birds’ songs and the sounds, perhaps, of spring; the trees are more varied and a greater feeling of faerie pervades the air. This is an adult region, and those of a sensitive nature should remember that fae nudity is accepted here. There are also gazebos, pavilions and tree houses where couples and friends can enjoy romantic trysts or meet for friendly conversation.

Like Enchanted Swansong, there is a teleporter to carry you skywards (or if you use the start-point, both around the sky and to the ground), which you can use to reach a ballroom, a club, hanging gardens and other delights.

The hanging gardens and Unicorn start-point floating beyond

Not everywhere may be reachable via teleport, however, so it’s worthwhile keeping your eyes open as you explore – there is a lot to find within Enchanted Unicorn both in the air and on the ground. One way to see more is to find the old white balloon and take to the skies, steering your way around the region while sitting in the basket admiring the view. Just be careful when sending the balloon home when you’re done as it requests – or you might end up standing on thin air!

Would you like to fly/In my lil’ white balloon…

The Enchanted sims make for a wonderful visit, regardless as to whether you’re into the fae scene or not – both are beautifully developed, and AliceDeejay Aya and Andrek Lowell have done a fabulous job in putting them together. Both are very photogenic and offer some wonderful opportunities for those key on SL photography. For those who enjoy  faerie or are looking for romantic spots witin SL, or who simply enjoy exploring the sights of Second Life, Enchanted Unicorn and Enchanted Swansong  together make a very worthwhile destination.

ballroom (l) and club, hovering over Enchanted Unicorn
Enchanted Unicorn as seen from Enchanted Swansong
The far pavilions – and nearby swing!

Related Links

All images captured using Exodus 12.01.03(b), no post-processing applied. All images using deferred rendering, gamma correction, active depth of field. Tone mapping active in all but images (1) and (3). 

The Zen of Second Life

Update January 27th, 2013: The Zen viewer has been discontinued by its creator.

Note: January 17th, 2012: I’ve received a number of complaints from the Firestorm team relating to elements included in the Zen Viewer. One in particular relates to the client-side AO, which in its current form I’d previously been given to understand had its roots in another Viewer & enhanced in Firestorm. However, I’m more than happy to correct this and give due credit to the Firestorm team.

No, I’m not going all metaphysical on you. Yet.

Zen is the name of the latest Second Life Viewer to cross my path, coming to me by way of a Twitter-poke from Cinder Roxley. Being developed by Zena Juran, this is a rather nice take on the LL Viewer, not altering too much, while adding some very nice touches.

Core Data

Currently available for the Windows platform, Zen is based on the latest 3.2.7 code from Linden Lab. This means it has the very latest in the Shining fixes, mesh upload, the  updated snapshot floater, etc. In addition, it also includes:

  • The alpha parametric deformer
  • Client-side AO and particle editor
  • Temporary texture & sculpt uploads and local sculpt and texture browsing
  • Area search
  • Pie menus
  • Toggle notifications between top / bottom right of the screen
  • LSL pre-processor and save / load scripts locally
  • Copy/Paste Object/Texture Parameters
  • Qarl’s prim alignment tool
  • Texture Refresh
  • Derendering option
  • Fetch inventory at log-in
  • Move orphaned system folders for deletion
  • Copy UUID on right-click
  • Resized View/Camera floater
  • Adjustable region restart timer.

In addition, the Viewer also has some useful defaults pre-set from the get-go which are liable to save most people using it time in getting things initially set-up.

The version I review here is version 3.2.7 (1), released 15th January, 2012, although version 3.2.7 (2) is available as of the 16th January, incorporating various tweaks and fixes.

Installation and First Looks

The installation EXE is 26.9Mb in size, pretty much par for the course nowadays, and installs Zen directly into its own directory without any hitch. On starting-up, Zen reveals the familiar 3.2 UI with a couple of interesting alterations from the norm: the Destination Guide doesn’t open by default, and the Mini-location Bar is displayed in preference to the Navigation/Favourites bars.

Zen default UI presentation

Transparent Buttons

Another, perhaps more obvious difference, is that the buttons – all positioned along the bottom of the window – are semi-transparent. Some may find them harder to see as a result, but I have to say I quite like it, although an option to adjust the level of transparency (if possible) would be welcome.

The buttons that are active by default are, it’s probably fair to say, the ones most people will prefer to see active from the get-go: Chat, People, Snapshot, Profile, MiniMap, View, World Map, Search, Build, Inventory and the AO buttons (on/off & settings). Other than the AO buttons, there are currently no additional buttons included in Zen’s Button Toolbar.

Menus

Menu-wise, Zen offers something of an eclectic mix, with a couple of the menus somewhat altered from the V3.2 offerings, others largely unchanged. Of particular note in a couple of the menus is the absence of many of the options that have corresponding buttons; there are no menu options for Choose an Avatar, Picks, Places and Camera Controls in the ME menu, for example, and World lacks a Destinations option.

Button access only: the ME menu from Zen (l) and from V 3.2.7 (r)

On the one hand, this appears to make sense – if the functions have buttons, why have duplicate menu option to access them?  Where a function is in frequent use, then it is likely it will be accessed through the button far more than through the menus. There is also the argument that experienced users (and Zen is aimed at those more familiar with SL, as are most TPVs) are unlikely to require access to some options (such as Choose an Avatar) while others will be more routinely accessed via Search (such as Destinations).

However, in some cases the menu options do offer a convenient means of accessing options that may not otherwise be used frequently enough to warrant having the button active at all times. As such, I’m not totally convinced removing some of the menu options (such as Picks and Places) is perhaps the right way to go.

Also missing from the ME menu, given it is built from the official 3.2.7 code, is the Merchant Outbox. However, this actually makes sense, as Direct Delivery isn’t yet available on the Main grid, so it’s hardly something people are going to miss at this point in time.

Zen menu options

Like many TPVs, Zen has its own dedicated menu called, appropriately, ZEN. This provides quick access to a number of  functions not found in the official Viewer: the ability to turn off / on Pie menus, disable / enable the mesh parametric deformer alpha, etc.

There may not be a lot of options here – but that’s intentional; Zen isn’t meant to be a feature-heavy Viewer, and to compare it with those that are would be a mistake. Zen is aimed at a very specific niche: building, as Zena explained to me, “I prefer to use  the official Linden Lab Viewer It has the best performance, but it does lack features found in other TPVs that I find very useful for content creation on the grid”. Full marks to her for defining the goal of the Viewer so clearly.

Preferences

This approach is also reflected in PREFERENCES, which currently sees little deviation from the official Viewer in terms of tabs and options. The only easily spotted differences are the inclusion of a LSL Pre-processor tab for scripters and a UI tab for skinning the Viewer.

LSL pre-processing options

The skin options are currently limited – you essentially get a choice of a blue highlighting for things like menu selections, etc., or the more traditional LL teal effect (complete with options to change other aspects of the UI). However, this is something Zena is again working on, so more options are liable to be available with future releases.

UI Skinning

Defaults

However, just because there aren’t a lot of extra menus options and Preferences, doesn’t mean there aren’t a lot of “under the hood” tweaks to the Viewer that may not at first be obvious. Zen actually differs itself from the herd in that several common defaults are pre-set to how many experienced users prefer them. For example:

  • Limit select distance is OFF
  • Camera constraints are DISABLED
  • Inventory is pre-set to SORT BY NAME and SYSTEM FOLDERS TO TOP is OFF
  • Inventory hover tips are disabled by default
  • Default cache size set to 1Gb rather than 512Mb
  • Network bandwidth is set to 1500Kbps (see this article on bandwidth settings) rather than the usual 500Kbps.

All of these tend to make getting started on Zen a lot less fussy, although it might be fair to say that many users would also like to see Chat and IM pre-set to use the “old style” non-header layout as well – Zen currently uses the LL default with headers active.

Camera Floater

The Camera floater in Zen has been nicely resized, and includes an option to quickly reset Draw Distance. The resizing is welcome – the camera floater on the official Viewer is somewhat supersized. However, in achieving the resizing, the more familiar zoom slider and viewing angle buttons have been removed. Again, I have very mixed feelings towards this approach.

Take the Mouselook button for example. While it is true that press the M key will drop you into Mouselook – it is equally true that this only works if you have your WASD keys set to move your avatar. For those that don’t, and who prefer to have WASD set to starting local chat (rather than having to tap ENTER first), the lack of a Mouselook button on the camera floater might cause a frown or two.

Animation Overrider

This is the “standard” client-side AO first seen in Firestorm and now found in most recent TPVs, which includes the ability to run multiple AO configurations, “build” AO sets “on the fly”, etc. In keeping with Dolphin, Zen currently uses the two-button configuration as mentioned above (one for accessing the AO floater, the other for turning the selected AO on / off), rather than the single-button approach used within Exodus.

Build Options

Zen offers all of the most frequently used build options found in the TPV “market” today. The build menu accepts four digits after the decimal point, there is Qarl’s alignment tool, the ability to copy / paste parameters, temporary uploads, sculpt and texture browsing, additional scripting tools, and for those working with mesh clothing, the parametric deformer alpha. Add to this the choice of using either the context menu or the Pie menu, and creators are supplied with a good range of options.

For me, there is only one item I’d like to see added, which is currently in Exodus, and that’s the ability to save / load position and rotation information of an object into /from it’s description field; when working on a number of builds and having limited space on my build platform, I find this a real boon for my work over copying / pasting co-ords manually.

What’s Not There

Again, it’s important to remember that this is focused Viewer aimed at delivering an improved building experience based more closely on the “vanilla” official Viewer when compared to other TPVs and that Zen is also something of a new development. As such,  the Viewer doesn’t currently include options such as radar or things like RLV and the media filters. This doesn’t mean these options won’t appear in time, but it would be unfair for people to dismiss the Viewer on the basis of their absence.

Viewer Status

Zen is TPV Policy compliant, and Zena informs me that, “I have an application submitted to be listed on the TPV directory and have been in contact with Oz Linden. As soon as Oz reviews the Zen Viewer it should (hopefully) be listed on the TPV directory.” The source code is available on Bitbucket, as is a fledgling wiki for documenting the Viewer and an issue tracker, which Zena requests is used for support issues / requests, rather than contacting her in-world.

Performance and Opinion

As Zen is based on the official 3.2.7 release I was expecting it to perform well on my usual system given my recent experiences with 3.2.5 and 3.2.6. So far, I’ve not been disappointed. Performance has largely matched my experiences with 3.2.5 (different environmental variables accepted, and remembering this is not intended as precise benchmark test), and frequently improved upon them (having shadows enabled at altitude, for example had the viewer running at around 15-16fps, slightly faster than 3.2.5, while on the ground, the rates were around those of 3.2.5 (about 11-12fps).

Overall, and in running Zen for a couple of days, I’ve found it to be a pleasant, crash-free experience (other than one issue which Zena fixed in the 3.2.7 (2) release). When building, the Viewer is easily as capable as my “default” Viewer choices (and I’ve given it a good run in this respect, given I’m (again) rebuilding my house…). Certainly, the additional build options made getting the work done a breeze, and it was nice to have a Viewer in which I can both build and have shadows running without suffering refresh stutter every time someone enters or leaves the sim.

Overall, the Viewer offers some nice build enhancements over the official Viewer, and those who prefer to use the LL-supplied Viewer, but would like to have some of the additional build options at their disposal without necessarily swapping to a TPV for general use should find Zen offers a very solid alternative.

Be a (Fishers’) Menace: drive a Neuspa!

I don’t really go in for vehicles in SL; I don’t live on the mainland, and private islands and estates don’t always look too kindly upon vehicles bouncing across them; plus, at the end of the day, the most convenient way of getting around SL over long or short distances is to teleport.

However, *years* ago, a friend (*waves to Itico*) took me for a spin on a wonderful little ATV-like vehicle that had me instantly hooked – I had to have one myself (and funnily enough, everyone I’ve ever introduced it to has invariably gone out and bought one). Even today, there are times when I cannot help but pull it out of inventory and go off for some silly fun.

I’m talking about the KR “Fishers’ Menace” Neuspa by Karsten Rutledge (of Greedy, Greedy fame), and I’m not sure there is a vehicle that is quite equal to it in terms of fun and cuteness anywhere in SL (and yes, I’m biased!).

All black: my usual Neuspa colour scheme

The Neuspa is a truly an amazing piece of SL creativity that brings together form and function in a little vehicle that packs-in a huge amount of features and which really is a lot of fun. Resembling a sleek ATV, all curves and aerodynamics, it is a “go anywhere” vehicle – literally.

Black and yellow: colour coordination is *everything*!

The range of options that come with the Neuspa are phenomenal, with over 100 button-driven menu options that allow to you to define just about everything about the vehicle, including: colour scheme (select a colour for the entire vehicle, or selected parts, the colour of the air jets, etc.), performance (gearbox options, acceleration, braking, turning radius, traction control, wheelies, etc), driver & passenger options (and set your own profiles), enable / disable a range of effects (engine sounds, dust kicked-up by the wheels, wake effects when on water, etc) – to list everything here would take the rest of this article… You can even set it to Group (based on your active tag) and rez copies for friends to scoot around on with you – or you can give a close friend (or two) a ride on the back!

The performance options are especially useful: find yourself encountering lag that in impacting on things like steering and acceleration to compensate for issues (such as finding your’s accelerating and hitting things before you have time to turn).

…on land…

Lag notwithstanding, the Neuspa’s performance is pretty amazing  – so much so that there is even a warning on the menu about using the “turbo” option:

WARNING: turbo in upper gears is EXTREMELY FAST and nearly impossible to control, not recommended for normal use.

So you have been warned! 🙂

That said, driving the Neuspa is simplicity itself – although mastering it takes time and you’ll likely need to fiddle with the various drive options to find the balance that best suits you. To start (assuming it is in Drive mode), simply jump on – if you have sound on, you’ll hear the engine start-up – movement is via the arrow / WASD keys, but be prepared to pull a wheelie or two. Braking or slowing the vehicle will have the brake lights working automatically, and steering includes a nice animation of turning the handlebars as well as the front wheels.

The performance options probably make this an ideal little vehicle for those into racing, as you can adjust a lot as mentioned above and generally fine-tune the Neuspa to suit the sim / track you’re on. When off-road, there is almost no terrain the Neuspa cannot handle, and getting airborne with it can be exhilarating.

Linden water isn’t an issue for the Neuspa; providing the vehicle is set to its “automatic” drive mode, simply drive into the water and watch the wheels rotate up to form floats that work with the streamlined hull, allowing you to skim across the water as fast as any jet ski – and with just as much manoeuvrability. When you reach the shore, the wheels fold back down and the Neuspa reverts to 4×4 mode.

…on water…

Nor is the Neuspa restricted to land and water – this is SL after all. Using the menu, you can toggle the vehicle’s mode to “air”. The will rotate the wheels once more and you’ll start hovering, use PAGE UP to increase your altitude and you can fly the Neuspa almost anywhere.

One thing to be wary of, however, is when crossing a sim boundary. Whether on land or sea or in the air, the Neuspa can shift. A consequence of this is, hit a sim boundary too hard and you can find yourself sitting in the middle of next week at 0,0,0 very quickly and often entirely sans Neuspa. However, the vehicle’s accessories include a crash helmet, should you feel you need some protection against sim-bouncing :).

…in the air…

Whether on your own or with a friend or two, the Neuspa can be a lot of fun, especially on land and/or water. When you’ve finished scooting around, there are even a couple of “relaxed” poses to go with it. And if you do feel the need to be protected wherever you go, there is even an “urban warfare” version, complete with a range of missile options and a retractable launcher!

Specifications

  • Product name: “K.R. Engineering Neuspa 4×4 Standard (Karoastoff)” and “K.R. Engineering Neuspa 4×4 Urban Warfare (Karoastoff)”
  • Permissions: COPY
  • Price: Standard model: L$1250; urban warfare version (with missiles): L$1550.
  • Available from: K.R. Engineering in-world.
Me an’ mah Neuspa – kicking back after a ride (with the optional crash helmet)…

Lab fails to align itself

Update 16th January: Charlar has added a comment to the JIRA that clarifies LL’s position on the alignment tool and puts concerns into perspective. The comment further makes it clear that from LL’s position, the opportunity to see the tool included in the official Viewer is far from closed, and Oz indicated in his comment from yesterday.

Update 15th January: The JIRA mentioned below has been re-opened, and Oz has requested any developers willing to take the alignment tool further to contact him directly. This clearly shows that the Lab is aware of feelings on the matter and are trying to meet people half-way, and full kudos to them on this. Qarl (Karl) has declined to update the code, but has stated it’s in the public domain, and others are welcome to do so.

Earlier in the month, Karl Stiefvater (do I still need to introduce him as the creator of the parametric deformer?) submitted an earlier piece of code he’d created – the prim alignment tool – to Linden Lab under a code contribution agreement.

I didn’t cover the contribution at the time, as Tateru had it very well covered. However to recap: Karl, formerly Qarl Linden, now Qarl Fizz, submitted the code to LL by way of a “Thank you” for a generous donation someone made towards the deformer project, as you can read on his website as well as Tateru’s blog (Tateru having steered the donation in the right direction).

The alignment tool does precisely what it says on the box: it aligns prims, as Karl’s own video demonstrates:

No fuss, no bother. It’s not a one-size-fits-all solution that is designed to fit every possible situation where prims (or linksets or objects)  may need to be aligned, and it is not intended to be. However, it does provides a major benefit for builders in dealing with a specific set of issues that can  otherwise be time-consuming to overcome. As such, it has been adopted by a number of TPVs, where it has proven to be highly popular.

But it has been rejected by Linden Lab under the original JIRA raised on it some 2 years ago by Nalates Urriah. As Lance Corrimal (himself the developer of the Dolphin TPV which uses the tool) and Tateru on her blog point out, the reason for the rejection appears to be primarily because the tool doesn’t perform tasks it was not designed to do and is thus “incomplete”.

The rejection notice as posted on the JIRA reads:

Thanks for making this effort. Alignment and snapping are an area where there are useful enhancements to be made.

However, we are not able to accept this contribution as it is.

These are the primary issues we found which resulted in that decision:

  • The feature should support the same modes as the other manipulation modes.
    • It does not work for non-mod permission objects. This functionality should work for all objects that the user can manipulate in-world.
    • It only supports World snap mode, not Reference and Local modes, unlike all our other manipulation modes
  • It packs and aligns to the face of the object bounding box. If objects are not cubes and do not share the same alignment, or aren’t aligned with the world coordinates (see above), the result of the operation is unexpected. Ideally the operations would use the actual shape of the object for aligning and packing.
  • There are also some coding implementation style issues that would need to be addressed. These can be covered in more depth after the functionality is dealt with.

In it’s current form, this is usable for purely prim-based builders under specific circumstances. It’s less useful for building with non-cube prims, mesh, sculpties. It’s minimally useful for building when the structure is not facing a global direction (ex: North, South, East, West). It’s not usable by non-building residents who need to place and organize purchased items.

LL obviously have the right to reject code that they feel is not in their best interests, or in the interests of the Viewer or their users. That’s a given and is fair enough. As such, and being of a generous nature, I have to say that there might be some mileage in some of the reasons given for the rejection (Jonathan Yap actually raises a couple of points within the JIRA). But, and again being fair to all, the rejection equally comes across as little more than nit-picking.

Take, for example, the remark that, “It’s minimally useful for building when the structure is not facing a global direction (ex: North, South, East, West).” On the surface, this might appear reasonable – until one remembers that the same is pretty much true for building as a whole in the Viewer at present – as anyone who has encountered prim drift can ably testify.

Then there is the comment, “There are also some coding implementation style issues that would need to be addressed. These can be covered in more depth after the functionality is dealt with.” This reads as not only nit-picking, but also to be putting the cart before the horse.

If Karl is in fact committing some basic errors in his approach to coding for the official Viewer, surely these should be addressed before embarking on any major functionality changes (were they to be agreed upon), in order to circumvent the risk that such “style issues” don’t lead to yet another rejection down the road?

Some have commented that the entire rejection smacks of a “not invented here” mentality. That may be the case, equally, there may be issues within the code as submitted we’re not privy to and which the note in the JIRA isn’t really helping to make clear. Even so, seeing this rejection I have to confess to being left with an uneasy feeling as to how the deformer tool is to be judged by the wider audience within LL. Time will tell on that, however.

As far as the alignment tool is concerned, I’m with Tateru on the matter and calling “time” on any hope of seeing it incorporated into the official Viewer, for precisely the reasons she states.

With thanks to Tateru Nino