[Gzz-commits] gzz/doc/pegboard/1003 PEG_1003.html

[Benja Fallenstein]

CVSROOT:        /cvsroot/gzz
Module name:    gzz
Changes by:     Benja Fallenstein <address@hidden>      02/08/30 10:44:21

Modified files:
        doc/pegboard/1003: PEG_1003.html 

Log message:
        Comment

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/doc/pegboard/1003/PEG_1003.html.diff?tr1=1.9&tr2=1.10&r1=text&r2=text

Patches:
Index: gzz/doc/pegboard/1003/PEG_1003.html
diff -c gzz/doc/pegboard/1003/PEG_1003.html:1.9 
gzz/doc/pegboard/1003/PEG_1003.html:1.10
*** gzz/doc/pegboard/1003/PEG_1003.html:1.9     Fri Aug 30 09:10:17 2002
--- gzz/doc/pegboard/1003/PEG_1003.html Fri Aug 30 10:44:21 2002
***************
*** 11,42 ****
  
  <p>Open issues:<br>
    </p>
!    
  <ul>
      <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>
!        
    </ul>
      <li>The most general use case is the PP-like viewport. How is that 
implemented?
   You need</li>
!        
    <ul>
        <li>clipping</li>
        <li>separate coordinate system for the motion of the clipping rectangle
   and the contents</li>
!        
    </ul>
!    
  </ul>
   Possible solutions:<br>
!  
  <ul>
    <li>Separate clipping from coordinate systems. Currently, a coordinate
  system defines a clip rectangle. How about specifying the coordinate system
--- 11,42 ----
  
  <p>Open issues:<br>
    </p>
! 
  <ul>
      <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>
! 
    </ul>
      <li>The most general use case is the PP-like viewport. How is that 
implemented?
   You need</li>
! 
    <ul>
        <li>clipping</li>
        <li>separate coordinate system for the motion of the clipping rectangle
   and the contents</li>
! 
    </ul>
! 
  </ul>
   Possible solutions:<br>
! 
  <ul>
    <li>Separate clipping from coordinate systems. Currently, a coordinate
  system defines a clip rectangle. How about specifying the coordinate system
***************
*** 115,121 ****
  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>
--- 115,137 ----
  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
  </p>
  
  <p>
***************
*** 149,152 ****
  <br>
  <br>
  <br>
! </body></html>
\ No newline at end of file
--- 165,168 ----
  <br>
  <br>
  <br>
! </body></html>