Re: CrystalSpace vs Ogre3d

[Francesco Orsenigo <xarvh@xxxxxxxxxxxxxxx>]

Frédéric Lopez:
[cut]
>  For your problem, see for example :
> http://www.ogre3d.org/phpBB2/viewtopic.php?t=10161&highlight=own+config+file
Great... I could not find this when searching on the forum.
Thanx.

>  > 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
Not what i need.
I'd just need to feed the engine with generated heightmap and textures.
And maybe change the heightmap run-time.
I'm digging into the code.

>  Compiling is not particulary slow on my machine. I don't understand what
>  you mean by "most of the programming is made inside headers".
On mine is.
Since most code lies inside headers, it must be compiled at every 'make'.

>  > and it is almost impossible search methods to see how they
>  > work...
>  You've got the manual and the API reference for that.
To see how they're coded.
However, it seems just a matter of experience.


>  You can find many good tutorials and articles on the Wiki. Fact is 3d
>  game programming is not an easy task. If you are not prepared to invest
>  some time in it, you won't go very far...
I know.
This is why i was looking for the simpler one.
The problem is investing time on something that is not what you need.
I'm asking here for this reason.

>  Yep, I did try OGRE and found it very nice, I really don't understand
>  why you don't like it. In case of a problem, take a look at the Wiki,
>  search or post messages in the forums or ask on the IRC channel. The
>  OGRE community is very helpful.
I like it, but i was wandering if it was the right choice, if it was worth 
further investiment of time.



==========================================================
Gregor Mückl:
>  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.
I'll have a try.

>  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.
I'm doing that... digging inside the TerrainSceneManager, but i didn't 
consider writing up my own... This could be a good idea.

>  The Ogre example applications are indeed written in a fashion that - quite
>  stupidly - puts all of the interesting code into a single header file.
[cut]
Not only that.
I already got rid of the ExampleApplication.h
Ogre is made up of 2Mb of headers and 2Mb of .cpp files.
Half of the actual code is stored inside headers, and must be compiled every 
time.
I was thinking about wrapping the code so that i could compile all ogre stuff 
only once and then just link it.
Ok, i need an upgrade.

>  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.
Maybe is just my inexperience with OOP;

>  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.
Iteresting, i'll try that.


Thanx,
Francesco Orsenigo