SL Pathfinding a Potential "Tsunami" (If We're Not Prepared)
I rely on Nalates Urriah's blog for getting geek-heavy updates about Second Life code and features, so when she mentioned in a recent post that Linden Lab's new pathfinding features presented a possible "tsunami" of problems, I paid attention:
When the pathfinding code is released to the grid, she explained to me in an e-mail, "Doors need to work in new ways. Bridges will become a performance issue. Anything that moves and cuts the Navmesh [pathfinding objects], anything would cause an AI critter to change path... will incur a lag cost. Again, how much is a question." Right now, she continued, "[i]t seems the plan is to roll out pathfinding enabled on all regions and let estate managers turn it on or off. If that is done, tsunami."
Whether there's a tsunami or not depends on how Linden Lab rolls out the pathfinding code, and how SL landowners deal with it. Here's Nalates with the full geek exegisis -- read and discuss after the break!
Pathfinding (PF) generates a Navmesh for the Havok Pathfinding functions to use. That reduces the calculations needed for AI Characters to find their way. A region can use the terrain and objects in the region or an Estate Mgr (EM) can build a Navmesh, which would let them spec roads, walks, grassy areas, etc. AI Characters will travel according to what people have programmed them to do, slow on grass, fast on walks...
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.
There is a problem with building. When you rez a prim it defaults to a Movable PF Object. As regions are enabled for PF all objects/prims are movable by default. This makes for a much slower Navmesh recalc.
They cannot default new or existing things to Static PF Objects. If they do so, when you rez a prim it becomes a static part of the Navmesh and cannot be moved without Unfreezing the Navmesh, opening it up for edit and change. This is a cumbersome and slow process. The Navmesh has to download to your viewer, taking several seconds. I am unclear on whether one has to Unfreeze the Navmesh to change and object from Static to Movable. The ADITI grid is some what messed up for me since my last password change and I haven't played with PF as much as I would otherwise.
But, if you rezzed a prim and it stuck in place, what would you think? If you can't move it or delete it, you'll likely be WTF!?! So, all objects are going to be movable by default, which is going to give regions a negative performance hit. It is just hard to know how much of a hit. They are getting 150 or so main grid regions into the Beta to test the numbers and times.
Doors need to work in new ways. Bridges will become a performance issue. Anything that moves and cuts the Navmesh, anything would cause a AI Critter to change path is a cut... short for path cutoff I think, will incur a lag cost. Again how much is a question.
It seems the plan is to roll out PF enabled on all regions and let EM's turn it on or off. If that is done, tsunami. If they roll with it disabled, which I think they will change to, no big deal.
This all looks like an excellent place for the Lab guys to drop the ball. I think [Linden Lab engineers] Falcon and Andrew are sharp capable people. But, what they see as easy I think is going to be a load of work and problems for EM's. Renters are going to be dropping movable prims all over the place. So, not only are scripts, prims, and textures lag producers now movable objects produce lag. Building with PF on is going to be more tedious.
We will learn how to deal with it. I think there is going to be a bunch of drama. I hope I'm wrong.
I put the question to SL coders who have been playing with SL pathfinding -- how much of a concern is this?