It seems some viewer problems are holding up the Pathfinding Project’s formal release into Second Life™. Along with that are some server side problems too. But, the viewer is the main hang up.
A World with Critters
If you have been using the LL Development Viewer, you know it is horrible. Of course it is the job of a development version to reveal problems and it certainly is doing that. The problems are not really related to Pathfinding or the Pathfinding tools. But, a decision to allow the PF Tools and a number of other viewer changes to be rolled together means they are now stuck going through QA together. It seems we are past the point of no-return for that ship.
Working with Pathfinding I’ve needed to do some things I don’t normally do. Basically I avoid doing rotations as much as possible because I just have not gotten my brain around idea of Euler-Quaternion and why gimbal lock is a problem.
The new task I needed to accomplish is how to get my Pathfinding AI Character to look at someone in the area. We have lots of new functions that can be used to assist with that.
My Pathfinding Character
I looked at llLookAt(). This function points the positive Z-axis toward an agent or object. That creates an immediate problem because the llCreateCharacter() points the Z-axis up. I think one can rotate the Character to make the Z-axis horizontal, but that doesn’t work for my character that needs to be taller than it is wide.
So, I created a simple character using the new LL pathfinding functions and watched it merrily wander around – I won’t be leaving the object out though as my simple 1 prim cube had a LE of 15! Not sure if the LE values are going to tweaked – I do hope so as I feel that is way too costly.
All pathfinding characters have a fixed physics weight of 15. Adding prims will not cause this weight to go up and the weight is not affected by the physics shape type parameter. Streaming and script costs are computed are for any other object and the total land impact remains the max of all weights. So yes, a simple 1 prim cube has a LI of 15, but a much more complex character may still only have a LI of 15 (unless dominated by streaming or scripts, in which case the physics weight is irrelevant).
So, there is a surprising cost to the AI Characters. At least it surprised me.
The Lindens have been gearing the SL system to associate costs with the resources used. From outside the Lab we have no way to know if the cost is equitable or not. Fortunately SL runs from a free market and users are free to use AI Characters or not. That won’t make the entitlement folks happy, but that’s life.
Adding Prims to Control Navmesh – Click Enlarge
I have a 2-prim and 1-sculpty AI Character. My edit panel shows it as 1 object and 3 Land Impact. I can’t get the More Info to show the Physics cost. That is probably and issue with the development viewer. Continue reading →
Thursday we had a meeting with Lorca, Falcon, and Stinson Linden. We got some questions answered. Motor Loon had a good whine about Pathfinding, the keyword being good.
The Lindens have a couple of days of stats to look at now. The result is the average performance of the grid has not changed. This means that while most regions are NOT optimized, they are not pulling down performance.
Pathfinding User Group
Falcon pulled up the Pathfinding code and explained what the code is doing in English. What he said follows. Continue reading →
There are some interesting threads appearing in the SL Forum. Most of the most outraged are people that don’t follow events or know the history of history of Second Life™. There are a few us trying to help those people. But, if they keep their heads buried in what they are doing and only in their primary interests, we can’t do much for them.
If you’re reading this blog and/or Inara’s Living in the Modem World, you are pretty well informed. I think we provide more news than you can get from the SL Forum and Blog. This morning I saw Inara’s: Pathfinding overview. It is a good overview/summary of Pathfinding.
The Problem People
Many of the vehicle makers have used a hack to create lower Land Impact vehicles and to get around other limits. Now they are crying about vehicles using those hacks being broke. I guess they did not include a script updating process either. I use DCS2 and UCE game meters and they send me a new boxed meter whenever they have updates. It is an easy process for them and me.
I’m seeing a load of misinformation on Pathfinding performance. Back in May I wrote an article getting into Pathfinding (PF) performance. See: #SL Pathfinding Update Week 20. Scroll down and read the section on The Size of the Problem.
Navmesh w/X-Ray Enabled
PF has several different aspects. One could break it into two main parts. One is the part where PF figures out where everything is in the region and how to treat it, as what are obstacles and where are the paths. This is a slow and calculation intense process. But, it really only has to run at region start up, when a region’s ground topology changes, or things are built on the ground. It is sort of an initialization process.
Another part is when PF has to find what has moved, like a door opening. Things like a door that cut across paths are called cuts. PF has to find things that move and ‘cut’ the Navigation Mesh mostly referred to as Navmesh. The cut calc’s are very fast. They only need to revise the previously calculated Navmesh.
I’ve put coverage of Pathfinding in several updates this week (29). This post has some of the unique items less related to other topics.
My First Pathfinding Bot (March)
Right now the main Pathfinding concern is how vehicles work with the new Havok Physics Engine version. Depending on who one asks, they work well or not at all. So, far that seems to be a matter of whether the vehicle is built well or not. I know saying ‘well’ is an over simplification.
The concern is not really with Pathfinding. It is Havok. But, Pathfinding precipitates the change from height maps to terrain mesh. That change is breaking some content…
The Lab does not resist breaking what they consider poorly made content, at least not in all cases. This seems to be one of those cases.
One of the big problems with vehicles and the new Havok is the use of collision surfaces made from sculpties and tori. Using either for the physical items in a vehicle is going to fail.
Report vehicle problems in PF regions in the PathBug project, so the right Lindens will see it.
This roll out of the Pathfinding code has caused a number of people problems. The wackadoodles are ranting in the forum. Those helping fix the problem are adding to the JIRA’s and creating new JIRA items. The forum thread is an exercise in ignorant arrogance by entitlement types… they are basically demanding: it’s a problem, you fix it. The Lindens have been looking for problem vehicles for weeks now. They need specific examples to learn what is wrong. Once they know they can create a fix, workaround, or explain what the problem is.
If one cannot provide specific steps for reproducing the problem, the Lindens can’t fix it. The vehicles they are using and testing work. So, if one is not going to provide specifics then please specify which hand you want them to wave in the air.
The thread is a good example for why Lindens tend to avoid conversing with residents.