Pathfinding in Second Life, or how did it ever get this bad?

Started by
3 comments, last by Nagle 4 years, 11 months ago

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

Advertisement
14 hours ago, Nagle said:

Linden Lab

Well there's your problem :D

.:vinterberg:.

Did you have any specific question, or objective in posting here?  Are you just looking for general comments on your approach?  Guesses as to the problems with the provided method?

- Jason Astle-Adams

7 hours ago, jbadams said:

Did you have any specific question, or objective in posting here?  Are you just looking for general comments on your approach?  Guesses as to the problems with the provided method?

I've been working on workarounds. Users can script Second Life, so it's possible to sort of work around bugs. But no, there's not much that can be done user side. They have a huge legacy code problem after 15 years.

I'm waiting for a next generation big virtual world in which I can build. High Fidelity just went bust. (They're "pivoting to enterprise applications." Right.) Sinespace is cute but going nowhere. Sominium Space never got any users. Sansar is at 11 users on Steam.  Nostos just slipped to October 2019. Nothing yet. I was expecting more from the Spatial OS crowd.

This topic is closed to new replies.

Advertisement