The central TODO file. There are also some TODOs scattered elsewhere,
do "find -iname TODO*" to find them.

------------------------------------------------------------------------------
Next release plans:

------------------------------------------------------------------------------
Next next release plans:

Definitely:
- Blender exporter fixes.
- Make CastleMessages buttons clickable, reported for castle many times.
  In fact, use there our buttons in CastleControls, this would be best.
------------------------------------------------------------------------------
WWW:
- Maybe change demo_models webpage to show screenshots and links to everything,
  like a gallery?
  But then, not everything is self contained?

  Maybe also rework demo_models layout to be more feature-oriented even more?
  Ideally, no vrml_1/2/x3d subdirs at top-level.

- wp-embed? everywhere - vrmleng, michalis?
  http://embedwordpress.com/ - nope, that's more a description how to create wordpress themes...
  I want to easily insert wordpress into an existing php page.
  Something started in /home/michalis/public_html/wordpress/part.php (chantal)

- more stuff to sidebar?
  Maybe view3dscene should have a sidebar, with links to forum,bugs etc.
  Make "donate" place on the sidebar, with links to flattr and fundr?
  (see opengameart for nice example).

* link to https://www.ohloh.net/p/castle-engine/widgets somewhere?
  put a link with "I use it"? And a link to stats (with commit graph?)?

- Add SVN commits google widget (idea from http://scandraid.sourceforge.net/)
  <div style="float:right">
  <script src="http://www.gmodules.com/ig/ifr?url=http://hosting.gmodules.com/ig/gadgets/file/101638777846294812126/2.xml&amp;up_url=http%3A%2F%2Fcia.vc%2Fstats%2Fproject%2Fvrmlengine%2F.rss&amp;up_style=1&amp;up_articles=10&amp;up_date=1&amp;up_size=50&amp;up_sort=1&amp;up_acolor=%2300c&amp;up_color=%23333333&amp;up_ads=1&amp;up_title=&amp;synd=open&amp;w=400&amp;h=200&amp;title=Recent+SVN+commits&amp;border=%23ffffff%7C3px%2C1px+solid+%23999999&amp;output=js"></script>
  </div>
  <!--
  Configure gadget from:
  http://www.gmodules.com/ig/creator?url=http://hosting.gmodules.com/ig/gadgets/file/101638777846294812126/2.xml&up_url=http%3A%2F%2Fcia.vc%2Fstats%2Fproject%2Fvrmlengine%2F.rss&up_style=1&up_articles=10&up_date=1&up_size=50&up_sort=1&up_acolor=%2300c&up_color=%23333333&up_ads=1&up_title=&synd=open&w=400&h=200&title=GSites+RSS&border=%23ffffff%7C3px%2C1px+solid+%23999999
  -->
  (Change it to use castle-engine, if using it.)

vrml_engine_doc:
- move "vrml overview" to the end (maybe an annex or such).
- The tutorial may be pasted as the 1st chapter of vrml_engine_doc, and partially will replace the current
  http://castle-engine.sourceforge.net/vrml_engine_doc/output/xsl/html/chapter.scene_manager.html#section.scene_manager_basic
  ? Or not, just make tutorial as HTML?
------------------------------------------------------------------------------
Mirrors:
- RenderedTexture.scene (let VA know).

- Allow recursive nodes: this is already wanted by
  GeneratedShadowMap.light (when places in defaultShadowMap),
  RenderedTexture.scene, Script.

  Fish demo also needs it to resolve routes.

  What with freeing? Cycles will make ref-counting bad.
  Maybe TVRMLNodeNames should have separate list for stuff that can only
  be weakly-referenced?

- flat mirrors - my approach. Mention on coverflow thread, also for VA.

- Once Material.mirror will be honored for interactive rendering,
  probably the Collada->VRML convertion should be fixed,
  to include "mirror" (as it will be useful then) but allow
  "Save To VRML (without Kambi extensions)" option.

- RenderedTexture: some way for MRT? Notify VAmat.

- RenderedTexture: use non-square texture rectangles. Notify VAmat.
------------------------------------------------------------------------------
Primitives by Proxy more improvements:
- Avoid incremental count +=, set count once in sphere/cone/cylinder/box
  proxy. This will speed them up a little.

- All Proxy* are called twice still, because all the shapes get destroyed
  (3 times?) before loading is complete... We could probably optimize it,
  to not recreate shapes, to save some time (for Proxy and others).

- Implement "Convert to Simpler Node (IndexedFaceSet, LineSet, etc.)",
  that "makes Proxy real".

------------------------------------------------------------------------------
VSM:
- ATI problems on chantal seem unsolvable. We should have some way to blacklist
  VSM on particular GPUs?

  ATI problems on chantal, for the result:
  - Very very slow initialization (huge delay, couple of minutes even,
    when you turn on VSM).

  - Result on sunny_street is a little nonsense, doesn't really work.
    Debugging gen textures: they are already wrong.
    So the trouble happens at generating VSM to float textures.

  - Done: Check: generate to normal 8-bit textures?
    Also wrong. And also slow initialization? WTF?
    Looks like writing from shader gl_FragCoord.z isn't really working on my radeon?

  Works fine on Radeon czarny, and NVidia kocury.
  So this is really a problem of old Radeon GPU on chantal.

- Unclean implementation, introduces some exceptions to normal work:
  - Using special RenderingCamera.Target = rtVarianceShadowMap feels unclean.
    It would be better to pass to Render() something like [dsDoNotControlShaders]?
  - Inventing special CustomShaderAlphaTest is unclean,
    and it means that VSM only really works when the 0th texture has alpha channel.

- Eventually, in the future, make DefaultVarianceShadowMaps as true.
  But this waits for VSM improvements, otherwise projected_spotlight clearly
  shows that VSM has problems with accuracy. See papers improving VSM.

- Allow to set anisotropic filtering for shadow maps, makes sense for VSM.

- try VSM with multisampling on FBO - GL_EXT_framebuffer_multisample, czarny supports it, chantal too
  Should work already (we use fbo multisampling when necessary), remains to test?

------------------------------------------------------------------------------
Scene manager / controls / better Lazarus integration:

- right after running vrml_with_2d_controls, it seems TCastleOnScreenMenu is focused,
  but should not. Hm, what should be focus by default?
  calculated based on initial mouse pos? But switching FullSize
  and such must also change it?

* TODO at TCastleAbstractViewport.Camera: allow one camera instance be shared
  by a couple of viewports/scene manager. Also fix multiple_viewports then.

- Also use TButton in terrain to place "open image" near the slider?

- For later, something like KeyPreview for viewport would be useful
  to split-screen games, to catch keys (but not mouse clicks) regardless
  of mouse position (to handle keys from both players at once, assuming
  not conflicting). So, actually (since TCastleViewport will decide about it)
  TCastleViewport.KeyPreview is needed.
  Maybe just make TUIControl.KeyPreview property?

  Note: normal handling of keys in OnKeyDown would not be enough here,
  since keys could be catched earlier by any TUIControl?

  Maybe TUIControl.KeyPreview simply changes KeyDown/Up interpretation:
  when KeyPreview = true, then control gets key events regardless of mouse
  positions. This is trivial to implement and should be enough?

- Make XML .x3d format, loaded to any T3D (list, translated, anim, scene...)
  Make a load method to load this.
    It should also be capable of loading any TCastleScene, TCastlePrecalculatedAnimation
    (so it has to be somewhere depending on OpenGL).
    Maybe just in TCastleSceneManager.Load?

- some more free notifications could be useful:
  - FreeAndNil(FMouseRayHit) when it's triangle is destroyed (e.g. octree rebuild)
    or any 3d object along the path is removed from the Items hierarchy
    (not necessarily destroyed!).

    For now, this isn't a problem, because
    1. nothing uses FMouseRayHit.Triangle afterwards
       (only TCastleSceneCore.MouseMove uses it, but this is immediately after
       RayCollision was done).
    2. Some stuff 3D objects are removed from the scene manager at the end
       (try e.g. mouse over touch sensor in touch_sensor_test in view3dscene,
       then ctrl+w). We know we only use ItemsAndCameraCursorChange,
       we just track free notification of FMouseRayHit3D.
       (instead of all on MouseRayHit.Hierarchy.)

  - TWalkCamera.AboveGround should be freed when triangle is destroyed.

* Let RenderingCamera use some Camera reference, maybe make TSimpleCamera to avoid
  overloading it with full camera props for temporary camera settings?

* Lazarus: make the control painted at design-time?

* Maybe make a news item and a few screenshots how to easily use it from Lazarus?

- Make TCastleControlCustom.Controls list settable from the IDE,
  to allow visually adding new TUIControls there.

  At designtime, warn on error: do not put > 1 camera in Controls list,
  while it works it's usually nonsense.
  Or not: old shadow_volume_test showed that it's possible to have two cameras,
  and things work smoothly. You just have to assign non-conflicting keys.

  Started in kambipropsedit. Need to figure out and debug how to
  correctly deal with TListPropertyEditor, or eventually write your
  own property editor for this.

- Make sure most useful props of our controls are settable:

  For TCastleOnScreenMenu, browse and decide which ones (Items?).

  TCastleSceneCore.CompiledScriptHandlers (will require some designer to settable from IDE)
  TCastlePrecalculatedAnimation.FileName, implement similar to TCastleSceneCore.FileName.

  For cameras generally, what Init method takes should be settable.
  For cameras generally, Input_Xxx properties.
  TWalkCamera: CameraInitialPos/Dir/Up (how are settable from IDE?)
  TExamineCamera: ModelBox (how are settable from IDE?)
  Gravity, CameraRadius, CameraPreferredHeight, OnMoveAllowed, OnGetCameraHeight?

- make icons for our components.
  Same style cameras (black with dotted lines):
    Walking man icon for TWalkCamera,
    Rotated box for TExamineCamera.
  Same style areas:
    TCastleControlCustom
    TCastleControl (maybe use the same image, with just a text "OpenGL" or "GL"
      on one, "VRML" on other)
  Needed ideas for TCastleOnScreenMenu.
  For TCastleConfig use some slightly modified icon of TXMLConfig, since this is almost the same?
  For TLazRecentFiles use some slightly modified icon of TMainMenu or TPopupMenu.

* TCastleSceneCore (no GL) on a Lazarus palette? Confusing with TCastleScene, but is also useful.
------------------------------------------------------------------------------
- basic networking support
(I want to have full coverage of X3D "Interactive" with some release).

- Improve EditableTransform proto:

  A 2nd plane sensor would be useful? At some angles, plane sensor behaves bad.

  Rot sensor - on teapot, even initial very small drag rotates it too much,
  see demo_models/x3d/cubemap_generated_recursive.x3dv
------------------------------------------------------------------------------
view3dscene 4.0:
- JavaScript (http://besen.sourceforge.net/
  or http://code.google.com/p/fpcjs/ (SpiderMonkey?))

- Maybe Python or Lua scripting too?

- OpenGL ES, Android? (This would also suggest engine 3.0.0 bump.)
  With complete shaders pipeline of course.

- Mac OS X dependencies and packaging fixes
  - bundle doesn't run, why? (we attach to running x now)
  - add to bundle that we handle x3dv / wrl etc (see Linux mime list?), with our icon
  Rest from http://castle-engine.sourceforge.net/macosx_requirements.php#section_help_wanted

- networking (at least http URLs) support

------------------------------------------------------------------------------
Shadow maps todos:
- Point light sources.
- Implement auto-calc of DirectionalLight:
  SFVec4f  [in,out]  \codeem{projectionRectangle} 0 0 0 0
  SFVec3f  [in,out]  \codeem{projectionLocation}  0 0 0
- ProjectedTextureCoordinate: when using viewpoint:
  - use near, far projection correct values (used by browser)
  - for currently bound perpective viewpoint, my spec says we should honour
    fieldOfView and aspect ratio of current window?
- For PCF bilinear:
  - we should turn NEAREST shadow map filtering, no point in bilinear then

------------------------------------------------------------------------------
Various ideas:

- A precise control over how steep hill you can climb.
  This is actually already done for player, Camera.ClimbHeight settable
  by X3D avatarSize.

  Do it also for creatures. Right now creatures can climb high
  (almost-vertical) walls.
  This is not so very noticeable now, because there are no high walls
  now, and creatures' AI doesn't let them fall into deep pits now.

- screenshot (per year contest?): http://vcg.isti.cnr.it/cgf/index.php

- demo_models/x3d/import_export.x3dv fails
  on view3dscene load+save test (run_tests.sh).

  That's because TX3DImport.SaveToStream doesn't bind the
  ImportedNodeAlias, like

    { When writing the contents back to stream, bind the name,
      otherwise ROUTEs using this name cannot be saved.

      Note we don't have here the actual ImportedNode reference
      (because when saving inline node, we do not collect names from an inline
      content, because we do not save inline content --- this could be a huge
      time eater, only to make this case faster). So we just pass nil. }
    (NodeNames as TVRMLNodeNames).Bind(nil, ImportedNodeAlias);

  Except, our code isn't really ready for the node = nil case.

  Postpone for later: correctly saving stuff with IMPORT clauses
  is too minor usage.

- http://www.web3d.org/x3d/specifications/spec_feedback/ - wait for ack
  6 times nurbs,
  2 times import/export.
  Hastened by email, still no ack.

* Use http://wiki.lazarus.freepascal.org/class_extensions_examples .
  We already depend on FPC >= 2.6.0, so should be fine now?
  This will be greatly useful :)

* Remove ScheduleChangesAll.
  Just like DoGeometryChanged: everything should be automatically generated,
  and ChangesAll only invalidates stuff, making it inexpensive.

- view3dscene: edit->add viewport here command (asks for viewport name to put in description),
  adds viewport to menu,
  this viewport will be saved to file

- display column / line numbers in vrml lexer errors.
  (Not so difficult if we assume it works only for Windows/Unix, because scans only for #10. Make it as an optional (boolean property) for reader. Measure downtime, maybe enable by default for vrml lexer?)

* CastleMessages scrollbars:
  http://www.useit.com/alertbox/20050711.html

- Joerg pointed out possible problem with quads for NurbsSurface*:

  Ah, I understand now, and that's also why the problem is visible with
  symmetric surfaces... Thanks, will do some testing, maybe eventually
  I'll add a field to IndexedQuadSet like tesselateIntelligently:SFBool to
  force tesselating quads into 2 tris by intelligently choosing a dividing
  edge (to make it shortest). This would force correct look of all
  IndexedQuadSet, including NurbsPatchSurface.

- Only on x86_64: GLU tesselatator is ultra-slow.

  So loading anything with a 3D Font takes some time (around 4-5 seconds per font; while it's instanteneous on 32bit). 3D Font is right now used only by VRML Text node, no program initializes TGLOutlineFont directly.

  The slowness can be seen e.g. in castle when loading ("credits" model has 3D fonts). Or in view3dscene when opening any file using font, like x3d/cubemap_generated_in_dynamic_world.x3dv. Extreme case is demo_models/vrml_2/text.wrl: all 9 fonts used, loading time is 37 seconds.

  This is also a blocker for making "welcome scene" in view3dscene using Text font.

  The slowness is in Cache.Fonts_IncReference.
  Not reproducible on 32 bit (fpc 2.2.4 kocury/linux/32), so it must be some 64-bit problem.
  The slowness is inside gluTessVertex in TGLOutlineFont.Create. Which means I cannot do anything about it? It's the GLU tesselators that are much slower on x86_64, it seems.

  One solution could be to cache the tesselated result. I could even compile the cached result into the program, this way user doesn't have to do it at all.
  Trouble: is it really helpful in the long run? I would like some time to load fonts from TTF files and then runtime tesselation is a must. And then caching helps, but not for the 1st tesselation run...

  Idea: not tesselating all letters would be useful?
  This would be a valid optimization (needed in the long run anyway, for Unicode fonts I wouldn't want to tesselate all characters at loading anyway).
  For now, possibly I would just need basic ASCII support, so not all 256 characters need to be defined?
  Done: we use only a subset: SimpleAsciiCharacters. 4-5 and 37 seconds measures are with this already enabled... so it's working, but it's still slow.

- view3dscene: rest of nurbs:
  finish X3D nurbs component up to level 2, update vrml_impl_status about it.
  Remaining:
    CoordinateDouble
    NurbsTextureCoordinate
    NurbsSet

- Improve collisions player<->creatures and player<->items to
  check not only final collisions, but also segment collisions when moving ?
  Otherwise when moving fast (or low FPS count, so SecondsPassed large),
  this collision check can fail to work.

  This doesn't seem to be a problem in practice, in practice moving speed is
  not so large (unless running on some ancient GPU with 1 frame per second,
  but there the game is not playable anyway...).

- do weather (I have snow and rain from my szklane_lasy, but they look poor...)

- weapon-less attack (does knockback + small damage)

------------------------------------------------------------------------------
Handle Cg?
Handle CgFX format, that allows to express multiple techniques and rendering passes:
- http://http.developer.nvidia.com/CgTutorial/cg_tutorial_appendix_c.html,
- OGRE also handles it,
- http://http.developer.nvidia.com/GPUGems/gpugems_ch36.html

------------------------------------------------------------------------------
Occlusion culling:

- Test on castle using OcclusionQuery.

- make TRenderParams.StencilTest be used also to pause (not update visibility) in hierarch oq, it would be a waste of temporal conh to not pause there.

- if tests show hierarchical is much better than UseOcclusionQuery,
  old UseOcclusionQuery may be removed (and this may be renamed
  to just UseOcclusionQuery). (Or keep old UseOcclusionQuery only
  for seminar.)

- make nicer interaction OctreeFrustumCulling (use it for frustum checks in
  UseHierarchicalOcclusionQuery).
  And with RenderFrustum_Frustum^, right now we just take it.

- UseHierarchicalOcclusionQuery ignores blending for now.

- this strange thing on bzwgen level, that always shown yellow block, although it should be normally visible afterwards. What's with it? Fixed now?
  No, it still exists.

- tree may be very very poor for shapes. E.g. atcs. This also makes hierarch culling perform badly.
  Hmm, I see why the octree has a lot of duplication on regular_labirynth, although how to improve? Possibly some bottom-to-top scan that turns off octree planes where all children are the same?
  For now, I can add dummy box to the regular_labirynth to force octree be correct.
  For atcs, how to fix?

- Various rendering targets, and "inshadow" for stencil, should just have a separate occlusion query state. This will allow to use oq for all situations, unlike current where oq is done normally only for non-shadowed with target = rtScreen.
  See TODO in CastleScene.pas about this too.

------------------------------------------------------------------------------
Victor Amat list (overlapping with mine, so let's go with it):
  - Note that to use it, you would also need to know the current screen
    size, how about adding outputOnly events to X3DViewpointNode that return
    screenWidth, screenHeight as SFInt32?

    Hm, bs contact has "eventOut SFVec2f windowSize", although I don't know on wha node.
    http://www.bitmanagement.com/documents/BS_Contact_VRML_june2006.pdf

TGLTextureStorage
    (2D - just a single GLuint for GL_TEXTURE_2D,
    video - TVideo, sequence of GLuint for GL_TEXTURE_2D,
    cube - ...
    3D - ...
    depth)
  TGLTextureNode can choose any TGLTextureStorage (maybe at runtime) as storage
  Possibly helpful for DDS mipmaps/compression impl?
  This would mean TGLTextureStorage is in GLImages, not only for GLRenderer.

- multitex:
  - remaining MultiTexture.mode ("MODULATE*_ADD*"),
  - MultiTexture.function field

Because of caching AlphaChannelType inside renderer, and using Renderer.PreparedTextureAlphaChannelType for calculating UseBlending, this means that if the same tex filename occurs in various ImageTexture nodes, and in one case we force it to have alpha different the auto-detection says (e.g. using alphaChannel "FULL_RANGE" to force full range on texture without alpha channel), then all texture occurences have the same alpha channel treatment. (alphaChannel field doesn't work correctly).

skd kreski na water w water_reflections_normalmap (both nvidia and radeon show this). Any relation to steep parallax mapping aliasing?

ImageGLInternalFormat should use symbolic names, not numbers!
(Check, since which OpenGL version?)

Dynamically changing camera radius may be implemented (along with decreasing camerapreferredheight, decrease cam radius?)

OpenEXR notes:
http://http.developer.nvidia.com/GPUGems/gpugems_ch26.html

- why on cubemap_generated_recursive.x3dv the reflections between two cubes
  have some pink color left when cube faces are exactly opposite each other?
  See TODO in cubemap_generated_recursive.x3dv

Zaimplementuj streaming dla OggVorbis.

There are still some rough situations when camera "shakes" when going around the corners with wall-sliding on castle_hall. Seems wall-sliding is done, but with somewhat bad direction?

- dyn ao:
  - use float textures
  - add to make easily usable from the engine?

S3TC:
- (minor) image_identify cannot display info about S3TC compressed images
- (minor) glViewImage can open s3tc compressed images, but it cannot be the 1st image on command-line (since opengl context is not ready then yet, so no decompressor initialized)

- Maybe make an option to make the GeneratedCubeMapTexture (and RenderedTexture?) grayscale? Useful since default tex mapping in VRML standard says that only grayscale should modulate, RGB should decal. And sometimes grayscale only modulated by tex color may look just better?
  Hm, for RenderedTexture it's already in the spec: dimensions field has "components" number, default 4, but (I guess) may be 1,2,3 as well.
------------------------------------------------------------------------------
octree todos moved for after view3dscene 3.2:
- remaining TODOs about octrees:
  - Shapeoctree.pas: we make box from sphere, and transform the box

  - CastleSceneCore.pas:
    There is still rebuilding with OctreeDynamicCollisions (it just happens
    on much smaller sets). Implement actual updating.

- also now the first octree update during CollisionCheck = false doesn't release the octree
  hm, that's actually somewhat good, as previous approach with "first octree update releases octree" was a little confusing for users (although it was for efficiency)

- some programs using currently okDynamicCollisions could be happy enough with okCollidableTriangles (malfunction, lets_take_a_walk, grep for rest). For now, keep using okDynamicCollisions, to compare speed eventually (okDynamicCollisions should be as well fast), maybe in the future drop to okCollidableTriangles?

  hm, not necessarily, on castle ssDynamicCollisions is slightly faster, except at the end of "cages" level. profile this particular case?

  finish castle testing and allow ssDynamicCollisions there for good?

- can we somehow fix precalculated anims now too for collisions?
  fix view3dscene docs then,

- add fields to make object->object and object->avatar collisions work somehow.
  (Right now, only avatar->object collisions are done.)

------------------------------------------------------------------------------
- TCastleSceneCore.Shapes tree, with switches/lods approach,
  may be also used to efficiently implement layers now.

- http://www.libpng.org/pub/png/pngvrml.html finish:
  with RGB Textures Color Mode->GL_REPLACE
  Still missing:
  - on palette opaque: PNGs with grayscale palette are not detected as grayscale (so do not blend with mat color)
  - on 8bit opaque: JPG is not detected as grayscale (can jpg be grayscale?)
  - pallette translucent:
    again not palette PNG detected as grayscale, so are not mixed with color
    GIF with gray palette not detected properly, why fully transparent?
  - 8bit translucent:
    again JPG is not detected as grayscale (can jpg be grayscale?)
    grayscale + transparent shade again fully transparent, don't know why?
  - 16bit translucent:
    again grayscale + transparent shade again fully transparent, don't know why?

- Make TGLApplication TCustomApplication one day?
------------------------------------------------------------------------------
large TODOs:
- First of all, I planned to make a new game at the beginning of next year, with draft title "human programming"

- Plane mirror support in OpenGL for Material.mirror field (porting to
general renderer the code from
castle_game_engine/examples/plane_mirror_and_shadow)

- Simple networking (support for http:// and such in view3dscene)

- Scripting in JavaScript (using spidermonkey after fixing
http://delphi.mozdev.org/ for recent fpc)

- And then physics engine and X3D rigid body component
  http://www.xj3d.org/extensions/rigid_physics_examples.html
  file:///home/michalis/doc/web3d.org/X3DPublicSpecifications/ISO-IEC-FDIS-19775-1.2-x3d_spec_edition_2/Part01/components/rigid_physics.html

- Particle engine.
  Following X3D spec.
  Would be great to be able to export Blender particle engine to it.
  Use ARB_point_sprite.
------------------------------------------------------------------------------
Shadow volumes finish:
  - allow multiple lights. This requires
    adding light contributions, so using blending --- this was problematic
    when shadow receivers could use blending themselves. Now it'll
    not be a problem.

    Do this by using receiveShadows, X3DLightNode.shadows fields
    --- common with SMs.

  - shadowVolumes and shadowVolumesMain: test headlight (or close to it)
    casting them, like a torch.
    Should actually work already, just
    add a light source to something 3d relative to player, like a torch?

  - ForceZFarInfinity - implement it also for ortho there.

  - VRML browser shadows don't actually do SV culling, since there's only one scene.
    We should make SV culling on shape level too, settable by some option?
    Hm, but not really possible with current impl --- we take all edges,
    from the whole scene, so we lost the separation into triangles.
    (OTOH, whole scene must be manifold, not necessarily one shape).
------------------------------------------------------------------------------
- prt: implement on shaders.
  Instead of our own radianceTransfer field, pass through vertex attribute nodes
  (except, it doesn't fit any vertex attribute node for now?).
  Remove radianceTransfer field, OnRadianceTransfer callbacks.

  make this easily usable by VRML authors, that is make it's rendering more integrated and available also from e.g. view3dscene

------------------------------------------------------------------------------
after view3dscene 3.0:

- fix extensions to all be gracefully declared by EXTERNPROTO,
  post to Joerg from white_dune

Using StringSensor Make it possible then to load new image file in castle_script_edit_texture.x3dv

------------------------------------------------------------------------------
MatrixTransform fix:

Joerg:

To decompose to translation / rotation / scaling / shearing you can use
unmatrix.c from graphics gems.
What is impossible, is to reconstruct Transform.center and
Transform.scaleOrientation from a matrix 8-(

Michalis:

Agreed, it's possible (when matrix is reversible at all; but then even normal Transform node can be non-reversible with scaling to 0 in some dimension). I found the http://tog.acm.org/GraphicsGems/gemsii/unmatrix.c source, thanks, I'll try to understand it and plug into my engine. It'll be useful for some cases, when now I use dummy algorithms that can only extract scaling and split into rotation/translation rigid body transformation.

------------------------------------------------------------------------------
Things for much later:
- some things, like InsidePrototype, should actually be now properties
  of the whole stack (not state). This is good, even excellent --- smaller
  state means less copying, and this is what we wanted.

  Hm, but this means that copying target should be some descendant
  of state (we want to have these InsidePrototype values in each copy).
  Copy target is just a snapshot of stack state --- stack will be now
  stack of states + some integers managing stack themselves.

  Too unimportant for now... It would be a very small optimization of
  memory and time. Most time spent on state copying is on dyn lights
  and transforms copying, saving 3 * sizeof(int) wouldn't help much.
  For now resigned.

  Hmmmmm, OTOH, moving Inside* to the stack properties will avoid
  making a changing the stack top item, thus preventing whole stack
  copy-on-demand... could be a good thing, if copy-on-demand would be
  done? (but it's not, right now, as was seen rather useless...).

  Postponed / half resigned.

- When some day we will modernize font_to_pascal, it would be nice
  to also generate font data into .font_data, similar to .image_data,
  to not confuse ohloh statistics.
------------------------------------------------------------------------------

macosx glViewImage -dRELEASE fpc 2.4.0:
  tiling on demo_models/textures/17_gris_... looks bad.
  Start screen tiling works fine.

  Images on kambi_lines are also broken the same way.

  glViewImage: view kambi_lines/images, with and without tiling, various erros.
  Seems radeon things line alignment is bad, and/or pixel format is bad,
  and it jumps eating too many/too few bytes per image row.

  On linux 32 bit (nvidia on kocury, and radeon on chantal) all works fine.
  So -> radeon on macosx opengl bug?

------------------------------------------------------------------------------
Transforming VRML graph:

Since vrmlshadowmap set a precedent, maybe do also others?

- Proxy
- parallax bump mapping could be impl better by a transformation too?
Hm, but I don't see a way to do a transformation like current shadow maps
in a way that is fast AND preserves current VRML graph:

  Consider you want to reuse the same node as exists (like IndexedFaceSet),
  but change it's children (like texCoord), and additionally you
  want to insert it's children into new children (e.g. you want to
  place new MultiTextureCoordinate in existing IndexedFaceSet.texCoord,
  and move existing IndexedFaceSet.texCoord inside MultiTextureCoordinate).
  Basically, using existing nodes as children of new nodes is not a problem,
  but using existing nodes as parent of new nodes is a problem.

  1. If you want to just make transformed VRML graph, then every parent
     will have to be duplicated --- this is a lot of data, e.g. coordIndex
     fields are long.

     The only way to make it work would be to make fields not attached
     to one node, so that they can be shared. But this is going to complicate
     the implementation a lot... (look at how current assumption that
     TVRMLNode may be inside many TCastleSceneCore causes a lot of problems).

  2. Or we have to decide at which point "anchor" these parents,
     for example: anchor at the "geometry". This works for current "Proxy"
     idea, but doesn't seem workable for shadow maps:
     we want to "anchor" at texCoord, and at Appearance.shaders,
     and at Appearance.texture...

     So we would need a general way to split a node, so that we can
     "anchor" our new nodes anywhere.
     Evey field could get alternative version: the processed one.

     Hmmm, this would require a lot of work to be comfortable.
     Every FdXxx should be a function that returns something else
     when Transformed=true...

  Given this, maybe it's better to just stick with current approach?
  "Proxy" field is managed through TShape.Geometry.
  bump mapping is managed inside vrml renderer, not as vrml transformation.
  and shadow maps for now just change the graph?

------------------------------------------------------------------------------
X3DNodes:
- optimize fields send() with direct value, no need for temp field usually?

- Eventually, moving all non-abstract nodes out of this unit
  could be nice. But
  1. for now, stuff that is inside TX3DGraphTraverseState.LastNodes
     must be defined in this unit
  2. I don't know if this is really good for users --- it adds
     another unit to your uses clause.

- Make Detail_ parameters (slices, stacks, cube divisions)
  depend on object's distance from viewer. But there is a problem:
  we need those parameters defined
  when implementing Vertices/TrianglesCount and Triangulate.

- I would eventually like to simplify HandleTransform, to avoid the need
  for traversing Shapes tree simultaneously with nodes. This is a little
  shaky, as we have to carefully synchronize it with the way ChangedAll
  constructs a Shapes tree.
  But not possible now:
  - But it needs fixing Traverse to be able to traverse also non-active graph
    parts. (This isn't difficult, problems below are more difficult.)
  - But ShapeLOD.LODInvertedTransform needs to be updated.
  - But ShapeTransform.TransformState(StateStack.Top.Transform) still needs to be updated.
  - But ProximitySensorInstance.InvertedTransform needs to be updated.
  Resign?

- TransformSensor: need to make separate shapes subtree for every X3DGroupingNode?
  What else?

- StaticGroup: would avoid the need for separate subtree for Transform etc.
  nodes? Worth the complications?

- Better TVRMLNode creation:
  - Make Scene constructor parameter? Load procedures may set it to nil (scene Load will change it anyway), but in many other cases Scene should be taken (from parent nodes). A node may be contained only within the specified Scene, or (when Scene = nil) inside many static scenes.
  - Remove NodeName from TVRMLNode constructor?

ScreenEffect ideas/TODOs:
- glDisable(GL_TEXTURE_RECTANGLE_ARB); // TODO: should be done by glPopAttrib, right? enable_bit contains it?
- test gradient trick from hdr: to increase perceived contrast,
  detect wide edges and make a gradient to lighter the light part,
  and darken the dark part.

MovieTexture:
- ffmpeg player from
  http://scandraid.svn.sourceforge.net/viewvc/scandraid/src/trunk/gui/ffmpeg.pas?revision=179&view=markup
  http://scandraid.svn.sourceforge.net/viewvc/scandraid/src/trunk/external/ffmpeg/
  integrate?

H-Anim:
- use skinNormal too.
  Interpolate skin normals, not recalculate them each time.
  This is what should be done according to seamless3d? reread http://www.seamless3d.com/hanim/index.html
- THAnimJoint translation (and scale, and others besides rotate?) is vs humanoid center?

Sound:
- Add sound volume control to view3dscene on toolbar.
  Show only when SoundEngine.ALActive?

- Possible extensions:
  Maybe: ext to make footsteps sound (default, and based on ground texture?)
  Maybe: to control listener sound (does instantreality have such thing?)

Renderer:
- Updating TGeometryArrays is still not optimal, because even
  when VboToReload is not full, Generator still allocates and calculates
  all the arrays. We don't reload them all to OpenGL, but they are still
  calculated and waste time for TVRMLArrayGenerator.

  Only parts of TGeometryArrays should be regenerated --- not possible
  with current TVRMLArrayGenerator, we'll have to make
  TVRMLArrayGenerator descendants work like "components", that is inserted
  into the generation, so each TVRMLArrayGenerator descendant
  like TColorGenerator is independent from others.

  Maybe split TGeometryArrays into three, following TVboType.

- optimization to render IndexedFaceSet using GL_QUADS is easy now,
  detect in 1st pass that only quads,
  and later set gpQuad.
  Check speedup.

  But is it useful? ElevationGrid uses smart triangles.
  Restore quads in ElevationGrid, and then check speedup.
  If large -> make ElevationGrid use quads back.

- Make bitmap font rendering faster, and modern: use textures,
  not glBitmap.

- on Windows (czarny) Radeon, some problems with
  view3dscen --screenshot 0 a.png chess.x3dv
  (no problems on other models?)

- Completely remove the need for TGLRenderer.Prepare.
  We don't use display lists anymore, we can just prepare everything
  inside TGLRenderer.RenderBegin.
  In fact, TCastleScene already calls Render to prepare arrays/VBOs.
  We should let and prepare everything else this way, along the rendering.

- We'll have to switch to analyzing shapes for 2-manifold, to port our shadows
  extensions (from SM) to shadow volumes?
  Not just whole scenes?

- Maybe implement options to convert TGeometryArrays to non-indexed version
  with only tgTriangles (no strips, quads etc.), and then remove
  the Triangulate method? (As then simple iteration over TGeometryArrays
  is what you want.)

- Improve raytracer to use INormal (smooth normals), ITexCoord (load and use
  textures).

- ~/sources/castle-engine/trunk/demo_models/shadow_maps/primitives.x3dv
  has invalid texture coords copied.

  This is currently harmless and is silently
  ignored, because CopyCount may be smaller than Count.
  It can be observed by changing
  to make EAssignInterleavedRangeError when Count <> CopyCount
  (not only when it's > CopyCount).

  Reason: both proxies (over-triangulate and not) are used,
  and invalid texcoord is copied, see TODO in X3DShadowMaps.pas.

------------------------------------------------------------------------------
Shaders:

More shaders demos, for some day:
- fog volumetric extend: light shafts through fog.
  How to make automatically light map in 3d?
  Add rects, and bake them --- maybe make a Python script in Blender for this?

- rain drops making waves on water - like humus demos,
  also http://www.youtube.com/watch?v=-yxnETZ6RZk&NR=1 for inspiration

- light source: some different light equation model
  (look e.g. at blender light model names, something sensible?)
  plug that modifies (replaces?) light contribution

- Refraction - voronoi glass

- particle engine fun. Maybe particle engine on gpu using plugs?
  Or just implement particle engine, and allow shading it using plugs?

- Extend water demos: use noise for heights of vertexes too.
  For now not critical: we have shown that it can work (combination
  of texture_animate_noise and water effect). We also have shown that
  it will be slow (water effect by noise is already slow,
  and texture_animate_noise only runs on NVidia).
  No point in doing this, as it will not be practical, and we have already
  prooved that it can work.

- Generate bump mapping (normals) by ShaderTexture.
  Resign? You can just make an effect overriding fragment_eye.

  Is there a reason to allow this functionality with direct ShaderTexture
  placed in normalMap, by plug like PLUG_texture_normal?
  Probably not so much, esp since our normalMap is only our extension.
  Resign.

- water_no_shader improve: place normals MovieTexture as bump map.
  Allow using MovieTexture for normalMap.
  I could improve bump mapping to use MovieTexture as normalMap,
  but it will not help immediately for water_no_shaders,
  as my bump mapping depends on 0th texture to set to normal
  texture that has 2D coords.
  This depends on bump mapping normalMap improvements:
  define special tex coords for bump mapping, don't reuse 0th texture unit.

- moonlight in a train (metro):
  - texture with night sky and large moon, casted by light (just like fancy_spot)
  - cast if through windows of a metro
  - make metro (or light source) move, thus making shadows move through.

------------------------------------------------------------------------------
Finish removal of VRML / Kambi from everything inside the engine,
things that can be deferred to much later:
- Maybe rename vrml_engine_doc and files inside to avoid "vrml" inside name?
  But not now --- it's centered on vrml anyway now.

  Together with this, also rename ./demo_models/vrml_engine_doc_simple_examples,
  also rename www/htdocs/vrml_engine_doc dir

- Rename also VRML/X3D extensions with Kambi inside name?
  Or just add alternatives, with Castle prefix or no prefix, to keep compatibility?
  TKambiAppearanceNode 	X3DNodes
  TKambiHeadLightNode 	X3DNodes
  TKambiInlineNode 	X3DNodes
  TKambiNavigationInfoNode 	X3DNodes
  TKambiOctreePropertiesNode 	X3DNodes
  TKambiTriangulationNode 	X3DNodes

------------------------------------------------------------------------------
Various:
- Make cameraXxx output events available from something like CameraSensor?
  Current extensions, Viewpoint,
  http://castle-engine.sourceforge.net/x3d_extensions.php#section_ext_viewpoint_camera_matrix
  are not always comfortable...

  Q: Maybe ProximitySensor is actually better?
  A: No, ProximitySensor suggests it's
  used only when camera is close to something. CameraSensor doesn't need
  such checks, it just always works.

  Suggested docs:
    The CameraSensor node returns information about the current camera.

    Design notes: This node is deliberately separate from a Viewpoint node. In VRML/X3D, there is always a single (or none) current ("bound") Viewpoint node. During the lifetime of VRML/X3D world, you can change the current Viewpoint node from one to another. This is uncomfortable if you want to *always* capture a matrix from a camera used for rendering (for example, if you want to route cameraMatrix to a uniform shader value):

    1. You would have to create ROUTEs from *all* Viewpoint nodes. This is very uncomfortable, especially if your shader is in a completely unrelated file (like a library of prototypes for appearance) than your viewpoint node (which is usually in model-specific VRML/X3D file).

    2. Also, sometimes we don't render from any viewpoint: when making off-screen rendering (used when generating textures for GeneratedCubeMapTexture, GeneratedShadowMap, RenderedTexture), we may use a camera that doesn't directly correspond to any viewpoint node. (See the description of "cameraMatrixSendAlsoOnOffscreenRendering" at Viewpoint.)

    Using a separate node for this, CameraSensor, that *always* receives camera matrix events (regardless of which, and if any, Viewpoint node is bound, and regardless if we make off-screen rendering or not) is more comfortable and natural. CameraSensor is similar in this sense to ProximitySensor, that also observes the camera inpependently of a Viewpoint node.

  Q: Actually HLSL / Cg For Direct 3D already specifies a couple
  of "magic" uniforms names. We could use them too?
  A: No --- there are some things (like "model") that I don't want to put now.

  Q: Maybe also add "position", in global coordinates, regardless of Viewpoint
  position.
  A: Yes, this could be useful.

- Also add to above CameraSensor events that return:
  - current calculated field of view horizontal/vertical
  - window width/height
  - near/far values (how to pass far = infinity? Possibly as 0 or -1?)
  Notify VAmat.

- Display warnings about unused attribute only *once*, not every frame
  (e.g. replace attr name to invalid inside demo_models/shaders/attributes.x3dv).

  For now, we do this successfully for uniforms, see demo_models/shaders/warnings/shader_invalid_uniforms.x3dv.
  For this, we just remove the invalid uniform (not adding it to
  EventsObserved, removing from UniformsTextures or OnReceive,
  as appropriate for the moment when we detect it's invalid).

  But for attribs, it's not that simple, as TGeometryArrays gathers attributes,
  and we have no nice place to mark the attribute as invalid.
  Marking appropriate VRML node as UniformInvalid would already require
  some code, and be unclean anyway (because validity needs to be reconsidered
  when shader url changes).
  For now, postpone.

- headlightNode has more promises:
  Allow to make headlight shadows by just shadows=TRUE.
  Add headlightMove (or headlightTranslation).
  Add headlightOrientation.
  Test interesting headlights.

  Also, to make headlight cast shadows by shadow volumes,
  MainLightForShadows should choose from BaseLights (after they are initialized)
  + MainScene lights.

- UseGlobalLights: rendered lights may come now from different scene
  with different translation (through T3DTranslated). This means
  that comparing light location vs radius may be wrong, since we fail
  to apply translation of T3DTranslated.

  How to fix? T3DTranslated must be able to change translation
  without the need to recalc anything, so we cannot keep TLightInstance
  with local positions inside each scene (besides, things like headlight
  and global lights should not really be treated as "belonging" to any scene).
  So we have to pass scene transformation to renderer, that will translate
  things like ShapeBoundingBoxWorld into world coordinates for testing
  with lights in WorldCoordinates.

- Our current check for texture[0..1] for shadow() should not be needed
  for SpotLight, as long as projectiveAngle is default or smaller than
  spot cutOffAngle (or maybe cutOffAngle / 2, see spec).

  It's still needed for DirectionalLight and weird cutOffAngle.

  Although, do we really save time by removing this check?
  The idea is that check for tex coords in [0..1] is not needed,
  because spot cutoff with multiply by 0 the result of shadow() anyway.
  But if a real conditional instruction is done, then this check can avoid
  a useless texture lookup. So wasting time on this check may be good,
  as we save time on avoiding texture lookup in many cases.
  Depends on GPU. Test, see if / where it's worth.

- normal fog doesn't work on kocury nvidia (volumetric and explicit fog is Ok)
  with shader pipeline.
  Replacing gl_FogFragCoord with custom kambi_fog_frag_coord doesn't help.

  Weird, as explicit fog shows that fog type linear is Ok...
  I can also assign kambi_fog_frag_coord to const, like 50.0, and then it works.

  So something must be bad when setting kambi_fog_frag_coord from vertex_eye.z.
  Defer for later, some driver bug.

- Dynamically changing BaseLights will cause a slowdown, as the new shaders need
  to be prepared. This shouldn't happen in the middle of the game.
  Concerns: lets_take_a_walk and castle thunder effect.
  Concerns: turning on/off headlight.
  Maybe also solution could include solution to shadow volumes, that for now use PassIndex.
  Full solution idea:
  - Allow calling PrepareResources([prRender]) repeatedly meaningfull
    (currently, RenderDone makes the 2nd call NOOP, otherwise it takes too long).
    Call it with various possible BaseLights, like thunder, no thunder etc.
  - Allow keeping prepared shaders for longer, not only when they are needed.
    Will need some UnloadShaders command or such.
  Defer for later (not 2.5.0), this is only a problem for shader pipeline with
  dynamic lights (like thunder or headlight). Not a problem for view3dscene,
  unless you design VRML/X3D lights that blink (and then, our above solution
  will have 1-time slowdown anyway; we cannot prepare for every possible
  VRML/X3D lighting configuration, just in case).

- Prepare shaders (and everything else) in PrepareRender by *actually*
  rendering a dummy triangle. Otherwise, merely linking the shader doesn't
  seem to always initialize it. That is, currently "if PrepareRenderShape = 0 then"
  then we stop before actually binding VBOs and rendering --- well, maybe
  we should not?

  Example (not reproducible anymore) was on room_parallax_final demo,
  or really any 3D model with complicated shaders on shapes not immediately
  visible. Only when you turn the camera to look at them, you get slowdown
  and you feel that shaders are actually prepared. (Although our PrepareResources
  took care to link *all* shaders at first call, but it's just not enough
  to initialize shader.)

  This is somewhat mitigated in practice now, through sharing shaders,
  so there's a smaller chance that you don't see some shader and it has to be
  prepared later. But this is just a coincidence, works for simple scenes.

  Rendering the shape into a hidden buffer (or just directly, as BeforeDraw
  will be overridden anyway) may be a good solution.
  Others use / suggest it too to bring the stuff actually loaded to GPU:
  http://developer.amd.com/media/gpu_assets/ATI_OpenGL_Programming_and_Optimization_Guide.pdf
  http://www.gpgpu.org/phpBB2/viewtopic.php?p=6100&sid=8da4dfe88523858a837e5f57a936b0b1 (about textures, but still)
  Defer for later.

- Better controls for bezier_surraces/design example,
  more intuitive (allow drag with mouse). Maybe just change it to use VRML/X3D NURBS surfaces?

- NURBS sometimes go wild, on demo_models/surface interpolator?
  Some numerical error in some case?
  Not in 3.8.0 (fpc 2.4.2)
  In 3.9.0 (fpc 2.4.0), 3.10.0 (fpc 2.4.4), and current 3.10.1 (fpc 2.4.4).
  At least it doesn't seem like FPC bug.
  This is seen on kocury. Not present on chantal? Check. Maybe some nvidia bug?

- Release binaries for win64 some day?
  All our binaries tested and work on win64, snapshots done for win64.
  It remains to get external libs (libpng, zlib etc.) for win64 and package them.
  For now, postponed --- no need to, as our 32-bit releases work on win64
  flawlessly too, with the same speed?
  Unless someone wants it (speak up on forum!).

- try do limit fps by vsync, like ogre does
  http://www.ogre3d.org/docs/api/html/classOgre_1_1Root.html#Ogre_1_1Roota34 :

    displayFrequency 	Refresh rate in Hertz (e.g. 60, 75, 100) 	Desktop vsync rate 	Display frequency rate, for fullscreen mode
    vsync 	        true, false 	                                false 	                Synchronize buffer swaps to monitor vsync, eliminating tearing at the expense of a fixed frame rate
    vsyncInterval 	1, 2, 3, 4 	                                1 	                If vsync is enabled, the minimum number of vertical blanks that should occur between renders. For example if vsync is enabled, the refresh rate is 60 and this is set to 2, then the frame rate will be locked at 30.

  Looks like implementation is trivial, just use
    http://www.opengl.org/registry/specs/SGI/swap_control.txt
    http://www.opengl.org/registry/specs/EXT/wgl_swap_control.txt

- When an EXTERNPROTO cannot be loaded, we still read it's fields.
  But when saving, looks like we assume that SFBool default is false etc.
  In such case (when an EXTERNPROTO cannot be loaded) we should instead
  remember that default value isn't known, and every field that has it's value
  set in input VRML/X3D should be saved back.

  *But do not save other fields*, i.e. if field is not explicitly set in VRML/X3D
  file then it cannot be saved back (as the class will then have boolean at default
  false, but we actually do not know the value of this field --- only that it's
  equal VRML/X3D proto default).

- Anchor URL expanding: currently LoadAnchor just opens original Url.
  It's not expanded (which would be pointless, as our PathFromWWWBasePath
  expands only dir, not really Url).
  Plan:
  - the Url should be expanded, to take into account base WWWBasePath
    which should be URL (not just a file-name).
    Eventually it should add file://.
  - if final Url contains file:// (because it was specified by user,
    or because the filename was relative and base Url was a file://
    on disk) then we should open it by OpenDocument, not OpenURL.
  - this should be done together with handling 3D models from real URLs.

- Current PointingDeviceXxx is sensible for "the castle" activation
  stateless "click and forget" activation. Activating stuff not under
  mouse is stupid then (why should all 100 creatures be notified
  about mouse click, transformed to their local coordinate system?)

  But it's not so sensible for stateful X3D activation. If you're over
  item, you want to be notified when this ends. If you're active with
  something (mouse pressed), again you want to be notified when this ends.
  We workaround this now by adding MainScene as a fallback, but this
  is workaround:

  1. if other T3D will have TouchSensor and process events,
     it will not always receive correct notifications when isover/isactive
     should end.

     This is not an issue now, because other T3D items (other than MainScene)
     do not really use sensors.

  2. when things intercept activation, by setting "result := true"
     because some message was done, it's possible that even MainScene will
     not receive them when neeed.

     This is not an issue now, because we "the castle" 3d items
     only "handle" stuff on PointingDeviceActivation with Active=true.
     So we only intercept mouse down clicks, which is Ok, since mouse down
     when mouse is not over any sensor would not have any effect anyway.

  Seems that a real solution is to introduce a list of 3d items
  that should be just always notified about mouse events. Something
  that can not intercepted (because item is not under mouse, or because
  something else set "already handled").
  Maybe all scenes with ProcessEvents := true? (but that's too much,
  since even interpolator animation will require ProcessEvents := true...).

- Merely moving (awsd) instead of rotating makes no MouseMove,
  so MouseRayHit.Distance stays the same even if you get closer to object.

  Update MouseRayHit in each camera changed?
  But do PointingDeviceMove only in MouseMove.
  How to avoid on MouseMove updating MouseRayHit needlessly 2 times
  (once from MouseMove, once from CameraChanged).

- followers component,
  see also x3d mail about new nodes
  http://www.hersto.net/VRML/DampersHowto/?lay=2
  http://www.web3d.org/x3d/content/examples/Basic/Followers/Stocker_06_Followers.pdf

- Dragging camera mistakenly starts also when dragging over buttons (like "Open" in view3dscene):

  For now solved by MouseDraggingStarted. This is not 100% guaranteed, as it is not guaranteed to get MouseUp always paired with MouseDown. When I press the mouse button over a viewport, and hold it pressed, and move mouse from a viewport over a button, and release the button over a button... then viewport (and so, camera too) will not get MouseUp. So MouseDraggingStarted will not be cleared.

  Although it works for view3dscene and many other demos, as viewport has FullScreen=true there so it always catches MouseUp.

  Full solution one day:
  - Buttons should not allow other controls underneath to process mouse events. Affects our OpenGL-drawn TCastleButton (and TCastlePanel too, and maybe others in CastleControls). Right now they allow others to handle MouseMove, Update underneath (only MouseDown, and sometimes MouseUp, is blocked). Hm, but this flexibility is useful sometimes: when pressing keys like arrows over buttons, it is Ok and useful that they are passed to viewport (and camera) underneath.
  - Maybe we should improve MouseUp to *make the above guarantee 100% true* also? Because the MouseDraggingStarted mechanism is sensible, and will stay too.

  So the full fix is not obvious, not trivial, and not really needed now.

- Add sharing of Proxy results for Sphere, Cylinder and such, to make memory usage
  of them smaller?

  roomarranger/manor test model memory usage:
  - ~400 MB is allocated during Load3D, reading TX3DRootNode.
  - ~400 MB goes for proxy shapes.
    Almost 200 MB for TCylinderNode proxy.
  - ~50 MB is added by the rest of Shapes tree, so it's not much.

  Possibly also do not create octrees for primitives?
  We could just resolve them simpler, by simple ray vs sphere etc. tests.
  But tests show that it's not memory or time eater.

- Compile gtkglext statically on Linux for view3dscene?
  Or not --- it's communicated nicely on www page that you need to install it now.
  When it will be packaged in popular distros, this issue should disappear.

- Readd scene manager to component palette?

  It was removed at 3.0.0 (when we break compat anyway) because it's
  included in TCastleControl after all, and should be usually configured there.

  Using TCastleSceneManager also actually requires using TCastleControlCustom,
  so if keep TCastleSceneManager is readd -> also readd TCastleControlCustom.
  Which means that it's confusing: palette would contain TCastleControl,
  TCastleSceneManager, TCastleControlCustom, while in 99% of cases only the
  1st should be directly used.

  Wait for finishing our demos and tutorial for 3.1.0 release,
  rethink this then?

  For 3.0.0 release: removed them from component palette for now.
  This way, in case I decide to keep them later, I will just add them back.
  In the reverse case (if we would keep them now, but remove later),
  we would break compatibility ---- which would be bad, as 3.0.0 already breaks a lot.

  Remove todo notes in castlecontrol.pas and castlescenemanager.pas
  when this is decided.

- Import blender models directly?
  http://code.google.com/p/gamekit/downloads/detail?name=AnimKitSrc_r1007.zip

  The question is, is it better to make blender->x3d convertion inside my code,
  having my own .blend reader?
  Vs. extending existing (awful, over-complicated in some places
  and lacking basic features for animations in other places)
  x3d exporter in Python. Eventually, we can always make our own.

- Input_PointingDeviceActivate polish for castle1 (if needed for castle2):
  - Input_PointingDeviceActivate in interacts (badly?) with key repeat.
    Keeping "e" pressed with activate/deactivate TouchSensor repeatedly.

    Can we avoid it? CastleScene already does check
    "FPointingDeviceActive <> Active". So we already check it, to avoid
    reacting to repeated PointingDeviceActivate(true,...).
    The problem is, GTK and Xlib send us keyup + keydown automatically?
    So no way to avoid it (unless some hacks with timeouts to counteract
    key repeat)? Or use some special flag in GTK and Xlib to detect when
    KeyUp is "bogus", and should be ignored (right inside CastleWindow
    implementation; outside code can then handle/or not repeated KetDown).

    Do it, if will be problematic for castle 2.

  - Make sure interact key input (PointingDeviceActivate)
    is always blocked for MenuBackground?
    Or maybe allow input for MenuBackground, maybe this will be actually useful?

- make gamma correction.
    Windows: http://www.delphi3d.net/articles/viewarticle.php?article=gamma.htm

- Messages: mouse over yes/no message boxes should work (reported by many
  usability tests on castle1 --- rudy, Kasia, Eric, Circular (laz forum)).

- (kasia usability test on castle1) items should automatically hide if they were uncovered by automatic show ?
  Users usually don't know immediately how to close them, and play
  with items list visible for a long the time, cluttering the screen.
  Maybe automatically hide items after some time without using
  (no [, ], pickup or Enter used). This way "i" (when items are visible)
  becomes a shortcut to hide items quick, but eventually they'll hide
  anyway.

- mouse look:
  - (Eric, castle1) I just saw one problem: when you switch (alt+tab)
    to other window, but the game window remains visible on the desktop,
    then the mouse is hidden when you mouse over the game window
    (even though the other window has focus).

  - (kasia usability test on castle1) when fps is low, and no fullscreen, the mouse sometimes gets
    outside of the window.
    This causes additional problems, since then it's easy to
    accidentaly switch to other program while playing the game.

- (Eric castle1) Display frequency can be changed, but is 60Hz by default,
  has to be changed by hand and is not hardware's optimal value

- "Color depth" and "Display Frequency" are ignored on non-Windows targets.
  (Seems that judges and most people test on Windows, so no time (it's already 4th May)
  to do this for Unix (xvf86mode) now.

  "Display Frequency" should be definitely possible using xvf86mode,

  "Color depth" --- I'm not sure.
  Looking at xvidtune and gnome-display-properties : no such possibility.
  Possibly color depth is not switchable without restarting XWindows ?

------------------------------------------------------------------------------
Shaders:

- Allow shadow map generation plugs.
  I would like to also develop a solution that can be applied to both non-VSM and VSM shadow maps. For example, I would like to transform objects by GLSL in such way that their shadow is also transformed (which means that the transformations must work also when rendering to the shadow map texture), regardless if you use VSM or not.
  So user-supplied shaders have to be combined with browser-internal shaders (at least for VSM), so probably enhancing my idea of http://castle-engine.sourceforge.net/compositing_shaders.php will be good here.
  Also, it should be possible to override value stored in shadow map.
  Notify VAmat.

- Implement passing the rest of coords through geometry shader, to make
  our "robust" geometry shaders (by geometryVertexXxx function) really work
  with every normal X3D rendering feature.
  Most important stuff is passed now:
  - tex coords are passed
  - colors are passed, for color from material or unlit case
  - castle_vertex/normal_eye is passed, lighting works
  But some minor (seldom used) stuff is left not passed.
  Grep "varying" in glrenderershader.pas, see also TODO in template_add_light.glsl.

- Test cellular texturing by funny distances:
  more weight to horiz, more weight to left.
  Maybe mail to cellular texturing chapter author, with thanks and link to my phd?

------------------------------------------------------------------------------
Lights rendering:

- make TLightInstance a normal class, and TLightInstancesList only keeps
  references to instances.
  This would simplify some code (like light renderer comparisons),
  and make copying it simpler.
  But it would also create a need to store and free references
  --- at TNodeX3DLightNode?

- Eliminate remaining glLight usage. Allow using TVRMLGLLightsRenderer
  for all objects, following vrml_engine_doc promises.
  Remaining only three cases:

  ./castle_game_engine/examples/vrml/plane_mirror_and_shadow.lpr:325:    fixed-function pipeline rendering (by glLight, used by DrawFloor). }
  ./castle_game_engine/examples/vrml/plane_mirror_and_shadow.lpr:329:  glLightv(GL_LIGHT0, GL_POSITION, LightPosition);

- Make lifetime of lights renderer longer. At least, for whole rendering
  from a scene manager (so 1 lights renderer for 1 TCastleSceneManager.Draw call).

  Then: maybe even make it global,
  and just track all light for the GL context lifetime? But this is more difficult,
  we currently assume that equal transform and equal node reference
  means nothing changed. What if light node contents changed? We would have
  to invalidate it from CastleSceneCore changes.

------------------------------------------------------------------------------
Examples reorganizations / improvements, more ideas:

- Maybe create research/ subdir for
  """These are programs that research new ideas, that *may* be in time incorporated into the engine itself. They sometimes use relatively internal parts of the engine."""
  Add there dynamic_ambient_occlusion,
  shadow_fields,
  radiance_transfer,
  plane_mirror_and_shadows,
  maybe more?

- Make a Lazarus demo when you build X3D graph, dragging node names etc.

------------------------------------------------------------------------------
SSAO:
- Normals available for screen effects in the future.
  Notify JA.

  Best: a way (using compositing shaders) to output to extra buffer
  in fragment shader.
  And then, a way to pass this buffer as texture for ScreenEffect shader.
  IOW, make this extensible, useful for any screen effects, to hold any values.

- Use real projnear/far (but they seem worse, more visible on fountain
  less on ja rooms, than hardcoded 1/1000?)
  See castlescenemanager.pas todo.

------------------------------------------------------------------------------
T3D improvements possibly postponed for later releases:

(These are things not necessarily planned for 3.1 release, unless something else
will turn out to need them.)

- We lost --debug-no-creatures feature of castle1.

- Add inventory to T3DAlive some day, to allow creature to carry items.

- CloseDirectionToPlayer generalize, to just give Target: T3D
  (watched for free with notifications) that is tracked.
  This will also be useful for player, to make some sort
  of "homing" missile.

- Maybe rename Xxx to MyXxx, and rename MyXxx to just Xxx
  (for T3D collision routines for AI).

- Future: T3DMoving change into something that can also rotate the objects
  standing on it (e.g. if you stand on a spinning table).
  Maybe also scaling (e.g. if you stand on an inflating cushion?).

- In a future it would be cleanest if MoveCollision would take as params
  just other T3D instance, along with some move description (move vector?).
  This would allow to handle self-collisions (current DisableCollisions),
  and also missiles HitsPlayer (once player is T3D) and HitsCreatures cleanly?
  Hm, for now, this just means adding Collider parameter to all collision
  structures... something that DisableCollisions variable tried to avoid?

- Maybe add GetVisible or GetBlocksView, and use it inside RayCollision
  and SegmentCollsion with LineOfSight=true.
  Currently we call in such cases just GetExists,
  which is a weaker check than GetCollides.

- <prepare_resources> simplify:
  - Some creatures are dependencies of others,
    like ThrownWeb from SpiderQueen or BallMissile from Alien.
    There should be no need to specify it every time when you use this creature
    on level.
    This dependency is already recorded (as FireMissileName) inside resource.xml,
    so it's just a matter of making a method like T3DResource.AddOtherResources
    (returns boolean if anything new added)?
  - There should be no need to specify creature that is initially placed
    on the level already.

- Automatically smooth between various creature states.
  I.e. expand the idea of StandToWalkAnimation, for every combination
  and make it automatic.

  "The Rift" actually already implements it.
  Use it (and also, then, use our creature system in "The Rift"?)

  Problem: long load times ("Loading creatures...") and memory consumption.

- creatures:
  -  footsteps sound
  - "first time sees player" sound (or maybe "sees player after long time
    of not seeing", with configurable delay)
  - creature avoiding falling down sometimes doesn't work like it should
    on castle1.
    I think that I know why: I check where the creature will be after
    2 secs, but what if there is a pit between 2 secs and current pos ?
    Fix by checking everything *along the 2 secs way*.

------------------------------------------------------------------------------
Load / save game ability:
- Place load in the start menu.
  Place save in the game menu.
  In the game menu, when asking before "End Game", do question
  like "Do you want to save the game before ending ?"
  with answers "Save and end the game", "Don't save and end the game", "Cancel".

  When loading game, load saved Notifications for this game.
