Thank you for your comments, we'll take them into consideration,
although we may not be able to address all of them for the 1.2
release.
--
Kevin Rushforth
Java 3D Team
Sun Microsystems
[EMAIL PROTECTED]
>Date: Wed, 15 Sep 1999 01:35:42 -0700
>From: Jon Barrilleaux <[EMAIL PROTECTED]>
>To: mail_list java3d <[EMAIL PROTECTED]>
>Subject: Re: view model (by trial and error)
>
>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".
