Great! Thank you!!!Download (pre-release for Irrlicht 1.4.1)
irrAI 0.50 - AI module for Irrlicht [Updated 28/11/09]
-
full.metal.coder
- Posts: 68
- Joined: Sat May 10, 2008 11:30 am
- Contact:
Started integrating IrrAI into TFK today. Everything compiles fine (Linux 32bit/GCC/Irrlicht SVN HEAD) except for one error on line 79 in CWayPointSceneNode.h line (remove "CWayPointSceneNode::" in front of "getType()" ).
It seems the manager lacks a way of properly managing waypoints. add, remove and clear are the basic methods REQUIRED in such a case so that waypoints may be loaded for a level (i.e scene) and unloaded before the new level is loaded.
The only purpose of the FOV scene node is (debug) rendering of FOV right? It is not required by IrrAI?
And what about the waypoint scene node? If I understand well it is placed in the scene graph by a proper editor to be loaded afterwards right? Is there a way to automatically hide/remove it from the scene once the actual data is loaded into the manager?
The API is sometimes misleading. For instance AIEntity::addEnemyGroup and AIEntity::addAllyGroup should be repesctively renamed to setEnemyGroup and setAllyGroup (or the implementation ought to be changed).
It'd be better not to use STL and to rely on Irrlicht container classes as much as possible.
Any chance to get rid of Irrlicht triangle selectors? A more generic interface would be nice as it would allow to take advantage of proper physics engine for collision and possibly reduce the memory footprint (triangle selectors always make a deep copy of the data and force you to make a second deep copy to read it!!! Nonsense and waste...)
Ok enough rant for now. I'll try to recreate the examples as pure TFK level (irr scene plus lua scripts) and see what how it works out.
It seems the manager lacks a way of properly managing waypoints. add, remove and clear are the basic methods REQUIRED in such a case so that waypoints may be loaded for a level (i.e scene) and unloaded before the new level is loaded.
The only purpose of the FOV scene node is (debug) rendering of FOV right? It is not required by IrrAI?
And what about the waypoint scene node? If I understand well it is placed in the scene graph by a proper editor to be loaded afterwards right? Is there a way to automatically hide/remove it from the scene once the actual data is loaded into the manager?
The API is sometimes misleading. For instance AIEntity::addEnemyGroup and AIEntity::addAllyGroup should be repesctively renamed to setEnemyGroup and setAllyGroup (or the implementation ought to be changed).
It'd be better not to use STL and to rely on Irrlicht container classes as much as possible.
Any chance to get rid of Irrlicht triangle selectors? A more generic interface would be nice as it would allow to take advantage of proper physics engine for collision and possibly reduce the memory footprint (triangle selectors always make a deep copy of the data and force you to make a second deep copy to read it!!! Nonsense and waste...)
Ok enough rant for now. I'll try to recreate the examples as pure TFK level (irr scene plus lua scripts) and see what how it works out.
Interesting that that compilation error wasn't picked up by either dev-cpp or msvc... not sure why, i'm sure msvc normally complains about things like that! 
Waypoints don't need to be managed by the app that uses IrrAI as IrrAI loads them all itself from the .irr scene. The waypoints are placed in the scene using the IrrAI Editor and are hidden from view by default so don't get rendered (though i suppose they could clog up the scene graph in some way possibly...). Unloading the waypoints i think it currently only handled by shutting down the IrrAI Manager and then recreating this, i'll stick in a better way of doing this.
The FOV node is necessary for doing the FOV intersection tests. The visual aspect of it isn't necessary and so by standard is not rendered. Again that could bring in added overhead so possibly i can think of a better way of handling it.
You're right about the addEnemyGroup etc. Should be setEnemyGroup as it stands at the moment, and i think that's how it will remain so i'll make that change for the next version.
You're probably right about not using STL.. i've tried to use irrlicht versions of things elsewhere so might as well stick wtih that idea.
You're also right that some sort of generic interface for the physics side of things would be useful... I'm not sure how to go about that... I wonder if just adopting bullet or whatever would be the simplest way to go about things.... If you (or anyone else) have ideas about this then feel free to make suggestions.
Cheers for the comments etc.
If you've got a linux version to share then please do send me a copy and i'll make it available for all!
Waypoints don't need to be managed by the app that uses IrrAI as IrrAI loads them all itself from the .irr scene. The waypoints are placed in the scene using the IrrAI Editor and are hidden from view by default so don't get rendered (though i suppose they could clog up the scene graph in some way possibly...). Unloading the waypoints i think it currently only handled by shutting down the IrrAI Manager and then recreating this, i'll stick in a better way of doing this.
The FOV node is necessary for doing the FOV intersection tests. The visual aspect of it isn't necessary and so by standard is not rendered. Again that could bring in added overhead so possibly i can think of a better way of handling it.
You're right about the addEnemyGroup etc. Should be setEnemyGroup as it stands at the moment, and i think that's how it will remain so i'll make that change for the next version.
You're probably right about not using STL.. i've tried to use irrlicht versions of things elsewhere so might as well stick wtih that idea.
You're also right that some sort of generic interface for the physics side of things would be useful... I'm not sure how to go about that... I wonder if just adopting bullet or whatever would be the simplest way to go about things.... If you (or anyone else) have ideas about this then feel free to make suggestions.
Cheers for the comments etc.
If you've got a linux version to share then please do send me a copy and i'll make it available for all!
-
full.metal.coder
- Posts: 68
- Joined: Sat May 10, 2008 11:30 am
- Contact:
I have embedded IrrAI sources into TFK to compile and did not try to compile the examples yet.
Also, even if I were to compile a linux version it probably wouldn't be easily "shareable" because I'm using a patched version of Irrlicht (based on SVN HEAD) which may cause symbol mismatch et all (if the system libs don't do it first). Binary distribution in the Linux world is very distro specific and as I'm using a cutting edge version of a not so common distro it is unlikely that any bins I make can be used on other distros...
I've not studied the internals yet but I have troubles figuring out why you would need a special scene node to compute FOV. FOV computation is done for a specific entity which is already attached to a scene node of its own (so you got position and rotation) and the intersection calculation are simple math that you'd better carry out on your own rather than relying on Irrlicht scene graph.
As for the physics part you got to define what you NEED from the AI side and create a clean interface for this that can be subclassed to use any physics engine (Bullet, Newton, PhysX, Havok, ...) or simply Irrlicht triangle selectors. Figuring out what objects are near enough to potentially appear in the FOV (broadphase) and detecting objects standing in the FOV (ray tests, convex tests, ... : narrowphase) would be the most two important functions I'd say but again I did not have a look at the implementation...
Also, even if I were to compile a linux version it probably wouldn't be easily "shareable" because I'm using a patched version of Irrlicht (based on SVN HEAD) which may cause symbol mismatch et all (if the system libs don't do it first). Binary distribution in the Linux world is very distro specific and as I'm using a cutting edge version of a not so common distro it is unlikely that any bins I make can be used on other distros...
I've not studied the internals yet but I have troubles figuring out why you would need a special scene node to compute FOV. FOV computation is done for a specific entity which is already attached to a scene node of its own (so you got position and rotation) and the intersection calculation are simple math that you'd better carry out on your own rather than relying on Irrlicht scene graph.
As for the physics part you got to define what you NEED from the AI side and create a clean interface for this that can be subclassed to use any physics engine (Bullet, Newton, PhysX, Havok, ...) or simply Irrlicht triangle selectors. Figuring out what objects are near enough to potentially appear in the FOV (broadphase) and detecting objects standing in the FOV (ray tests, convex tests, ... : narrowphase) would be the most two important functions I'd say but again I did not have a look at the implementation...
Fair enough about the linux distro, i'm gonna try and get round to setting up a makefile and compiling it on the distro i have on my home PC, just gotta find the time to do it!
yeah the FOV scene node itself isn't particularly necessary in the calculation (though it is currently) so i'll try and seperate it out a bit, it's all a bit of a mess still really i think!
I'll give the physics side of things some thought when i get a chance, but i'm rather busy at the moment with my ps3 work so probably won't get round it to very soon.
yeah the FOV scene node itself isn't particularly necessary in the calculation (though it is currently) so i'll try and seperate it out a bit, it's all a bit of a mess still really i think!
I'll give the physics side of things some thought when i get a chance, but i'm rather busy at the moment with my ps3 work so probably won't get round it to very soon.
-
hybrid
- Admin
- Posts: 14143
- Joined: Wed Apr 19, 2006 9:20 pm
- Location: Oldenburg(Oldb), Germany
- Contact:
I've also compiled a Linux version, but I couldn't get the examples running. I can provide you with the Makefile, but I cannot guarantee that the compilation did work as expected...
The problem with the additional classname in front of methods declarations is only recognized by gcc 4.x, mingw uses 3.x gccs, though, so you won't even get a warning.
The problem with the additional classname in front of methods declarations is only recognized by gcc 4.x, mingw uses 3.x gccs, though, so you won't even get a warning.
Interesting, must have been the PS3 compiler i was using which is based on 4.x gcc then!
The examples probably didn't work due to my callous disregard to preparing for a linux version and making sure all paths were constructed with the proper slashes and capitalisations. If you chuck me the makefile then that would save me time in making it myself and i can look into what might be going wrong.
The examples probably didn't work due to my callous disregard to preparing for a linux version and making sure all paths were constructed with the proper slashes and capitalisations. If you chuck me the makefile then that would save me time in making it myself and i can look into what might be going wrong.
Little update:
The problem with the progress bar not clipping in DX will apparently be fixed in Irrlicht 1.5 as i found out recently a fix was put forward and should be included.
Unfortunately i did a pretty bad job of testing the IrrAI Editor before releasing it, the auto-link function doesn't do occlusion properly for some strange reason, i've fixed this in my current version though so the next release will have that sorted.
I'm also working on a flood-fill algorithm so you don't even have to place waypoints yourself.
The problem with the progress bar not clipping in DX will apparently be fixed in Irrlicht 1.5 as i found out recently a fix was put forward and should be included.
Unfortunately i did a pretty bad job of testing the IrrAI Editor before releasing it, the auto-link function doesn't do occlusion properly for some strange reason, i've fixed this in my current version though so the next release will have that sorted.
I'm also working on a flood-fill algorithm so you don't even have to place waypoints yourself.
full.metal.coder...
Q: It seems the manager lacks a way of properly managing waypoints. add, remove and clear are the basic methods.
A: As i said above the AI manager handles all the adding and removing of waypoints by loading them from the scene and aimgr->clear() will remove all the things the manager is handling; waypoints, entities and entity groups. So this is what you need for switching levels and also i think this would be ok for switching between seperated areas of a large level as you'd probably have a safe zone between the sections of a level where you can safely remove old nodes, add new ones and so the old waypoints and entities etc are no longer needed there. Not sure if it's compatible with the fact you need to do loadScene, that would require your seperate level sections to be seperate .irr files which might not be suitable for everyone and would require loading times between level sections which isn't ideal... would be nice to think of a way around that... Maybe i'll just stop using the .irr file as a configuration file for the waypoints and make my own file format for that so it can be seperate...
Q: The only purpose of the FOV scene node is (debug) rendering of FOV right?
And what about the waypoint scene node?
A: I've got rid of the dependency on the FOV scene node and implemented IFieldOfView so you can basically set your own FOV if you don't like my sort of cone version. The FOV scene node is still there as a debug option though so you can visualise it for it testing etc.
I'm gonna look into a similar thing for the waypoints as well and also improve their rendering performance quite a bit hopefully anyway. Probably what i said above, about doing away with using the .irr format for the waypoints would help in not requiring the waypoints to be scene nodes.
Q: Any chance to get rid of Irrlicht triangle selectors?
A: Job done. I've offloaded the occlusion test onto the library user. Basically you just register a callback with IrrAI which takes a line3df that the NPC wants to do an occlusion check on and you return true/false based on your own occlusion check with your world's physics representation which could be Irrlicht's triangle selectors or a physics engine like Bullet, Newton, Physx etc. I've made an Irrlicht triangle selector implementation for this in the examples of the next version to show how it's done and i'm considering doing an example using a physics engine but it's not a high priority as if you're using a physics engine you'll probably know how to do this or can get an example of how to do a raycast from the engine's tutorials.
In other news i've nicked Acki's A* search implementation from his Simple Steering demo so now the search should be more efficient and takes into account the distance of a path as being better rather than the number of links as before. And i've turned the path finding into a external class to the NPC so it can easily be used elsewhere in code if necessary and also implemented differently if desired.
Obviously all these changes will be in IrrAI 0.5 so aren't available yet, though hopefully it won't be long before 0.5 is ready.
Q: It seems the manager lacks a way of properly managing waypoints. add, remove and clear are the basic methods.
A: As i said above the AI manager handles all the adding and removing of waypoints by loading them from the scene and aimgr->clear() will remove all the things the manager is handling; waypoints, entities and entity groups. So this is what you need for switching levels and also i think this would be ok for switching between seperated areas of a large level as you'd probably have a safe zone between the sections of a level where you can safely remove old nodes, add new ones and so the old waypoints and entities etc are no longer needed there. Not sure if it's compatible with the fact you need to do loadScene, that would require your seperate level sections to be seperate .irr files which might not be suitable for everyone and would require loading times between level sections which isn't ideal... would be nice to think of a way around that... Maybe i'll just stop using the .irr file as a configuration file for the waypoints and make my own file format for that so it can be seperate...
Q: The only purpose of the FOV scene node is (debug) rendering of FOV right?
And what about the waypoint scene node?
A: I've got rid of the dependency on the FOV scene node and implemented IFieldOfView so you can basically set your own FOV if you don't like my sort of cone version. The FOV scene node is still there as a debug option though so you can visualise it for it testing etc.
I'm gonna look into a similar thing for the waypoints as well and also improve their rendering performance quite a bit hopefully anyway. Probably what i said above, about doing away with using the .irr format for the waypoints would help in not requiring the waypoints to be scene nodes.
Q: Any chance to get rid of Irrlicht triangle selectors?
A: Job done. I've offloaded the occlusion test onto the library user. Basically you just register a callback with IrrAI which takes a line3df that the NPC wants to do an occlusion check on and you return true/false based on your own occlusion check with your world's physics representation which could be Irrlicht's triangle selectors or a physics engine like Bullet, Newton, Physx etc. I've made an Irrlicht triangle selector implementation for this in the examples of the next version to show how it's done and i'm considering doing an example using a physics engine but it's not a high priority as if you're using a physics engine you'll probably know how to do this or can get an example of how to do a raycast from the engine's tutorials.
In other news i've nicked Acki's A* search implementation from his Simple Steering demo so now the search should be more efficient and takes into account the distance of a path as being better rather than the number of links as before. And i've turned the path finding into a external class to the NPC so it can easily be used elsewhere in code if necessary and also implemented differently if desired.
Obviously all these changes will be in IrrAI 0.5 so aren't available yet, though hopefully it won't be long before 0.5 is ready.
Some more news:
I'm now part way through scrapping the waypoint scene nodes and replacing them with a mesh buffer of cubes to represent the waypoints. This is much more efficient for rendering as rendering a large number of cubes as individual draw calls (as it currently is in 0.4) really kills the performance, in 0.5 they'll all be rendered in one draw call so will be much faster. And obviously the mesh buffer can be removed/not created for release versions of a game so that the scene graph isn't clogged up and memory isn't used unnecessarily.
Also i've set up a forum for IrrAI. I don't expect it to be filled with threads/posts any time soon as this thread is generally only filled with me giving info/updates and people saying 'datz kewl' etc. Mostly it's a place for some private discussions about IrrAI development to be done easily but will also provide a place for IrrAI questions to be asked and any projects using IrrAI to be announced, as i'd love to know who's actually using the library. It seems that a large number of people have been downloading IrrAI but i've only heard from a few people that they actually plan to use it. This could be just because people download it out of interest of course
Anyway, here's the forum url, feel free to drop by!
http://www.freepowerboards.com/irrai
I'm now part way through scrapping the waypoint scene nodes and replacing them with a mesh buffer of cubes to represent the waypoints. This is much more efficient for rendering as rendering a large number of cubes as individual draw calls (as it currently is in 0.4) really kills the performance, in 0.5 they'll all be rendered in one draw call so will be much faster. And obviously the mesh buffer can be removed/not created for release versions of a game so that the scene graph isn't clogged up and memory isn't used unnecessarily.
Also i've set up a forum for IrrAI. I don't expect it to be filled with threads/posts any time soon as this thread is generally only filled with me giving info/updates and people saying 'datz kewl' etc. Mostly it's a place for some private discussions about IrrAI development to be done easily but will also provide a place for IrrAI questions to be asked and any projects using IrrAI to be announced, as i'd love to know who's actually using the library. It seems that a large number of people have been downloading IrrAI but i've only heard from a few people that they actually plan to use it. This could be just because people download it out of interest of course
Anyway, here's the forum url, feel free to drop by!
http://www.freepowerboards.com/irrai