Jump to content

Lorca Linden

Retired Linden
  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Lorca Linden

  • Rank
  1. We’d like to thank those of you who participated in the pathfinding beta and those who have started building pathfinding enabled objects and characters since the grid-wide release of the pathfinding server code.  We’ve been collecting questions and address many of them here. Feedback continues to be much appreciated! Q: Will pathfinding cause massive lag on my region/parcel? A: No. For much of the pathfinding beta, this was a valid concern for mainland regions and any region where Second Life users did not update the pathfinding properties of their linksets to make them “static” (sometimes called “permanent,” meaning that the linkset use had been set to “walkable,” “static obstacle,” “exclusion volume,” or “material phantom.”) Updating your linksets may still improve performance and is required to get optimal behavior from pathfinding enabled creatures on your region, but the worst-case performance has now been capped in such a way that most regions will not notice a performance difference after enabling pathfinding. In a full region, no more than 4ms/frame (on average) will be spent updating the navmesh to account for “movable obstacles” (the default for existing prims) each frame. On homesteads, this is capped at 1ms/frame. Reduced performance should only be noticeable on regions where (a) performance was already poor (i.e., spare time was less than 4ms for a full region or 1ms for a homestead), and (b) linksets have not been marked static. Q: Will updating a build to use pathfinding be time consuming? A: In most cases, it should be relatively straightforward to retrofit an existing build to work with pathfinding. We designed the new pathfinding “Linksets” floater to allow you to select batches of objects and update their pathfinding properties at once. We have also provided a new simulator console command (the simulator console can be accessed with ctrl+shift+` -- note that it’s a “backtick,” which is found to the left of the ‘1’ key on US keyboards), which will allow residents to set all linksets (or just those that are unscripted) on their parcel (or on a group-owned parcel) to either walkable or static obstacle. For estate managers, this can be used to modify all linksets on the region. You do not need to have mod rights to a linkset to update its pathfinding properties. They can be changed by anyone with (a) ownership of the object, (b) mod rights to the object, or (c) ownership of the parcel or region on which the object is present. (Note that to apply changes to unowned objects for which you do not have mod rights, but which are present on your parcel, you must use the console command and not the linksets floater.)  See more details about the pathfinding bulk update tool here.   Q: When will the pathfinding tools be released in the SL Viewer and where can I get a beta version of the viewer tools? A: We expect to have the pathfinding tools integrated into the main viewer by the end of September!  In the meantime,  you can get access to the tools - which are very helpful to anyone looking to build or retrofit pathfinding friendly environments - by downloading the latest beta viewer here.   Q: Will I be able to move my objects around once I’ve marked them as static? A: If you move or alter a linkset which has been marked as static, the navmesh will be marked as “dirty” and you will be presented with a button to “rebake” it that updates it to account for your changes. Two limitations will remain: (1) you cannot modify a static linkset unless you are in the same region as its root prim, and (2) scripts in static objects will not be permitted to modify the object in a way which would dirty the navmesh (e.g., linking/delinking prims, changing the shape or transform of any prim which is not set to physics shape type “none.”) If you’re wondering how to make your house’s doors work with pathfinding, see the question below. Q: How can I enable pathfinding on my house which has scripted doors? A: Because of the rule that scripts on a walkable object (such as a house) are prohibited from modifying the linkset in a way which would invalidate the navmesh (e.g., by changing its physics shape to open a door), it will be necessary to build houses and similar linksets a bit differently. Instead of having the door as part of the linkset scripted to open/close, the linkset will instead have to “rez out” the door from its inventory as a separate object. The door can then be scripted to swing/slide open or close using llSetKeyframedMotion. This will allow pathfinding objects to respond correctly to the door while avoiding the expensive process of fully recomputing the navmesh. In the near future, we plan to make examples of this type of build available along with a guide about how to easily retrofit an existing house to work with pathfinding.   Q: Why does terrain editing behave differently now than before? A: For performance reasons, we no longer represent the terrain as a heightfield (like a topographic map,http://en.wikipedia.org/wiki/Topographic_map) for collisions on the server. Instead, we use a “welded mesh.” Collisions are much more efficient for most terrain, but updating the mesh is much slower. To account for this, there’s now a built-in delay of about 30 seconds after you stop editing the terrain before we begin to rebuild the mesh (which can take up to a minute or two). Until the mesh has been updated, objects and avatars will not collide with it properly and you may notice artifacts like avatars bouncing up and down when walking on the edited areas of the terrain. Q: What are those percentages listed in the linkset floater? (Note that the majority of users will never need to worry about this advanced feature) A: Those numbers are the walkability coefficients of the linkset for each character type. This is perhaps the most advanced, complex, and non-intuitive feature of pathfinding. Let’s say you have a build that involves animals and human NPCs. The build consists of a network of roads and some grassland. For the most part, you’d like to keep the animals on the grass and the humans on the roads. But if a human NPC is trying to get from point A to point B and taking the road would take 100x longer (because it’s a winding road, let’s say) than just cutting across the grass, you’d like them to take the direct path across the grass. This is exactly what walkability coefficients and character types are meant to address. To do this, you’d script your human NPCs to use CHARACTER_TYPE_A and your animals to use CHARACTER_TYPE_B. Then you would open up the linksets floater and set the walkability coefficients for the terrain to “A=1%, B=100%” meaning that pathfinding characters using CHARACTER_TYPE_A will move 100x slower on the terrain (and prefer paths that avoid the terrain unless the path is much longer), but that creatures using CHARACTER_TYPE_B will move at full speed on the terrain. Then you would select all your roads in the linksets floater and set them to “A=100%, B=0%” meaning that characters using CHARACTER_TYPE_A will move at full speed on the roads but creatures using CHARACTER_TYPE_B will avoid the roads at all costs. Note that to handle certain inconsistencies, if a pathfinding character finds itself in an area with zero walkability for its CHARACTER_TYPE, it will move at full speed in order to be able to escape. This can happen if, for example, the character is pushed into the area by collisions or is forced into the area due to its movement properties (like turn radius). Q: As a content creator, what character type should I make my pet (or butler or AI car)? A: To promote interoperability between linksets and characters, we suggest the following for characters which will be sold for general use. Humans/Humanoid NPCs/Pets: CHARACTER_TYPE_A Wild Animals/Off-Road Vehicles: CHARACTER_TYPE_B Road-Going Vehicles: CHARACTER_TYPE_C Other: CHARACTER_TYPE_D Remember that the key feature is not what the character is but rather on which surfaces you want it to prefer to travel -- and how quickly it can do so. For example, while a rideable horse might be a pet, it’s probably better to treat it as a wild animal/off-road vehicle so that it doesn’t try to walk into your customers’ houses. Similarly, if you are selling prefab road pieces, you will probably want to set those to have high walkability coefficients for types A and C, and a low coefficient for type B. Q: What can I do with the View/Test floater if I’m not using pathfinding? A: The views available via the View/Test floater are not just useful for pathfinding. When you view walkables, static obstacles, material volumes, and exclusion volumes (but not “movable objects”), you’re getting a peek into the physics engine. This is currently the only method available in the Second Life Viewer by which Second Life users can see the real physics representations of their objects, which can be a useful tool for optimizing the physics of your region. For instance, if you’re wondering how the simulator “sees” the vehicle or the weird sculpty lawn ornament you’re building, try temporarily making that linkset part of the navmesh, re-baking, and viewing it. We hope to turn this into more of a feature in the future. In the meantime, there is one caveat to be aware of: the pathfinding visualization does not account for an object’s convex radius, which is an extra bit of collision tolerance used internally. On account of this, certain linksets may appear to be a bit smaller in the viewer than they are in the engine.  We have also added a handy feature within the pathfinding tools that will let you teleport directly to objects for which you have edit rights.
  • Create New...