There are lots of interesting bits of news on the Pathfinding topic this week.

In an odd start just as the Pathfinding User group (PFUG) meeting was starting the region was rolled to a new version. I just assumed my viewer had crashed and relogged. By the time I could restart and login, the region was back up. That is a pretty fast restart, but it is ADITI.

The new version is (or may be was by the time you read this) DRTSIM-100D 12.05.10.256426.

Navmesh Height

If you know region owners that are in the Pathfinding (PF) Beta, let them know the Lindens need user input on what value the community would like for a default HEIGHT for Navmesh. The Lindens will soon have to make a decision and implement it.

This height is the default character height the Pathfinding system assumes for Pathfinding calculations.

llSetRot et al

In the PF Project there have been some problems in regard to being able to animate AI Character linksets. The Lindens think they have that fixed in the ADITI PathTest regions.

llWanderWithin

This part of PF has changed. See the new information on the wiki page: llWanderWithin().

The function now uses a central base point and a distance to set the area. The distance is to be given as an X, Y, Z vector.  That effectively defines a cubical volume. A value of <20,20,2> allows for a distance out to +20m and -20m of the origin on the X and Y world axes and ±2m on the Z-axis.

One must be careful with the Z-axis specification. If it differs too much from the actual vertical displacement in the wander area, the process can fail.

ABCD Value Default Names

The Lindens are still taking resident suggestions for the naming of the ABCD Pathfinding controls. The naming will either cause perpetual confusion or make life easier. It all boils down to what the names mean to users.

Lorca Linden is considering using: humanoid, creature, mechanical, and other.

Sandry Logan likes Maestro suggestions: biped, pet, wild animal, vehicle.

Falcon suggested: Humanoid, Non-human animal, vehicle (mechanical?), other.

What these are named is dependent on what one thinks will be the largest uses of Pathfinding. Get your suggestions in, contact Lorca.

 

llGetClosestNavPoint()

This function now includes options for: CHARACTER_TYPE and GET_NAV_POINT_RADIUS. The wiki page for llGetClosestNavPoint() has yet to be updated. So, I’m not sure how to use those.

Jumping AI

I had not noticed that AI Characters can jump. Falcon said, “Anything can jump. llExecCharacterCmd(CHARACTER_CMD_JUMP, [float height])…or something like that…”

Cross region Navigation

Mæstro Linden thinks they have cross region navigation working for AI’s now. There were bugs in the process of fetching the neighboring region’s Navmesh. Mæstro Linden thinks they have that fixed.

Dynamic Content

Improvements have been made on performance in regions with a large amount of PF Dynamic Content, things that move and change an AI Character’s path. Since recalculating the Navmesh to relocate moving obstacles takes a relatively long time, the process is going to skip frames to keep the PF load to something less than 4ms per frame.

Falcon described it this way, “We will skip updating the Navmesh enough times that we keep the average time consumed at less than 4ms. So, if there are 15k dynamic objects in the region and it takes 25ms to step the AI system, we’ll skip stepping it for 4 or 5 frames. That will result in better performance but significantly reduced accuracy. If, e.g., there are vehicles moving around where you actually do care about updating them each frame. So we still strongly recommend you change your objects to walkable/static obstacle where possible.”

The current estimate is it will take about 50µs of a region’s time per frame to update the Pathfinding. This assumes the region is well crafted.

Managing AI’s

Falcon says they have code they plan to release that will allow users to manage the number of AI Characters based on region performance. This will be a function in Linden Scripting Language (LSL).

llGetObjectDetails() has or will have something like OBJECT_CHARACTER_TIME. They are currently using the feature in the Wilderness regions. This has not yet been documented in the wiki as it only works in Pathfinding regions.

One can also use the feature to tell when AI Characters are having problems. When their time exceeds 75µs there is likely a problem. On average they use 50µs or less.

Lorca says they will release the script templates they used in the Wilderness when they release Pathfinding.

Second Life Doors

I’m not at all sure I understand this one. But, it seems to me doors in SL are going to become a problem. Since doors are moving obstacles for AI Characters and have an effect on the Navmesh calculations, they are going to become much more complex things.

If a typical scripted door is set to STATIC for Navmesh purposes, the door breaks. The PF system keeps it from opening. Falcon’s idea is to use an auto-rezzing door…  A resident passed along a script for a house with auto-rezzing doors. That script can and will be made available with the release of Pathfinding. Personally I suggest releasing it now so people can start figuring these things out and how to implement them now.

Falcon says, “The correct solution is for the walkable house to rez out its door and for the door to use llSetKeyframedMotion.” That will change the world.

Apparently one can still use llSetRot(). But it’s likely going to look odd and add to PF lag.

Since the frame skipping addition to Navmesh recalculation, there is going to be some delay in the Pathfinding system knowing that a door has opened or closed. Which means AI’s could be blocked by an open door or pass through a just closed door.

Falcon explained, “llSetPos and llSetRot incur significant penalties, so they are throttled in terms of their effect on the Navmesh. Also, an object that changes its shape is HUGELY throttled. We will process only one such change per second for the entire region. The policy is fair in that every object will get its turn…eventually. I mean that we throttle the affect on the Navmesh, not the actual change. So the shape will change and the Navmesh will be wrong for a while. Translation: don’t make objects that change their physical shape.”

So… if you have pursuing monsters and escaping players some careful planning and proper door coding is going to be important. I’m expecting lots of problems and confusion in this area.

Changing AI Character Size

There are several things that can be done with character size and orientation. One thing that will cause a fail is increasing the size or orientation such that a character will penetrate a wall or other obstacle when the change completes. In such cases the change will be rejected and the script command will fail. I’m unsure whether it will trigger an error.

In other words a character cannot go from crawling to standing in a tight space.

One needs to remember the AI Character is always the collision capsule. The actual prim, sculpty, mesh bounding box shape is irrelevant for the size consideration.

Enable-Disable Pathfinding

If this is starting to sound complex, you should get over to the JIRA and watch this item:

PATHBUG-32 – Add server support and UI elements to enable/disable Pathfinding.

If implemented, and indications are it will be, a land owner can disable Pathfinding. That would allow them more time to prepare the region… assuming that Navmesh and object PF attributes editing is still possible while PF is disabled. Link over and click WATCH.

At the present time the enable-disable is going to be a region console command. This limits the ability to those with region console rights, Estate Managers.

All Regions Change

I mentioned elsewhere that a tsunami is building to hit SL. This is it:

For those on regions switched to Pathfinding code! You will need to use the linkset tools to change the pathfinding attributes of the objects on your region to improve region performance!

By default, all object are set to Moveable Obstacle (except terrain). You will need to set walls, trees, fences, etc to Static Obstacle. Set floors and other areas that need to be walkable to Walkable.

Don’t forget to click apply! Then FREEZE your changes for the navigation mesh to update.

Your viewer may freeze or appear to be locked up for a short time when you open the Edit/Test window, due to the client downloading the current navmesh. Any time the navmesh changes, you may experience freezes.

When Pathfinding rolls to the main grid… what is going to happen? Also, with new users building, their prims are going to be Movable/Dynamic prims. Those will place a load on the PF calc’s. So, we are going to have a new performance factor to deal with.

PF calc’s do not use up much time. But, in prim heavy regions the activation of PF is going to incur some performance penalty. Those regions that have lots of moving prims are going to take an extra hit. What the hit is going to be is hard to know. I suspect there will be little noticeable difference in regions with PF enabled and no AI Characters running around.

If a typical region would lag out from enabling PF, I doubt they would have decided on the default to make everything ‘movable.’ However, the reason for making all new prims movable is because making them static would mean the builder would not be able to move them after rezzing them. One would have to rez a prim,  edit the Navmesh attribute, then finish sizing and positioning the new prim. Since this Navmesh thing has been a normal part of the existing work flow, it would create confusion. Plus all those ‘How to build in SL’ videos would have to change.

I expect this to be a bumpy grumpy change.

Viewer Statistics

There is no specific stat for Pathfinding. The PF Time is included in the region Physics Time.

Fun Trivia

According to Havok, the peeps that make the physics engine Second Life uses, this is the first time anyone has tried to implement Pathfinding in a large scale, 3d world with dynamic content creation.

So, SL has another first in its line of credits.

Vehicles

People keep wanting to use PF over KeyFrameMotion to handle vehicles. The ABCD pathing in PF would seem to allow that. But, keeping vehicles in the proper lane become an insolvable problem… so far.

It may be possible if ‘exclusion volumes’ are used to divide lanes… but intersections allow the possibility that paths would wonder into the wrong lane.

See Hamlet’s coverage of the idea of Pathfinding vehicles here. Neat video included.

llGetPath()

Several people are interesting in getting a function that would return a path form the PF system. They would then use the list of points to accomplish their tasks. Falcon would like to add that function. For now it is a ‘someday’ dream.

It is considered handy for setting up railroads… I suppose the list would be a time saver for setting up the llKeyFramedMotion scripts. It would help with any path that seldom changes.

PURSUIT_GOAL_TOLERANCE

PURSUIT_GOAL_TOLERANCE is now part of the Pursue function for PF. I didn’t see the update in the wiki.

The item is to help with pursuing objects not being able to close the final distance to target and fire the ‘arrived’ event.

Summary

I have yet to get to play with these features so this is not much of a tutorial. I prefer to provide more how to help than this. I’m just not there yet. Plus this is already a long article.

I hope it helps and you learned from it.