[Gzz-commits] gzz ./genimages.pl Documentation/Manuscripts/Pa...

[Tuomas J. Lukka]

CVSROOT:        /cvsroot/gzz
Module name:    gzz
Changes by:     Tuomas J. Lukka <address@hidden>        02/11/22 10:23:11

Modified files:
        .              : genimages.pl 
        Documentation/Manuscripts/Paper: paper.tex 
        gfx/demo       : papertest.py 
        gfx/librenderables: renderables.py 
        gzz/vob        : VobScene.java 

Log message:
        Screenshot; first part of Vob tutorial

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/genimages.pl.diff?tr1=1.5&tr2=1.6&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/Documentation/Manuscripts/Paper/paper.tex.diff?tr1=1.61&tr2=1.62&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/gfx/demo/papertest.py.diff?tr1=1.50&tr2=1.51&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/gfx/librenderables/renderables.py.diff?tr1=1.150&tr2=1.151&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/gzz/vob/VobScene.java.diff?tr1=1.16&tr2=1.17&r1=text&r2=text

Patches:
Index: gzz/Documentation/Manuscripts/Paper/paper.tex
diff -u gzz/Documentation/Manuscripts/Paper/paper.tex:1.61 
gzz/Documentation/Manuscripts/Paper/paper.tex:1.62
--- gzz/Documentation/Manuscripts/Paper/paper.tex:1.61  Fri Nov 22 08:39:39 2002
+++ gzz/Documentation/Manuscripts/Paper/paper.tex       Fri Nov 22 10:23:11 2002
@@ -35,6 +35,8 @@
 
 % XXX Mention that these are something like marbled paper
 
+% XXX Ref to xstarfish!
+
 \begin{abstract}
 We introduce unique backgrounds: procedurally generated background textures 
based on  
 node identity,
@@ -336,20 +338,30 @@
 
 \section{Hardware-accelerated implementation}
 
-In hardware rendering, the use of resources is critical
-The two relevant types of resources here are texture memory
-and rendering time.
-
+In this section, we discuss our hardware-accelerated implementation
+of unique backgrounds .
+Our main platforms are NV10, i.e. OpenGL 1.3 + GL\_NV\_register\_combiners,
+and NV20, i.e. NV10 + GL\_NV\_texture\_shader2.
 
+One important goal for the implementation is that it should be easily 
+applicable in a variety of situations. 
+For example, mapping between paper and screen can be complicated,
+e.g.~fisheye. 
+Because of this, we have 
+adapted the OpenGL model: the background ``texture coordinate'' is set
+and then a vertex is rendered using glvertex. If a vertex program
+extension is available, it is used to allow the use of vertex and texture
+coordinate arrays.
 
+This enables the use of distortion inside the nodes.
 
-Performance: zoomability, memory, speed
+\subsection{Resource usage}
 
-Our main platform: NV10, i.e. OpenGL 1.3 + GL\_NV\_register\_combiners,
-and NV20, i.e. NV10 + GL\_NV\_texture\_shader2.
+In hardware rendering, the use of resources is critical
+The two relevant types of resources here are texture memory
+and rendering time.
 
-Using only textures: mapping between paper and screen can be complicated,
-e.g.~fisheye. 
+Performance: zoomability, memory, speed
 
 \subsection{Colors}
 
Index: gzz/genimages.pl
diff -u gzz/genimages.pl:1.5 gzz/genimages.pl:1.6
--- gzz/genimages.pl:1.5        Mon Nov  4 16:42:03 2002
+++ gzz/genimages.pl    Fri Nov 22 10:23:11 2002
@@ -1,5 +1,7 @@
 #!/usr/bin/perl
 
address@hidden = (300, 50);
+
 @not = qw/
 0000000008000000E951C69F2500047B509B19C36307791FF5813EE8F1C5DF461505ED93327A9F
 0000000008000000E951C8305800044FD3E704860499CD06AC4FEF6B8B0232FEAC9548908CD189
@@ -34,13 +36,13 @@
     psystem "perl stripblock.pl $file >$mstmpimg/$resultname";
 }
 
-for $resolution (85, 25) {
+for $resolution (@resolutions) {
 
     for $file (grep {!/$not/} @pdf) {
        $file =~ /b_(\w+)$/ or die "Invalid block name $file";
        $block = $1;
        # First, do into triple resolution
-       $tres = $resolution * 4;
+       $tres = $resolution ;
 
        if(!$do_all) {
            if(-e "$mstmpimg/$block-$resolution-1") {
@@ -51,14 +53,16 @@
 
        $tmpfile = "$mstmpimg/tmp/$block-tmp";
        system "perl stripblock.pl $file >$tmpfile";
-       psystem "(cd ../mstmpimg/tmp; gs -dBATCH -dNOPAUSE -sDEVICE=ppmraw 
-r$tres -sOutputFile=$block-tmp-$resolution-%d.ppm $block-tmp) ";
-       for $image (<$mstmpimg/tmp/$block-tmp-$resolution-*.ppm>) {
-           $to = $image;
-           $to =~ s/-tmp-/-/;
-           $to =~ s/\.ppm//;
-           system "pnmscale -reduce 4 $image | pnmtopng >$to";
-           unlink $image;
-       }
+       psystem "(cd ../mstmpimg/tmp; gs -dBATCH -dNOPAUSE -sDEVICE=png256 
-r$tres -sOutputFile=$block-$resolution-%d $block-tmp) ";
+#      for $image (<$mstmpimg/tmp/$block-tmp-$resolution-*.ppm>) {
+#          $to = $image;
+#          $to =~ s/-tmp-/-/;
+#          $to =~ s/\.ppm//;
+#          } else {
+#              system "pnmtopng $image >$to";
+#          }
+#          unlink $image;
+#      }
        system "mv $mstmpimg/tmp/$block* $mstmpimg/";
        unlink $tmpfile;
     }
Index: gzz/gfx/demo/papertest.py
diff -u gzz/gfx/demo/papertest.py:1.50 gzz/gfx/demo/papertest.py:1.51
--- gzz/gfx/demo/papertest.py:1.50      Fri Nov 15 04:14:20 2002
+++ gzz/gfx/demo/papertest.py   Fri Nov 22 10:23:11 2002
@@ -1,6 +1,7 @@
 from __future__ import nested_scopes
 
 from types import ClassType
+from gfx.libutil import saveanim
 
 # Jython doesn't have boolean. (future?)
 False = 0
@@ -77,6 +78,8 @@
     if k == "f":  # as fork
         MultiPaperScene.has_dual_papers = not MultiPaperScene.has_dual_papers
         print 'Dual papers:', MultiPaperScene.has_dual_papers
+    if k == "p":
+       makeScreenshots()
 
 def dobenchmark(w, vs):
     global benchmark
@@ -410,4 +413,15 @@
 if not globals().has_key("window_resized"):
     window_resized = 1
     w.setLocation(0,0,1200,900)
+
+def makeScreenshots():
+    ps = MultiPaperScene()
+    ps.seed = 199871850
+    ps.initpaper()
+    vs = w.createVobScene()
+    ps.scene(vs)
+    w.renderStill(vs, 0)
+    saveanim.saveframe("shots/multipaper.png", w)
+
+
 
Index: gzz/gfx/librenderables/renderables.py
diff -u gzz/gfx/librenderables/renderables.py:1.150 
gzz/gfx/librenderables/renderables.py:1.151
--- gzz/gfx/librenderables/renderables.py:1.150 Thu Nov 21 07:07:13 2002
+++ gzz/gfx/librenderables/renderables.py       Fri Nov 22 10:23:11 2002
@@ -78,10 +78,42 @@
        "CXX": "GLenum",
        "pre" : (lambda v, p : "GLenum "+v+" = " \
                    "tokenFromJstring(env, "+p+");")
-    }
+    },
+    "float[]" : {
+       "Java": "float[]",
+       "JNI": "jfloatArray",
+       "CXX": "vector<float>",
+       "pre" : (lambda v,p : """
+                       vector<float> %(v)s (env->GetArrayLength(%(p)s));
+                       {
+                           jfloat *f_ = env->GetFloatArrayElements(%(p)s, 0);
+                           for(unsigned i_=0; i_<%(v)s.size(); i_++) 
+                               %(v)s[i_] = f_[i_];
+                           env->ReleaseFloatArrayElements(%(p)s, f_, 
JNI_ABORT);
+                       }
+                       """%locals())
+    },
 }
 
 rs = [
+
+# Here for testing float[], no other purpose
+{
+    "Type" : "1",
+    "Name" : "StupidLinestrip",
+    "Data" : "vector<float> arr;",
+    "Params" : "float[] arr",
+    "ParamCode" : "this->arr = arr; ",
+    "RenderCode" : """
+       glBegin(GL_LINE_STRIP);
+       for(int i=0; i+1<arr.size(); i+=2) {
+           ZPt p(arr[i], arr[i+1], 0);
+           coords1.vertex(p);
+       }
+       glEnd();
+    """
+},
+
 {
     "Type" : "0",
     "Name" : "CallList",
Index: gzz/gzz/vob/VobScene.java
diff -u gzz/gzz/vob/VobScene.java:1.16 gzz/gzz/vob/VobScene.java:1.17
--- gzz/gzz/vob/VobScene.java:1.16      Thu Nov 21 04:52:35 2002
+++ gzz/gzz/vob/VobScene.java   Fri Nov 22 10:23:11 2002
@@ -25,17 +25,65 @@
 
 /** A scene into which Vobs are placed.
  * <p>
- * How should the Vob hierarchy and indexing interact?
- * Which of the following queries need to be efficient?
- * <ul>
- *  <li> Get matching vobs in the whole hierarchy
- *  <li> Get matching vobs in a subtree starting at given vob
- *  <li> Get matching vobs in a particular node of the hierarchy
- * </ul>
- * If only the first one is necessary, separation is simpler.
- * Otherwise, the parent has to be usable as a secondary key always...
- * Hmm... giving the parent index might be workable.
+ * A VobScene is somewhat like a scene graph but has some rather special 
features.
+ * The most interesting special feature is probably the
+ * interpolation between unrelated views, followed by (in the OpenGL 
implementation)
+ * nonlinear coordinate systems.
+ * <p>
+ * The VobScene is an aggregate of objects which perform different aspects of 
its function:
+ * VobCoorder keeps track of the coordinate systems defined in the VobScene,
+ * VobMap keeps track of which Vobs use which coordinate systems
+ * and VobMatcher keeps track of the <i>keys</i> of the coordinate systems.
+ * <p>
+ * For example,
+ * <pre>
+       // create a new coordinate system, at (100,100), with size (100,50).
+       // In this coordinate system, the point (0,0) is mapped to (100,100) on 
screen
+       // and the point (1,1) is mapped to (200,50)
+       int cs = vs.coords.ortho(0, 0, 100, 100, 100, 50);
+       
+       // set key of the coordinate system.
+       vs.matcher.add(cs, "MYVOB");
+
+       // Place a vob into it.
+       vs.map.put(vob, cs);
  * </pre>
+ * places a single vob into a single coordinate system. Now, when generating
+ * the next keyframe, if we do
+ * <pre>
+       // Lower down and narrower
+       int cs2 = vs2.coords.ortho(0, 0, 100, 200, 50, 50);
+       
+       vs2.matcher.add(cs2, "MYVOB");
+
+       vs2.map.put(vob, cs2);
+ * </pre>
+ * The VobScene can be used to generate an animation from vs to vs2, smoothly 
animating
+ * the location and size of the vob (by animating the coordinate system).
+ * The VobScene contains shortcuts for the above code:
+   <pre>
+       vs.put(vob, "MYVOB", 0, 100, 100, 100, 50);
+
+       vs2.put(vob, "MYVOB", 0, 100, 200, 50, 50);
+   </pre>
+   has the same effect as the above code.
+ * <p>
+ * It is perfectly allowable to leave the keys undefined; this simply means 
that the
+ * coordinate systems which have no keys should not be interpolated.
+ * <p>
+ * Coordinate systems can be nested, and here's a difficult bit: there are 
actually
+ * two distinct hierarchies here: the transformations and the keys form their 
own,
+ * separate hierarchies. 
+   <pre>
+       int cs = vs.coords.ortho(0, 0, 100, 100, 100, 50);
+
+       // A translation RELATIVE to cs: the origin of cs_t is at (150, 125) on 
screen.
+       int cs_t = vs.coords.translate(0, .5, .5, 0);
+
+
+   </pre>
+ * <p>
+ *
  */
 
 public class VobScene {