#SL Pathfinding Wk17 & Wk18

A little catching up… RL work has interfered with my making a couple of User Group meetings. One of the Lindens was kind enough to send me transcripts for the meetings I missed.

Land Impact

The Lindens were testing the modified Land Impact system in week 17. They were using the algorithm that set a cap on Streaming/Download Weight of 1 on all non-mesh-prims.

Also, the Script Factor of increasing Server Weight by 0.5*prim_count for unscripted-prims and scripted was switched to 0.5*prim_count + (0.25*number_of_scripts) with a cap of 2. Rounding is done on linksets. The Lindens believe that change would only cause the Land Impact cost of existing objects to decrease.

While one could probably prove the deceasing cost belief mathematically, on a practical level bugs tend to add chaos to and invalidate clean logical proofs. So, they test.

The costs for poorly made physics shapes will still be high. The change should handle most of the other valid complaints about the new Land Impact cost accounting.

Example

Consider the case of 4 cubes linked together. Three use shape=none and one uses shape=prim. That gives a download weight of 0.2, physics 0.1, and server 2.0.

In the previous Land Impact accounting adding a script would raise the server weight to 4.0. In the system being tested the server weight will change to 2.25.

To keep the example simple, change 3 of the cubes to tori: 1-cube and 3-tori. Under the current system download weight is 4.2, physics is still 0.1, and server is still 2.0. The system under test should give a download weight of 3.2. Falcon Linden thought the system was set to round to the nearest integer value.

Example 2

Using 3 linked tori with the root set to convex hull and the children set to none the LI costs are: 4.1 download, 1.8 physics, 1.5 server. In the new system: 3 download, 1.8 physics, 1.5 server.

Falcon Linden said, “Essentially, in the new system, the only thing that can make the LI of an all prim object exceed its prim count is physics.” I would add to that: …and a load of scripts. But, I’m not sure I understand.

Maestro Linden phrased it as: “…you take the minimum of calculated streaming cost and the cap (prim count) then go from there and take the max to calculate Prim Equivalence.” In a attendee build a sculpted 31 prim motorcycle, in mesh accounting gives 39 PE (39.4), from a physics of 5.5 (with engine block and wheels as convex hulls and everything else as”none”) thus: PE = max { min{39.4, 31} , 5.5, 31 } = 31.

Falcon says, “Mesh objects with fewer than 2*num_prims scripts will see their server weight reduced. If that wasn’t the limiting factor, though, their LI won’t change.

This new accounting was to be rolled to the Pathfinding regions in the main channel Monday week 18. There were about 50 or so regions moved into the Beta Testing on the main grid in week 18. Lorca Linden is still working his way through a stack of emails. So, if you haven’t heard back on a request to join, give it some time. You are good to go, if you have sent an email… and included the region name If you want to join the beta email: pathfinding-beta@lindenlab.com. Hurry. This Beta will likely only get one move group added. That means you’re out until Pathfinding is released. Lorca thinks they will max out the beta group at 150 regions.

As of 5/3 the number of regions in the Beta more than doubled, about 102 regions now. The code they are running on is debug code. That means it takes a performance hit. However, Lorca Linden says of the 102 regions all but 4 of them are performing at over 30 fps, with the great majority at over 40 fps.

Test Region

Isle of Legacies is one of the regions in the Beta. It is a complex region and is providing a good example of region with complex Pathfinding. A high number of dynamic objects (3352 movable obstacles ) throw a load on the server.

Due to a miscommunication Isle of Legacies was added into the PF Beta by mistake. The region had not been prepared for Pathfinding. The region is going to be atypical as it uses SL traditional NPC’s. But, it is representative of what can happen when Pathfinding is released grid wide. Region and land owner’s will need to make some changes to keep performance up. So, I expect to see a grid wide slow down when Pathfinding is rolled to the main grid.

Feedback

In week 17 Falcon created 2 JIRA items to get feedback on the Navmesh A/B/C/D character types and character height. See:

PATHBUG-95 – Suggested Character Height

PATHBUG-96 – Suggested Character Types

Lorca says, “If you don’t help us pick values, WE will pick them ourselves.

The problem with heights is no single selection is going to work for everyone. If the avatar height is used, pets will never run under a table. There are many complications. The Lindens are trying to find out what the resident’s preferences are. So, don’t say they never ask.

User Group Listing

There is now a listing for PFUG (PathFinding User Group) on the Second Life User Groups page of the wiki. That leads to a page with the PFUG meeting transcripts.

Behavior Changes

The team has made changes to AI character behavior;

  • Improved avoidance and better adherence to the character properties  specified.
  • Characters should also stay a bit farther away from one another when passing. Bad things may happen if characters are forced too close together. That is being worked on.
  • CHARACTER_CMD_SMOOTH_STOP was added, which will slow down the AI either at the max deceleration or, if that doesn’t provide enough room, it will temporarily change the max deceleration to make sure the AI can stop in time.
  • You can now ask to not avoid other characters and you can ask to not avoid fast moving objects and agents (together as a group).
  • llPursue should behave better in most circumstances. Apparently offset pursuit characters can run off the Navmesh. Falcon is looking into that.
  • PURSUIT_GOAL_TOLERANCE has been added as a float parameter to llPursue.
  • PURSUIT_GOAL_TOLERANCE will make the system consider the AI to have arrived at the target if you are with the specified distance. This should help keep characters from pushing people around during pursuit.

Work has started work on some parcel restriction support. The current plan is to make it so that characters will not willfully cross into or out of No Entry or No Script parcels. They can move around inside or outside, and will violate the boundary if pushed, but will try to avoid it where possible. Falcon’s hope is that a full parcel (prim limit full) will temporarily have boundaries like a no script/no entry parcel, but it’s not clear how easy that will be to make happen.

A character will require a minimum of 15 free prims, more if the streaming or server weight dominates. So, even with 14 free prims, a character might get returned. And temporary prims do count.

Falcon is thinking that to ensure the Lab actually releases this stuff some day, they won’t handle the full parcel case. But Andrew Linden might disagree.

Temp Rezzers

You may know about various tricks to use ‘temp rezzers’ to get around region prim limits. Should have noticed that no longer works with the Land Impact accounting system.

Pathfinding ETA

The Lindens are not saying. It is getting “close.” The hope is to be rolling out release builds starting week 18. In this case a “release build” means: a completely non-debug build. The Lindens are using different levels of debugging. The trades offs are between collection crash information and performance.

Building Defaults

For legacy reasons the default attribute of rezzed objects is Pathfinding Movable. These items have a Pathfinding cost. They place some load on the server. Movable obstacles have to be checking every frame to see if they’ve moved or if anything overlapping them has moved. The larger they are the more expensive they are because of the increased number of overlaps and objects touched. Objects marked as Static are essentially load free once the Navmesh is calculated.

So, why not make all newly rezzed objects ‘static’? The reason is the Navmesh. To move a ‘static’ object one must “Unfreeze” the Navmesh. Imagine what would happen if everyone had to unfreeze the Navmesh to move a prim. Using static as a default to improve region performance would not be a fun thing for builders. As Lorca Linden says, “Setting all objects to static as default is definitely the best option as far as performance is concerned. HOWEVER, that means people will be unable to move those objects without changing modes first.” Since one has to be using a PF Viewer and have rights to change the Navmesh, using ‘stat’ as a rez default would block many people from building. While there is a Region Console Debug Setting for unfreezing the mesh, most users do not have access to region consoles.

Breaking Changes

This is beta, so some changes break previous objects. Falcon is making a couple of change that can break stuff. There are two API changes;

llWanderWithin will start taking a vector instead of a float to specify the extents in which to wander. Falcon thinks that may break any characters that use it… he’s not sure, existing characters might be able to handle that, but new characters won’t compile unless they use the vector.

As mentioned above: CHARACTER_MAX_TURN_SPEED will be renamed to more accurately reflect what it does. CHARACTER_DESIRED_TURN_SPEED.

Region PF Rules

Region Parcel Rules for PF made it into the current PF version. But, the rules only work on the FIRST parcel in a region. This is a bug, so it is not possible to know which parcel is ‘first.’ One will have to experiment to find it. That will get fixed.

The plan for the rukles is:

  • If your parcel does not allow everyone’s scripts OR does not allow everyone’s objects to enter, it will be considered isolated which means:
    • Essentially, very thin exclusion volumes will be placed along its borders from 0 to 4096m. This will prevent characters from willfully pathing into or out of such a parcel. However, it will not prevent characters from crossing if:
      • They are pushed there by something physical (including an avatar or other character).
      • They may punch through during certain pursuit maneuvers.
      • llNavigateTo FORCE_DIRECT_PATH will completely ignore the boundaries.
      • What will happen at parcel edges on region borders is currently unpredictable. That will get fixed at some point.
      • Full parcel handling is being omitted for now, as impractical for the time frame.

Turning Circle

Part of avoiding the thin-volume punch through problem involves turning radius. AI characters now consider turning-radius in their Pathfinding. Failure to handle the radius properly was resulting in AL’s falling off things and punching through thin obstacles. While it is handled now, is incomplete. The AI pivots rather than use the radius in these cases.

PATHBUG-109

PATHBUG-109llSetPrimitiveParams [ PRIM_ROTATION ] Broken. This bug is causing those using Pathfinding and attempting to animate their AL’s a problem or two. Basically rotation is borked.

PATHBUG-109 - Rotation Bork

Hyper Mole

Hyper Mole is a mole person… if you don’t know about the mole people ins Second Life, check out the wiki. Basically this are the people that do building for the Lindens in public spaces, like the road system.

Hyper Mole built much of the Pathfinding related things in the new Wilderness Area. If you need help with Pathfinding in your region, contact Hyper in-world.

Stinson Linden

Stinson has been working on the Pathfinding Tools. He was in the week 18 PFUG meeting to answer questions.

Currently there is a new release of the PF Project Viewer about every other day.

Summary

Pathfinding is definitely a busy beta project with lots of things changing. I think it is cool we have 102 regions in the main grid using Pathfinding now.

4 thoughts on “#SL Pathfinding Wk17 & Wk18

  1. Pingback: Land Impact change: “Is it a prim? Is it a sculpt? It’s a…” | Living in the Modem World

  2. Pingback: 2012 Reviewed – April To June » Ciaran Laval

  3. Pingback: 2012 Reviewed – The Full Monty » Ciaran Laval

  4. Pingback: Pathfinding overview | Living in the Modem World

Leave a Reply

Your email address will not be published. Required fields are marked *