This posting showed up on the SL forum:
BlackMagi Darkwatch wrote:
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.
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.
In another post this showed up:
BlackMagi Darkwatch wrote:
Why do I now need to unlink buildings (remove the floor prim) to make it walkable? This is especially pertinant as mesh builds can’t simply be unlinked. The only option (if I’ve read correctly) is to add another prim to act as the physics shape?! Or re-upload the mesh…
You don’t need to unlink and relink. Honestly, I’m not sure where that idea came from but I know it made its way into the documentation somewhere (which should be fixed). Here’s the deal:
In a perfect world, walkability would be a per prim property not a per linkset property. For technical reasons, this wasn’t achievable (and how would you have liked to have to set properties not just on all your linksets but on individual prims?!). So you have a couple options if you’d like to make a complex linkset like a house walkable (ignoring issues surrounding special prims like doors):
1) Make the whole house walkable. This is a perfectly good first pass solution. The only negative effect is that rebaking the navmesh will take slightly longer (I very much doubt it will ever be noticeable).
2) Unlink the walkable surfaces, link them together as a second linkset, and make just that walkable (and the rest Static Obstacle). This is understandably annoying, sometimes impossible, and generally unnecessary.
3) As a step better than (1), make whole house walkable and then drop an exclusion volume in that encompasses only the walls/roof. This will produce a result very similar to (2) (though not identical).
My house is not something I can edit. I made it walkable by adding 4 prims. Click to enlarge the images. I’ve added notes in the image so you can see what I did and the result.
The first image shows my house with 4 prims added. If I had built the house I would have used the existing floor prim. The Walkable prims create a yard, ramp, and in-house floor. There are 4 obstacle prims. I really only needed the one I have colored red.
The second image shows the resulting Navmesh laid over the original image. You can see the vertical faces of walkale primes are ignored by Havok as it builds the walkable Navmesh. You can also see how it handled the ramp connecting the floor and yard.
I’m still experimenting. My AI Character works just fine in the yard. It won’t start or wander on the patio or floor. On most occasions the character has stalled when I return. I’m adding some debug code so I can see what is happening.
In one case it managed to fall out of the yard. I still don’t know how that happened.
Innula Zenovka wrote:
As to vehicles, one issue I know some people have had is that when stuff that was using llVolumeDetect automatically converts to physics shape none (llVolumeDetect prims) and convex hull (everything else), this obviously puts you into the mesh accounting system, and it doesn’t necessarily do it the most economical way, in that (for example) tortured prims — especially toruses — can artificially inflate the LI unless at least some of them converted to physics shape none, too (the number of prims with a high rendering cost makes a difference). But the automatic conversion process can’t know what to convert and what not.
Incorrect. The sim will never automatically opt you into the new accounting system. We only change the child to shape none if it was already using mesh accounting. Otherwise, we change the prim to behave like a normal phantom object. You can see this by noticing that in a non-mesh-accounting linkset with llVolumeDetect hacks those hacked prims now collide with the terrain (like a phantom object) whereas they did not before (and do not if using new accounting a shape type none). This is a minor problem and we felt it was the best way to handle the issue without introducing significant additional complexity.
We have a number of Chicken Little types running around. There is lots of bad information and misinformation around right now. Plus a few people with little experience are blaming problems with their builds on Pathfinding and the Havok 2012.1 update. And buried in among the bogus stuff are some legitimate problems.
If you have a problem that you can reproduce and can write a step-by-step process for reproducing it, submit it as a JIRA. If the Lindens cannot see the problem, they cannot fix it.