As we get closer to programming combat we'll probably want to look at dragging in a 3d graphics engine from elsewhere to do some of the dirty work. I'd actally like to have one or two people start tinkering with our engine of choice well before the serious tactical combat programming start so there will be at least somebody familiar with it. So, it would probably be wise to start investigating and discussing our options here.
A few libraries that have been mentioned so far:
OGRE: http://ogre.sourceforge.net/
VRS: http://www.vrs3d.org/
Crystal Space: http://crystal.sourceforge.net/drupal/
[/url]
3d graphics engines
Moderator: Committer
-
- Pupating Mass
- Posts: 95
- Joined: Thu Jun 26, 2003 12:09 pm
- Location: Chicago
3d graphics engines
Programming Lead
I'd vote for OGRE, it look better to me, it is also fast and appearently heavily developed. And there must be a reason why universities use it for teaching 3D graphics
But I must admit that I haven't look intensly at VRS (as opposed to CS)
PS: I'm aware that we don't want to have a DOOM3-engine for combat
But I must admit that I haven't look intensly at VRS (as opposed to CS)
PS: I'm aware that we don't want to have a DOOM3-engine for combat
I'll tell you all why I like VRS over OGRE. Both are very well documented, both are fairly mature, and both put a great deal of emphasis on good OOD and good use of modern C++ techniques.
However, OGRE is not so much a 3d engine as a game engine; it expects you to use its application framework for OGRE apps, expects you to use OGRE's input to drive you app, etc. It appears (though I haven't looked into this that deeply) that you can't "turn off" OGRE when you don't need it (i.e. most of the time, when combat is not occurring). Also, I tried to get the basic example apps working under MinGW, and it's a nightmare. (For those of you who don't follow this, MinGW is the build environment upon which DevC++ is built.) Another thing I don't like about it is the fact that there are so many classes in OGRE. It screams out "overdesign". I get the distinct impression that these guys have continued to strap more and more features onto a design that was not originally designed to fit them all. A case in point is the limited built-in GUI support. Speaking of GUIs, I don't think we could get GG to work with OGRE without a substantial rewrite of at least the code in SDLGGApp.cpp, and possibly more.
By contrast, VRS is a lot smaller in scope than OGRE. It seeks to be an advanced and robust scene manager, but not to control anything in your app that you don't want it to. There are drivers that exists for VRS to run under input from GLUT, Qt, Tcl/Tk, MFC, and Gtk+. I've already written a driver for SDL that is largely trivial, though I haven't tested it extensively. I've also built several of the example GLUT-version apps under MinGW with relatively few headaches.
I feel from looking at the docs and messing around with the libraries for both, that VRS is a better fit for our project.
However, OGRE is not so much a 3d engine as a game engine; it expects you to use its application framework for OGRE apps, expects you to use OGRE's input to drive you app, etc. It appears (though I haven't looked into this that deeply) that you can't "turn off" OGRE when you don't need it (i.e. most of the time, when combat is not occurring). Also, I tried to get the basic example apps working under MinGW, and it's a nightmare. (For those of you who don't follow this, MinGW is the build environment upon which DevC++ is built.) Another thing I don't like about it is the fact that there are so many classes in OGRE. It screams out "overdesign". I get the distinct impression that these guys have continued to strap more and more features onto a design that was not originally designed to fit them all. A case in point is the limited built-in GUI support. Speaking of GUIs, I don't think we could get GG to work with OGRE without a substantial rewrite of at least the code in SDLGGApp.cpp, and possibly more.
By contrast, VRS is a lot smaller in scope than OGRE. It seeks to be an advanced and robust scene manager, but not to control anything in your app that you don't want it to. There are drivers that exists for VRS to run under input from GLUT, Qt, Tcl/Tk, MFC, and Gtk+. I've already written a driver for SDL that is largely trivial, though I haven't tested it extensively. I've also built several of the example GLUT-version apps under MinGW with relatively few headaches.
I feel from looking at the docs and messing around with the libraries for both, that VRS is a better fit for our project.
-
- Space Krill
- Posts: 6
- Joined: Sat Jul 19, 2003 7:35 pm
Why not use an engine completly dedictated to space graphics, as well as opensource, lightning fast, and easy to modify? You should have a look at vegastrike. This would be an excellent engine if you want space combat to take place across the entire solar system (like moo3 originally was supposed to) as it is 64-bit float compliant and can handle realistic space distances. Everything is in there, even the combat AI. You would only need to make new art and intigrate the Vega Strike combat into Freeorion.
-
- Space Krill
- Posts: 6
- Joined: Sat Jul 19, 2003 7:35 pm