[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: CrystalSpace vs Ogre3d
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 :
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,
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.