Category: SL User Group Meetings

Pathfinding overview

Posted on by Inara Pey

Tuesday August 7th saw the roll-out of pathfinding across the main Second Life Server Release Channel. For those of you who may still be unaware of what pathfinding is, there is an overview on the SL wiki. However, for those wanting a shorter description, here’s how Rod Humble introduced it back in December 2011:

NPCs: coming to a region new you … ?

Because worlds feel most vibrant when they are full of life, one of our next focuses for Second Life is the ability to make high-quality “life” within it. So in 2012, we will be rolling out more advanced features that will allow the creation of artificial life and artificial people to be much smoother. 

So, simply put, pathfinding is the means by a range of automated characters – people, animals, monsters, mobile objects (“mobs”) and so on – can be created and set into motion within Second Life far easier than has previously been the case. These can then navigate their way around obstacles, follow roads, climb inclines, and so on using  specialised LSL commands and the “navmesh”.

Pathfinding has a wide variety of potential uses – as “background” in role-play sims using non-player characters (NPCs), the creation of game-play mechanics (such as the use of “food” to attract animals), and so on. Characters can be set to have certain behaviours – such as chasing you or fleeing from you, and so on.

Above: a video by “fpady”, demonstrating pathfinding using a spider which pursues an avatar

The following is designed to provide a very high-level overview of pathfinding and some of its key aspects as they are likely to impact the majority of SL users. It is not intended as an in-depth guide, and should not be used as such. Nor is it designed to be any kind of tutorial for creating pathfinding characters  nor as a tutorial. Links are given throughout (and at the end) to more comprehensive information which can be referred to for a deeper understanding of pathfinding.

Viewer Tools

Pathfinding brings with it a new set of viewer tools and panels. Fore detailed information on these tools see, Pathfinding Tools in the Viewer. The folllowing notes are for broad guidance only, and are based on accessing the tools through the official SL Viewer.

Floaters

Pathfinding has three new floaters: Linksets, Characters and View / Test, all of which are explored in a little more detail later in this article. They are accessed either via the Build menu or through the right-click context menu thus:

  • The Build menu includes a new Pathfinding option, which opens a sub-menu allowing you to access any of the three new floaters
  • Right clicking on an object in a pathfinding region will display a Show in Linksets option in the context menu, which will open the Linskets floater
  • Right clicking on a pathfinding character will display an option to open the Characters floater

Information Panels and Address Bar Icons

Pathfinding adds a number of additional informational panels in the Build, Object Profile and Statistics floater of the viewer, as well as a new set of icons which many be displayed in the viewer’s Address Bar / SLurl Bar. Full details on these can be found in Pathfinding Tools in the Viewer, linked-to above.

Rebake Region Button

There is also a new button  – the Rebake Region button  – which may periodically appear towards of the bottom of your viewer’s window when on a region where the navmesh is being modified (see Navmesh, below).

At the time of writing, the tools are only fully available in the Beta (3.4.0.262596) and Development (3.4.1.262722) versions of the official SL Viewer, although this will obviously change as the new code is more widely adopted. Niran’s Viewer 1.48 provides the core pathfinding tools, but does not include the additional pathfinding attribute panels in the Build floater.

Navmesh

For those not familiar with the term, “navmesh” is short for navigation mesh. This is a representation of a region’s geometry generated and used by the Havok physics engine to determine paths for pathfinding characters. An overview of the navmesh is available on the SL wiki.

Every region where pathfinding is enabled has a navmesh, which is also shared with their immediate neighbours to allow cross-region pathfinding. For users not directly involved in the creation of pathfinding elements, the navmesh should be totally transparent, although the updates to the Havok physics engine required for it to work have led to a number of issues, some of which have yet to be resolved, which may have an impact on some activities in regions with pathfinding enabled (see Issues, JIRA and Bugs on the next page).

By default, the navmesh is active across an entire region (but it can be disabled if required – see Console Commands on the next page). However, parcels set to No Entry for objects  will cut the navmesh at their borders, and pathfinding characters will not be able to navigate across them (although there is a bug with this (PATH-787, which is not open to public viewing): if a parcel is set to No Entry for object and sits on the border between two pathfinding enabled sims, it is possible that characters may attempt to cross the region boundary and enter the parcel. This is currently being worked-on by LL).

Region Rebakes

The navmesh can be somewhat fluid in nature, depending upon what is going on in a region and whether anything is being changed within the region which may affect the navmesh (see Objects, the Navmesh and Optimising Performance below for an example of changing the navmesh).

Optional pop-up which may be displayed on viewers in regions where the navmesh needs to be rebaked

When a change is made that does require an update to the navmesh, a Rebake Region button will appear towards the bottom of all pathfinding-capable viewers connected to the region, together with an optional pop-up message (right).

Anyone can click the Region Rebake button in order to initiate the rebake. Once the button has been clicked, it will change its appearance as the rebake proceeds (which can take a little time, depending on the complexity of the navmesh).

The Region Rebake button: indicating a region rebake is required  (t),  and while a rebake is in progress (b)

Objects, the Navmesh and Optimising Performance

Where pathfinding is enabled, objects need to be optimised to ensure the navmesh functions correctly. This requires setting the correct attributes for each object within the region. By default, all objects within a region are set to one of two attributes: Moveable Obstacle (all non-phantom objects) and Moveable Phantom (all phantom objects). Neither of these attributes contribute to navmesh calculations.

If pathfinding is enabled, but is not being used within a region, it is possible to leave objects with these default attributes. While this may have some impact on region performance, depending upon how heavily the region is being used, it shouldn’t be something that is overly noticeable to users.

However, if pathfinding is being actively used within a region, then the objects within the region must have their attributes properly set in order for the navmesh to be properly calculated and characters can properly navigate through / around / over them. This means updating objects to one of the following four attribute types, all of which directly contribute to navmesh calculations. These are: Walkable, Static Obstacle, Material Volume, and Exclusion Volume.

All six object atributes should be used as follows :

  • Walkable: all objects / surfaces pathfinding characters can move across (the terrain of a region is always set to Walkable and cannot be changed)
  • Static Obstacle: any object that should block character movement and which does not move (e.g. walls, trees, fences, railings, etc.)
  • Material Volume: can be used with phantom objects to alter the rate at which characters can move across a specific area (e.g. imagine a wooded area: a single Material Volume phantom prim could be used to reduce the speed characters traverse the woods, or even just the densest part of the woods)
  • Exclusion Volume: can used with phantom objects to create areas where characters cannot roam
  • Movable Obstacle: any object that should move (e.g. doors, gates, etc.), but which blocks pathfinding characters from moving through (so a door can still open / close, but characters will not move through it, regardless of its state)
  • Movable Phantom: phantom objects that have no affect on pathfinding characters

An example of how these attributes might be used is to imagine a room where pathfinding characters are to be active:

  • The floor would be set to Walkable
  • The walls and furniture would set to Static Obstacle
  • Doors would be set to Moveable Obstacle
  • If the room included a specific area where characters were not to roam, it would be denoted using a phantom prim set to Exclusion Volume.

Note that objects set to attributes that contribute to navmesh calculations will generate a request for a region rebake in order for the navmesh to be updated. Additionally, these objects have some special restrictions applied to them:

  • They cannot change their physical shape via LSL script (changing object position, shape parameters, scale, rotation, physics shape type, and linking/unlinking is generally blocked)
  • They can only be physically changed via the build tool by avatars who have modify permission and are in the same region as the object (i.e. they cannot be physically changed by avatars located in a different region, nor can they be moved across region boundaries by editing them and dragging them).

Continue reading “Pathfinding overview” →

LL announce “first set” of advanced creator tools now live

Posted on by Inara Pey

Yesterday, as I reported, Linden Lab rolled-out the first pass of the advanced creator tools across the main release channel for the grid. These are the functions that lead to an outbreak of griefing when they were first rolled-out on the Magnum Release Channel back in June.

Since then, the code has been revised – and now includes a “master switch” that allows Linden Lab to disable the functionality should anyone try to get up to mischief using the tools. The code was in fact enabled on both LeTigre and BlueSteel last week without major incident, and so the code was rolled-out to the main channel in an enabled mode on July 31st.

Today, LL has formally announced this initial release of the tools via a new blog post. This initial release comprises three new functions:

These functions should allow a range of new experiences to be created, some of which are demonstrated in the Linden Realms game, wherein the attachment option is used to attach the game HUD to avatars and the teleport options are used in conjunction with things like the rock monsters.

Linden Realms HUD (top left): attached using the full experience tools

The functions are also designed to be used with a new permissions system, which has yet to be rolled-out across the grid. This means that until the new permissions are rolled-out, some of the functions will not operate as transparently as they eventually will. For example, rather than something like a HUD being automatically attached to your avatar (as is the case with the Linden Realms game, which does use the new permissions system), you will be prompted to accept the object first (thus making you the owner) in order for it to attach.

It’s not currently clear as to when the new permissions system will be rolled-out, but with the “master switch” at their disposal, Linden Lab are confident that the kind of issues that marred the June RC roll-out can be avoided.

The official blog post includes a video from Torley.

Project Shining: project viewer released for new HTTP Library

Posted on by Inara Pey

A part of the Shining project is to improve the underpinning HTTP messaging that is crucial to simulator / simulator and simulator / Viewer communications. As commented upon in the notes from the TPV/Developer meeting on July 13th, the initial focus on this project is to provide an initial texture fetch library for the viewer, together with a “wrapper” that will allow further http code enhancements to be added over time.

On Friday July 27th, Linden Lab made the initial code available within an LL project viewer (SL Alternate Viewers). The availability of the code, and LL’s plans / hopes for it were discussed during the TPV/Developer meeting also held on the 27th July. The discussion can be heard in full on the meeting recording, the key points from which have been summarised below.

During the discussion, both Oz and Monty Linden (who is leading the project) had the following to say:

  • The code is currently free-standing, although there will eventually be server-side protocol changes made to better support it (as well as further capabilities to be added to the libraries), which should further improve robustness and overall performance
  • Even without the server-side changes, the Lab hopes that the code itself will make things “a little bit better” for those using older routers, particularly Linksys WRT routers (Monty indicated server-side work would most probably be required to improve things for people using Belkin G-series routers)
  • While  the libraries are close to what is expected to be the “final” code (barring bug-fixes, etc.), it is unlikely they will be integrated into the Development Viewer for at least the next two weeks. The reason for this is two-fold:
    • The code needs to be merged-up with 3.4.0
    • Integration is dependent upon what kind of experience is had with the code “in the field”
  • LL hope that people will use the project viewer, and TPV developers will integrate it into experimental releases of their own, so that greater feedback (via JIRA entries, etc.) can be obtained in terms of:
    • General experience reports – completeness, reliability, robustness, improved rezzing, etc.
    • Whether the new code is helping to ease the strain faced by the likes of Linksys WRT routers, and what (if anything) it is doing to people’s home networks
    • (From the TPV developers themselves) design comments on the code itself, whether it is felt things have been missed, if there are issues in integrating the code into TPVs, etc.

Again, note that the code is currently only related to textures; the “more ubiquitous” uses (as Oz has previously put it) of the new http library within the viewer have yet to be implemented, so HTTP inventory, etc., is currently unchanged.

Oz asked the question (of Monty), as to whether it would be a problem if TPV developers were to convert some of the additional HTTP functionality for use with the library. Monty didn’t see any major issues, other than the new library introduces the concept of a policy class, rather than the current global priority scheme, and this has not been fully implemented as yet, because it is not required in this first pass. However, additional functions could share the policy used for HTTP textures, and that would “still be productive”. Monty further indicated that there is a “to do list of intent” included in the code as a file, which TPV developers can look at if they are minded to look at committing to some of the work themselves.

Related Links

Server roll-outs w/c 30th July

Posted on by Inara Pey

Oskar has issued a notification of the planned server roll-outs for this week. As they currently stand, the roll-out will comprise:

Main Channel: Sever release 12.07.24.262437 – Tuesday 31st July

This should see a further roll-out of the LSL functions related to the Advanced Creator Tools. This release will see the addition of three new LSL functions:

These new LSL functions work with the current runtime permissions system, and are precursor to future work with experience permissions. More information about the runtime permission is here:PERMISSION_TELEPORT.

This is a roll-out of the code deployed to LeTigre and BlueSteel last week. As with both of those channels last week, the code will be enabled on the main channel regions following the deploy (although LL retain the capability to disable it).

Magnum RC: Further Pathfinding Roll-out – Wednesday August 1st

Roll-out due to commence: 07:00 SLT

A further roll-out of the server-side pathfinding code, with fixes. Currently the wiki notes for this channel appear to be stalled on the 12.07.24.262484 release.

Note that the viewer-side pathfinding tools are now available in the latest Development Viewer.

BlueSteel RC – Wednesday August 1st

Re-start due to commence: 08:30 SLT

There are no changes to this channel. It will have the same code as the main channel.

LeTigre RC: Infrastructure Project update – Wednesday August 1st

Roll-out due to commence: 09:30 SLT

Oskar comments: “This channel will have an infrastructure project that has no intentional changes to existing behaviour. There are perhaps unintentional changes to existing behaviour. If you find some please let us know!”

SL Server roll-outs: creator tools and pathfinding

Posted on by Inara Pey

Update July 18th: The Magnum RC roll-out has been delayed until Thursday July 19th. Oskar may supply a reason on the deployment thread in the forums – keep an eye on that for updates (with thanks to Wolf Baginski).

Main Channel Release

Tuesday 17th July sees the a roll-out of LSL functions related to the Advanced Creator Tools. This release will see the addition of three new LSL functions (comments taken from the release notes):

  • llAttachToAvatarTemp(integer attach_point): Follows the same convention as llAttachToAvatar, with the exception that the object will not create inventory for the user, and will disappear on detach, or disconnect. It should be noted that when an object is attached temporarily, a user cannot ‘take’ or ‘drop’ the object that is attached to them. The user is ‘automatically’ made the owner of the object. Temporary attached items cannot use the llTeleportAgent or llTeleportAgentGlobalCoords LSL functions
  • llTeleportAgent(key agent_uuid, string lm_name, vector landing_point, vector look_at_point): Teleport Agent allows the script to teleport an agent to either a local coordinate in the current region or to a remote location specified by a landmark. If the destination is local, the lm_name argument is a blank string. The landing point and look at point are respected for this call. If the destination is remote, the object must have a landmark in its inventory with the teleport agent script. lm_name refers to the name of the landmark in inventory. This function cannot be used in a script in an object attached using llAttachToAvatarTemp
  • llTeleportAgentGlobalCoords(key avatar, vector global_coordinates, vector region_coordinates, vector: Teleports an agent to region_coordinates within a region at the specified global_coordinates. The agent lands facing the position defined by look_at local coordinates. A region’s global coordinates can be retrieved using llRequestSimulatorData(region_name, DATA_SIM_POS). This function cannot be used in a script in an object attached using llAttachToAvatarTemp.

The new LSL functions work with the current runtime permissions system and are precursor to future work with experience permissions. More information about the runtime permission is here:PERMISSION_TELEPORT.

The keen-eyed will note that these are the functions that were rolled-out to the Magnum RC channel in May, and which were subsequently abused for griefing purposes. However, Linden Lab have added a new capability to the functions  – what is described as an “on / off” switch which is available only to Linden Lab personnel, and which allows the functions to be enabled  / disabled (the functions were also rolled-out to the Le Tigre RC on July 11th with the “on / off” switch capability). As the release notes make clear, the functions are disabled by default in the roll-out, and will presumably remain that way until such time as the updated permissions system has been rolled-out.

The release also includes three bug fixes (again, as specified in the release notes):

  • SCR-342: llTeleportAgent() does not fail gracefully when specifying an invalid landmark name
  • SVC-7966: Magnum RC, llTeleportAgent gives a wrong message
  • SVC-7987: llTeleportAgent always points in the positive Y direction on teleport.

Pathfinding release: Magnum and Le Tigre

On Wednesday 18th July, the Magnum RC will get a further roll of the pathfinding code and Le Tigre will apparently get the same code as well. At the time of writing, the actual release note pages on the SL wiki for Magnum and Le Tigre still reflected the releases for July 11th and the forum post announcing the release did not show any specific changes from the forum post relating to the July 11th release. Any alternations which may have been made following the difficulties some initially encountered on the Magnum RC following that roll-out are therefore hard to identify. This ma change prior to the actual roll-out.

Related Links

Project Shining: what it means for the viewer

Posted on by Inara Pey

On the 29th June, Linden Lab announced Project Shining, aimed at improving avatar and object streaming speeds. At the TPV/Developer meeting on Friday 13th July, the project was discussed in terms of how the various elements within it will affect Second Life viewers.

The following is a summary of that discussion, based on the recording of the meeting, and focused primarily on the viewer changes / updates that will be most directly seen / felt by the majority of users.

HTTP Library

Commencing at 22:30 into recording.

The aim of this project is to improve the underpinning HTTP messaging that is crucial to simulator / simulator and simulator / Viewer communications. Monty Linden is leading this project.

Key points:

  • LL will release a project viewer containing a new “wrapper” implemented around how data is handled and a new texture fetch library  (see time frame comments at the end of this article)
  • Providing there are no major problems with the project viewer, the initial code release will move to a release version of the viewer
  • This will be followed by changes to group services and a “more ubiquitous” use of the library in the viewer – which is where Oz’s warning to TPV developers comes into play, as some services and the behaviours will start to change to improve throughput and reliability – and may even help improve the SL experience for those on older routers.

As a side note, some of this work has involved router testing aimed at determining what router hardware is compatible with Second Life. While it is hoped that work around the HTTP libraries will improve the SL experience for some using older router hardware as noted above, the tests have revealed that certain types of older router – Linksys WRT and Belkin G series routers were specifically named – are not compatible with running Second Life.

Avatar Baking

Bake fail: a familiar problem for many

Commencing at 32:38 into the recording.

The aim of this work (Project Sunshine) is to improve issues around avatar baking and to eliminate bake fail issues. It will primarily focus on moving the emphasis for the baking process from the viewer to a new Texture Compositing server. The viewer will retain some elements involved in avatar baking – the actual baking of the avatar shape (i.e. shape values and IDs) will still take place on the viewer side, for example.

Precisely how this new service will work on the server-side of things is yet to be fully determined by Linden Lab. However, work is progressing on the viewer side of the equation, with the current key points as follows:

  • The new service will use the Current Outfit folder to drive the new baking service
  • TPVs not currently supporting Current Outfits will have to implement it, otherwise they will effectively fail on avatar baking
  • The basic process will be that when it is time to send a rebake request (e.g. after a user has finished editing their appearance) the viewer must send a new message to the baking service which effectively says, “Look at the contents of my Current Outfit folder and give me back a new appearance based on that”
  • Viewers in general will have to support this new message that is sent to the service, and change how they perform the fetching of avatar textures; for the technically inclined, this will be HTTP without UDP fallback.

Currently, the plans is for LL to integrating the new way of doing avatar baking into their viewer code, which will be available for TPVs to integrate – although none of the Linden Lab 1.x code will be updated to support the new process, so this will effectively break their own Viewer 1.23.5, which currently is still in use within SL.

The viewer code will support both the “current” method of avatar baking (within the viewer itself) and the new baking service (using the Texture Compositing server) until the new service is fully rolled out across the grid. This means that if a user is in a region that does not make use of the new baking service, avatar baking will continue to be handled using the viewer-side mechanism we currently have. However, if the user is on a region that utilises the new baking service, avatar baking will be handled through that. The viewer will be able to recognise whether it is connected to a region supporting the “new” method through the region capabilities.

In order to ensure as smooth a transition to the new baking process as possible, LL are proposing a relatively long lead-in to the new service, making the code available well ahead of the new service being enabled, allowing TPVs to integrate it into experimental builds. The server-side changes will initially be implemented on a number of beta grid regions for testing with viewers there, prior to being scaled-up. The server changes will then be released onto the main grid in a controlled manner and then scaled up from there.

What Does This Mean for Users?

If all goes according to plan, and providing that you keep up-to-date with releases of your preferred viewer, this actually shouldn’t mean very much in real terms. There are however a number of things to be aware of:

  • If you use a viewer that is not updated to use the new code (i.e. the official viewer 1.23.5 or a viewer that is not updated to use Current Outfit folder and / or to support the new bake request message / HTTP texture fetch mechanism) OR you continue to use an old version of a viewer rather than updating, there will come a time when your avatar  – and those around you – will not bake correctly
  • There are two issues that may occur during the transitional period when both the “current” and the “new” baking methods are in issue:
    • When teleporting or crossing between regions that use the different methodologies, users will experience their avatar rebaking, as the viewer will effectively be using two sets of data for the bake process
    • If there are two adjacent regions, one of which is uses the current avatar bake process and the other is using the “new” baking service viewers in one region will not be able to correctly resolve the textures of avatars in the other region
  • It is hoped that the transitional period where both methods of avatar baking are active will only last for about two weeks.

Object Caching and Interest Lists

Commencing at 57:25 into the recording.

When you enter a region at the moment, your viewer receives a huge amount of information on what requires updating, much of it relating to things you can’t even see from your position in the region. The data is received in no particular order, with the familiar result that things appear to rez in your view in a totally random order – quite often with the thing you actually want to see being one of the last to rez due to the mechanics of Sod’s Law. What’s more, if you have previously visited the region, the chances are that much of the information being sent to your viewer is already cached.

Object caching and interest list changes: easing the pain of random rezzing

The focus of this project is to optimise the data being sent to the viewer, information already cached on the viewer and the manner in which that data is used in order to ensure it is used more efficiently so that things rez both faster and in a more orderly manner than is currently the case.

At this point in time, this work is in a greater state of flux than the HTTP library and avatar bake projects. This is more a process of optimisation both on the server-side of things and within the viewer itself, rather than that of new functionality within the viewer per se. There are no general time frames for this work at present, but there will be updates once things become clearer as to how the optimisation is going to be addressed.

Time Frames

The precise timeframes for implementing these changes have yet to be properly defined. However, Oz Linden hopes that there will be at least a two month period between Linden Lab making the code for each of these project elements available for integration by TPV developers into their viewers and the point at which the Lab states the code must be in use.

At the moment it is likely that the HTTP library element of the project will but rolled-out first, although this is unlikely to be within the next two months, for the reason given above. Project Sunshine, dealing with avatar baking, will then follow after that – or although how soon after has yet to be determined; as described earlier in this article, this will be a very controlled roll-out. It is possible that the object caching / interest lists part of the project many not be rolled-out for another six months. However, timeframes are still in discussion within LL, so any of this may well change.

Expect updates on all three of these project elements as and when more information is supplied by Linden Lab.

Related Links