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

Hey folks, I just want to clear something up right away: this will work great for many of the examples described in posts above, but it works on root prims only. It is not a full animation system by any means. See the llSetKeyframedAnimation talk page on the wiki for more info. I am considering changing the name to llSetKeyframedMotion to reduce confusion. Have fun! Falcon

Void is correct: there is no limit on PE when using this function, the limit is only on physics weight. Why did I tie this to using the PE system at all? No, it was not due to any new LL policy seeking to push all new content into the PE system (there is no such policy to my knowledge). It was simply to limit strain on the physics engine induced by allowing more complex objects to move around the world. Why 64? Honestly, I just picked a number that seemed reasonable. It's more generous than the limit of 32 imposed on making an object physical and the only real way to build a physics shape with a PW >64 is either by using concave prims (eg a torus) which are VERY hard on the physics engine or by just being lazy/sloppy and not using Shape Type None on detail prims. If anyone can show me a quality, efficient build that is limited by this requirement, I will seriously consider altering it. Falcon

Hey Arton/Drongle, That is not correct. There is no minimum PE per prim in a linkset. This is because not all prims will affect all weights (e.g., no physics prims will not affect physics weight) and because only the highest of the three weights is used to determine the PE. I took your boat in world and replaced the 4 convex hulls in the tower with 4 boxes. If you go to Develop | Show Info | Show Render Info, you will get a text overlay on the bottom right of your screen. Near the bottom of the overlay is the streaming or network cost for the linkset. Call that 'NW'. Let's call your boat A and my boat with 4 boxes B. Boat A, Non-Physical: PW = 14.4, NW = 84.5 --> PE = 84 ( NW is probably more like 84.499 and getting rounded to 84 on the server but 84.5 on the viewer) Boat A, Physical: PW = 84.0, NW = 84.5 --> PE = 84 (same as above) Boat B, Non-Physical: PW = 13.3, NW = 84.7 --> PE = 85 Boat B, Physical: PW = 77.8, NW = 84.7 --> PE = 85 In other words, whether you add the boxes or not, you're streaming cost bound, not physics or server cost bound. Adding the 4 boxes added a total of ~0.2 to the streaming cost which, in your case, just bumped up the PE by 1. Adding another 4 boxes (just as a test) only increases your NW to 85.2, which still leaves your final PE at 85. Of course, in this specific case, the only incentive for switching to boxes is slightly improved physics performance. For vehicles, though, this can still really matter at the end of the day. Falcon

For linksets including at least one mesh or at least one prim with physics shape type convex or none, only the physics weight must remain below 32. Once the vehicle is made physical, its physics weight will go up, but that will not prevent it from remaining physical. Falcon

Hey Arton, I haven't had a chance to look at the .dae files you sent yet, but I did have a look at the boat in world. The most important thing I noticed is that there are a number of pieces for which you are using a convex decomposition when you could simply replace them with boxes for 1/4 the cost (0.1 vs 0.4 prims) with little to no loss of fidelity. I'm not sure what effect this would have on server weight, though, as the the total number of prims would be higher. Also, although you can only sit on one part of the tower, you have physics bits for each level. You might consider removing some of these extra parts (i.e., setting them to no physics). I hope that helps. I'll try to look at the .dae files when I can. Falcon

Thanks Arton, I've received the boat and will check it out when I'm next in the office (Tuesday). Could you also send me the .dae file (via jira or direct e-mail)? It's worth pointing out, btw, that your total PE only went up by 7 prims as a result of making the boat physical. That does not seem bad to me. I'm also looking into putting together a more detailed explanation of the reasoning behind the current physics weight calculations. I hope it will help everyone understand the tradeoffs involved and my motivations in developing the formulae. I truly believe that most reasonable builds should not be limited by their physics weight. In general, I expect the other PE factors to almost always exceed physics weight for well-optimized, legitimate objects (i.e., "useful objects" rather than pathological cases). Falcon

Arton, can you please give me a copy of the boat? (And, if possible, the .dae that it was uploaded with--you can make a jira and include that privately, I believe). I'd like to see if it could use further optimization as well as see how its impact on the server compares to its cost. The decision to add a penalty for dynamic objects based on scale came from testing which showed how easily a number of large, dynamic objects could bring a sim to its knees. However, the cost that we've associated with that penalty (4%/m^2) was deliberately chosen to be at least a little too high. That's because we need to see how meshes are used on Agni and what their impact is before we can settle on the exact values. Since we know we can't ever increase the costs for existing content, we wanted to start high and potentially lower it in the future. Falcon

Hey folks, I'm a bit late to this thread, but I thought I'd chime in. Drongle is 100% correct. The physics shape is the convex hull of a torus. The viewer's physics shape display feature does not work in all cases. The server does not send down the real physics shape, so the viewer tries to follow the same logic as the server to derive the shape. This doesn't work in all cases and can easily get out of sync with the server. I'm not sure it was ever fully implemented for sculpts. Feel free to submit a feature request. Falcon

I can't repro this problem and have commented on CTS-682. However, I just wanted to throw in a tip here: The best way to represent a sphere in the physics engine is to actually use a sphere prim. I'd recommend using a physics mesh without the sphere part, doing a decomposition, uploading, and then linked to a 100% transparent sphere to get the physics right.

Hi folks! I know, it's been forever since I've come to office hours and some of you may think I'm dead. I'm not! I'm hard at work making your meshes work without causing problems for our physics engine (among other things). I can't give you the answer you want--a release date for mesh. But I can help a little by letting you know that there are concrete dev issues remaining. For example, you may notice that in some cases when you enter a mesh region, particularly one that's been restarted recently, you can't move about as you would expect. In fact, the collision geometry for many meshes is a giant box with dimensions equal to the mesh's scale! Craziness. Huseby Linden and I have recently solved this problem but the solution is far more complex than you'd think and it will be at least a couple weeks before we can deploy it to Aditi. Other remaining issues on my plate include physics cost computation and proper upload validation. It's great to hear that you aren't hitting many mesh upload bugs. Rest assured that we are continuing to actively develop mesh as a feature and that we are probably even more eager than you to see it deployed to the Main Grid. Cheers, Falcon