Re: CrystalSpace vs Ogre3d

[Gregor Mückl <GregorMueckl@xxxxxx>]

On Sunday 10 July 2005 22:56, Frédéric Lopez wrote:
> Francesco Orsenigo a écrit :
> > moreover, the only way to create a terrain is loading it from
> > a .cfg file, while i would to generate it and maybe morph during
> > gametime.
>
> Same thing, see :
> http://www.ogre3d.org/phpBB2/viewtopic.php?t=6630&highlight=realtime+genera
>tion
>

I don't think that this is what Francesco meant. Some terrain plugins 
(paginglandscape, for example) do indeed require a config file as input and 
that can't easily be fixed. But as far as I can remember, the paginglandscape 
plugin allows morphing the terrain in the demo. I never really tested it, 
though.

If you want to generate terrain dynamically you might have a look at the 
nature and terrain scene managers. Maybe you can start out with one them as a 
base for an own scene manager which runs on dynamically generated data.

> > most of the programming is made inside headers so that it takes biblic
> > times to compile,
>
> Compiling is not particulary slow on my machine. I don't understand what
> you mean by "most of the programming is made inside headers".
>

The Ogre example applications are indeed written in a fashion that - quite 
stupidly - puts all of the interesting code into a single header file. But 
this coding style is in no way binding or even recommendable for bigger 
projects. I never tried anything close to that, but put initialisation code 
in a simple, straight-forward init() function. The ExampleApplication class 
may be correct from an OO design point of view, but it's suggesting a coding 
style which is unusable for anything bigger than those simple examples 
shipped with the engine.

> > and it is almost impossible search methods to see how they
> > work...
>
> You've got the manual and the API reference for that.
>

The API reference is really quite good. And if you really have to look at the 
implementation, you usually have only to look into the right source file. The 
sources all follow a convenient naming scheme. For the main Ogre classes it's 
Ogre[classname].cpp, for plugins and platform managers the prefix may be 
different, but the basic scheme is identical. Header files are named 
accordingly. I find it really simple to locate a function on Ogre.

If you're still not satisfied you can regenerate the Doxygen API reference 
with source code included. This simplifies browsing the Ogre source code 
quite a bit. Just modify Docs/src/html.cfg accordingly and run makedocs.sh. I 
found this to be really useful in the past.

> > And it seems a bit too windows-oriented...
>
> How so ? I use it on my machine with the official Debian/unstable
> packages without any problem.
>

Ogre itself runs perfectly on Linux. It's practically guaranteed to do that. 
However, quite a number of addons in the ogreaddons collection does not ship 
with proper build systems for Linux and some won't even compile if you're 
going for the naive approach. Most of the Ogre users are windows-centric, 
although the core team isn't. And that shows, unfortunately.

Regards,
Gregor