Pathfinding in Second Life, or how did it ever get this bad? Second Life, which is halfway between a game and a game engine, supports a pathfinding system. It combines a reasonably good path planner with a terrible path follower. I've been bugging Linden Lab about this for a while. The bugs are not fixed yet. So I made a video. This is Second Life pathfinding under overload conditions in a hard situation. The video is to demonstrate to Second Life developers what needs be fixed. In open ground, not under overload, pathfinding performs much better. But it's never been reliable enough for wide use. The NPC won't reach its goal. This is why there are few moving NPCs in Second Life. So I've been trying to work around the bugs and make better NPCs. I wrapped recovery code around the pathfinding operations, to restart them when they give up or just stop working, do a bit of random motion when they get stuck, and take recovery action if they get out of bounds. The built in pathfinding system is supposed to handle that. It doesn't. Pathfinding in Second Life has a reasonably good planner, and you can see its waypoints with a dev tool. That part is not bad, except that it clips corners and causes unnecessary collisions. It also sometimes generates near-coincident waypoints, which confuses the path follower.Then there's the execution of the path. That works through the physics engine. For physics purposes, the NPC is a capsule, always upright. The path follower gives it a velocity vector and starts it on its way. Collisions, including collisions with ground surfaces, can get it off course. The NPC continues to move in the direction indicated until the pathfinding system does another cycle and provides a new movement vector. Under overload, there's lots of overshoot, of course. That's the cause of most of the trouble. We can slow down the movement under overload, which helps. (As a user, I don't have access to the simulator code, or I'd try to do something about this. The client is open source C++, and I've put fixes into that. Not fun. Little internal documentation, few comments, and not enough separation of policy and machinery. I'm told that the simulator code is equally bad. Second Life remains the main big, shared, persistent, user modifiable world that works, and I like the options that offers. The Spatial OS people have made a lot of claims that they can do all this better, and spent an insane amount of money on it, but so far, nothing has shipped that demonstrates that. Nostos just slipped to October 2019.) https://ift.tt/eA8V8J

Second Life, which is halfway between a game and a game engine, supports a pathfinding system. It combines a reasonably good path planner with a terrible path follower. I've been bugging Linden Lab about this for a while. The bugs are not fixed yet. So I made a video. This is Second Life pathfinding under overload conditions in a hard situation. The video is to demonstrate to Second Life developers what needs be fixed. In open ground, not under overload, pathfinding performs much better. But it's never been reliable enough for wide use. The NPC won't reach its goal. This is why there are few moving NPCs in Second Life. So I've been trying to work around the bugs and make better NPCs. I wrapped recovery code around the pathfinding operations, to restart them when they give up or just stop working, do a bit of random motion when they get stuck, and take recovery action if they get out of bounds. The built in pathfinding system is supposed to handle that. It doesn't. Pathfinding in Second Life has a reasonably good planner, and you can see its waypoints with a dev tool. That part is not bad, except that it clips corners and causes unnecessary collisions. It also sometimes generates near-coincident waypoints, which confuses the path follower.Then there's the execution of the path. That works through the physics engine. For physics purposes, the NPC is a capsule, always upright. The path follower gives it a velocity vector and starts it on its way. Collisions, including collisions with ground surfaces, can get it off course. The NPC continues to move in the direction indicated until the pathfinding system does another cycle and provides a new movement vector. Under overload, there's lots of overshoot, of course. That's the cause of most of the trouble. We can slow down the movement under overload, which helps. (As a user, I don't have access to the simulator code, or I'd try to do something about this. The client is open source C++, and I've put fixes into that. Not fun. Little internal documentation, few comments, and not enough separation of policy and machinery. I'm told that the simulator code is equally bad. Second Life remains the main big, shared, persistent, user modifiable world that works, and I like the options that offers. The Spatial OS people have made a lot of claims that they can do all this better, and spent an insane amount of money on it, but so far, nothing has shipped that demonstrates that. Nostos just slipped to October 2019.)

from GameDev.net http://bit.ly/2JMQjnf