/[gzz]/gzz/doc/pegboard/1003/PEG_1003.html
ViewVC logotype

Diff of /gzz/doc/pegboard/1003/PEG_1003.html

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.12 by benja, Mon Sep 2 16:58:42 2002 UTC revision 1.13 by tjl, Fri Sep 6 11:56:36 2002 UTC
# Line 9  Author: Tuomas Lukka Line 9  Author: Tuomas Lukka
9  <p>Hierarchical <tt>VobScene</tt>s need some fixing.<br>  <p>Hierarchical <tt>VobScene</tt>s need some fixing.<br>
10   </p>   </p>
11    
12  <p>Open issues:<br>  <h2>Open issues:<br>
   </p>  
13    
14  <ul>    </h2>
     <li>Is the integer identifier of the coordinate system into which to  
 place  a new coordinate system appropriate?</li>  
     <li>Should plain coordinate systems be usable as those ints?  
        <small>(Benja:) "Plain coordinate systems"?</small></li>  
   
   <ul>  
       <li>What are the semantics there? Current, just translate, is not good.  
  However, using the vob-internal CS is not really nice either, as Vob CSs  
 usually are in pixels, and this would be in 10s or 100s of pixels per unit.</li>  
15    
   </ul>  
     <li>The most general use case is the PP-like viewport. How is that implemented?  
  You need</li>  
16    
17    <ul>  <ul>
18        <li>clipping</li>      <ul>
       <li>separate coordinate system for the motion of the clipping rectangle  
  and the contents</li>  
19    
20    </ul>    </ul>
21    
22  </ul>  </ul>
23   Possible solutions:<br>  <h2>Suggested solution:</h2>
24    Vobs should not have to worry about clipping,
 <ul>  
   <li>Separate clipping from coordinate systems. Currently, a coordinate  
 system defines a clip rectangle. How about specifying the coordinate system  
 to clip to when creating a (any) coordinate system, as well as the coordinate  
 system into whose coordinates the given coordinate system should go.<br>  
   <small>(Benja:) This doesn't serve well in the usual viewport case, where  
          you have:  
          <ul>  
              <li>A thing you want to view (e.g. a PP paper, the contents  
                  of a cell)</li>  
              <li>A place inside that thing where your focus is (you want to  
                  view the stuff around the focus)</li>  
              <li>An area on the screen where you want to show the viewport  
                  (so that the focus is shown in the middle of the viewport,  
                  and as much of the viewed thing is shown around the focus  
                  as fits in the viewport).  
          </li></ul>  
          Calculating the position of the viewed thing relative to the viewport  
          is easier than calculating the absolute position of the viewed thing  
          on the screen: to calculate the position relative to the viewport,  
          you don't need to know the viewport's position, just the focus;  
          to calculate the absolute position on the screen, you need both,  
          essentally translating the focus coordinates by the viewport's.  
          <br><br>  
          Therefore, I think that there is no need to special-case this in  
          the API, as it's easier to do with two nested cs.<br>  
 (Tuomas:) Sorry, I don't follow this argument at all. Could we start using  
 (x,y,w,h) etc. notation, since the verbal description is a bit hard to follow?  
 Even more so, pictures would be good...</small></li><li>A suggested principle: Vobs should not have to worry about clipping,  
25  neither in AWT nor in GL. The current system where a Vob has to set its cliprect  neither in AWT nor in GL. The current system where a Vob has to set its cliprect
26  works for really simple cases but gets inefficient and inconvenient.</li>  works for really simple cases but gets inefficient and inconvenient.<br>
   <li><tt>createCoordsys(int transformedBy, int clippedBy, Object key, ...)</tt></li>  
   <li>0 would be default for both, i.e. no clipping, no transformation.</li>  
   <li>Unfortunately, to get the translate-and-clip effect, you'd need two  
 different coordinate systems:</li>  
   <ul>  
     <li>clipping: the current one (x,y,w,h)</li>  
     <li>transforming: (x-1, y-1, 2, 2) would give the correct one. Of course,  
 we'd have shortcuts for these.</li>  
     <li>OTOH, &nbsp;you could just create the clipping one and give the coordinates  
 explicitly anyway, if that's the meaning; that would work.</li>  
      <li>What are the semantics there? Current, just translate, is not good.  
 However, using the vob-internal CS is not really nice either, as Vob CSs usually  
 are in pixels, and this would be in 10s or 100s of pixels per unit.<br>  
      (Benja:) I think use the parent cs to translate and optionally give a scale  
      when creating the sub-cs, and use the parent for clipping. I think this  
      serves well in the usual case.  
      </li>  
   
   </ul>  
   <li>Clipping would work recursively:</li>  
    <li>The most general use case is the PP-like viewport. How is that implemented?  
 You need  
   
     </li><li>cs1 = createCoordsys(0, 0, ...)</li>  
     <li>cs2 = createCoordsys(0, cs2, ...)</li>  
     <li>would clip by both coordinate systems when cs2 used.<br>  
     </li>  
      <li>clipping</li>  
      <li>separate coordinate system for the motion of the clipping rectangle  
 and the contents</li>  
   
   </ul>  
   
   <p>(Benja:) I thought rotation/scaling? The above is extremely easy to do by  
      putting two cs into each other, the parent being used for clipping,  
      and the child being used for the contents.</p>  
 <p>(Tjl):How would you specify that? You'd have to think about the inner coordinate system relative to the outer, right?</p>  
 <p>(Benja:) Aaah, now we get to the real discussion! Yes, that's exactly what  
             I mean. Now if you can give me a single good case where this is  
             inconvenient and your system is more convenient, you've gone a long  
             way in convincing me of it. <tt>;-)<br>  
 </tt></p>  
 <p>(Tjl:) Easy. &nbsp;Imagine a skewed, perspective coordinate system (i.e.  
 using the homogeneous coordinate transformations of OpenGL). Now imagine  
 e.g. putting an image behind a viewport transformed like that it so that  
 you *don't* want to transform that image. Finding the inverse transformation  
 there is not trivial and requires inverting a 4x4 matrix. It <b>can</b> be done but it's nasty. &nbsp; I can well imagine wanting to do this. Even with just rotations there's too much to worry about.<br>  
 </p>  
 <p>  
 (Benja:) Ok. And you could still do the more usual case where you <em>want</em>  
          to think of the inner coordinate system relative to the outer: you can  
          still put your transformation coordsys inside your clipping coordsys...  
 </p>  
 <p>  
 (Benja:) Hmmm, issue: Before hierarchical coordsys, we used coordsys essentially  
          as bounding boxes for vobs (ok, different in pp, through the (AFAIK)  
          complicated PP viewport mechanism). But a coordsys is actually a cross  
          between a box and a coordinate transformation to you, if I understand  
          correctly: you want to use the vectors inside the coordsys as the unit  
          vectors for transformation coordsys in your hierarchical scheme  
          (meaning that when using OrthoCoorder, you would often create coordsys  
          with width = height = 1, because you do not want scaling).  
          This isn't very elegant, especially because vobs aren't truly  
          (graphically) scaled by changing their coordsys' width and height... Hm<br>  
 <br>  
 (Tjl:) Of course, the API needs changing in that case. Something like<br>  
 </p><tt>/* Get a coordinate system which is translated dx, dy from the given coordinate</tt><br>  
 <tt>&nbsp;* system.</tt><br>  
 <tt>&nbsp;*/</tt><tt><br>  
 int translate(int transBy, int clipBy, Object key, float dx, float dy);</tt><br>  
27  <br>  <br>
28  And so on. Affine coordinate systems would also have <tt>rotate</tt>, and  The suggested API change is in the file coorders.java.<br>
 with that we would actually get rid of the current problem with affine coordsys  
 interpolation as well, where interpolation across a rotation shrinks (since  
 the coefficients go linearly), getting us closer to the semantics. <br>  
29  <br>  <br>
 This takes us closer to a scene graph... maybe that's a good thing. It may  
 be easier to explain to people that Vob coordsystems are nodes in a scenegraph  
 that get identified with nodes in another scene graph.<br>  
 <p>(Benja:) Starts to sound really good, but I don't completely understand yet.  
 Care to propose a full interface (i.e., a list of *all* supported methods)?  
 I think that would help me getting the "big picture" here. (Just giving the  
 method signatures would probably suffice.)  
   
   
 <p>  
   
   
 <br>  
 Transforming and clipping:<br>  
 <img src="d1.png" alt="Showing an example" width="569" height="788">  
 <br>  
   
   </p>  
30    
31       The most general use case is the PP-like viewport. To achieve that, you need
32    
33        
34    <ul>
35    <li>cs1 = createCoordsys(0, 0, ...), the coordinate system of the frame.</li><li>cs2 = createCoordsys(0, cs1, ...), the coordinate system inside.</li><li>would clip by the frame coordinate systems when cs2 used.<br>
36        </li>
37    </ul>
38    Another use case is the cell content. There, <br>
39    <ul>
40      <li>cs1 = createCoordsys(0, 0, ...) the frame coordinate system</li>
41      <li>cs2 = translatedCoordsys(0, cs1, ...) the internal coordinate system<br>
42      </li>
43    </ul>
44    <ul>
45      <li>Note about cells: As discussed in Documentation/TechReports/Graphics,
46    there is a really nasty special case for cell-like things where you interpolate
47    them, changing the aspect ratio. Because of this, the rendering code needs
48    to either 1) look at the external coordinate system, or 2) get more interpolated
49    information. This is something we might want to consider.</li>
50    </ul>
51    
52    
53    <ul>
54      </ul><p>
55    </p>
56    
   <br>  
57    
58  <h2>Coordinate systems</h2>  <h2>Coordinate systems</h2>
59  <p>One thing that is currently not used enough with vobs is the possibility  <p>One thing that is currently not used enough with vobs is the possibility
# Line 185  discussed in the Graphics techreport.<br Line 71  discussed in the Graphics techreport.<br
71  <br>  <br>
72  <br>  <br>
73  <br>  <br>
74  </body></html>  <br>
75    </body></html>

Legend:
Removed from v.1.12  
changed lines
  Added in v.1.13

savannah-hackers-public@gnu.org
ViewVC Help
Powered by ViewVC 1.1.26