Falcon Linden

Hi Frionil, Freya is correct. There is absolutely no need to delete and re-rez your objects. You are correct in that setting your objects to 'static obstacle' should eliminate the vast majority of pathfinding-related computations (assuming that there are no characters around). If you provide the name of your region, we may be able to investigate the cause of your performance issues. Falcon

Prokofy Neva wrote: Throughout my entire Second Life (eight years today!) I've always heard Lindens solemnly tell me that we must Avoid Collisions. That if a sim is acting up, it's probably because we have thingsg colliding. That we should not put chickens in coops because it makes them bang again static objects as they wander and all that physics dings the sim's performance. Always and everywhere, we try to remove colliding objects using the estate menus where you can see them -- pets, other automatic things moving. We try to keep the number of those colliding things down because they add to lag. So now along comes this Pathfinding thing, and I have to wonder (since you didn't mention it in your essay here) what all those collisions are going to do. Here are pets that are designed to deliberately wend their way through things, and likely they're going to collide on the sides of things on their way, no? How do you see this playing out? Hi Prokofy, One of the primary purposes of pathfinding was to provide a method for moving characters through the world that would be low-impact in terms of the physics system. Pathfinding characters use a map of the region (the navmesh) and predictive algorithms to avoid collisions wherever possible. This allows them to generally keep their collisions limited to the ground. I.e., no, pathfinding characters are not likely to collide on the sides of things. At the same time, all characters are represented by a special physics shape (a capsule, like a medicinal gelcap--a cylinder with hemispherical endcaps) for which particularly efficient collision calculations are possible. For pathfinding characters, the worst case collisions performance is generally caused by situations where many characters are confined to a small space and are continuously forced to bump one another in order to reach their goal. The chickens you mention were non-performant because (a) their shapes were complex and (b) they navigated in large part by bumping into things. Keeping them in a coup only made matters worse as you were confining many of them to one small area leading them to collide not only with each other but with the walls. Falcon

Hi Hitomi, You're correct that if you have a no mod object with moving parts, you should leave it as a movable object. In the case of a house, depending on its construction you may be able to work around this limitation and still use pathfinding characters inside. To do so, you would create a new set of transparent floor prims that lie just above the floor of the house and set /those/ to be walkable. If the walls of the house are made of independent prims (and not, e.g., a hollowed box) then it should be possible for characters to walk around the new floors. Unfortunately, the only way to test this is to actually try it because the effect of the movable obstacle house on the navmesh won't be visible in the viewer's pathtest view. Good luck, Falcon

Hi Qie, Those 3ms are spent updating the navmesh to account for movable obstacles in case any pathfinding characters should need to navigate around them. You make an excellent point though: why bother updating the navmesh at all when there are no characters? I'll need to ponder this some more--it might seem obvious that we should skip the work entirely in that case, but we need to fully consider any side effects that might have. I'll definitely give it some thought and perhaps implement that optimization in an upcoming server version. In any case, 23 skipped updates per second means that each update took roughly twice as long as we'd like, and so we're throttling them to 50% (0 skipped frames indicates no throttling, 45 indicates that none are ever occurring--a theoretical impossibility except for rounding errors in reporting). Setting additional objects to static obstacle or walkable should reduce this number. Falcon, reporting from vacation on Kona, Hawaii.

BlackMagi Darkwatch wrote: Another question about Exclusion Volumes (EV) I created an EV for a building out of prims, positioned, linked – prims used = 6 (LI 3, physics shape Convex Hull). Tested the path using the floater from inside the building to the outside, no problems at all. Tried the same exercise but this time using a single mesh and then hit a bit of a wall. The mesh shown in the linkset window was bracketed as concave and there was no option in the drop down list to turn it into an EV as physics type prim. However, upon changing the physics type to convex hull (as we’ve been told there is no agent interaction with an EV) I was then able to select EV from the drop down list in the linksets floater. Rebaked the navmesh and then tested – there was no way to place the test character within the building and upon inspecting the object it had turned itself phantom. Not sure if this is a bug or expected behaviour but it would be very nice to have the option to create a 1LI EV for people who would like to use pathfinding. What does the concave bit mean? Great questions. 1) Exclusion volumes are, by definition, "volumes". They must be made up of one or more well-defined volumetric shapes (e.g., boxes, spheres, cylinders, convex hulls, etc.). Meshes, on the other thand, are composed of individual triangles generally do not represent convex shapes (if you're using a mesh to represent a convex shape, don't. Use a convex hull instead). Essentially, for a mesh object, we don't have a good way of determining "inside" from "outside" without some very expensive calculations (and, in many cases, there is no "inside" vs "outside" because the mesh doesn't form what mathematicians call a "closed, orientable surface"). So if we were to let you designate a mesh as an EV what you'd end up with is an object where each individual triangle behaves like a 2D exclusion volume (e.g., by slicing the navmesh where they intersect) which is definitely not the idea. The same thing applies to Material Phantoms. One workaround might be to upload the mesh using a convex decomposition for physics and leave it as shape type prim. The result would be a shape made up of one or more convex hulls, but still representing the original mesh fairly accurately. To be clear, I've never tested this as it wasn't really expected to be a common use case, so if you try it, please report back. 2) Exclusion volumes and material phantoms are always phantom. The idea is that they should be used to designate volumes in a region which have different properties (e.g., EVs designate volumes characters can't enter and material phantoms designate volumes where characters may move at different speeds). Designating an entire house as an exclusion volume doesn't make much sense. Perhaps what you want to do in this case is set the house to Static Obstacle? That will prevent it from being included in the navmesh but will allow it to behave normally in the physics system. 3) Yes, LI 1 exclusion/material volumes would be nice. It was an idea we discussed internally but determined that it had too many implications. To ensure that the low land impact was only applied to objects that were being used exclusively as exclusion/material volumes (rather than allowing a new exploit for getting any linkset down to 1 LI) and that that land impact accurately reflected resources consumed on the server, we would have had to make EVs/MVs into a new kind of "first class object" (like Linden Trees, Prims, etc.). This, in turn, would have introduced significant UI work and under-the-hood complexity. Hope that helps, Falcon

BlackMagi Darkwatch wrote: So now a question about the exclusion volume (EV). Do they need to be bigger than the original prims in the build or can they be the same size? Do av's interact with the EV in other words making the EV 100% transparent, will av's bump into it or by setting the pathfinding properties to EV will they then become phantom and then there will be no interaction with av's or does this need to be done manually? Black An EV is phantom and therefore won't interact with avatars. The EV must encompass all areas of the navmesh that you wish to be removed (have a look at the View/Test... preview to see the navmesh, but remember that if an EV was already placed when the navmesh was last baked, no navmesh will appear inside the EV). So the basic workflow would be: 1) Make appropriate objects into walkables and, where possible, static obstacles 2) View the navmesh 3) Add EVs that encompass any unnecessary areas of the navmesh or any areas that look "weird" or generate bad paths (test that with the View/Test... floater) 4) Rebake the navmesh and preview again to verify your changes Falcon

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. Falcon

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 to 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). Falcon

Ayesha Askham wrote: Innula I'm going to take the second point first: "it can't be to do with pathfinding?" Well, perhaps to a degree it isn't, but the basic error in traffic calculation was certainly introduced to server code around the time Pathfinding infected the Grid, and it certainly first surfaced as an issue on Magnum RC. Guilt by association? There is another aspect though, and this is more insidious: I suspect that as Pathfinding and Havok 7 was rolled to the Grid some aspects of sim operation were changed, maybe "reverted" in Lindenspeak. It now seems that bots are being counted as genuine avatar visitors again. That is definitely an aspect that is NOT "working as expected"...unless...I recall that back when Rod announced the advent of Pathfinding that "empty spaces" are not inviting. So maybe there is an algorithm that is intended to count NPCs as vistors to give ranking in search to Pathfinding sims and this code also allows bots to be counted in seach ranking? The sounds a tad Macchiavellian, but it's the best explanation I have for what is a very real issue, yet we are told all is "working as expected" As regards the bandwidth issue I am a bit out of my depth here. However this may be a consequence of sims that have little or no "spare time". The connection has held on all the sims that I have seen this issue. I had noticed in times past that these sims had very little on no spare time, so Havok 7 physics may well be causing this. Note I am not blaming Linden Lab for this, it is a consequence of the change that we were warned might occur. I am old enough to recall the manifold issues that accompanied the introduction of Havok 4 to the Grid some years ago. We are investigating the dwell time issue but I can say with confidence that it was not directly related to pathfinding (although it may have been introduced as a merge error/regression). We definitely are not trying to include NPCs in these calculations! The pathfinding team did not intentionally touch any code that relates to dwell time calculations. By the way, pathfinding actually uses Havok 2012.1. The previous servers used Havok 2010.2. Havok 7 has not been on the grid in over a year (possibly more). Falcon

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). Falcon

Hey Alisha, Just wanted to clarify two minor points: (1) llFleeFrom actually just tries to get a specified distance away from a provided point. It's llEvade that tries to dynamically run and hide from another character/object/avatar (2) Havok AI does form the underlying basis of pathfinding, but the behaviors are provided by our own code layer. This is important because it means that, going forward, we'll be able to improve them and add new ones as time permits and users request. Glad you're enjoying it! Falcon

Hi Josey, The poor performance you've seen is almost certainly due to the fact that the sims are, as Vincent said, running debug code which can easily spend 50ms each frame validating data, cutting frame rate at least in half. In testing, we have measured characters taking approximately 30-50us (microseconds) on average, less than one third of the time slice allocated to each script in the region each frame. The only thing we've seen cause significant performance issues is when half a dozen or more characters pile up on each other. The upcoming viewer tools will allow you to see how expensive each character on a region is and take action accordingly. Falcon

Pathfinding is in no way limited to estates or even to land owners. If you rent a parcel, you can use pathfinding to let your pet navigate your home. Or bring your pathfinding creations to a public region. Falcon Linden

I'm glad that worked. I'll add a comment about the delta times to the wiki. Falcon

Hey folks, I have a hunch that the cause of the drift is related to the simulator's fixed time step and the fact that llSetKeyframedMotion is implemented in terms of frames and not real time. This decision was made in order to produce more deterministic results. Before giving up on this method of animation, can you try changing your delta times to be integer multiples of 1/45s? Let me know if this resolves the issue. If not, please file a jira. Falcon