> 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 hit?
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. Regards John W. _______________________________________________ Flightgear-devel mailing list [email protected] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
