Hopefully none of this comes off as a rant ... I know we are doing some complex stuff here and there are complex interactions.
First let me explain what I need to do. I need to configure an "asymmetric view frustum". I need to place 3 monitors next to each other, aligned along a flat plane. The view drawn in each monitor needs to be projected on that same flat plane. I cannot just set a view offset for the side channels because the view won't come out right. If I simply rotate the view offset and take a symmetric view frustum, the plane of projection will be perpendicular to the viewer in each channel. That won't work for this particular application and it's not what I need. I need to configure an actual asymmetric view frustum for each side channel. If someone thinks they can help me, but is confused by my description, I'm happy to explain this further. Think about this from a top down view. Imagine I have a single super wide screen monitor and imagine the view frustum that goes along with that. Now imagine I want to replace the super wide monitor with 3 normal sized monitors, but otherwise generate the exact same display output. I need to chop up the one wide frustum into 3 frustums, but keep the original shape so if you put the 3 small frustums together, you get the original wide frustum. Said another way, the plane of projection of all 3 views needs to be the same. From the top down you can see that the center frustum will be symmetrical, but the two side channels will have to be asymmetric. So that's what I need to do.
I did some playing in the code to intercept the actual frustum being used by calling ssgGetFrustum(). I can look at the values and change the left/right sides of the frustum. This yields the results I want, except for view #0 (the inside the 3d cockpit view.) My hack works for the aircraft model and 3d cockpit as seen from the inside, but the rest of the scene (i.e. the terrain) is completely screwed up. So somehow, the camera/view parameters must be getting set separately for the outside geomtry versus the 3d cockpit geometry. Can anyone explain how/where this happens.
At the risk of making this message more complicated, I was planning to get an asymmetric view frustum by configuring a single triple-wide, normal-height screen, grabbing the view frustum values after they've been set by all the incomprehensible, ultra-optimized flightgear magic, then adjust the left/right values to get the portion of the screen that I want, and then rewrite the frustum. This is an awful, awful, terrible, ugly hack, but the view matrix setup code is now ultra-optimized and pretty much impenitrable to me.
Going back to my original query. My little experiment to pan the view frustum side to side using this technique worked great in all the external views, but totally screwed up the outside world in view #0 ... I ended up with extreme overzoom and no panning relative to the outside scenery, but the 3d cockpit worked ok and panned as I was hoping it would.
For what it's worth, I think the same issue is happening with the "TR" tiled rendering routines that generate the ultra-highres tiled screen shots ... that code suffers the same problem in view #0 with the outside world seen through extreme overzoom (i.e. you only get a tiny, itsy, bitty bit of the outside world expanded to fill the screen.)
I'm extremely desperate to get this figured out and working in the next day or so!!!
-- Curtis Olson http://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d
_______________________________________________ Flightgear-devel mailing list Flightgearemail@example.com http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d