Closed GoogleCodeExporter closed 8 years ago
Original comment by silveira.nestor@gmail.com
on 18 Feb 2010 at 10:22
Hmm, I would prefer to stay away from a boost dependency, simply because boost
is
such a massive library. Since it's mostly header only, if parts can be
extracted and
used from the Dependency directory it may be doable.
Best to see what Erwin's thoughts are.
Original comment by snailr...@gmail.com
on 18 Feb 2010 at 11:34
Please no BOOST or other bloated libraries.
We have some threading abstraction in Bullet, and I supposed Ogre might also
have such
feature (or does Ogre use BOOST for that?).
In Bullet I also stay away from STL for cross-platform compatibility, but I
suppose
that isn't a big concern for GameKit.
Original comment by erwin.coumans
on 19 Feb 2010 at 1:48
Original comment by silveira.nestor@gmail.com
on 19 Feb 2010 at 8:49
Pity! I wanted to implement some AI support for the logic nodes. But is too
much work
without boost support...
Are you planning to implement some kind of AI support inside OgreKit? (I mean
A*
pathfinder algorithm)
Original comment by silveira.nestor@gmail.com
on 19 Feb 2010 at 10:56
AI support would be great, it's been on my todo list for some time now.
I would like to have AI not limited to nodes exclusively, but as a subsystem
like
bricks & nodes.
What kind of structures & algorithms are you using from BOOST, in order to
accomplish
A* ? Maybe with a little extra work, we can create internal algorithms to
accomplish
this ?
Original comment by snailr...@gmail.com
on 19 Feb 2010 at 2:55
We could check out this one:
http://code.google.com/p/recastnavigation
What features of boost do you need to implement AI efficiently?
Original comment by erwin.coumans
on 19 Feb 2010 at 3:49
Here are the headers that I am using from boost:
#include <boost/statechart/state_machine.hpp>
#include <boost/statechart/simple_state.hpp>
#include <boost/statechart/state.hpp>
#include <boost/statechart/transition.hpp>
#include <boost/statechart/custom_reaction.hpp>
#include <boost/statechart/asynchronous_state_machine.hpp>
#include <boost/statechart/fifo_worker.hpp>
#include <boost/intrusive_ptr.hpp>
#include <boost/lambda/lambda.hpp>
#include <boost/lambda/bind.hpp>
#include <boost/lambda/if.hpp>
#include <boost/lambda/loops.hpp>
#include <boost/lambda/switch.hpp>
#include <boost/lambda/construct.hpp>
#include <boost/lambda/casts.hpp>
#include <boost/lambda/exceptions.hpp>
#include <boost/lambda/algorithm.hpp>
#include <boost/lambda/numeric.hpp>
#include <boost/thread/condition_variable.hpp>
#include <boost/thread/condition.hpp>
#include <boost/thread/mutex.hpp>
#include <boost/thread/recursive_mutex.hpp>
#include <boost/thread/thread.hpp>
#include <boost/thread/barrier.hpp>
#include <boost/pool/pool_alloc.hpp>
#include <boost/pool/object_pool.hpp>
As you can see I am using boost massively.
(Really I like the way boost is implemented. Its a nice set of libraries and
very
well documented.)
I have to say that for pure AI implementation is not really needed but I have a
lot
of code using it and I did not want to redo everything...
For A* what I do is to generate a depth map (once the scene is loaded) with all
the
static objects in the scene. Then I use this depth map in my pathfinder...
Via logic nodes I can instruct the engine to move gameobjects to some arbitrary
point
in the scene(x,y). In order to no stop main thread, logic calculates the path
in
another thread (I have implemented a transparent way to make
asynchronous/synchronous
calls between threads to perform (in this case) motion in the main thread but
directed by AI thread....)
It would be nice to have all this stuff in OgreKit and my first idea was to add
it
via logic nodes without touching the Core-Engine since I do not want to
introduce any
conflict with your code...
In any case what is really needed is some consistent API(interface) inside
OgreKit to
handle threads and perform synchronization. The rest... I can redo it.
By the way http://code.google.com/p/recastnavigation looks very interesting!
Thanks guys!
Original comment by silveira.nestor@gmail.com
on 19 Feb 2010 at 4:42
I agree that we need to make OgreKit thread safe. I was thinking about trying to
extract threading information from the bullet multi threaded library to be used
in
OgreKit. To be honest though, I have very little threading experience and am
not sure
what all is needed in order to get this done.
Original comment by snailr...@gmail.com
on 20 Feb 2010 at 6:44
Thanks Charlie! I just was wondering if having access to boost from inside
OgreKit
was possible. I understand Erwin concerns and I agree with him too. Anyway I
can link
externaly OgreKit and Boost and do all my experimental AI stuff without
touching
OgreKit...
If in the future you implement A* in OgreKit you are going to need threading
support
basically because pathfinding takes a bit of time and it cannot be implemented
entirety inside the render loop(basically it will cause rendering to pause).
I was taking a look to recastnavigation and I like it. I think it could be a
good
candidate for navigation meshes and pathfinding inside OgreKit.
Anyway thanks you guys for considering all this Boost stuff....
Original comment by silveira.nestor@gmail.com
on 21 Feb 2010 at 1:06
Original comment by silveira.nestor@gmail.com
on 25 Feb 2010 at 2:27
Original issue reported on code.google.com by
silveira.nestor@gmail.com
on 18 Feb 2010 at 10:21