[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gzz-commits] gzz/doc/pegboard 1009/PEG_1009.rst 1010/PEG_101...
|
From: |
Tuomas J. Lukka |
|
Subject: |
[Gzz-commits] gzz/doc/pegboard 1009/PEG_1009.rst 1010/PEG_101... |
|
Date: |
Sun, 06 Oct 2002 13:24:00 -0400 |
CVSROOT: /cvsroot/gzz
Module name: gzz
Changes by: Tuomas J. Lukka <address@hidden> 02/10/06 13:24:00
Modified files:
doc/pegboard/1009: PEG_1009.rst
doc/pegboard/1010: PEG_1010.rst
Log message:
answer
CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/doc/pegboard/1009/PEG_1009.rst.diff?tr1=1.8&tr2=1.9&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/doc/pegboard/1010/PEG_1010.rst.diff?tr1=1.2&tr2=1.3&r1=text&r2=text
Patches:
Index: gzz/doc/pegboard/1009/PEG_1009.rst
diff -c gzz/doc/pegboard/1009/PEG_1009.rst:1.8
gzz/doc/pegboard/1009/PEG_1009.rst:1.9
*** gzz/doc/pegboard/1009/PEG_1009.rst:1.8 Sun Oct 6 12:52:16 2002
--- gzz/doc/pegboard/1009/PEG_1009.rst Sun Oct 6 13:24:00 2002
***************
*** 4,11 ****
=============================================================
:Authors: Tuomas Lukka
! :Date: $Date: 2002/10/06 16:52:16 $
! :Revision: $Revision: 1.8 $
:Status: Incomplete
Transformations
--- 4,11 ----
=============================================================
:Authors: Tuomas Lukka
! :Date: $Date: 2002/10/06 17:24:00 $
! :Revision: $Revision: 1.9 $
:Status: Incomplete
Transformations
***************
*** 44,72 ****
layout, because *the aspect ratio changes*, as I have said above.
You *cannot* assume that you can scale below the view level in
AWT.
And into AffineVobCoorder the following functions::
int rotate(int into, float degrees);
- int rotate3D(int into, float degrees, float x, float y, float z) ;
int scale(int into, float x, float y, float z);
.. IMPORTANT::
Should we add default implementation of rotate?
- .. IMPORTANT::
- 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...
-
- (Tjl:) Well, have you looked at fillets demo? We don't always
- want to keep in a 2 1/2 D world. Sometimes 3D is nice.
- But maybe best to leave it to GLVobCoorder.
-
- (Benja:) Ok.
-
Also, for all these functions, we should have a shorthand
in VobScene:
--- 44,61 ----
layout, because *the aspect ratio changes*, as I have said above.
You *cannot* assume that you can scale below the view level in
AWT.
+ (Tjl:) I didn't make my point clear. We *can* do this,
+ if we ask, at vobscene construction time,
+ how tall a given cs will be.
+
And into AffineVobCoorder the following functions::
int rotate(int into, float degrees);
int scale(int into, float x, float y, float z);
.. IMPORTANT::
Should we add default implementation of rotate?
Also, for all these functions, we should have a shorthand
in VobScene:
***************
*** 74,105 ****
just to make it a little easier to say them.
- (Benja:) How about just ``translate``?
-
- (Tjl:) Want to make sure it's not interpreted as "translate this
vobscene".
-
- (Benja:) Hmmm... ok... ``translateCS`` just seems hard to write.
-
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.)
!
! (Tjl:) How about UnsupportedOperationException? Hmm..
! or a subclass of that, NotAffineCoorder
!
! (Benja:) Subclass, because a) we need to store the view in
! the exception, and b) ``UnsupportedOperationException`` is
! raised by *many* things, not safe to use at all.
!
Transforming points into coordinate systems
-------------------------------------------
--- 63,73 ----
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. A direct cast is not permitted;
! the functions must check ``instanceof`` and then throw
! NotAffineVobCoorderException, which is a subclass of
! UnsupportedOperationException.
Transforming points into coordinate systems
-------------------------------------------
***************
*** 116,139 ****
/** 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.
-
- (Tjl:) One that requires catch() or one that doesn't?
- I don't really like the exception either way: a pseudoinverse
- (closest to real inverse) can be well-defined.
-
- (Benja:) Hm. So is the method supposed to return ``true``
- if the inverse that was found is real? Then need to change
- javadoc: a pseudoinverse is "reasonable" IMHO. On the other
- hand, if there are cases where no usable inverse can be found,
- we need the exception (not sure which type).
The reason for allowing the array ``pt[]`` to contain several points is
simply performance.
--- 84,98 ----
/** 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 reasonably accurate inverse was found.
! * If an inverse cannot be found, a reasonable attempt shall
! * be made to give a point close (e.g. if an affine transform
! * is singular / near-singular, pick a point on the line
! * that's close to the original.
*/
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.
Index: gzz/doc/pegboard/1010/PEG_1010.rst
diff -c gzz/doc/pegboard/1010/PEG_1010.rst:1.2
gzz/doc/pegboard/1010/PEG_1010.rst:1.3
*** gzz/doc/pegboard/1010/PEG_1010.rst:1.2 Sun Oct 6 12:44:05 2002
--- gzz/doc/pegboard/1010/PEG_1010.rst Sun Oct 6 13:24:00 2002
***************
*** 3,10 ****
=============================================================
:Authors: Tuomas Lukka
! :Date: $Date: 2002/10/06 16:44:05 $
! :Revision: $Revision: 1.2 $
:Status: Incomplete
Main benefits
--- 3,10 ----
=============================================================
:Authors: Tuomas Lukka
! :Date: $Date: 2002/10/06 17:24:00 $
! :Revision: $Revision: 1.3 $
:Status: Incomplete
Main benefits
***************
*** 25,37 ****
Coordinate system type
E.g. "affine", "rotation", "fisheye", "buoytrans".
- (Benja:) "buoytrans"?
Derived coordinate system type
A coordinate system type whose possible transformations
are a subset of another coordinate system type's transformations,
implemented internally by generating a set of parameters
for the parent type.
(Benja:) Example? Is rotation derived from affine?
--- 25,40 ----
Coordinate system type
E.g. "affine", "rotation", "fisheye", "buoytrans".
Derived coordinate system type
A coordinate system type whose possible transformations
are a subset of another coordinate system type's transformations,
implemented internally by generating a set of parameters
for the parent type.
+
+ For example, the buoytrans coordinate system, which is
+ a translation to the location where the buoy should be,
+ based on a
(Benja:) Example? Is rotation derived from affine?