What DBDigital did not get to is the size of the chore that converting to Static PF Objects becomes. He only scratched the surface. It’s bad enough that one must consider changing 14,000 prims. While that is tedious enough there is more to think about. I do hope we get some script API’s so we can write scripts to do the conversion to PF statics.

Consider adding a bunch of steps to your building process. When I build I usually have the Build Tool and inventory open while I work. I suspect for new things that will still be true for me. But, as I start to set objects to PF Static things get really tedious. And this is what I think will fuel the drama.

Editing Problems with Static PF Objects

I’ve got to UNFREEZE the Navmesh so I can set an object to one of the PF classes, i.e., movable, static, etc. Add two more panels open. Then what happens if someone else is editing the Navmesh? How many of us can have the Navmesh in an editable state at the same time? I suspect several of us. And I suspect… or hope… the Lindens have looked at building stats to see how many people are building within a region at the same time. The stats likely tell them this is going to work.

I also suspect that several changes at the same time in complex Navmesh areas are going to confuse individual builders until it sinks in that they are not the only one making changes. And complex mesh that takes a ‘few minutes’ generate… is going to be a challenge. Builders will never have seen building lag like this. Fortunately is should be extremely rare occurrence.

The Upside

The Lindens are doing lots of neat things to make PF efficient and an effective tool for building regions. I talked about the negative side and things that are likely to annoy residents. But, there is an incredible upside.

Beyond Pf just being way neat and fun, its overall effect should be a significant performance improvement for Second Life. The current style of animation using llSetPos() is throwing a huge load on the physics engine. I think Falcon would remove the function if possible. Since doing so would break an enormous part of Second Life that isn’t going to happen. But, using llSetPos() for prim animation is going to die out. The performance hit of using llSetPos() is going to be too high. Scripters will move over to llSetKeyFramedMotion().

One of the supposed scripting tricks for performance is to use llSetPos() with phantom objects. Supposedly this removes them from the physics engine’s consideration. WRONG. It throws a number of wrenches into the works. I’ll get into that in another article.

llSetKeyFramedMotion() is way more efficient plus it is passing information to the physics engine. With this information the engine can improve PF calc’s and do them more efficiently. Plus it does the everyday movements and collisions much more efficiently.

The Lindens see the change over as being some something that will greatly improve the grid.

Summary

We have a load of work ahead of us. The Lindens have been doing a lot to improve the grid. We bitch and moan about how long it takes. But, they have been doing their share of the work to improve SL. Now, we will start to build more efficient models and script more efficient object animations.

My fear existing builds would be forced to update is likely not the case. A region that does not use PF can turn it off. Or they can leave it on and probably not notice a difference. DBDigital’s experience is something the Lindens are working to avoid. When the Linden have PF done then if region owner does leave it on, AI Characters built to wonder the grid will stroll through. They won’t stroll as efficiently as they would if the region was optimized, but I doubt we’ll notice much difference.

Converting a region will be important only to those that plan to use lots of AI Characters. I expect to see a grunge region with a load of roaches that flee when you walk in a room.

These are things that will make the learning curve higher for new 3D builders and more exciting for advanced builders.

These are things many are going to argue and debate in the coming weeks. Pathfinding is getting close to moving to a release channel. So, there is little time left for feedback to the Lindens to affect the final product.

Beta Test: Region owners can still get in on the testing and learn firsthand what’s up. This coming week will probably see the end of that opportunity. But, it could continue longer. I think Lorca Linden will soon start taking regions from the mainland and adding them to the PF channel. They need to get the PF code well tested before moving it to an RC. Email pathfinding-beta@lindenlab.com.