I recently came across OpenSteer, and being extremely impressed with the included demos I have decided that I would like to start playing with it :) This will hopefully include updating the current steertest OpenGL graphics package to something a bit more powerful (OGRE 3D graphics engine).
Anyway, I was a little worried about the current activity involved with this project, i.e.
Last SourceForge Forum Post: June 16, 2004
Last SourceForge file release: October 7, 2003 (!!)
OpenSteer web site last modified: May 28, 2003
In other words, is this project still undergoing development? Is there still any active support?
I sincerely hope so.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Perhaps it would be feasible to "fork" OpenSteer and build an "ExperimentalOpenSteer" project which allows contributers to submit their code/experiments easier into the codebase? Craig could than inspect and take over changes he likes and wouldn't get swamped with change and improvement requests. However this is something he should like because he provided the fantastic OpenSteer we have now!
I am also thinking about doing more stuff with OpenSteer (think parallelization) but would have just done it on my private copy (which has a few changes in it currently).
Whatever, I wouldn't opt for including a specific 3D backend but to define a very small and clean interface that could be mapped to OpenGL, Ogre 3D, Open Scene Graph, whatever...
As far as I am depicting this interface (and I haven't looked into OpenSteer for a long time) I would like to have functions (or methods) that create (return links to) material/shader info and functions that return something to depict boids, obstacles, lines, the floor, and so on. Every single instance would have an id or something like that. If OpenSteer would need to change the attributes of a boid it would just send a change-command with the id and the attrbiutes to change to the interface (think transaction semantics).
Behind this interface all of this could directly be mapped to OpenGL or could be mapped into a scene graph using the "ids" to find/link to the respective nodes.
This would also allow for batching changes -> higher performance and possibly graphics with new bells and whistles :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Im sorry, I may have mislead you when I mentioned "updating the current steertest OpenGL graphics package". I do not intend to change or modify ANYTHING to do with the OpenSteer or the OpenGL SteerTest. They both do a grand job and I have neither the desire nor the experiance to mess with them.
What I meant was that it would be interesting to create an OGRE plugin, meaning people using the OGRE engine can take advantage of the A.I. provided by OpenSteer.
My question really is about OpenSteer...is it still in active development?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If the gist of your question is "has development on OpenSteer permanently stopped?", I would answer no. Long-winded reply and limp "call for action" follows:
I hang my head in shame at the pace of OpenSteer development. On the other hand, to quote Monty Python "I'm not dead yet" so progress on OpenSteer is expected. Sadly, reality frequently intrudes, and my time is taken up elsewhere. (In addition to my main projects at SCEA, some side projects that might be of interest to the readers of this forum include this recent workshop (http://www.stottlerhenke.com/gameai/) and my new page on game research (http://www.red3d.com/cwr/games/))
Here are some pending tasks, roughly in order of importance. There may be other topics that I've forgotten about, see (2) below. The first four might constitute a good 0.9 release:
(1) IDE support (MS Visual Studio, Apple Xcode(, Eclipse?))
(2) Begin using the bug tracking facility provided by SourceForge. Transfer all known bugs (http://opensteer.sourceforge.net/doc.html#KnownBugs) into it.
(4) Redesign SteerTest's graphics module to support multiple graphics APIs.
(5) Create a new vehicle class to model wheeled vehicles its control inputs are throttle, brake and "turning" (as front wheel angle as in Ben Forsyth's tricycle, or as curvature (turning radius) as in my ad hoc version).
(6) add a (cross-platform!) GUI to SteerTest to replace its current 1960s style UI based on single key commands
Notes:
(1) Mostly the hang up on IDE support is "fear of commitment" -- I have a Mac OS X ProjectBuilder "project" which I assume I can easily change to an Xcode project, and I have a project MS Visual C++. But I worry about the correct directory structure, placement of these project files etc., especially for Windows where I have no experience. How about if I post these files somewhere and let people look at them?
(3) this was my main project for a few months around New Years (see https://sourceforge.net/forum/message.php?msg_id=2609142\). I just need to clean it up and release it "as is". Its not very good at what it does, and the vehicle model is a grotesque hack, but I'll plan to replace it with a better version in the future.
(4) As an OpenSteer user myself, I need this feature, particularly the ability to run SteerTest using another graphics API. If someone else wants to design and implement it, that is fine with me. Note that I had private communications back in April with Ruairi McCarron who had made a first stab at getting SteerTest to run using Direct3D on Windows. He was going to send me code "as soon as he cleaned it up" but I haven't head back.
(6) a GUI would be fairly perpendicular to the rest of OpenSteer (plus I don't know anything about modern GUI toolkits) so this might also be a good project for someone else.
Finally to Bjoern's suggestion of forking off an "ExperimentalOpenSteer": I won't try to block anyone who wants to do that, but it does not seem unnecessary to me. Certainly we don't have to worry about experimental code disrupting the majestic progress of the main OpenSteer fork! Also, while I am the only one with write access to the source code, I don't think this has had any effect on the pace of integrating contributed code to the project. Aside from the early days in May and April of 2003 when many people contributed patches to allow cross-platform compilation, I cannot recall any recent pending patches. If anyone sent a patch and is waiting for me to integrate it, please remind me.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The main reason for thinking about a "spin-off" is to have a place to collect all the different user specific changes so they don't get "lost" on the private hard disks :-)
When you announced to work for the AI rally and then that you are about to introduce some changes it felt wrong to work on further patches because they might have collided with your work.
One of the things I had laying around here was a bit of a rewrite to adapt the vector class (and some other classes) to the C++ programming style promoted by Herb Sutter and Meyers and co. But there was no point in sending you this while other work was more important for you.
Back to your points:
1. Converting a Mac OS X Project Builder project to Xcode is rather easy (automatic) but it would be great to enable lots of the new warning options then :-)
I would be very interested in seeing/discussing the new directory/project layout you are planning.
3. I will look into OpenSteer to see if it is feasible to parallelize it (using threads (from the Boost lib), OpenMP and possible MPI) and would like to refactor the graphic interface therefore, too (all OpenGL calls have to reside in in just one/their own thread).
6. There are quite some free GUIs around. As far as I know there is even a project that builds a GUI with OpenGL and GLUT.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Bjoern: "The main reason for thinking about a "spin-off" is to have a place to collect all the different user specific changes so they don't get "lost" on the private hard disks :-)"
Hmm, basically you just want to be able to check in your changes into a CVS somewhere? My concern is that all the development would then happen in the experimental branch, creating an ongoing chore to back patch and resynchronize the main branch. My take is that if you think the experimental branch is important, go ahead and do it, but I am not promising to migrate changes from the experimental to the main branch. Which I think leaves us in about the same situation as now.
Bjoern: "When you announced to work for the AI rally and then that you are about to introduce some changes it felt wrong to work on further patches because they might have collided with your work."
This seems wrong to me. The C in CVS is for Concurrent, the whole idea is that multiple developers are supposed to be able to work on the same source files and synchronize their changes later. Besides, the driving demo is fairly self contained (too much so, its all in one large file). Changes I made to the rest of the system were checked into CVS as I went along.
Bjoern: "One of the things I had laying around here was a bit of a rewrite to adapt the vector class (and some other classes) to the C++ programming style promoted by Herb Sutter and Meyers and co. But there was no point in sending you this while other work was more important for you."
Ah yes, now I remember this from about 13 months ago. Sorry about that. At the time I was focused on getting the systems compiling and running on multiple platforms. I think you gave me a patch which combined required changes for OS X and other (may I call them "philosophical"?) changes to Vec3. We had some discussions about it which felt inconclusive to me, and it wasn't a "causes a compilation error" issue so I put it aside. Do you have a version of these changes compatible with the current CVS? How about if you open a new thread and restate briefly what you want to accomplish with this change?
Regarding the Xcode (and VC++) project file, I'm off to SIGGRAPH next week, but I will put a note on my calendar to return to this on August 16.
Let us know what you learn about parallelizing OpenSteer. I'm generally interested in parallel implementations of crowd/flock simulations, although using different substrate.
A GUI based on OpenGL and GLUT sounds very applicable, since all current OpenSteer users need to have both libraries to run the current version.
Speaking of SIGGRAPH: this is the one year anniversary of Bjoern saving the day by catching a last minute bug which threatened to ruin my demo. Thanks again for that invaluable help!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On 2004-08-05 15:41 I said: "...Regarding the Xcode (and VC++) project file, I'm off to SIGGRAPH next week, but I will put a note on my calendar to return to this on August 16..." I didn't do that today because I realized I needed to do a preliminary step. On 2004-08-04 11:06 I said: "...(3) release driving plug-in (road following, map-based obstacle avoidance, quasi-realistic vehicle)..." So I checked in a file called plugins/MapDrive.cpp which defines a plug-in titled "Driving through map based obstacles". (I also checked in a version of src/Draw.cpp with the static DeferredLine::size bumped up to 3000.) If anyone is so inclined, I'm interested to hear about any problems compiling or running this "new" plug-in. There is a too-brief explanation at the top of the file:
Driving through map-based obstacles (SteerTest PlugIn)
This demonstration is inspired by the DARPA Grand Challenge cross country race for autonomous vehicles (http://www.darpa.mil/grandchallenge/). A route is defined as a series of (GPS) waypoints and a width associated with each segment between waypoints. This demo assumes sensors on-board the vehicle create a binary map classifying the surrounding terrain into drivable and not drivable. The vehicle tries to follow the route while avoiding obstacles and maximizing speed. When the vehicle finds itself in danger of collision, it "gives up" (turns yellow) and slows to a stop. If it collides with an obstacle it turns red. In both cases the simulation is restarted. (This plug-in includes two non-path-following demos of map-based obstacle avoidance. Use F1 to select among them.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Plug and play as it should be - aside some compiler warning (about hidden instance variables and shadowed local variables and a problem with a method that should be const) :-)
The "problem" with the const method is changeable - though I am not entirely sure if the changes (promoting const to other methods called) is true to the initial design... (just wanted to get rid of the warning)...
A very nice plugin it is - while it was running colleagues stopped to watch it and asked about OpenSteer :-)
Cheers
Bjoern
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Craig, Paul and Bjoern.
I use OpenSteer in a somewhat bigger project here, and after struggling a bit, I find it really useful. But, I think that there are some things that could be done better for a 0.9 (0.9.1?) release.
1) One of the biggest problems I had, was that OS is not really a library but a bunch of files where you have to take what you need. I use OS with OpenSG (www.opensg.org) here and it was quite annoying to get rid of all the PlugIn, and SimpleVehicle stuff (although I find this demo app quite cool). A stripped down to the guts version with a Makefile for a shared library would be nice.
2) Another big problem is that the documentation is not doxygen conform. Could you please run a search & replace on your code to change the // in /// and or /** */ comments, this would be a huge help sometimes. I would do this myself for (parts of) 0.8, but I don't know what has changed so far.
3) Steerimg wishlist: steerForWall(), BoxObstacle (well, maybe I find the time to do this myself, at this very moment spheres are sufficient for me) and a cool way to combine different behaviours to strategies.
4) Forgive me, master, please, but, I, uhh, don't know how to say, well: I don't really like your programming style: Many class members are declared public, there are often no accessor methods, much of the implementation is done straight in the header file. That was one of the main reasons for me to encapsulate everything that is OS related in a statically linked library and get rid of it in my own app.
Nevertheless: Great work and thanks for replying always that fast in this forum.
Regards,
Dominik
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
inikofdoom: "I use OpenSteer in a somewhat bigger project here, and after struggling a bit, I find it really useful."
Great. That is good to hear, and I appreciate you taking time to make these suggestions.
inikofdoom: "[OpenSteer] is not really a library but a bunch of files where you have to take what you need...A stripped down to the guts version with a Makefile for a shared library would be nice."
Yes, thanks for reminding me of this issue. While it is a good idea, "nothing is simple". For example, different people might want different portions of OpenSteer in the "stripped down shared library". One might want SimpleVehicle left out, another might want it included. Also doing this via the Makefile probably only helps Linux geeks (like me) whereas Window and OS X users probably want it integrated with IDE support. Finally, some users (say console game developers) don't care about DLLs or SOs since they target unique hardware, which might not even support dynamic linking. This audience really just wants a "a bunch of files where you have to take what you need."
inikofdoom: "Another big problem is that the documentation is not doxygen conform. Could you please run a search & replace on your code to change the // in /// and or /** */ comments, this would be a huge help sometimes. I would do this myself for (parts of) 0.8, but I don't know what has changed so far."
Lets take a poll: how many OpenSteer users also use doxygen? I am only vaguely familiar it. I used and liked Cocoon, an earlier (but similar?) documentation engine. Assuming this would be useful to a significant portion of the users, you (Dominik) will need to explain in more detail what needs to be done, or do it yourself. BUT DO NOT USE THE 11 MONTH OLD SOURCE IN RELEASE 0.8, USE THE CURRENT SOURCE FROM THE CVS REPOSITORY.
inikofdoom: "Steering wishlist: steerForWall(), BoxObstacle (well, maybe I find the time to do this myself, at this very moment spheres are sufficient for me) and a cool way to combine different behaviours to strategies."
The last is a bit too vague to implement yet(!) but discussions are welcome. I'd be very happy to accept a contribution of a BoxObstacle implementation (based upon https://sourceforge.net/forum/message.php?msg_id=2601759\). Say more about steerForWall ("steer to avoid wall"?), how are walls specified? is this like "containment" (http://www.red3d.com/cwr/steer/Containment.html)?
inikofdoom: "Forgive me, master, please, but, I, uhh, don't know how to say, well: I don't really like your programming style..."
Ahem. I'll admit to having a good background in steering behaviors and object oriented programming, but as I've said before (https://sourceforge.net/forum/message.php?msg_id=2170047) I am no C++ expert.
inikofdoom: "Many class members are declared public, there are often no accessor methods"
Helpful criticism requires more detail. For example, all member variables of SimpleVehicle are private. But then you said SimpleVehicle was one of the classes you threw away immediately. Which classes would you like to see changed? Which of those is most urgent?
inikofdoom: "much of the implementation is done straight in the header file. That was one of the main reasons for me to encapsulate everything that is OS related in a statically linked library and get rid of it in my own app."
Why do you object to implementation in .h files? Is this a compile time issue? (In which case, precompiled headers fix it, right?) Or are there other philosophic objections?
inikofdoom: "Nevertheless: Great work and thanks for replying always that fast in this forum."
I always reply fast, no matter how long it takes! :-}
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I try use doxygen when I have time to properly comment my code and I like it. And in other news I'm back from my south american backpacking trip and crunching away on my thesis which should be done in a few weeks. After that I hope that I will have some time to clean up my opensteer modifications and make them public.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
(Makefiles)
Yes, I think I was bit to fast here. This is a bigger task and not that necessary at this moment. But I think there should be a simpler way to integrate OS in your own app. I wrote a class called OpenSteerEnvionment, that holds the clock, obstacles, the ProximityDB etc. and is accessible everwhere as a Singleton object via OpenSteerEnvironment::the()-> . I will clean it up a little bit and send it to you, maybe this is also useful for others.
(Doxygen)
I think this can be done quite fast, as I said before, most can be done by a simple text replace. I will check out the CVS version and try it out these days. If it works like I think I will send you some pathches.
(Steering)
Yes, I meant containment, but I think it's closely related to the box obstacle thing. Btw., maybe a very simple (infinite?) plane obstacle could be also very useful.
(Private/public members)
I think this should be done consequently in all basically used classes, some examples are Pathway, Obstacle, and Vec3. But again I think that this can be done quite fast.
(Headers and Implementation)
Well, I think discussions about programming style are always philosophic in some way. But there are some reasons against putting it all in the header.
* Everything you implement in the header is inlined by most compilers by default (if possible). This is sometimes useful but shouldn't be done with nearly every function because this can seriously bloat up the size of your executable.
* The are quite heavy compile time and linking dependencies (although I have to admit that that's not really a problem in a rather small project like OS, but if you integrate it (the wrong way) in a bigger project it can be really annonying to change something in the implementation of OS).
* I find it much cleaner to have all declarations and class/method documentation in the .h and the implementation a .cpp file.
Regards,
Dominik
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Glad to hear that the project is still alive, Craig :)
In that case, I will want to take a deeper look at OpenSteer in a couple of months time. Right now, I have other priorities on the go (as we all do...not enough hours in the day, eh). I just wanted to pop in and make sure that this project was still moving forward. I did however manage to quickly get the sourcecode and get it compiled and running pretty painlessly (Win XP, Visual Studio 2003).
Im sorry to hear that not much came from the DirectX version. So with this and your desire for OS independant graphics and GUI's, (and I know there is many graphics packages available out there) let me take this opportunity to 'advertise' the OGRE graphics engine ( http://www.ogre3d.org/ ). You should take a look at the engines features on the site, but here's a few major points to note:
- It's Free and OpenSource.
- Supports Direct3D and OpenGL, and builds/runs on Windows, Linux and Mac.
- Good solid design, with uptodate and concise documentation. This leads to a highly flexible, easy to use graphics library. This is a graphics engine, not a game engine.
- Recently began incorporating a new seperate GUI system into its core. The GUI itself is highly flexible and easy to use ( http://crayzedsgui.sourceforge.net/ )
- Brilliant community. You would be hard pressed to find more mature, supportive and professional developers and forum users than at the OGRE web site. (It was also from those forums that I heard of OpenSteer.)
- Very fast rendering, with support for high-end graphics! Fantastic material and shader funtionality, shadows, special effects etc.
I know I sound like a salesman, hehe, but its just my honest opinion following more than a year experiance using it. Like what Bjoern proposed, if the ability was there to 'plugin' OpenSteer into your graphics engine of choice, then OGRE would be a wise starting point. I sincerely hope that someone gives this crack, if not I will attempt a cutdown example myself in the future.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I recently came across OpenSteer, and being extremely impressed with the included demos I have decided that I would like to start playing with it :) This will hopefully include updating the current steertest OpenGL graphics package to something a bit more powerful (OGRE 3D graphics engine).
Anyway, I was a little worried about the current activity involved with this project, i.e.
Last SourceForge Forum Post: June 16, 2004
Last SourceForge file release: October 7, 2003 (!!)
OpenSteer web site last modified: May 28, 2003
In other words, is this project still undergoing development? Is there still any active support?
I sincerely hope so.
Perhaps it would be feasible to "fork" OpenSteer and build an "ExperimentalOpenSteer" project which allows contributers to submit their code/experiments easier into the codebase? Craig could than inspect and take over changes he likes and wouldn't get swamped with change and improvement requests. However this is something he should like because he provided the fantastic OpenSteer we have now!
I am also thinking about doing more stuff with OpenSteer (think parallelization) but would have just done it on my private copy (which has a few changes in it currently).
Whatever, I wouldn't opt for including a specific 3D backend but to define a very small and clean interface that could be mapped to OpenGL, Ogre 3D, Open Scene Graph, whatever...
As far as I am depicting this interface (and I haven't looked into OpenSteer for a long time) I would like to have functions (or methods) that create (return links to) material/shader info and functions that return something to depict boids, obstacles, lines, the floor, and so on. Every single instance would have an id or something like that. If OpenSteer would need to change the attributes of a boid it would just send a change-command with the id and the attrbiutes to change to the interface (think transaction semantics).
Behind this interface all of this could directly be mapped to OpenGL or could be mapped into a scene graph using the "ids" to find/link to the respective nodes.
This would also allow for batching changes -> higher performance and possibly graphics with new bells and whistles :-)
Hi, thanks for your reply.
Im sorry, I may have mislead you when I mentioned "updating the current steertest OpenGL graphics package". I do not intend to change or modify ANYTHING to do with the OpenSteer or the OpenGL SteerTest. They both do a grand job and I have neither the desire nor the experiance to mess with them.
What I meant was that it would be interesting to create an OGRE plugin, meaning people using the OGRE engine can take advantage of the A.I. provided by OpenSteer.
My question really is about OpenSteer...is it still in active development?
If the gist of your question is "has development on OpenSteer permanently stopped?", I would answer no. Long-winded reply and limp "call for action" follows:
I hang my head in shame at the pace of OpenSteer development. On the other hand, to quote Monty Python "I'm not dead yet" so progress on OpenSteer is expected. Sadly, reality frequently intrudes, and my time is taken up elsewhere. (In addition to my main projects at SCEA, some side projects that might be of interest to the readers of this forum include this recent workshop (http://www.stottlerhenke.com/gameai/) and my new page on game research (http://www.red3d.com/cwr/games/))
Here are some pending tasks, roughly in order of importance. There may be other topics that I've forgotten about, see (2) below. The first four might constitute a good 0.9 release:
(1) IDE support (MS Visual Studio, Apple Xcode(, Eclipse?))
(2) Begin using the bug tracking facility provided by SourceForge. Transfer all known bugs (http://opensteer.sourceforge.net/doc.html#KnownBugs) into it.
(3) release driving plug-in (road following, map-based obstacle avoidance, quasi-realistic vehicle)
(4) Redesign SteerTest's graphics module to support multiple graphics APIs.
(5) Create a new vehicle class to model wheeled vehicles its control inputs are throttle, brake and "turning" (as front wheel angle as in Ben Forsyth's tricycle, or as curvature (turning radius) as in my ad hoc version).
(6) add a (cross-platform!) GUI to SteerTest to replace its current 1960s style UI based on single key commands
Notes:
(1) Mostly the hang up on IDE support is "fear of commitment" -- I have a Mac OS X ProjectBuilder "project" which I assume I can easily change to an Xcode project, and I have a project MS Visual C++. But I worry about the correct directory structure, placement of these project files etc., especially for Windows where I have no experience. How about if I post these files somewhere and let people look at them?
(3) this was my main project for a few months around New Years (see https://sourceforge.net/forum/message.php?msg_id=2609142\). I just need to clean it up and release it "as is". Its not very good at what it does, and the vehicle model is a grotesque hack, but I'll plan to replace it with a better version in the future.
(4) As an OpenSteer user myself, I need this feature, particularly the ability to run SteerTest using another graphics API. If someone else wants to design and implement it, that is fine with me. Note that I had private communications back in April with Ruairi McCarron who had made a first stab at getting SteerTest to run using Direct3D on Windows. He was going to send me code "as soon as he cleaned it up" but I haven't head back.
(6) a GUI would be fairly perpendicular to the rest of OpenSteer (plus I don't know anything about modern GUI toolkits) so this might also be a good project for someone else.
Finally to Bjoern's suggestion of forking off an "ExperimentalOpenSteer": I won't try to block anyone who wants to do that, but it does not seem unnecessary to me. Certainly we don't have to worry about experimental code disrupting the majestic progress of the main OpenSteer fork! Also, while I am the only one with write access to the source code, I don't think this has had any effect on the pace of integrating contributed code to the project. Aside from the early days in May and April of 2003 when many people contributed patches to allow cross-platform compilation, I cannot recall any recent pending patches. If anyone sent a patch and is waiting for me to integrate it, please remind me.
The main reason for thinking about a "spin-off" is to have a place to collect all the different user specific changes so they don't get "lost" on the private hard disks :-)
When you announced to work for the AI rally and then that you are about to introduce some changes it felt wrong to work on further patches because they might have collided with your work.
One of the things I had laying around here was a bit of a rewrite to adapt the vector class (and some other classes) to the C++ programming style promoted by Herb Sutter and Meyers and co. But there was no point in sending you this while other work was more important for you.
Back to your points:
1. Converting a Mac OS X Project Builder project to Xcode is rather easy (automatic) but it would be great to enable lots of the new warning options then :-)
I would be very interested in seeing/discussing the new directory/project layout you are planning.
3. I will look into OpenSteer to see if it is feasible to parallelize it (using threads (from the Boost lib), OpenMP and possible MPI) and would like to refactor the graphic interface therefore, too (all OpenGL calls have to reside in in just one/their own thread).
6. There are quite some free GUIs around. As far as I know there is even a project that builds a GUI with OpenGL and GLUT.
Bjoern: "The main reason for thinking about a "spin-off" is to have a place to collect all the different user specific changes so they don't get "lost" on the private hard disks :-)"
Hmm, basically you just want to be able to check in your changes into a CVS somewhere? My concern is that all the development would then happen in the experimental branch, creating an ongoing chore to back patch and resynchronize the main branch. My take is that if you think the experimental branch is important, go ahead and do it, but I am not promising to migrate changes from the experimental to the main branch. Which I think leaves us in about the same situation as now.
Bjoern: "When you announced to work for the AI rally and then that you are about to introduce some changes it felt wrong to work on further patches because they might have collided with your work."
This seems wrong to me. The C in CVS is for Concurrent, the whole idea is that multiple developers are supposed to be able to work on the same source files and synchronize their changes later. Besides, the driving demo is fairly self contained (too much so, its all in one large file). Changes I made to the rest of the system were checked into CVS as I went along.
Bjoern: "One of the things I had laying around here was a bit of a rewrite to adapt the vector class (and some other classes) to the C++ programming style promoted by Herb Sutter and Meyers and co. But there was no point in sending you this while other work was more important for you."
Ah yes, now I remember this from about 13 months ago. Sorry about that. At the time I was focused on getting the systems compiling and running on multiple platforms. I think you gave me a patch which combined required changes for OS X and other (may I call them "philosophical"?) changes to Vec3. We had some discussions about it which felt inconclusive to me, and it wasn't a "causes a compilation error" issue so I put it aside. Do you have a version of these changes compatible with the current CVS? How about if you open a new thread and restate briefly what you want to accomplish with this change?
Regarding the Xcode (and VC++) project file, I'm off to SIGGRAPH next week, but I will put a note on my calendar to return to this on August 16.
Let us know what you learn about parallelizing OpenSteer. I'm generally interested in parallel implementations of crowd/flock simulations, although using different substrate.
A GUI based on OpenGL and GLUT sounds very applicable, since all current OpenSteer users need to have both libraries to run the current version.
Speaking of SIGGRAPH: this is the one year anniversary of Bjoern saving the day by catching a last minute bug which threatened to ruin my demo. Thanks again for that invaluable help!
On 2004-08-05 15:41 I said: "...Regarding the Xcode (and VC++) project file, I'm off to SIGGRAPH next week, but I will put a note on my calendar to return to this on August 16..." I didn't do that today because I realized I needed to do a preliminary step. On 2004-08-04 11:06 I said: "...(3) release driving plug-in (road following, map-based obstacle avoidance, quasi-realistic vehicle)..." So I checked in a file called plugins/MapDrive.cpp which defines a plug-in titled "Driving through map based obstacles". (I also checked in a version of src/Draw.cpp with the static DeferredLine::size bumped up to 3000.) If anyone is so inclined, I'm interested to hear about any problems compiling or running this "new" plug-in. There is a too-brief explanation at the top of the file:
Driving through map-based obstacles (SteerTest PlugIn)
This demonstration is inspired by the DARPA Grand Challenge cross country race for autonomous vehicles (http://www.darpa.mil/grandchallenge/). A route is defined as a series of (GPS) waypoints and a width associated with each segment between waypoints. This demo assumes sensors on-board the vehicle create a binary map classifying the surrounding terrain into drivable and not drivable. The vehicle tries to follow the route while avoiding obstacles and maximizing speed. When the vehicle finds itself in danger of collision, it "gives up" (turns yellow) and slows to a stop. If it collides with an obstacle it turns red. In both cases the simulation is restarted. (This plug-in includes two non-path-following demos of map-based obstacle avoidance. Use F1 to select among them.)
Plug and play as it should be - aside some compiler warning (about hidden instance variables and shadowed local variables and a problem with a method that should be const) :-)
The "problem" with the const method is changeable - though I am not entirely sure if the changes (promoting const to other methods called) is true to the initial design... (just wanted to get rid of the warning)...
A very nice plugin it is - while it was running colleagues stopped to watch it and asked about OpenSteer :-)
Cheers
Bjoern
Hi Craig, Paul and Bjoern.
I use OpenSteer in a somewhat bigger project here, and after struggling a bit, I find it really useful. But, I think that there are some things that could be done better for a 0.9 (0.9.1?) release.
1) One of the biggest problems I had, was that OS is not really a library but a bunch of files where you have to take what you need. I use OS with OpenSG (www.opensg.org) here and it was quite annoying to get rid of all the PlugIn, and SimpleVehicle stuff (although I find this demo app quite cool). A stripped down to the guts version with a Makefile for a shared library would be nice.
2) Another big problem is that the documentation is not doxygen conform. Could you please run a search & replace on your code to change the // in /// and or /** */ comments, this would be a huge help sometimes. I would do this myself for (parts of) 0.8, but I don't know what has changed so far.
3) Steerimg wishlist: steerForWall(), BoxObstacle (well, maybe I find the time to do this myself, at this very moment spheres are sufficient for me) and a cool way to combine different behaviours to strategies.
4) Forgive me, master, please, but, I, uhh, don't know how to say, well: I don't really like your programming style: Many class members are declared public, there are often no accessor methods, much of the implementation is done straight in the header file. That was one of the main reasons for me to encapsulate everything that is OS related in a statically linked library and get rid of it in my own app.
Nevertheless: Great work and thanks for replying always that fast in this forum.
Regards,
Dominik
inikofdoom: "I use OpenSteer in a somewhat bigger project here, and after struggling a bit, I find it really useful."
Great. That is good to hear, and I appreciate you taking time to make these suggestions.
inikofdoom: "[OpenSteer] is not really a library but a bunch of files where you have to take what you need...A stripped down to the guts version with a Makefile for a shared library would be nice."
Yes, thanks for reminding me of this issue. While it is a good idea, "nothing is simple". For example, different people might want different portions of OpenSteer in the "stripped down shared library". One might want SimpleVehicle left out, another might want it included. Also doing this via the Makefile probably only helps Linux geeks (like me) whereas Window and OS X users probably want it integrated with IDE support. Finally, some users (say console game developers) don't care about DLLs or SOs since they target unique hardware, which might not even support dynamic linking. This audience really just wants a "a bunch of files where you have to take what you need."
inikofdoom: "Another big problem is that the documentation is not doxygen conform. Could you please run a search & replace on your code to change the // in /// and or /** */ comments, this would be a huge help sometimes. I would do this myself for (parts of) 0.8, but I don't know what has changed so far."
Lets take a poll: how many OpenSteer users also use doxygen? I am only vaguely familiar it. I used and liked Cocoon, an earlier (but similar?) documentation engine. Assuming this would be useful to a significant portion of the users, you (Dominik) will need to explain in more detail what needs to be done, or do it yourself. BUT DO NOT USE THE 11 MONTH OLD SOURCE IN RELEASE 0.8, USE THE CURRENT SOURCE FROM THE CVS REPOSITORY.
inikofdoom: "Steering wishlist: steerForWall(), BoxObstacle (well, maybe I find the time to do this myself, at this very moment spheres are sufficient for me) and a cool way to combine different behaviours to strategies."
The last is a bit too vague to implement yet(!) but discussions are welcome. I'd be very happy to accept a contribution of a BoxObstacle implementation (based upon https://sourceforge.net/forum/message.php?msg_id=2601759\). Say more about steerForWall ("steer to avoid wall"?), how are walls specified? is this like "containment" (http://www.red3d.com/cwr/steer/Containment.html)?
inikofdoom: "Forgive me, master, please, but, I, uhh, don't know how to say, well: I don't really like your programming style..."
Ahem. I'll admit to having a good background in steering behaviors and object oriented programming, but as I've said before (https://sourceforge.net/forum/message.php?msg_id=2170047) I am no C++ expert.
inikofdoom: "Many class members are declared public, there are often no accessor methods"
Helpful criticism requires more detail. For example, all member variables of SimpleVehicle are private. But then you said SimpleVehicle was one of the classes you threw away immediately. Which classes would you like to see changed? Which of those is most urgent?
inikofdoom: "much of the implementation is done straight in the header file. That was one of the main reasons for me to encapsulate everything that is OS related in a statically linked library and get rid of it in my own app."
Why do you object to implementation in .h files? Is this a compile time issue? (In which case, precompiled headers fix it, right?) Or are there other philosophic objections?
inikofdoom: "Nevertheless: Great work and thanks for replying always that fast in this forum."
I always reply fast, no matter how long it takes! :-}
I try use doxygen when I have time to properly comment my code and I like it. And in other news I'm back from my south american backpacking trip and crunching away on my thesis which should be done in a few weeks. After that I hope that I will have some time to clean up my opensteer modifications and make them public.
Hi Craig.
(Makefiles)
Yes, I think I was bit to fast here. This is a bigger task and not that necessary at this moment. But I think there should be a simpler way to integrate OS in your own app. I wrote a class called OpenSteerEnvionment, that holds the clock, obstacles, the ProximityDB etc. and is accessible everwhere as a Singleton object via OpenSteerEnvironment::the()-> . I will clean it up a little bit and send it to you, maybe this is also useful for others.
(Doxygen)
I think this can be done quite fast, as I said before, most can be done by a simple text replace. I will check out the CVS version and try it out these days. If it works like I think I will send you some pathches.
(Steering)
Yes, I meant containment, but I think it's closely related to the box obstacle thing. Btw., maybe a very simple (infinite?) plane obstacle could be also very useful.
(Private/public members)
I think this should be done consequently in all basically used classes, some examples are Pathway, Obstacle, and Vec3. But again I think that this can be done quite fast.
(Headers and Implementation)
Well, I think discussions about programming style are always philosophic in some way. But there are some reasons against putting it all in the header.
* Everything you implement in the header is inlined by most compilers by default (if possible). This is sometimes useful but shouldn't be done with nearly every function because this can seriously bloat up the size of your executable.
* The are quite heavy compile time and linking dependencies (although I have to admit that that's not really a problem in a rather small project like OS, but if you integrate it (the wrong way) in a bigger project it can be really annonying to change something in the implementation of OS).
* I find it much cleaner to have all declarations and class/method documentation in the .h and the implementation a .cpp file.
Regards,
Dominik
Hi all,
Glad to hear that the project is still alive, Craig :)
In that case, I will want to take a deeper look at OpenSteer in a couple of months time. Right now, I have other priorities on the go (as we all do...not enough hours in the day, eh). I just wanted to pop in and make sure that this project was still moving forward. I did however manage to quickly get the sourcecode and get it compiled and running pretty painlessly (Win XP, Visual Studio 2003).
Im sorry to hear that not much came from the DirectX version. So with this and your desire for OS independant graphics and GUI's, (and I know there is many graphics packages available out there) let me take this opportunity to 'advertise' the OGRE graphics engine ( http://www.ogre3d.org/ ). You should take a look at the engines features on the site, but here's a few major points to note:
- It's Free and OpenSource.
- Supports Direct3D and OpenGL, and builds/runs on Windows, Linux and Mac.
- Good solid design, with uptodate and concise documentation. This leads to a highly flexible, easy to use graphics library. This is a graphics engine, not a game engine.
- Recently began incorporating a new seperate GUI system into its core. The GUI itself is highly flexible and easy to use ( http://crayzedsgui.sourceforge.net/ )
- Brilliant community. You would be hard pressed to find more mature, supportive and professional developers and forum users than at the OGRE web site. (It was also from those forums that I heard of OpenSteer.)
- Very fast rendering, with support for high-end graphics! Fantastic material and shader funtionality, shadows, special effects etc.
I know I sound like a salesman, hehe, but its just my honest opinion following more than a year experiance using it. Like what Bjoern proposed, if the ability was there to 'plugin' OpenSteer into your graphics engine of choice, then OGRE would be a wise starting point. I sincerely hope that someone gives this crack, if not I will attempt a cutdown example myself in the future.