The KD-tree implementation for spatial queries ends up breaking obstacles into sub-obstacles. I.e., a single segment can be decomposed into a set of disjoint subsets spanning the same wall. Some algorithms can detect these co-linear and coincident segments and handle it. Some cannot.
Force-based models create a repulsive force for each obstacle. That means, a single wall, depending on how it is dissected, could end up introducing multiple forces (giving an overall greater repulsive force for that wall.)
If an underlying algorithm decomposes the specified obstacles into sub-obstacles, this should be hidden from the pedestrian algorithms.
To that end, modify the KD-tree so that the obstacles it uses have knowledge about the "original" obstacle from whence it arose. When performing spatial queries, don't return the kd-tree obstacle, return the parent obstacle. In this case, it is possible that the same obstacle can be returned multiple times; it should be accounted for in building the neighbor set.
The KD-tree implementation for spatial queries ends up breaking obstacles into sub-obstacles. I.e., a single segment can be decomposed into a set of disjoint subsets spanning the same wall. Some algorithms can detect these co-linear and coincident segments and handle it. Some cannot.
Force-based models create a repulsive force for each obstacle. That means, a single wall, depending on how it is dissected, could end up introducing multiple forces (giving an overall greater repulsive force for that wall.)
If an underlying algorithm decomposes the specified obstacles into sub-obstacles, this should be hidden from the pedestrian algorithms.
To that end, modify the KD-tree so that the obstacles it uses have knowledge about the "original" obstacle from whence it arose. When performing spatial queries, don't return the kd-tree obstacle, return the parent obstacle. In this case, it is possible that the same obstacle can be returned multiple times; it should be accounted for in building the neighbor set.