Pathfinding overview

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”

Viewer release summary 2012: week 31

The following is summary of changes to SL viewers / clients (official and TPV) which have taken place in the past week. It is based on my Viewer Round-up Page, which provides a list of  all Second Life viewers and clients that are in popular use (and of which I am aware) and which are recognised as being in adherence with the TPV Policy.

This summary is published every Monday, and by its nature will always be in arrears. Therefore, for the most up-to-date information on viewers and clients, please see my Viewer Round-up Page, which is updated as soon as I’m aware of any changes, and which includes comprehensive links to download pages, blog notes, release notes, etc., for Viewers and clients as well as links to any / all reviews of specific viewers / clients made within this blog.  

Updates for the week ending: 5 August, 2012

  • SL Viewer updates:
    • Beta: rolled to 3.4.0.262596, July 30 – core update: addition of viewer-side pathfinding tools (also see my notes on the tools)
    • Development: rolled to 3.4.1.262722 on Aug 2nd
    • The Pathfinding viewer has been removed from the list, as the code is now incorporated in the Beta viewer
  • Dolphin rolled to 3.3.12.24739  on August 2nd – core updates: the reset, start, stop, remove, recompile script operations now request confirmation & can be accessed from the context menu of an in-world object; temporary upload is available when doing snapshots to inventory (release notes)
  • Niran’s Viewer rolled to 1.47 on Jul 30 – core changes: updates to experimental Preferences overlay; FPS counter will be displayed as text by default; assorted fixes (release notes)
  • Cool Viewer:
    • Stable branch rolled to 1.26.4.23 on Aug 4th, and is referred to as a “catchup release with the v1.26.5 branch”
    • Experimental version (SL3.3 renderer) rolled to release 1.26.5.2 on Aug 4
    • Release notes for both
  • Group Tools rolled to installer release 2.2.8 on July 28th.

Related Links

Mountain Lion issues for SL viewer

An issue has emerged trying to use the Second Life Viewer on Mac systems running OS X 10.8 Mountain Lion.

Notification of the issue has been posted to the Grid Status Page, which reads:

Issues Opening the Second Life Viewer in MacOSX

[Posted 8:30am PDT, 1 August 2012] Some residents may be experiencing problems opening the Second Life Viewer in a MacOSX Mountain Lion environment. This is due to a security feature of this operating system which is misidentifying some programs as potential security risks. While this is not indicative of any actual issues with our software, we are working on an update to our viewer which should address this. In the meantime there are instructions on how to bypass this feature temporarily, as well as an explanation of the cause of this issue, here:

http://osxdaily.com/2012/07/27/app-cant-be-opened-because-it-is-from-an-unidentified-developer/

Please note that this is not a problem with the viewer, and that we are not responsible for the workaround above – we are merely providing a link to a possible fix posted by a third party.

If you are experiencing issues using Second Life on Mac OSX, you might try the workaround noted above – but again, please note, as the report states, it is a link from a third-party, and Linden Lab (nor I) cannot be held responsible if the workaround fails or causes other unforeseen issues with your computer.

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

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

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

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!”