[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gzz-commits] gzz/doc/pegboard/1009 PEG_1009.rst
From: |
Benja Fallenstein |
Subject: |
[Gzz-commits] gzz/doc/pegboard/1009 PEG_1009.rst |
Date: |
Sun, 06 Oct 2002 12:27:42 -0400 |
CVSROOT: /cvsroot/gzz
Module name: gzz
Changes by: Benja Fallenstein <address@hidden> 02/10/06 12:27:42
Modified files:
doc/pegboard/1009: PEG_1009.rst
Log message:
comment
CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/doc/pegboard/1009/PEG_1009.rst.diff?tr1=1.4&tr2=1.5&r1=text&r2=text
Patches:
Index: gzz/doc/pegboard/1009/PEG_1009.rst
diff -c gzz/doc/pegboard/1009/PEG_1009.rst:1.4
gzz/doc/pegboard/1009/PEG_1009.rst:1.5
*** gzz/doc/pegboard/1009/PEG_1009.rst:1.4 Sun Oct 6 12:16:00 2002
--- gzz/doc/pegboard/1009/PEG_1009.rst Sun Oct 6 12:27:42 2002
***************
*** 3,10 ****
=============================================================
:Authors: Tuomas Lukka
! :Date: $Date: 2002/10/06 16:16:00 $
! :Revision: $Revision: 1.4 $
:Status: Incomplete
Transformations
--- 3,10 ----
=============================================================
:Authors: Tuomas Lukka
! :Date: $Date: 2002/10/06 16:27:42 $
! :Revision: $Revision: 1.5 $
:Status: Incomplete
Transformations
***************
*** 26,31 ****
--- 26,39 ----
.. IMPORTANT::
Should 3D scaling be here as well?
+
+ (Benja says:)
+
+ ``scale`` doesn't belong here, because AWT cannot do it properly
+ when text is involved (because text's aspect ratio may change
+ with size).
+
+ (Therefore, 3D scale doesn't belong here, either.)
And into AffineVobCoorder the following functions::
***************
*** 40,45 ****
--- 48,58 ----
Should rotate3D really be there? It extends the capabilities?
Should there be a third interface, ThreeDCoorder?
Or leave it into GLVobCoorder for now, like distort?
+
+ (Benja says:)
+
+ What would rotate3D be for? In our 2 1/2 D world, the z axis
+ is really different from x and y...
Also, for all these functions, we should have a shorthand
in VobScene:
***************
*** 47,73 ****
public int translateCS(int into, Object key, float x, float y);
just to make it a little easier to say them.
For the affine ones, the VobCoorder is cast into AffineVobCoorder, and
the error propagated if it's not.
! Transforming points interactively
! ---------------------------------
It would be nice to be able to easily transform points to and from
coordsystems, since we now have hierarchies. Since the coordsys are
known incrementally, it should not be a problem to provide in VobCoorder::
/** Transform one or more points to screen coordinates from the given cs.
* @param into The array to store the results in.
*/
public void transformPoints3(int withCS, float[] pt, float[]into) ;
/** Transform one or more points from screen to given CS.
* @return True, if a reasonable inverse was found.
*/
public boolean inverseTransformPoints3(int withCS, float[] pt,
float[]into) ;
At the same time, remove VobCoorder.getRenderInfo as unnecessary.
The reason for allowing the array ``pt[]`` to contain several points is
simply performance.
--- 60,105 ----
public int translateCS(int into, Object key, float x, float y);
just to make it a little easier to say them.
+
+ (Benja:) How about just ``translate``?
+
For the affine ones, the VobCoorder is cast into AffineVobCoorder, and
the error propagated if it's not.
! (Benja:) Not sure about error propagation: we need to make sure
! that we can catch the error at a high level and look at it and
! be *sure* that the reason for it is that one view needs an
! ``AffineVobCoorder``, and we also need to know which view, so
! that we can give a reasonable error message to the user. (This
! is the direction into which we need to be moving... because this
! is not a programming error when it happens, it is that a view
! is used in an environment it wasn't programmed for, which may
! happen in a production system.)
!
!
! Transforming points into coordinate systems
! -------------------------------------------
It would be nice to be able to easily transform points to and from
coordsystems, since we now have hierarchies. Since the coordsys are
known incrementally, it should not be a problem to provide in VobCoorder::
/** Transform one or more points to screen coordinates from the given cs.
+ * Each point is represented as three values (x,y,z) in pt[].
* @param into The array to store the results in.
*/
public void transformPoints3(int withCS, float[] pt, float[]into) ;
/** Transform one or more points from screen to given CS.
+ * Each point is represented as three values (x,y,z) in pt[].
* @return True, if a reasonable inverse was found.
*/
public boolean inverseTransformPoints3(int withCS, float[] pt,
float[]into) ;
At the same time, remove VobCoorder.getRenderInfo as unnecessary.
+
+ (Benja:) I think ``inverseTransformPoints3`` should raise an exception
+ if no reasonable inverse can be found.
The reason for allowing the array ``pt[]`` to contain several points is
simply performance.
- [Gzz-commits] gzz/doc/pegboard/1009 PEG_1009.rst, Tuomas J. Lukka, 2002/10/06
- [Gzz-commits] gzz/doc/pegboard/1009 PEG_1009.rst, Tuomas J. Lukka, 2002/10/06
- [Gzz-commits] gzz/doc/pegboard/1009 PEG_1009.rst, Tuomas J. Lukka, 2002/10/06
- [Gzz-commits] gzz/doc/pegboard/1009 PEG_1009.rst, Benja Fallenstein, 2002/10/06
- [Gzz-commits] gzz/doc/pegboard/1009 PEG_1009.rst,
Benja Fallenstein <=
- [Gzz-commits] gzz/doc/pegboard/1009 PEG_1009.rst, Tuomas J. Lukka, 2002/10/06
- [Gzz-commits] gzz/doc/pegboard/1009 PEG_1009.rst, Benja Fallenstein, 2002/10/06
- [Gzz-commits] gzz/doc/pegboard/1009 PEG_1009.rst, Tuomas J. Lukka, 2002/10/06
- [Gzz-commits] gzz/doc/pegboard/1009 PEG_1009.rst, Tuomas J. Lukka, 2002/10/06
- [Gzz-commits] gzz/doc/pegboard/1009 PEG_1009.rst, Tuomas J. Lukka, 2002/10/07