OT: Opinions about OGRE please

[swiych]

A group of people are about to start an open source flightsim and discussion turned towards 3D APIs. 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

[kieranatwork]

If it's got a plugin architecture, which with a quick glance it seems to have, then you'll be saving yourself a lot of difficult and boring work by using something like ogre. Basically, if I were you I'd be looking for something really simple, that has an open architecture (plugins/callbacks for custom functionality at the most useful stages) and ideally open source code, with plenty of documentation.
Otherwise, prepare yourself for lots of boring fiddly coding, abstracting windows api's, writing your own data loading libs etc.
There's a lot to be said for middleware.

[jwatte]

Last I checked, Ogre didn't use indexed vertex arrays for rendering.

[SirKnight]

I just started playing a little with OGRE and I find that while it has a lot of features and the OOP design is nice, it's not excatly fast. The framerates on VERY simple scenes was horrible and it took a while for the program to load before any thing was happening on screen. I'm not sure why it's so slow yet since I have only messed with it for a small amount of time. But it's still a good piece to learn from for making your own engine if that is your thing.

-SirKnight

[john]

Personally, I'm sceptical since OGRE is an API on top of an API and a loss of flexibility is certain.

Statements like this bug me. I'm not talking about OGRE or DirectX here, I'm talking about the perception that *AN* API built on another is inherently inefficient and wrong. It isn't; and, in fact, its done all the time.

At the lowest level, whatever language you are using to write programs is built on another language. Thus, the C API is being munged at the very least into an binary object (with its own 'API'). This is true for all languages with the exception of machine code. Furthermore, your source might be transformed into any number of intermediate languages without you even knowing it. GCC, for instance, compiles all input languages into a machine-independent assembler before being targetted for a particular machine. The code is then reemitted into this machine language.

You're also using different APIs At the O/S level, even to the point at using an API to call a function because you're using some interface to set-up a stack frame so the o/s can read your parameters.

Higher up, still, at the language level: everytime you use public inheritence in C++ you're basing one API (this time, a class) layered ontop of another API.

My point is: just because you have an API which is implemented in-terms-of another API doesn't mean that you're losing anything. In fact, the idea of layering APIs is to ADD functionality. OpenGL is an API upon the video card's machine interface. Your scene-graph implementation is an API that is layered upon OpenGL, and so on.

Programming is just about defining a set of symbols to make expressing a program easier. Just like you can manipulate synmbols in mathematics to express one variable in terms of another, you can do the same kind of thing in programming. (This scene=graph in terms of OpenGL or this graph in terms of DirectX, for instance.)

anyway

[*Aaron*]

First, John, he didn't say it would be slower, he said it would be less flexible. Not all APIs are compatible. For example, there is an implementation of OpenAL layered on top of DirectSound3D. OpenAL allows one to specify a "rolloff factor" for each sound source. DS3D does not. Thus, it is not possible to create a fully compliant implementation of OpenAL using DS3D. I'm no expert on Direct3D, but I wouldn't be surprised to find similar incompatabilities in these two APIs, especially in their shading languages.

Second, the authors of GCC will admit that the code that it produces is not quite as fast as that produced by VC++. (I use it anyway because it has better ANSI compliance and it's free.)

[dorbie]

Hmm... less flexibility, it's that vs free functionality, and of course being well designed it might add flexibility.

Let's look at early C++ compilers for a second. Was C++ less flexible than C? I don't think so, was it slower? Not if you stuck to fairly vanilla C code and the extra power of the language could be used wisely for fast code too. It's not an API but a language but I think it's a reasonable counterpoint that everyone can understand.

There are good APIs and bad APIs, some APIs don't try to offer all the original flexibility, nor should they, some APIs coexist with the libs they call through and other APIs try to support extensibility and flexibility. You cannot make sweeping generalizations about them.

[Robert Osfield]

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

Flight Gear
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/

Originally posted by swiych:
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

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).]