I was looking around reading here and there (mostly gamedev.net though lol), and been watching a few demos. One of the more impressives was Opensteer.
Question Nr1.: It was nice to see how well it could navigate on it's own. Actually, did anyone try implementing Opensteer and a physics library together? Does that still work that way? I'd think that a physic lib affects the movement of moving objects a lot, and that could kick in to a pathfinding library which might be counting without taking physics into account. (I could be wrong though.)
Question Nr2.: there were some "weird" things happening in the Opensteer demos, like in the CTF where the flag carrier simply walked through obsticles at some points. If anyone uses Opensteer with OGRE, does such behaviour often appear in 3D? (Trying to go through obsticles I mean.)
Any other experiences regarding some pathfinding libraries+OGRE are also welcomed though.
Opensteer pathfinding AI in OGRE, some experience anyone?
-
- Greenskin
- Posts: 145
- Joined: Wed Apr 28, 2004 12:10 pm
- Location: Hungary
- Contact:
Opensteer pathfinding AI in OGRE, some experience anyone?
Hope is the first step on the road to disappointment.
- alphageek
- Gnome
- Posts: 365
- Joined: Mon Jan 03, 2005 11:56 am
I used to use OpenSteer in my Ogre + ODE application.
However, I replaced it because the design of OpenSteer was conflicting with some of my stuff.
IIRC, OpenSteer vehicles come up to speed instantly and also always travel in the direction they are looking (so a direction change means an instantaneous velocity change as well). As you point out, things like this could create some issues in a physical simulation.
In my experience, however, there was no problem. I allowed OS to calculate the desired velocity of the vehicle and then I calculated how much force would need to be applied to get to that desired velocity.
Sometimes the velocity change was greater than a vehicle could apply, so there was some continuing error. However, that error is still there and can be corrected the next physics tick.
When I excised OpenSteer from my project, it took me only a day or two to reimplement the parts of OpenSteer that I was using. In some cases, such as path following behaviour, my approach was better.
That said, OpenSteer has some cool demos and is definitely worth a read through to learn about ways to approach steering problems.
NB. strictly, OpenSteer doesn't do pathfinding, it does steering. Pathfinding generally refers to calculating a movement path while negotiating obstacles etc.
HTH
However, I replaced it because the design of OpenSteer was conflicting with some of my stuff.
IIRC, OpenSteer vehicles come up to speed instantly and also always travel in the direction they are looking (so a direction change means an instantaneous velocity change as well). As you point out, things like this could create some issues in a physical simulation.
In my experience, however, there was no problem. I allowed OS to calculate the desired velocity of the vehicle and then I calculated how much force would need to be applied to get to that desired velocity.
Sometimes the velocity change was greater than a vehicle could apply, so there was some continuing error. However, that error is still there and can be corrected the next physics tick.
When I excised OpenSteer from my project, it took me only a day or two to reimplement the parts of OpenSteer that I was using. In some cases, such as path following behaviour, my approach was better.
That said, OpenSteer has some cool demos and is definitely worth a read through to learn about ways to approach steering problems.
NB. strictly, OpenSteer doesn't do pathfinding, it does steering. Pathfinding generally refers to calculating a movement path while negotiating obstacles etc.
HTH
- Robomaniac
- Hobgoblin
- Posts: 508
- Joined: Tue Feb 03, 2004 6:39 am
-
- Greenskin
- Posts: 145
- Joined: Wed Apr 28, 2004 12:10 pm
- Location: Hungary
- Contact:
- PeterNewman
- Greenskin
- Posts: 128
- Joined: Mon Jun 21, 2004 2:34 am
- Location: Victoria, Australia
- Contact: