Development news: grand rename to "Castle Game Engine" finished, more

1. --viewpoint command-line option was implemented for view3dscene. This allows to choose a different viewpoint as the default (initial) one, especially useful in combination with --screenshot option. As requested on forum.

2. Shadow map generation improved: for shadow maps, we render model with shaders turned off. This is consistent with Variance Shadow Maps (that requires using custom shader, so user shaders are also ignored at shadow map capture). It avoids problems with shaders writing to gl_FragDepth and accidentally breaking shadow map content. Thanks to Victor Amat for pointing this out!

3. The quest to cleanup and improve our examples continues. A lot of them are simplified now (using new TCastleWindow that automatically provides a scene manager instance). Some previous examples were merged and extended into the new viewport_and_scenes/view_3d_model_advanced example.

4. As announced, rename of our engine ("Kambi VRML game engine" -> "Castle Game Engine") will also bring renames to a lot of identifiers. Since we're breaking compatibility anyway, I took some time to really think about new proper names for various stuff (previous names were invented somewhat organically, often without consistency, often following the implementation approach instead of following the typical usage).

   I wrote a document describing in details what renames were done, and what is the reasoning behind them. This may be too much information for some of you, but I hope you appreciate this kind of transparency :) To upgrade your existing programs to new engine version, just do the same renames in your code — both Pascal sources and form resources (lfm), and all will work Ok :)

   In short:

   • Our official prefix for most units is now CastleXxx. No more KambiXxx, VRMLXxx, VRMLGLXxx units. Most of them become CastleXxx, with the exception of concepts defined in the X3D specification: X3DNodes, X3DFields, X3DLexer (many other castle units in fact use or depend on X3D stuff too; the whole engine is based on X3D nodes graph after all).

   • Our official prefix for classes is now TCastleXxx, but preferably no prefix at all. All components get TCastle prefix (these are registered on component palette, so essentially have to live in a global namespace with all other components, so prefixing them is a good idea). Most other classes have no prefix at all, not needed.

     Generally no more TGLXxx, TKamGLXxx, TVRMLXxx, TVRMLGLXxx. They become TCastleXxx (if it's a component) or just TXxx.

     Our most important class, TVRMLGLScene, is now called TCastleScene. This nicely removes the implementation details from it's name (the fact that it's rendered using OpenGL, and uses X3D scene graph inside). These implementation details were really excessive (for an identifier name), because everything in our engine uses OpenGL (and if other renderer will be made, it should be pluggable and will not change the name anyway), and this component can load 3D data in any format (even if internally everything is converted into X3D nodes graph).

   • Control and window names simplified and made consistent: simple control or window is now TCastleWindow or TCastleControl. Descends from TCastleWindow/ControlXxx, adds SceneManager and easy Load method. For most programs/games with 3D world and 2D controls, just use this.