Originally posted by swiych:
A group of people are about to start an open source flightsim and discussion turned towards 3D APIs.
Has your group look the possibility of leveraging exisitng open source flight simulator projects? Two come to mind:
Combat Simulator Project
[http://csp.sourceforge.net](http://csp.sourceforge.net)
Flight Gear
[http://www.flightgear.org/](http://www.flightgear.org/)
Both CSP and Flight Gear use open source scene graphs rather than game engines -
CSP uses OpenSceneGraph
http::/www.openscenegraph.org
Flight Gear uses PLib
[http://plib.sourceforge.net/](http://plib.sourceforge.net/)
Originally posted by swiych:
[b]Cross platform compatability is desirable so that pretty much rules out DirectX. However a DirectX supporter suggested using OGRE and it is being considered ( http://ogre.sourceforge.net ).
Personally, I’m sceptical since OGRE is an API on top of an API and a loss of flexibility is certain. If it were up to me, we would go with OpenGL.
Has anyone experimented with OGRE, and if so could you touch on the pros and cons of using it in a project.
Thanks[/b]
I can’t comment on OGRE as I’ve only ever browsed its website out of curiosity. It never struck me as something designed for flight sims though.
As a high level graphics toolkit developmer myself I always found the idea of targetting both Direct3D and OpenGL a pretty good way to eat into precious development time without provide any value to the end user.
API’s that try to straddle both will require an abstraction layer which need time to design, implement and test. You then have to maintain multiple graphics API’s to implement and test aginst for each of the Direct3D and OpenGL API’s. And your test matrix is doubled for each release you ever make. This all adds up to a big increase in the work required to develop the scene graph or game engine which ontop this abstraction layer.
This won’t directly affect you since you won’t be developing Ogre itself, but it could well have an impact on how well this project keeps on developing. Maintaing all the different ports is a burden that its development community will have to manage carefully, as it could end up as shackles holding the projects development back.
Abstraction layers also make it more complex for developers using a scene graph or game engine to code and maintain extensions such as utilising latest graphics card extensions.
The abstraction may also may also have a peformance impact, not neccersily from any indirection due to API abstraction, but due to the difficulty in exposes all the latest fast paths, such as the new arb_vbo extensions.
Also related to need for extending the API is the issue of integration with other toolkits, for instance if you wanted to use an external CLOD lib such as Demeter (http://www.terrainengine.com) how easy whould that be? Would it even be possible?
Personally I’d sit down with your Direct3D advocate and work on how to address any concerns that they might have with a pure OpenGL route. If you can go a pure OpenGL route I think the project would be more productive as you could open up what API’s are available to you.
For instance all of the leading open source scene graphs are OpenGL only. You’ll find commericial flight simulators are almost all entirely built ontop of scene graphs rather than game engines too, you’ll even find a number of these being ported across to use certain open source scene graphs too…
Robert.
[This message has been edited by Robert Osfield (edited 06-23-2003).]