I made a little test the other day to see what is actually the difference between sharp (geometric) and smooth (sampling) velocity obstacle. The first segment shows hard boundary and the second shows soft boundary.
The code in both cases are the same, but in the first case, the time of collision is threshold to imitate geometric solution to velocity obstacles. If time to collision is < 1.5 seconds, then full collision penalty is applied to the sample, else no collision penalty is added.
In the second case, the collision penalty is inversely proportional to time of collision, making the velocity obstacle to appear softer. Even in cases where the geometric method would totally block the movement, the smooth boundary allows to find the best movement direction.
There are some twitching and bugs in the first segment when the velocity obstacle completely covers the sampling area.
On another note, Phil's comment on the one of my previous posts put me thinking. I think he's right. Obstacle avoidance alone will not create believable locomotion. There are a lot of nuances which can be only captured in the simulation if you simulate the perception, social forces, etc.
Instead of turning this project into a behavior simulation project, I will narrow my focus even more. It is such a monster research field already. I don't think an individual can successfully research and get something done in the human/crowd behavior simulation stuff in reasonable time.
Multi-agent obstacle avoidance is one of the sub-problems, and I'm going to focus on just that. I can later build some behavior stuff on top of this research if I choose so. Actually acknowledging that there is some higher logic above the obstacle avoidance, allows me to leave some things unsolved and expose them as parameters of the model.
For example if the agent always chooses the fastest possible speed, the result is rush or panic like behavior. If you always choose the nearest speed towards your target, the agent appears shy, or stubborn.
Even if I felt a bit despaired the week following Phil's post, I think it has really helped me to define the problem I'm trying to solve more clearly. Sometimes, it is actually harder to find the problem than to solve it.