From e1025c7266c3ff5d905f73879c75ac89335e830a Mon Sep 17 00:00:00 2001
From: Christophe Geuzaine <cgeuzaine@ulg.ac.be>
Date: Fri, 11 Oct 2002 02:10:01 +0000
Subject: [PATCH] add example+explanation for MergeWithBoundingBox
---
benchmarks/misc/low_memory_animation.geo | 53 ++++++++++++++++++++++++
1 file changed, 53 insertions(+)
create mode 100644 benchmarks/misc/low_memory_animation.geo
diff --git a/benchmarks/misc/low_memory_animation.geo b/benchmarks/misc/low_memory_animation.geo
new file mode 100644
index 0000000000..639e2df97c
--- /dev/null
+++ b/benchmarks/misc/low_memory_animation.geo
@@ -0,0 +1,53 @@
+// 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.
+
--
GitLab