> Jorge Van Hemelryck wrote:
> >Have you been successful in implementing your asymmetric frustum hack ?
> >It might be a good idea to add it to the official FlightGear code. It is
> >one of the features that might fill in the gap between "amateur" flight
> >simulation and a professional product. It might even be useful to have
> >any arbitrary frustum, meaning that the screen could have any position
> >with respect to the subject. The difficult part would then be to figure
> >out which parameters to use. Maybe I could try and help with that.
> >
> >Actually, when I talked about FlightGear at work, our visual systems
> >(screens, projectors, optical systems) specialist asked about asymmetric
> >frustums right away. Not to mention projecting on a spherical surface,
> >which would probably need work in the video board itself, not to mention
> >the drivers and the software part (OpenGL doesn't do it yet, does it ?).
> >
> >For those who might have had trouble understanding (or explaining) what
> >the problem was, I found a page a few weeks ago where it was put quite
> >clearly:
> >
> >http://astronomy.swin.edu.au/~pbourke/projection/caev/
> >
> >
> >
> Yes, I think I was successful in adding support for asymmetric view
> frustums.  It's a bit of a hack to get there, but the way I have set it
> up I think is slightly more intuitive than just passing l, r, t, b, n, f
> parameters to the glFrustum() function.
> For my specific need I wanted 3 monitors side by side in a straight
> line, and I wanted the projection plane to also be a straight line.  So
> referencing your link, Example 1 is what we originally could do, but is
> not what I wanted.  I wanted to do something similar to Example ....
> errr ... I guess there isn't an example on that page of what I wanted to
> do.  Kind of like Example 5 I guess except with the "red" line (plane of
> projection) extending straight across.  The center view frustum would be
> symmetic and the sides would be asymmetric.  I realize this isn't
> "correct" but I need a compromise to build a display system that look
> "reasonable" from a large variety of perspectives at the same time.
> So anyway, here's my approach.  Let's say I wanted 3 monitors, each
> covering 30 degrees FOV.
> 1. I added an --aspect-ratio-multipler=x.xx option.  FG automatically
> calculates aspect ratio based on X, Y screen resolution.  This option
> scales the Y FOV.
> 2. I created a super wide display with something like --fov=90
> --aspect-ratio-multiplier=0.33333
> 3. I added some options to select a portion of this wide screen to draw
> onto the individual monitor:
> --prop:/sim/current-view/frustum-left-pct=0.00000
> --prop:/sim/current-view/frustum-right-pct=0.333333
> This gives me the leftmost 1/3 of my wide (--fov=90) screen.  And the
> aspect ratio multiplier option allows me to get the desired vertical
> field of view.
> I'm not sure that all makes sense.  It is a little convoluted, but
> essentially it allows you to specify a larger symmetric frustum, and
> then select a portion of that to get your asymmetric frustum.
Does this still require 3 machines to generate the views for each of the 3
monitors?  And does each machine have to generate the full fov of all
objects therein but only display the selected portion? A bit of a performace

A while back I set up a dual-headed video card to run two instances of FG on
a P4 to create a left and right view and a single machine to generate the
center view. I don't recall the specifics regards # of screen objects or
other details other than it was KSFO. Peformance was not all that bad on the
P4 machine -- around 20-25fps as I recall. Each FG instance had to calculate
only the objects within the FOV defined by the frustrum -- a bit if an
optimization there.

John W.

Flightgear-devel mailing list

Reply via email to