Difference between revisions of "Pathfinding Overview"
Jump to navigation
Jump to search
| (One intermediate revision by the same user not shown) | |||
| Line 14: | Line 14: | ||
*[[llExecCharacterCmd|Actions]] - Make the character jump or stop the current pathfinding behavior | *[[llExecCharacterCmd|Actions]] - Make the character jump or stop the current pathfinding behavior | ||
*[[llUpdateCharacter|Update]] - Modify the pathfinding attributes of the character | *[[llUpdateCharacter|Update]] - Modify the pathfinding attributes of the character | ||
*[[llGetStaticPath|Get a Path]] - Request a path for an object other than a pathfinding character | |||
==Best Practices== | |||
*Try to limit walkable surfaces to those that characters should really walk, instead setting things like lamp poles, fences, statues, and trees to “static obstacle”. This will produce optimal pathfinding performance and results. Since walkability is a property of whole linksets and not individual prims, you can use exclusion volumes (similar to material phantoms described above) to enclose parts of a linkset that should not be traversed by any kind of character. | |||
*Limit the number of “movable obstacles”. While we have limited the negative performance impact of these objects, the tradeoff is reduced pathfinding responsiveness. If you have too many movable obstacles, we may not update the navmesh to account for them each frame, meaning that characters could collide with, e.g., a vehicle that uses llSetPos() to move around. | |||
*When making characters, you may wish to provide fallback navigation mechanisms. For example, if you get a behavior failure indicating that you are off the navmesh, you could use llGetClosestNavPoint() to find out where the nearest navigable area is and then try llNavigateTo() with DIRECT_PATH=TRUE to get there. If that fails, you could llSetPos() to that location. If the region wasn’t set up for pathfinding at all and llGetClosestNavPoint() returns an empty list, you could fall back on existing methods to navigate (e.g., by detecting obstacles with llCastRay() and moving with llSetKeyframedMotion()). | |||
---- | ---- | ||
Return to [[Good_Building_Practices]] | Return to [[Good_Building_Practices]] | ||
Latest revision as of 18:04, 27 August 2012
Pathfinding is a method content creators can use to create moving and interactive characters within Second Life. Characters can use LSL functions to avoid obstacles, move around corners, climb inclines, and move across region boundaries: things that are very difficult or even impossible before. Pathfinding will also enable new gameplay mechanics, such as creating food that attracts monsters.
Terminology
- Character - an object that uses a Pathfinding LSL function.
- NavMesh - Short for Navigation Mesh. It's a map for characters.
Functions
- Evade - Run (and or hide) from a specified avatar or object.
- Flee - Move a specified distance from a specified location.
- Navigate - Move to a specified location.
- Patrol - Move along a specified path specified by patrol points.
- Pursue - Follow specified avatar or object.
- Wander - Randomly wander a specified distance from a specified central point.
- Actions - Make the character jump or stop the current pathfinding behavior
- Update - Modify the pathfinding attributes of the character
- Get a Path - Request a path for an object other than a pathfinding character
Best Practices
- Try to limit walkable surfaces to those that characters should really walk, instead setting things like lamp poles, fences, statues, and trees to “static obstacle”. This will produce optimal pathfinding performance and results. Since walkability is a property of whole linksets and not individual prims, you can use exclusion volumes (similar to material phantoms described above) to enclose parts of a linkset that should not be traversed by any kind of character.
- Limit the number of “movable obstacles”. While we have limited the negative performance impact of these objects, the tradeoff is reduced pathfinding responsiveness. If you have too many movable obstacles, we may not update the navmesh to account for them each frame, meaning that characters could collide with, e.g., a vehicle that uses llSetPos() to move around.
- When making characters, you may wish to provide fallback navigation mechanisms. For example, if you get a behavior failure indicating that you are off the navmesh, you could use llGetClosestNavPoint() to find out where the nearest navigable area is and then try llNavigateTo() with DIRECT_PATH=TRUE to get there. If that fails, you could llSetPos() to that location. If the region wasn’t set up for pathfinding at all and llGetClosestNavPoint() returns an empty list, you could fall back on existing methods to navigate (e.g., by detecting obstacles with llCastRay() and moving with llSetKeyframedMotion()).
Return to Good_Building_Practices