The Lindens were not overly happy with my explanation of Pathfinding (PF) to Hamlet (see: SL Pathfinding a Potential “Tsunami” (If We’re Not Prepared)). I didn’t expect it to get quoted when I wrote it. So, I took less time with it than I would have if I knew it would appear on Hamlet’s blog. Hamlet ask if he could quote me after I wrote it, which is OK. I could have rewritten some of it to be more accurate and more geeky. But, I didn’t. So, I got some stuff right and some stuff wrong and it got out there.
Whatever… The Linens got busy in Thursday’s PFUG meeting and explained which parts were right and wrong. We got lots of good information. The technical corrections are easy. The most disagreement was on how much drama there will be. I have no doubt there will be some drama. There always is.
Falcon explained about doors, I got that right… 🙂
“Doors will need to be made differently IF you want the characters to cross the doorways. What that means is that your house (which will be walkable) will need to rez out its door as a separate keyframed object. Since you can’t move prims around on a walkable object. You’ll need to rely on the dynamic Navmesh cutting to handle doors.”
The biggest mistake is in my statement: 🙁
“The challenge is when something in the region moves, like a door or bridge. Then the Navmesh has to be recalculated. The Navmesh calc is intense and slow. It is done in a separate thread so the region won’t freeze. But, the simulator has to crunch the numbers. This is so intense Falcon Linden has built in frame skipping and throttled the Navmesh recalc frequency.”
That statement is a mix of right and wrong. First Navmesh calc is slow. Falcon said, “The very long and slow part (usually only tens of seconds, really, but sometimes a few minutes) is Navmesh generation.” I got that part. But, the things that trigger a Navmesh recalc (re-generation) are not movables moving. So, doors and bridges won’t be as big a problem as I thought because they are handled by a separate Navmesh Cutting thread. Also, Navmesh calc, while intense, is in its own thread, so it does not freeze a region.
About the only thing that will force a Navmesh recalculation is changing the Navmesh. That can be done by editing it. After some experimenting, I can’t find anything else that forces a Navmesh re-generation.
Once the Navmesh is calculated Falcon Linden has written in several measures to prevent it from needing to be recalculated. So, when a prim moves it must be a movable Pathfinding (PF) object. If an object is set to Static, neither simple editing via the build panel nor scripting can move it. All Static objects are dealt with in the Navmesh generation and then ignored by the Navmesh Cutting calc’s.
Size of the Problem
Think about a region with a 15,000 prim limit and suppose it has 14,000 prims. Initially the region would have 14,000 movable objects for PF to deal with. The way the system works, is complex.
Navmesh Generation and the Navmesh Cutting calculations are handled by different threads running in the simulator. The movable objects Navmesh cutting calc is way less intense than Navmesh Generation calc’s. Since cutting runs in separate thread it is possible to cap it at 4ms per frame. So, only a region without 4ms of free time will see any slowing from movables causing cutting calculations. Mix in the new Region Idling and slowing within the simulator from cutting calc’s should be minimal.
As movables load up the cutting process the calculations must fit in the 4ms/frame window or fall behind. The system is designed to have PF performance degrade and avoid degrading region performance.
So, I was wondering what actually happens to a region when a 14,000 prim region begins running with PF enabled. So, I asked, “When a region with lots of prims converts to Pathfinding, do all of the prims act as movable? Or only those touching the ground and intersecting the PF area?”
Falcon answered: “It’s a bit complicated. There are different levels [of] optimization involved. For example, every movable object (i.e., everything, initially) will be checked each frame (assuming we’re doing cutting that frame, per the 4ms/frame average rules I discussed above) then those whose AABBs DO NOT intersect the Navmesh are eliminated from consideration. Finally, the remaining movable obstacles are checked for whether they’ve moved since the last cut. It’s a bit more complicated than that, but it’s generally optimized and accurate.”
So, if things go as the Lindens envision them, this tsunami should be a small ripple.
If you read through the comments following Hamlet’s article, DBDigital Epsilon wrote:
I have some firsthand experience with the Pathfinding beta. Long story short we were placed in the beta by accident and the sims went from 1.00 to .50 time dilation (at best). And .20 at worse. If you jumped when you landed normally you hear a “thud” sound. But in this case it sounded like a machine gun going of THUD-THUD-THUD-THUD for several seconds. When we finally figured out what was going on the sims were revered to the normal SL Server. And I figured it was likely due to the different physics engine and when I was jumping I was landing on prims instead of ground.
But here is the really interesting part. Afterward we find out that apparently if the prims on your sim are not set to “obstacles” or aka “non moving” they cause lag. So the fix is to *cough* set all your prims to non-moving or “obstacles”. Now keep in mind in a empty sim or new build sure no problem. But in a old build who in the world is going to go though and set 12,000+ prims PER SIM to “obstacle”?
I can’t imagine why LL is not setting that by default? Most objects don’t move, some do yes, but not most. And therefore their thinking is totally backwards. I can only imagine they have only been developing on ground instead of on top of builds (which most of us in SL do). If this beta is released with its current methodology I can tell you that a lot of estates are going to close rather than try to go though and fix the mess.
DBDigital doesn’t say when the experience happened. So, we cannot know which iteration of the PF software his region ran on. Also, the main grid is always behind the ADITI versions. Both versions also currently have ‘debugging’ code running and that slows things down. Each day optimizations are tuned and added. So, the actual release code will be faster.
DBDigital also sees the problem of updating thousands of prims to Static to improve performance. I think the quick take many will take way is not making the change to static will slow their regions down. The information above should show that it will be Pathfinding Performance that will degrade NOT the overall region performance. While having lots of movable PF objects in a region is more load on the simulator, if you have been watching regions lately, it looks they have more than enough spare time to handle PF without slowing the regions. And Region Idling will give the simulator even more free time.