add example+explanation for MergeWithBoundingBox

benchmarks/misc/low_memory_animation.geo

+// Define some general options
+
+General.Trackball = 0; // use Euler angles
+General.RotationX = 30;
+General.RotationY = 10;
+General.RotationZ = -15;
+
+// One can use View.XXX instead of View[YYY].XXX to define general
+// View options!
+
+View.ShowElement = 1;
+View.ColorTable = {Red,Green,Blue};
+
+// Let's load the views one by one:
+
+For i In {0:1000} // we have 1001 views
+
+  If (!i)
+    // we force the bounding box to be the one of the first view:
+    MergeWithBoundingBox "view0.pos";
+  EndIf
+  If (i)
+    // we merge the other views using the same bounding box as the
+    // first one:
+    Merge Sprintf("view%g.pos",i);
+  EndIf
+
+  Draw;
+
+  Print Sprintf("out%g.jpeg",i);
+
+  // and we delete the view:
+  Delete View[0];
+
+EndFor
+
+// Why do we have to play such a game with the bounding box? 
+
+// If you don't load a geometry or a mesh at the same time as the
+// views, the bounding box is only computed at the end of the loading
+// of the main model file (the .geo). This is because a view should
+// normally NOT affect the bounding box of a scene, except if the .geo
+// file is indeed a view... So, without the MergeWithBoundingBox, the
+// bounding box is indeed undefined (well, set to some stupid default
+// value) when we want to draw our views (since this happens before
+// the main file (the script) is completely read)...
+
+// One solution would be to define dummy geometry points in the
+// script. This is not general since we may not know beforehand the
+// bounding box of the view. The correct way to handle this is to use
+// MergeWithBounding box, which forces the computation of the bounding
+// box.
+