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?

Tweet

Comments

[shockwave yareach]

I would have thought a simple additional command (llSetPathfinding) so that ONLY prims actually coded to be pathfinding would run it was planned. You're saying that any and all devices that move will be running the pathfinding code whether I want it to or not?

I think I'd better find a pathfinding sandbox and experiment.

[Shug Maitland]

I wonder how this will impact the mainland, where LL is the Estate Manager. There is every possibility of a double-whammy for us.

[DBDigital Epsilon]

I have some first hand 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.

[Shug Maitland]

OMG! can you imagine a place like Omega Point resetting every prim in the build!!!

[Little Lost Linden]

Holy Moly!

[Dave Bell]

And has anything from Linden Realms actually appeared yet?

I can adjust my own stuff, I suppose, if the silly beggars ever take the trouble to tell their customers, but what of some purchased item that is No-Modify?

Worse, what of the stuff owned by dormant accounts, which is scattered across Mainland. And then there are the prims for the roads and bridges and volcanoes that the Lindens have scattered across the landscape.

This all seems entirely consistent with the idea that nobody looks at the big picture. Maybe somebody should ask the Boss Mole what he plans to do.

[Marianne McCann]

Guess that explains all those transparent boxes and cylinders all over the Wilderness, over every "collidable" bit of sculpt or mesh content

[Any Gynoid]

Chuckles! I'm glad hand-wringers are "playing" with PF. Movers and shakers are building an amazing PF future for SL. I'll be teaching that course at NCI every week 2:30pm SLT: Pathfinding AI. PF is a major sea change for SL; transforming SL's vast lifeless regions into lively immersive experiences, teaming with life. Responsible use of PF will cause zero lag. I am stress testing right now on a complex region, 80 NPCs, no impact on Time Dilation or lag, Spare Time still 8 - 10 ms range, plenty! Falcon announced yesterday a 4ms/frame throttled max time for cutting the navimesh. Don't fear the future.

[Any Gynoid]

Sorry, I omitted date/place: Pathfinding AI Class, Tuesdays starting May 22nd, 2:30pm SLT, SLURL http://tiny.cc/2t2hew free. Prerequisites: Basic Building and Basic Scripting.

[Ajax Manatiso]

LL decided to outlaw scripted bots, but then created PF scripted "faux people". And the sense of this is ......??

[Nalates Urriah]

Falcon and Lorca corrected several points in my explanation to Hamlet. I've updated those in #SL Pathfinding Update Week 20 = http://blog.nalates.net/2012/05/18/sl-pathfinding-update-week-20/

Any Gynoid & DBDigital have very different experiences of PF. As PF is released we'll see how many fall in which group. Overall I believe PF will improve grid performance.

After Falcon's explanations I doubt we will have the problems DBDigital ran into. Those are being fixed. But, for built out regions adoption of PF for use is going to be some work. New builders are going to run into problems.

[shockwave yareach]

@Ajax -- the sense is, LL has finally realized what so many have been saying for a long time. That SL is a recreational venue for most people. And while there are a number of professional builders and scripters in SL, even among them very few are making a living doing anything in SL.

There are a number of possibilities opened up by having games which you are persued, or are the pursuer. Or with NPCs in a more traditional MMO setting. Basically a person can create their own miniGame within SL itself! Why would anyone want to, you ask? Imagine you are a DM in a D&D game. Now imagine not only are you able to create new games every week for your friends, but visualize them in SL and turn what was a board and dice game into an actual video game, with new adventures every week or two. And if you charge a small amount for people to play the adventure on your sim to cover the costs of the sim...

It enables the builders in SL to create videogames within SL itself. It improves upon SL's interactivity and adds some game elements to the mix; stuff we've been sorely needing for half a decade. This is hardly the same thing as bots sitting in chairs to make the sim look full.

[Ciaran Laval]

NPC's aren't going to happen much until we get improvements to the way we can animate prims.

There some potentially horrendous issues, as outlined, but it's still in the testing process.

[Any Gynoid]

I cannot validate your concern Ciaran. Haven't you heard about llSetLinkPrimitiveParamsFast which is a wonderfully powerful new architecture for linkset animation (linkset is a set of linked prims), you don't need a script in every prim anymore, it's all doable from the root prim...

But wait there's more... you don't even have to write LSL to animate prims... just use Ferd's Super Prim Animator Script ( http://tiny.cc/tu5iew )... Put this script in a linkset critter and Touch it... self explanatory... easier to learn prim animation than using an early MAC imho...

And guess what, when you do this in combination with Pathfinding and chatbots and other LSL capabilities... the possibilities are awesome... It's really too simple; that's why I'm teaching this new class on Pathfinding Artificial Intelligence (scroll up on this page for time/date/SLURL).

Hand-wringing does lead anywhere. If you need more help with prim animations, I will hold your hand in my class until we will cross together into this brave new future… to create… prim animated… pathfinding … zero lag… artificial life forms. Which will proliferate throughout SL, once enough people see the light.

[foneco zuzu]

Lets hope that on this one at least the Lab will make it seamless and easy to adapt!

[Gonzo Thompson]

While I am certain teaching Pathfinding is a great idea... as is the idea itself... I am distressed to see namecalling and egotism raising up in the teacher.

If you want to be a great teacher, be secure in what you know, don't put down those who haven't your exact knowledge set and preconceived notions.

"Handwringing" to you may indeed show "serious bugs" to a developer.

And there is simply no reason to call fellow SL-ers names of any sort. We're all in the same boat.

[Ciaran Laval]

@Any Gynoid, there's no hand wringing going on, I've been testing pathfinding. The glorious future, as hinted at by Linden Lab, involves rigging mesh to animated armatures and development of object skeletal animations.

[RainO Tenk]

its been rolled out
PF on and i immideately did disable it
if anyone needs info about how to
just IM me about
RainO