From: Yves Strube (czys++at++ocag.ch)
Date: 10/31/2001 23:50:27
Hi,
thanks for your answers (see below) but I use simply pfChannel::setFOV()
and pfChannel::setNearFar(). What I thought should work is:
pfChannel::setNearFar(near, far);
pfChannel::setFOV(horizAngle, 0.0f);
Then *I expected* that I see everything from near [units] to far [units]
where the distance is measured along the line of sight (LOS) vector,
i.e. is independent of the LOS. Changing the FOV should not change the
"visiblity interval" between near and far.
But what *I get* is:
I did a test and positioned an object at e.g. 1501 [units] from the
point of view measured along the LOS vector. I thought that if I set the
back clipping plane to 1501 (or slightly more) that the object is
visible - but it is not. So I increased the back clipping plane distance
until the object becomes visible (with a constant FOV).
For an FOV of 90 [deg] I had to set the Performer back clipping plane
(in short PBC, i.e. the value to put into pfChannel::setNearFar()) to
2860 [units] to see the object. Now I decreased the FOV and obeserve how
the back clipping plane begins clipping my object (though
pfChannel::getNearFar() reports the back clipping plane to be constant).
To keep the visible range of 1501 [units] constant I have to set the
following values for Performer's back cipping plane (PBC) (depends on
the FOV):
FOV [deg] PBC [units]
-------------------------
2 42910
10 10450
20 6330
30 4920
40 4190
50 3740
60 3430
70 3200
80 3010
90 2860
I did another test with the object positioned at 3571 [units] and got
the following dependency:
FOV [deg] PBC [units]
-------------------------
2 84070
10 19920
20 11820
30 9070
40 7660
50 6790
60 6200
70 5750
80 5410
90 5120
A plot of PBC(FOV) shows that PBC seems to be something like
PBC = desiredConstantBackClip * scalingFactor * 1/FOV
So I implemented a work around where I scale the back clipping plane
which works but is of course not accurate. It gives me more visible
range than I require. So I can always see the object but get a poorer z
buffer resolution.
I thought a while about trying to get a more accurate estimation when I
observed that the PBC value also depends on the object's elevation. I.e.
the tables given above are only valid for a certain elevation of the LOS
vector. So I get a function
PBC(FOV, LOS, desired constant back clipping plane)
So I gave up and use the work around but I am not happy with this
solution and would like to know what is going on?
Why does the visible range depend on FOV and LOS?
Why are the units of the back clipping plane not the same as my world
coordinate units?
Bye,
Yves
Benedikt Kessler wrote:
>
> Hi!
>
> See below...
>
> Scooter wrote:
> >
> > X-No-Archive: yes
> >
> > Hi, Yves:
> >
> > Your problem sounds very similar to mine, but I'm not sure of
> > that. I'm using a horizontal FOV (HFOV) of 88 degrees. Near
> > clipping plane is 2.0 m and far clipping plane is 1000 m. But,
> > clearly, the motion of the car through the database (driving
> > simulator) appears way too slow with those values. Choosing a
> > near clipping plane of 10.0 m causes the scene to appear *very*
> > compressed along the gaze vector so that quite distance objects
> > appear *very* close. And when driving it feels like you are
> > moving *very* slowly, yet the car coordinates vs. time and the
> > car's speedometer suggest a "normal" speed.
> >
> > Conversely, choosing a near clipping plane much closer to the
> > eye (0.5 m) causes the scene to appear stretched way out, so
> > even relatively close objects appear far away. In this case,
> > when driving it appears you are going
> > *very* fast, yet it still takes the same amount of time to reach
> > some object as when the scene was more compressed. I have been
> > unable to get this behavior to change with a 45 degree HFOV.
>
> Are you using
>
> pfMakePerspFrust(pfFrustum* frust, float left, float right,
> float bottom, float top);
>
> You should be aware that the left, right, ... parameters give you quite
> a different frustum if you have different near values (set by
> pfFrustNearFar(pfFrustum* frust, float near, float far); )
>
> So you should call pfFrustNearFar first and then pfMakePerspFrust with
> the right values according to your near value:
>
> ^
> /|\
> / | \
> / | \
> / | \
> / | \
> / | \
> / right| left \
> /-------+-------\ near
> / | \
> /---------+---------\ far
>
> >
> > There were no responses to my previous posts to this group, so I
> > assume no one really knows what to do about this problem or has
> > not encountered it themselves. I've exerienced the problem since
> > I wrote my application a couple years ago. The best I've beeb
> > able to do is choose a near clipping plane distance (about 1 m)
> > that gives (subjectively) the right speed and apparent road length.
>
> If yout left, right, bottom and top values also were in meters you got
> the right frustum...
>
> >
> > Performer bug? Interaction between HFOV, VHOV, near/far clipping
> > planes, eyepoint? I can't find the answer to this problem.
>
> This is from the pfFrustum manpage:
>
> Note that
> the field of view of a frustum configured with pfMakePerspFrust is
> dependent on the current near plane distance. However, subsequent
> changes
> to the near plane distance with pfFrustNearFar do not affect the
> field of
> view, simplifying clip plane modification.
>
> Bye! Benedikt
>
> > > From: Yves Strube <czys++at++ocag.ch>
> > > Date: Tue, 30 Oct 2001 14:16:03 +0100
> > > Subject: Why does the FOV influence the back clipping plane?
> > >
> > > Hi,
> > >
> > > I oberserve some strange effects in my application when changing the
> > > field of view to zoom in and out of the scene. If I zoom in, objects
> > > which I see with e.g. a FOV of 90 degrees are clipped. I observe that at
> > > first the parts of the objects which are further away from the point of
> > > view are clipped and so on until the objects are no more visible at all.
> > > This looks like the back clipping plane comes closer if I zoom into the
> > > scene (for whatever reason) and is pushed farther away if I zoom out. So
> > > I displayed the back clipping distance with Channel::getNearFar() and
> > > wondered that the back clipping distance is reported to be constant!?
> > > If I adjust the back clipping plane with pfChannel::setNearFar()
> > > dynamically to be farther away when zooming into the scene and come
> > > closer when zooming out everything looks well. But then I have to put in
> > > values which have nothing to do with reality. I have to set the back
> > > clipping plane to a value of e.g. 3.0e6 for very small FOVs to see
> > > objects which are only 100000 units away. Otherwise these objects
> > > disappear. So the units given for the back clipping distance are not the
> > > same as the units given for object positions.
> > > And it is even worse that this behaviour is not linear. I.e. if I zoom
> > > into the scene objects which I see with an FOV of 90 degrees disappear
> > > for an FOV of 70 degrees and appear again for an FOV of 64 degrees. This
> > > effect can only be avoided by setting the back clipping plane to an
> > > astronomically large value (e.g. 3.0e6) with the negative effect that my
> > > z buffer resolution gets worse.
> > > Since I know that the objects are in the scene and observe how they are
> > > cut by something (must be the back clipping plane) I am really curious
> > > how this behaviour can be explained?
> > > I thought that the FOV has nothing to do with the front and back
> > > clipping plane!?
> > >
> > > I use Performer 2.4.2 (same effect with 2.4) on a Linux machine and
> > > would be glad to get any help or a note from someone who observes the
> > > same effect.
> > >
> > > Thanks,
> > > Yves
> > >
> > > --
> > > Oerlikon-Contraves AG
> > > Yves Strube, S-EMI
> > > Birchstr. 155 Email: czys++at++ocag.ch
> > > CH-8050 Zurich Phone: +41 1 316 2675
> > > Switzerland Fax: +41 1 316 2032
> > >
> > > *****************************************************************************
> >
> > *****************************************************
> > * "...a definition, by the way, by definition, is *
> > * not exact"--Heinz Tschabitscher *
> > *****************************************************
> > -----------------------------------------------------------------------
> > List Archives, Info, FAQ: http://www.sgi.com/software/performer/
> > Open Development Project: http://oss.sgi.com/projects/performer/
> > Submissions: info-performer++at++sgi.com
> > Admin. requests: info-performer-request++at++sgi.com
> > -----------------------------------------------------------------------
>
> --
> +---------------------------------+----------------------------------+
> |Benedikt J. Kessler | Silicon Graphics GmbH |
> |Professional Services | Am Hochacker 3 - Technopark |
> |SGI | 85630 Grasbrunn-Neukeferloh, FRG |
> | --- __o ,__o | |
> | ------_ \<,_ _-\_<, | Phone: (+49) 89 46108-366 or -0 |
> |----- (*)/ (*) (*)/'(*) | Fax: (+49) 89 46107-366 |
> +---------------------------------+----------------------------------+
> |E-Mail: bjk++at++sgi.com Web (private): http://reality.sgi.com/bjk |
> | Web: http://www.sgi.de/dienstleistungen/ |
> +--------------------------------------------------------------------+
--Oerlikon-Contraves AG Yves Strube, S-EMI Birchstr. 155 Email: czys++at++ocag.ch CH-8050 Zurich Phone: +41 1 316 2675 Switzerland Fax: +41 1 316 2032
This archive was generated by hypermail 2b29 : Wed Oct 31 2001 - 23:47:10 PST