The Teegle Animesh horse

Teegle Animesh horse

At the start of April 2019 I reviewed the Water Horse Animesh horse – a horse that, unlike Bento horses, is not limited to having to be worn in order to be ridden – as it has its own skeleton, completely independent of an avatar, an Animesh horse can also be rezzed in-world, where it can wander, or ridden in the style of a vehicle, making it perfect for use both when riding, or as region décor.

However, the Water Horse model isn’t the only Animesh horse. Teegle, for example, are currently developing their own horse, which is currently in public beta – and in the interests of comparing the two, I recently picked one up and took it for a test drive. Err, ride.

Currently, the Teegle horse comes in two styles: a paint and a Hanoverian. The former might be seen as more suited to an American style of riding, and the later leaning towards more European riding, but the fact is that as both horses are supplied sans tack, you’re free to decide which you’d like, and then choose your preferred style of tack, or even swap riding tack depending on your mood.

The horse is supplied at two price points, which at the time of writing were: L$1,500 for the No Copy version, and L$6,000 for the copy version (allowing you to rez as many as you like). Again, note that these prices are purely for the horse, no riding tack is included; you can however ride them bareback. Tack will cost an additional L$750 from Teegle, although there are other suppliers. Other points worthy of note with the horses at both price points are functionally identical, and:

  • You can set them to be ridden by yourself or, when rezzed in-world, by others.
  • When rezzed in-world each horse can carry a rider and up to two passengers.
  • The basic LI for a Teegle horse is 28LI. With riding tackle attached, this rises to 35 LI.
  • The no Copy version come with a guarantee of automatic replacement if lost as a result of a bad region crossing, or broken as a result of incorrect editing. Replacements are delivered via the horse management HUD.
  • Horses can be individually renamed.
  • Retexturing is possible, but requires the purchase of texture packs at L$450, which include skin, mane and eye colour options.
  • The wander option when horse is rezzed in-world, does not require Pathfinding to be enabled within a region.

The HUDs

Two HUDs – both of which are still under development at the time of writing – are supplied with each Teegle Animesh horse.

  • A Management HUD, which:
    • Allows the horse’s gender to be set.
    • Includes a button that provides a chat link to a dedicated web page listing all Teegle pets you may have purchased. The last grind location the animal was recorded as being at, together with the date and time, is listed, allowing you to relocate a “lost” horse. A redeliver option is also provided here as well.
  • A riding HUD, which provides:
    • 4 different click-selectable riding speeds: walk, trot, canter, gallop. Riders can also move between these by tapping the UP arrow key (or W if WASD is set for avatar motion and the horse is being worn).
    • 4 horse animations: spook, (horse jumps sideways nervously and looks around); buck, rear, and reward (rider leans forward and pats the horse).
    • An autowalk function: set the horse walking in a straight line. The rider can look around, take snapshots, etc., or simply steer.
    • Follow (rezzed horse only): the horse will automatically follow the named avatar.
    • Lead (rezzed horse only): lead the horse via the halter when walking.
The Teegle riding HUD. Note the Lead / Follow options are only available when the horse is rezzed in-world

Riding the Horse

Before riding the horse, make sure any AO you have (scripted or client) is turned off to avoid any conflicts. Then either:

  • Add it to your avatar from inventory as a worn attachment.
  • Mouseover the horse in-world, right-click and select Ride.

The first option will add the horse to you, with you in the saddle (if attached to the horse); the second will place you in the saddle (if attached) of a rezzed horse. Note that if worn, you’ll need to the manually attach the riding HUD; if the horse is mounted while rezzed in-world, you’ll be asked if you’d like to accept the HUD, which then attaches automatically (note this is a slightly different HUD to the one in your inventory, as it includes the Lead and Follow options for the rezzed horse).

Movement is via the usual WASD / Arrow keys, with W / Up for forward motion, with double-taps advancing through the four speed options. Tapping the Down keys while moving forward will step back down through the riding speeds. When riding the horse from rezzed, the Down arrow will play a nice backwards walking animation.

Camera-wise, riding the horse from rezzed fixes the camera in a good position above and behind the horse, regardless of any camera offsets you may have set (not something seen with the Water Horse Animesh horse). Riding the horse from worn may leave the camera awkwardly positioned if you use custom camera offsets, the mousewheel and CTRL-Mousewheel generally fix this.

You can lead a Teegle Animesh horse to water…

Passenger Riding

Passengers can ride with you simply by clicking the horse. The rider can then select who “drives” the horse via a left-click to display the menu, and then the Driver option (rider 1= the avatar in the saddle; rider 2 = the passenger directly behind the rider; rider 3 = rearmost passenger). Who has the reins is indicated via local chat. The same menu option is used to take back control.

Riding Permissions

Who can directly ride a Teegle Animesh horse when rezzed in-world is also set via the menu: left-click the horse, then Settings > Driver Perm. At the time of writing, the options were limited to Private (owner only) and Public (anyone), but I understand more granular options will be added.

Other Capabilities  / Options

… and you can have it swim!

As the Teegle Animesh horse is still in development, it is hard to say what else might be included. However, some of the current additional capabilities include:

  • Linden Water swim option: the left-click menu offers a Settings option to have the horse swim in deep enough Linden water, complete with a companion swimming animation for the rider (but not passengers).
  • Flying option: you can set the horse to fly or disable flying (so no accidents when trying to jump an obstacle).
  • Motion function: set the horse to physical (default), so it will respond to objects around it (useful for racing, when wandering in  paddock, etc), or non-physical (useful for things like dressage).
  • Set wander distance via chat.
  • Rename function: Teegle horses can all be given their own name.

Adding Tack and Other Options

Riding tack by Teegle is easy to attach to the horse:

  • Rez both horse and tack in world.
  • With neither selected, right-click on the tack and selected edit.
  • Press and hold the SHIFT key and then left-click on the horse to additionally select it.
  • Click the Link button in the edit floater (arrowed, below).
  • The tack will correctly orient itself and attach to the horse, as seen in the inset image, below.
Adding options such as riding tack – use the Link option in the Edit menu (arrowed)

To remove an attached item (e.g the saddle or entire riding tack):

  • Rez your horse in-world.
  • Left-click the horse for the menu.
  • Click Unlink to display the Unlink menu.
  • Use the numbered buttons to unlink the required items.
  • Move your horse away from the unlinked objects and then delete them.
Removing items – use the Unlink option in the horse’s menu

Continue reading “The Teegle Animesh horse”

Advertisements

2019 SL User Groups 16/2: Content Creation summary

Puddlechurch; Inara Pey, March 2019, on FlickrPuddlechurchblog post

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

SL Viewer

  • The Estate Access Management (EAM) RC viewer, version 6.2.0.526190, dated April 12th, 2019 was promoted to the de facto release viewer on Wednesday, April 17th. See my EAM overview for more information.
  • The Teranino Maintenance RC viewer updated to version 6.2.1.526357 on April 18th.

All other SL viewers in the pipelines remain unchanged:

  • Release channel cohorts:
  • Project viewers:
  • Linux Spur viewer, version 5.0.9.329906, dated November 17, 2017 and promoted to release status 29 November – offered pending a Linux version of the Alex Ivy viewer code.
  • Obsolete platform viewer, version 3.7.28.300847, May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7.

Environment Enhancement Project

Project Summary

A set of environmental enhancements allowing the environment (sky, sun, moon, clouds, 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 not include certain atmospherics such as crepuscular rays (“God rays”).

Resources

Current Status

The bug stomping continues.

Animesh Follow-On

Vir is now looking at adding shape support (or similar) to Animesh, which Vir sees as possibly being approached in a couple of ways:

  • To make Animesh objects behave as much as possible like avatars. This might be done by issuing a command to load a given shape into an Animesh, or just have a similar appearance resolution to avatars, which would allow associations with body parts for any attachments contained within the Animesh’s contents.
    • Advantage: either route offers the closest compatibility to the way in which avatars work, making it easy to port stuff over from using with avatars to using with Animesh (e.g. Animesh NPCs).
    • Disadvantages:
      • This is a much more complex project to implement as it requires substantial changes to the Bake Service, which can be a performance bottleneck. So a concern is that adding Animesh support to the Bake Service could have a further adverse impact on its general performance.
      • While applying a body shape could be done via the simulator (avoiding the Bake Service), but this again involves added complexity in the amount of asset information fetching the Simulator already has to do.
  • An alternative approach would be to offer a more granular control, using LSL to set the values usually set by shape sliders.
    • Advantages: It can reduce the complexity by allowing s subset of slider changes to be replicated via LSL (e.g. face, hands, etc), rather than trying to have the entire slider system replicated.
    • Disadvantages: This doesn’t give the same level of compatibility to the way avatars work, and if all the sliders were required, it would add considerable additional work with LSL calls for the 130+ sliders.

Which approach should be taken is down to whatever the most common use-case for customising Animesh might be (a likely topic for discussion). Currently, either approach will require additional server / viewer messaging, so Vir is looking at that.

There are also questions on what else might be preferable to add to Animesh (e.g. extending Bakes on Mesh to support Animesh, adding attachments support, etc), and the relative priorities people place against the various options as to any order as to how things might be tackled (would applying shapes be sufficient? Should it be shapes then another requirement, or is there another requirement that should take priority over shape support?).

Attachments are an issue in themselves; as Animesh doesn’t have an associated agent, there are no attachment tables for it to use, making basic attachment to s specified point difficult. Also, avatar attachments are effectively individual linksets applied to a common root – the avatar.

However, as an Animesh object is a single linkset, adding attachment to one object is more akin “merging” the attachment’s linkset into that of the Animesh, making them one continuous linkset. This clearly add complications; for example, how do you identify all the parts of the attachment to remove them when detaching, and how do you ensure they detach as a single object, rather than a coalesced group of unlinked items?.

One potential solution might be to have a means by which individual prims within the Animesh linkset can be flagged with an associated joint within the skeleton, thus allowing attachments to be made to that joint, and somehow “faking” the fact that the attachment linkset is not part of the Animesh linkset.

Exactly how this would work in practice still has to be properly determined, together with an mechanism for handling local position and the attachment’s position and rotation offsets. It is further unclear at present whether this approach might required support from and additional viewer UI element or could be controlled entirely through LSL.

Bakes On Mesh

Project Summary

Extending the current avatar baking service to allow wearable textures (skins, tattoos, clothing) to be applied directly to mesh bodies as well as system avatars. This involves viewer and server-side changes, including updating the baking service to support 1024×1024 textures, but does not include normal or specular map support, as these are not part of the existing Bake Service, nor are they recognised as system wearables. Adding materials support may be considered in the future.

Resources

Current Status

Anchor Linden is dealing with issues related to handling alpha layers in the new baking channels – with some of them not getting correctly baked, and which may need some fixes in the baking process. BUG-226599 is also being looked at; although a feature request, it might actually be the result of an underpinning bug.

Following the April 11th CCUG, Cathy Foil carried out further tests to apply materials to a Bakes of Mesh surface. This involves using a script to take the UUID for one of the new universal bake channels (e.g.BAKED_ AUX1), and pointing it to a normal map (shown in the place holder normal map image “BAKED AUX1 IMG”, right), then wearing a universal wearable that uses the same bake channel. This results in the normal map then being applied to the desired face, as show in the image of the normal map in the Edit floater (arrowed on the right, above). This approach also appeared to allow a layering of normals on a face. However, the method is not currently seen as a recommended approach to materials with BoM, and probably won’t be treated as a supported technique.