The main difference between Ogre and CS + CEL is that Ogre is a rendering engine while CS + CEL is a game engine.

That is, CS + CEL does not only help you to display 3D objects, but covers many other features such as 3D sounds, physics, animation, artifical intelligence, avatar and camera management, etc. Most of this is possible with Ogre by using external plugins, but all of these plugins are working with different versions of Ogre, and it is not an easy task to get all of them working together. CS + CEL provides all these features in a common framework and is therefore more suited for complex applications such as video games.

So, the choice depends on what you want to do exactly. If you don't need many things other than 3D rendering, then you may prefer Ogre as it has a better community and documentation. But if you plan for a bigger project or a long term usage of 3D content, then CS + CEL is probably more interesting.

I used the term "CS + CEL" because the whole project is actually split in two main sub-projects: the CS SDK with all low-level features, and CEL for the game logic.

Have you checked out the tutorial on using CS with CodeBlocks:
http://www.crystalspace3d.org/main/CodeBlock_Tutorial

For blender2crystal, you can use Blender up to 2.49, but limited to Python 2.5. See the following page for the installation process:
http://leapingcat.org/blender2crystal/index.php/ArtistInstall

I can't tell for the Python version needed for CS, but as you mentioned it is probably a good idea to start using the CS 2.0 candidate branch instead of CS 1.4

Sorry, I'm not able to help you.
But maybe you would try asking your question on the mailing list or the irc, the developers that can probably answer to this are more active on these communication channels.

CS has many features that can be used for that (terrains, water shaders, LODs, etc, etc) but I don't think there has been many flight games made with it.

For a flight game, you would probably need nice clouds. There has been a GSOC on that topic a few years ago, but the system was not finished. You may want to look at it.

Another interesting topic would be the generation of very big terrains (or even planets as you propose). The libnoise library has been integrated recently into CS, it can generate coherent noise functions such as the Perlin noise and can be very useful to generate terrains or planets. There is an example for that in the libnoise web site, this wouldn't be that complex to extend this example to the setup of the CS's terrain system. Another example of Perlin noise has been made by Sueastside who used it to generate animated clouds in the csdemo application.

1. Can it manage high poly characters?

Yes and no. The Krystal animated model has 16 000 triangles and runs at few hundred FPS on my machine. The problem is however that all computations are still made in software while it should be made through hardware. That's one of the topic I expect to work on in the incoming months.

2. Can it support RTS?

Why not? Frank and Mike have worked recently on various improvements of the shaders for the terrain system. It looks really great now and would be a good start for your RTS, along with the water shaders, the foliage and the Level of Details systems.

3. What format does it use regarding models?

CS has its own XML compliant format. You can import your models into this format through the corresponding scripts of Blender, 3DS max and Maya. CS has also an importer to read directly data from the COLLADA file format.

The main classes of the messaging system are in the following file: http://crystalspace3d.org/cel/docs/online/api/messaging_8h_source.html

Each iCelEntity implements the iMessageChannel interface, it can be queried by iCelEntity::QueryMessageChannel(). The property classes then use these message channels to send and receive messages, they implement the iMessageSender and iMessageReceiver interfaces for that purpose.

I have 3DS MAX 2010.

Maybe this is due to that. The documentation of the script says that it has been tested on 3DS 5 and 6. This fact in the documentation may be obsolete and it may work with higher versions, but I can't tell you which ones as I don't have any experience with 3DS.

You first have to convert it to the CS XML format.

You can do it by using the 3DS scripts in "CS/scripts/max" (the documentation for it is in "CS/scripts/max/exporterguide/index.html").

There is also the "3ds2lev" converter application that should have been compiled in your CS directory, but I don't know what is the exact status of this application.

MinGW and MSYS are a set of programs that can be used to have a programming environment similar to what exists on GNU/Linux.

To install it, you have the information at http://www.mingw.org/wiki/HOWTO_Install_the_MinGW_GCC_Compiler_Suite
The info for the MinGW/MSYS installation of CS is at http://www.crystalspace3d.org/docs/online/manual/MinGW.html

Basically, you would need
- download and launch the MinGW/MSYS automatic installer (mingw-get)
- install it (pay attention to not use space or special characters in the installation path)
- choose the right CS library package from http://www.crystalspace3d.org/downloads/cs-winlibs/
- install the package by enabling MinGW/MSYS support when asked for
- MinGW/MSYS should have installed a shortcut on your desktop, this opens a terminal. In this terminal, type:
- "cd /c/PathToCrystal/CS"
- "configure"
- "jam"

There are several domains where CS is clearly lacking documentation. We would need some help to improve that. For example, if you find the information on the coordinate system of the terrains, then you can fix the documentation and provide a patch (for that, either ask for a programmer account or use the bug tracker http://crystalspace3d.org/trac/CS/report).

If you don't find the info you need on the API doc, the manual or the tutorials (http://www.crystalspace3d.org/main/Tutorials), then you may consider looking at the code of the demo applications (eg in data/terrain*). Blender2crystal has also some examples with terrains and portals (http://leapingcat.org/blender2crystal/index.php/Examples).

In last resort, you can have a look at the code of the terrain mesh. The associated XML loader object is also a general good way to find information on the usage of an object.

Your error message is not in english and I don't understand it, although it probably simply stands that the application has crashed. In this case, it is not possible to say what can be the problem if you don't provide more information.

You should use a debugger to look what is happening exactly. A debugger can for example print the backtrace of the error, giving information on the type and the context of the error. If you provide such a backtrace, then we would be able to help you finding what can be the problem.

If I can work out how maps, regions, zones, sectors, cells and portals relate to each other, I think I may be able to come up with at least one way of doing this.

The main environment would be made of one big sector. This sector would contain one terrain2 mesh (see http://www.crystalspace3d.org/docs/online/api/structiTerrainSystem.html).

You would have split the terrain in many cells (that can be loaded separately). You can configure the terrain2 mesh to load automatically in background the cells that are close to the camera.

You can add foliage, rocks and such objects on the terrain by using the mesh generator (see http://www.crystalspace3d.org/docs/online/api/structiMeshGenerator.html).

You can also add bigger objects such as small houses, big trees, etc. These objects would be genmeshes (see http://www.crystalspace3d.org/docs/online/api/structiGeneralMeshState.html). These objects can use either imposters, static or progressive LOD in order to have more details when close to them but still having many of them in view all the time (see http://www.crystalspace3d.org/docs/online/manual/Level-of-Detail.html).

When you want to create a big building or dig a cavern onto the terrain, you would create other sectors and connect them with portals. The sectors would be used to split the big building in small areas that can be loaded separately. Portals are used to go from one sector to another, they are also the main way to create a hole in a terrain (eg for the entrance of a cavern). The default level ('castle') of walktest is a good example of a heavy use of portals (although their exact position should be tweaked).

To actually manage to way all these sectors are automatically loaded and unloaded, you would use the iPcZoneManager (see http://crystalspace3d.org/cel/docs/online/manual/PropClass-ZoneMgr.html and http://crystalspace3d.org/cel/docs/online/api/structiPcZoneManager.html). This manager defines the following concepts:
- map: a sector or a list of entities (eg NPC's)
- region: a list of map (ie sectors or entities) that would be loaded alltogether
- zone: a list of region

By defining how the regions are shared by the zones, you can define how these regions will be loaded and unloaded in background from the memory.

Are there any Windows binaries available so that I can test Crystal Space without having to compile the source and install dependencies?

No, sorry, there are still no binary available.

Crystal Space has many features that could be useful regarding your needs: a terrain system with paging and splatting, a mesh generator for details such as foliage and rocks, many Level Of Detail systems (static LOD, dynamic LOD with sliding window, and imposters), different water shaders and meshes, a portal system which would be helpful for detailed indoors areas, and a threaded loader for the streamed loading of all of that.

In CEL, there is also a world manager (see the iPcZoneManager property class) which stream load the objects depending on the position of the camera. In CEL, there are also some features such as the path finding and the behavior trees which would help building realistic NPC's.

I don't know how well the positioning problem you mentioned in order to avoid the floating point inaccuracies is managed by the iPcZoneManager property class, but this would at least still to be dealt at the physical simulation level.

The branch of the GSOC of the student that was working on Snow Leopard has been merged in trunk yesterday on r34871. It includes some other fixes that you may also want to try.