Skip to content
GitLab
    • GitLab: the DevOps platform
    • Explore GitLab
    • Install GitLab
    • How GitLab compares
    • Get started
    • GitLab docs
    • GitLab Learn
  • Pricing
  • Talk to an expert
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    • Switch to GitLab Next
    Projects Groups Topics Snippets
  • Register
  • Sign in
  • openmw openmw
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
    • Locked files
  • Issues 832
    • Issues 832
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 32
    • Merge requests 32
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test cases
  • Deployments
    • Deployments
    • Releases
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • OpenMWOpenMW
  • openmwopenmw
  • Issues
  • #4894
Closed
Open
Issue created Mar 03, 2019 by elsid@elsidDeveloper

Consider actors as obstacles for pathfinding

This should resolve problem when actors hit each other trying to go to their destination.

There was a try to resolve it using DetourCrowd (a part of recastnavigation library) in the pr introduced recastnavigation based pathfinding system. Solution quality wasn't quite enought to merge it into master. Code is still there. DetourCrowd allow to handle multiple actors simulaniously and their paths. It handles their movement to avoid collisions. Current system is not. Each actor consider world as there is no other actors, only static objects.

Most significant problem of DetourCrowd is it is handle all movement physics internally. It is not simply compatible with OpenMW. Resolving this issue should be helpful. First solution had problem like this:

the guard npc will kind of walk around trying to get to the exact spot they need to talk to you, but it takes them several attempts to do so

This is actor's movement synchronization problem. dtCrowd works like MWPhysics::PhysicsSystem. You call update (stepSimulation) method with dt. And it calculates and set what actor's position will be in current_time + dt. I can't directy set use this values to set new actor position. It could break game physics. So I use it as next target. There is also a speed of actor to simulate acceleration. But OpenMW doesn't allow to apply factor to actor's speed. Maybe movements for distance less than actor's speed shouldn't be applied. I need to figure out how to fix this.

Another problem is DetourCrowd has fixed limit of actors. It couldn't be changed after initialization. OpenMW potentially can have infinite number of actors in a single scene. There is no limit for that. Possible solutions are:

  1. Limit number of actors in a scene in OpenMW. There is always should be some limit. Maybe it's memory capacity. I don't now if there any specific number in OpenMW. This is more preferable option to be consistent and avoid out of memory errors.
  2. Use fallback to logic without dtCrowd when there is too much actors. Will hide the problem, could lead to worse player's experience.
  3. Reinit dtCrowd to increase number of agents. Could lead to performance problems (need to test). Of course there still be memory capacity limit.

DetourCrowd should be used for each navmesh separately. Current system builds different navmeshes for actors with different half extens for interior cells. There shouldn't be more than one navmesh in a game or each actor should be present in each dtCrowd to be visible for other.

One more potential problem:

Currently actor pathfinding is extremely strange and they go in circles, to the opposite directions from the target and in weird trajectories way too often.

DetourCrowd doesn't handle actor direction. I've noticed this behavior, but didn't consider this as a bug, More changes in AiPackage::pathTo logic are required to fix this, especially for turns.

Edited Mar 03, 2019 by elsid
Assignee
Assign to
Time tracking