Re: [Flightgear-devel] Camera/FOV/View Frustum question.
Ok, I figured out what's wrong. I'm trying to set the right properties, but those properties don't exist. I know this is a newbie question, but what's the procedure for creating and initializing a property node? I tried defining it in preferences.xml, but that just gave an error. Thanks, Drew On 6/13/05, Drew <[EMAIL PROTECTED]> wrote: > > 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. > > . > > . > > . > > --prop:/sim/current-view/frustum-left-pct=0.0 > > --prop:/sim/current-view/frustum-right-pct=0.33 > > Curt, > > I know I'm reviving a somewhat old thread here, but I'm trying to use > this code to implement something similar. It's a digital > pan/tilt/zoom camera control, and since I'm panning around a piece of > an image, it's the same situation with an offset image center. > > Anyway, I'm modifying these properties real-time, and it's not > changing anything. Is this something that will only work during > startup, or am I doing something wrong? Is there a function I can > call to force the changes to work real-time? Are they too > computationally intensive for this (I don't imagine it would be, since > you can rotate a standard view in a similar way). > > Thanks, > Drew > ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Camera/FOV/View Frustum question.
> 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. > . > . > . > --prop:/sim/current-view/frustum-left-pct=0.0 > --prop:/sim/current-view/frustum-right-pct=0.33 Curt, I know I'm reviving a somewhat old thread here, but I'm trying to use this code to implement something similar. It's a digital pan/tilt/zoom camera control, and since I'm panning around a piece of an image, it's the same situation with an offset image center. Anyway, I'm modifying these properties real-time, and it's not changing anything. Is this something that will only work during startup, or am I doing something wrong? Is there a function I can call to force the changes to work real-time? Are they too computationally intensive for this (I don't imagine it would be, since you can rotate a standard view in a similar way). Thanks, Drew ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Camera/FOV/View Frustum question.
Hi, > If you want to project an image from a single projector onto a curved > wrap-around screen, could you just use a normal projector, and add a > fish-eye lens of some sort? Something like a glass cylinder cut in half > vertically, with the flat part facing the projector, and the curved part > towards the curved screen? I'd imagine a fairly simple view frustum > could compensate for the horizontal stretching effect of the lens. A more general solution (for non-linear distortions, e.g. a planar projection onto a curved screen) would be to render to a texture, and map this texture to a tesselated imaging plane with appropriate texture coordinates (to yield a piecewise-linear approximation of the inverse distortion). This would allow for fairly flexible projection setups, and shouldn't add noticeable (if any) overhead for hardware with render-to-texture support (e.g. OpenGL 1.5 framebuffer objects). The only tradeoff is uneven sampling of the projection area (because the area covered by a pixel on the projection screen is a function of the angle of incidence), which shouldn't be a big problem if the screen is not to strongly curved. bye, Manuel ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Camera/FOV/View Frustum question.
If you want to project an image from a single projector onto a curved wrap-around screen, could you just use a normal projector, and add a fish-eye lens of some sort? Something like a glass cylinder cut in half vertically, with the flat part facing the projector, and the curved part towards the curved screen? I'd imagine a fairly simple view frustum could compensate for the horizontal stretching effect of the lens. The bad part would be that you'd need to keep the projector centered vertically in front of the wraparound screen, and couldn't tilt it upward or downward. If the projector was above and tilted downward (like I'd prefer to avoid people near it from casting shadows), the lens needed would be pretty complicated to get the image on the screen to be stretched evenly horizontally, but not appear distorted. - Miles -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Wojnaroski Sent: Friday, March 04, 2005 3:51 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Camera/FOV/View Frustum question. > > I should say though that most people will just want to point their > displays perpendicular to the viewer and use a more > standard/straightforward symetric view frustums. I had to do > asymmetric view frustums for a particular project with specialized > needs. We ended up with a combination of compromises that I wasn't > entirely happy about. We were trying to achieve a middle of the road > solution that wasn't perfect anywhere, but wasn't horrible anywhere either. > Sounds kind of like the problem I'm facing with the left seat/right seat view perspective in the 747 simulator. Short of a fully collimated projection(s) and optics to handle a curved, wrap-around screen any solution will be a compromise. Understand there are electronics available to handle "warping" with CRT projectors by controlling the electron beam to handle frustum distortions and other projection artifacts. Have a feeling they're not cheap and probably some specialized software to handle all the geometry. Am I correct in understanding that the modified code has been added to CVS? Regards John W. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Camera/FOV/View Frustum question.
John Wojnaroski wrote: Sounds kind of like the problem I'm facing with the left seat/right seat view perspective in the 747 simulator. Short of a fully collimated projection(s) and optics to handle a curved, wrap-around screen any solution will be a compromise. Yes, any time you want to make the view look correct from more than one perspective you run into problems. Putting monitors on top of your dash is a worst case scenario because they are so close to the viewer. If you go with a projection screen and move the surface a few feet away from the viewers that helps ... the further away you can place it the better. In our driving sim, we have our screens probably 6-8' away from the viewer and you can get by with the passenger view not being too horrible. It's hard to match reality perfectly. Understand there are electronics available to handle "warping" with CRT projectors by controlling the electron beam to handle frustum distortions and other projection artifacts. Have a feeling they're not cheap and probably some specialized software to handle all the geometry. This stuff get's expensive really fast, and it snow balls. There's no point going down the path of image warping if you aren't using a curved screen. But if you do that, you might as well do edge blending, and before you know it, you are calling companies around the world for quotes and you've sunk $500,000 into your visual system . I recommend people stick with *simple* unless they really know what they are doing (and I'm not claiming that I fully know what I'm doing here.) :-) The problem is that if you try to step up incrementally and learn from past experience, you invariable do things wrong, and with decent LCD projectors starting at $5000, mistakes get really expensive really quick. Best case scenario, you are doing this with someone else's money and mistakes are just really embarrasing or you can shift blame. Worst case scenario, you are doing it with your own money. :-) Am I correct in understanding that the modified code has been added to CVS? Yes, it is there now in CVS. Let me know if you have any questions. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Camera/FOV/View Frustum question.
> > I should say though that most people will just want to point their > displays perpendicular to the viewer and use a more > standard/straightforward symetric view frustums. I had to do asymmetric > view frustums for a particular project with specialized needs. We ended > up with a combination of compromises that I wasn't entirely happy > about. We were trying to achieve a middle of the road solution that > wasn't perfect anywhere, but wasn't horrible anywhere either. > Sounds kind of like the problem I'm facing with the left seat/right seat view perspective in the 747 simulator. Short of a fully collimated projection(s) and optics to handle a curved, wrap-around screen any solution will be a compromise. Understand there are electronics available to handle "warping" with CRT projectors by controlling the electron beam to handle frustum distortions and other projection artifacts. Have a feeling they're not cheap and probably some specialized software to handle all the geometry. Am I correct in understanding that the modified code has been added to CVS? Regards John W. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Camera/FOV/View Frustum question.
John Wojnaroski wrote: 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.3 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.0 --prop:/sim/current-view/frustum-right-pct=0.33 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? Well, technically, my scheme still requires a separate running copy of FG and a separate video card for each monitor. I've had the best results doing this from 3 different machines, but I've heard stories of others having reasonable results with running multiple copies of FG on a single machine. At the moment FG doesn't have direct support for opening up multiple windows to drive multiple displays from a single instance of FG. There really isn't any extra performance hit though for asymmetric view frustums. The frustum is trimmed down before the cull and draw phase. I should say though that most people will just want to point their displays perpendicular to the viewer and use a more standard/straightforward symetric view frustums. I had to do asymmetric view frustums for a particular project with specialized needs. We ended up with a combination of compromises that I wasn't entirely happy about. We were trying to achieve a middle of the road solution that wasn't perfect anywhere, but wasn't horrible anywhere either. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Camera/FOV/View Frustum question.
> 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.3 > > 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.0 > --prop:/sim/current-view/frustum-right-pct=0.33 > > 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 Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Camera/FOV/View Frustum question.
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.3 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.0 --prop:/sim/current-view/frustum-right-pct=0.33 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. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Camera/FOV/View Frustum question.
Jorge Van Hemelryck wrote: Curt, 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. I have seen code submitted to support that. It is added to FGRenderer located in FlightGear/src/Main/renderer.* (search for "FOV"). Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Camera/FOV/View Frustum question.
Curt, 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/ -- Jorge Van Hemelryck ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Camera/FOV/View Frustum question.
Hello again, sorry, I didn't read your whole mail, so my response was probablly not relevant to your problem. > 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. This is just a wild guess, but it might have to do with the near-far clipping planes being changed for the scenery rendering in renderer.cxx. This results in an update of the frustum parameters, so maybe you will need to reapply your viewport modifications at different stages? Manuel ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Camera/FOV/View Frustum question.
Hello Curtis,
> 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
I hope the attached camera class might help you - I implemented support for
off-center and tiled projections for a similar project (powerwall
rendering).
The parts that probably interest you are in update_frustum() and the
parameters set via the setTiling(...) method.
hope to help,
Manuel
/***
Camera.cpp - description
---
begin: Thu Apr 18 2002
written by : Manuel Massing
email: [EMAIL PROTECTED]
***/
/***
* *
* This program is free software; you can redistribute it and/or modify *
* it under the terms of the GNU General Public License as published by *
* the Free Software Foundation; either version 2 of the License, or *
* (at your option) any later version. *
* *
***/
#include "Camera.h"
Camera::Camera()
{
n = 1.0f;
f = 4000.f;
fov = 45.f;
eye_separation = 0.f;
focal_length = 2000.f;
resx = 1; resy = 1;
llx = lly = 0;
aspect = 4.f/3.f;;
tile_t = tile_r = 1.f;
tile_b = tile_l = 0.f;
frustum_dirty = orientation_dirty = obj2clip_dirty = true;
}
void Camera::update_frustum() const
{
if (frustum_dirty) {
// Calculate the symmetric frustum extent at focal distance.
float frustum_top = focal_length*tanf(fov*M_PI/360.f);
float frustum_left = -frustum_top*aspect*((tile_t-tile_b)/(tile_r-tile_l));
// Adapt frustum to desired viewport region.
t = (2.f*tile_t - 1.f)*frustum_top;
b = (2.f*tile_b - 1.f)*frustum_top;
l = (1.f - 2.f*tile_l)*(frustum_left - eye_separation);
r = (1.f - 2.f*tile_r)*(frustum_left - eye_separation);
float rescale = n/focal_length;
t*= rescale;
b*= rescale;
l*= rescale;
r*= rescale;
local_clipplane[cpNear] = Plane(Vector3d(0.f, 0.f, -1.f), n); // near
local_clipplane[cpFar] = Plane(Vector3d(0.f, 0.f, 1.f), -f); // far
Vector3d cpn(n, 0, l);
cpn*=1.f/cpn.length();
local_clipplane[cpLeft] = Plane(cpn, 0); // left
cpn = !Vector3d(-n, 0, -r);
local_clipplane[cpRight] = Plane(cpn, 0); // right
cpn = !Vector3d(0, -n, -t);
local_clipplane[cpTop] = Plane(cpn, 0); // top
cpn = !Vector3d(0, n, b);
local_clipplane[cpBottom] = Plane(cpn, 0);// bottom
frustum = Matrix4x4( 2.f*n/(r - l), 0.f, (r + l)/(r - l), 0.f,
0.f,2.f*n/(t - b), (t + b)/(t - b), 0.f,
0.f,0.f,-(f + n)/(f - n), -2.f*f*n/(f - n),
0.f,0.f,-1.f, 0.f);
#ifdef LOGGING
if (hasLogfile())
get_logfile().setItem("fov", fov);
#endif
frustum_dirty = false;
obj2clip_dirty = true;
}
}
void Camera::update_modelview() const
{
if (orientation_dirty) {
if (vp == vpLookAt) {
Vector3d xAxis, zAxis, tmp_up = up;
zAxis = !(lookat - pos);
xAxis = !cross(zAxis, tmp_up);
tmp_up = !cross(xAxis, zAxis);
Matrix3x3 rotation = Matrix3x3(xAxis, tmp_up, -zAxis).transpose();
modelview = Matrix4x4(rotation, rotation*(-pos - eye_separation*xAxis));
}
else if (vp == vpTargetRoll) {
Vector3d xAxis, zAxis, tmp_up = up;
zAxis = !(lookat - pos);
// Make sure we are not looking down the y-axis
if (!zAxis.x && !zAxis.z)
tmp_up = Vector3d(-zAxis.y, 0.f, 0.f);
else
tmp_up = Vector3d(0.f, 1.f, 0.f);
xAxis = !cross(zAxis, tmp_up);
tmp_up = !cross(xAxis, zAxis);
Matrix3x3 rotation = Matrix3x3(xAxis, tmp_up, -zAxis).transpose();
Matrix3x3 camroll;
camroll.setRotateZ(roll);
rotation = camroll * rotation;
modelview = Matrix4x4(rotation, rotation*(-pos - eye_separation*xAxis
RE: [Flightgear-devel] Camera/FOV/View Frustum question.
Curtis L. Olson writes: > > First let me explain what I need to do. I need to configure an > "asymmetric view frustum". .. > 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.) Not very helpful but I think you are correct about this being the 'same issue' FWIW I never did figure out exactly what was causing this but IIRC this was a problem even when I implemented the TR view but was not an issue for me as I was only interested in the '2D' panel' if any when not in exterior view mode. Norman ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Camera/FOV/View Frustum question.
> world seen through extreme overzoom (i.e. you only get a tiny, itsy, > bitty bit of the outside world expanded to fill the screen.) This isn't the same problem - and won't help you - but does anyone else see visual corruption when loading up view 0 for the first time, that clears when you reset the system, but not before? I see a view where every polygon has been drawn with at least one corner at a vanishing point in the centre of the screen - I've not been able to trace the source, but the error occurs on both MingW and MSVCC binaries, and it makes me wonder what view 0 actually does? Giles Robertson (ATI 9700/Win XP) ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Camera/FOV/View Frustum question.
> From: "Curtis L. Olson"
> Sent: Thursday, 24. Feb 2005 23:37 -0500
> To: FlightGear developers discussions
Ok it's too late for me to be a lot of help right now.
A couple of things.
1) Does everything work ok in other "lookfrom" views (where the camera rotates
from a
viewpoint). The second tower view that lets you look around the airport does
that. If
that works then the matrices are fine ("lookfrom" views all use the same
matrices).
2) Look at FGAircraftModel::draw in FlightGear/src/Model/acmodel.cxx. There is
a hack in
there that resets the near/far plane and clears the depth buffer.
I can't see what you see and it is too late for thinking hard let alone firing
up
flightgear and playing with the tiled dump. But those are the only two things
I can think
of that are done differently for the 3D cockpit view.
Oh...hmmm...you were talking about 3D, right?
If not then look at the 2D panel code. It does some weird things with the
frustrum. And if that's it look at the panel config for one of those clear
panels because they don't frig with the frustrum.
Best,
Jim
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
