Thanks for the info.
> Using RELATIVE_TO_SCREEN should do what you want. Btw, we have
> considered adding a variant of RELATIVE_TO_WINDOW that isn't centered
> in X and Y--similar to RELATIVE_TO_SCREEN, but with the manual X and Y
> eye position being relative to the lower left corner of the window
> rather than the screen.
Maybe I keep looking over that four leaf clover but I can't make
RELATIVE_TO_SCREEN do what I want. With RELATIVE_TO_SCREEN the eye
position is relative to the *screen*. What I need is for it to be
relative to the *window*, specifically in X and Y, like what you
mentioned you have "considered".
What I am trying to do is offset the view in the display so that the
view -Z axis is located at a position in the display window (not
screen) other than the center. This is useful, for example, in
situations where you want the out-the-window view to appear in the
upper part of the display and HUD controls and indicators and other
"display space" decorations to appear in the lower half (like that
done in GAMES). This requires that the "view space" origin be offset
from the "display space" origin. (See further comments about the view
model below.)
>
> 5) When the view platform attach policy is NOMINAL_HEAD, scaling about
> the center of the view platform has no effect in a perspective
> projection. The objects get proportionally smaller and closer to the
> viewer making their projection the same size in clipping coordinates.
> You can see other examples of this phenomenon by putting a scale
> transform directly above the view platform: it will have no effect.
> When the view platform attach policy is NOMINAL_SCREEN, then the
> scaling is centered about the screen and the scale does have an
> effect. In parallel projection mode, the distance from the screen has
> no effect on the rendering so the scale has an effect regardless of
> where the scale is centered. This is counter-intuitive and we are
> examing whether we can change this behavior for Java 3D 1.2.
Counter-intuitive seems a fair statement.
At least for my own humble needs a decent camera model would suffice
for now. I need a way to offset the view space origin relative to the
display space origin (be that the display window or the display
screen, which can be considered two different spaces). I'd also like
to control the view space scaling factor (i.e. the scaling factor
applied to the view space before projecting it into the display
space). If there were ever such a thing as a bonified "display space"
(with overlay capability) then I'd also like to control the display
space scaling factor (i.e. the scaling factor applied to the display
space and its overlays before clipping it to the display window).
I've tried long and hard to do display-view offset and view space
scaling using both the Java 3D compatibility mode and raw projection
transforms (frustum). I can do neither one (offset or scale)
satisfactorily using either approach. It appears as though the
compatibility mode is not quite compatible enough and the raw
projection is not quite raw enough. Perhaps with some of the info you
mentioned about what is going on in other parts of the "black box" I
could now get it to work, but I think I'll wait for the new and
improved model. :-)
There seems to be an awful lot of coupling going on between all the
modes and models and models within the model. Perhaps with better
documentation, some useful examples, and a fully implemented and
bug-free version of the model(s) things might seem a bit clearer. On
the other hand this might be indicative of an "overly
intellectualized" viewing model. Perhaps more of the low-level view
model parameters should just be exposed in the API rather than the API
trying to second guess what the developer is trying to do. It
certainly couldn't be any more challenging dealing with low-level
viewing parameters than it would be with compatibility bits, scene
graph liveness, and the behavior and collision models.
--jon
____________________ Peculiar Technologies ____________________
Jon Barrilleaux 3800 Lake Shore Ave. Purveyors of
[EMAIL PROTECTED] Oakland, CA 94610 Alternate Reality
510.444.4370 voc Augmented Simulation
510.444.0231 fax www.augsim.com and 3D Solutions
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
