Hi Curt,
This is very helpful and I agree on the concept of scheduling tile caching for
all the views. First I'm going to try and resolve the Aircraft issues and get
the "faking" out of the viewer (it is really only "faking" with the tower views).
Let me do some work with this and get back to you.
Best,
Jim
"Curtis L. Olson" <[EMAIL PROTECTED]> said:
> Jim,
>
> This is a real problem and becomes increasingly apparent as the view
> point moves further away from the aircraft we are simulating.
>
> Perhaps what we need to do is make sure we conceptually separate those
> things that need positional data for rendering a view, and those
> things that need positional data for modeling the aircraft and it's
> systems:
>
> View:
> - Stuff related to time of day/lighting effects
> - Stuff related to the scenery manager
> -
>
> Aircraft:
> - Things like magnetic variation calculations
> - Height above ground for gear reaction forces, etc.
>
> The individual modules would have to be carefully examined and we'd
> have to make sure that each of them is getting information from the
> appropriate place (either the current aircraft position or the current
> view position.)
>
> <more comments below>
>
> Jim Wilson writes:
> > Speaking of impact, one thing that has been on my mind is what to do
> > with the location (aka position) data. Right now just about
> > everything is either asking the viewer for information or directly
> > accessing the hard coded path to the property tree ("/position/").
> >
> > The immediate problem is the viewer doesn't always know the correct
> > information to give. Currently it is faking it to placate the
> > routines that are still asking the viewer for things like sea level
> > vectors and "view position". By "faking it", I mean it is
> > calculating and reporting a "view position" based on the location of
> > the aircraft that might not actually be the "real" current view
> > position.
> >
> > Well you might say, that it is ok for the "view position" to be reported by
> > the viewer. In some cases I think the values aren't being used in an expected
> > way. And keep in mind that the "actual" view position is no longer (as in
> > Tower view) anywhere near the aircraft that is being driven by the FDM.
> >
> > These problems were evident during testing before I made the viewer fake the
> > data:
> >
> > 1). Somehow the altitude in JSBSim was being increased to the height of the
> > tower. Thus when you went back to the pilot view the plane was falling from
> > the sky.
> >
> > 2). Depending on how the view positions are located, and where the tile
> > boundries are, switch views will trigger tile loading code.
>
> This may or may not be a problem depending on how you look at it. If
> we switch the view to some other location, we want to see the
> surrounding terrain for that view, so we need to have the local tiles
> in the cache. This is probably the 'right thing to do', but it
> imposes a greater load on the tile manager. Perhaps we need to make
> sure that the cache is big enough to have all the tiles for several
> different views, and then let the user live with some loading/popping
> of scenery if they haven't been to a particular view location in a
> while.
>
> Or the scenery manager could traverse the view list every frame and
> schedule tile loads for all the views. This would impose minimal
> additional load if the 'other' views were static, or if a couple views
> were in close proximity (i.e. pilot view, chase view, nearby ground view.)
>
> > Other problems:
> >
> > Even with the data that I am faking, there still seems to be a problem with
> > the lights (both runway and "city" lighting).
> >
> > 1) It appears that when switching tiles the lights jump up.
>
> Perhaps the 'lifting' transform for the lights isn't getting
> calculated correctly for one frame as we cross a tile boundary?
>
> > 2) From the tower view the runway lights are way to high.
>
> The lights are lifted up based on the distance from the 'faked' viewer
> data to the aircraft. So if you are faking data, then the lights will
> raise up as the aircraft flies away for the airport ... even if the
> tower view is stationary.
>
> > Solutions?
> >
> > Unless we want to maintain the tile cache for each view (ack!)
>
> We can have one cache and then schedule tiles for multiple views, we
> just need to make sure the cache is big enough so we don't start
> thrashing when we cycle through the views.
>
> > then we should have one location that has nothing to do with "view"
> > for developing the cache.
>
> The scenery tile cache is there mostly for the purpose of the views
> though, so if we aren't going to load tiles surrounding a particular
> view, what's the point? We would also want to load at least the tile
> that the view is sitting on so we can calculate ground elevation and
> keep the view above the ground.
>
> > The view positions, depending on how they are cofigured can either
> > look at the tile cache or not. As some have noticed you get a
> > big-pale-blue-nothing depending on how far away your tower is. This
> > will be acceptable for the time being, or we should print some sort
> > of message that the view isn't going to be displayed since it is too
> > far away.
>
> I like the idea of scheduling tile loads for each view ...
>
> > As far as the FDM is concerned, nothing from the viewer should be
> > going to the FDM, directly or indirectly.
>
> Correct, we need to keep this separate. Positional data we need for
> caclulating magnetic variation, height above ground, etc. needs to
> come from the aircraft position, not from the view position.
>
> Stuff we need for drawing the immediate frame (i.e. scenery data,
> height of view point AGL, relative position of sun for lighting
> effects, etc.) should come from the viewer position.
>
> Regards,
>
> Curt.
> --
> Curtis Olson IVLab / HumanFIRST Program FlightGear Project
> Twin Cities [EMAIL PROTECTED] [EMAIL PROTECTED]
> Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org
>
> _______________________________________________
> Flightgear-devel mailing list
> [EMAIL PROTECTED]
> http://mail.flightgear.org/mailman/listinfo/flightgear-devel
>
--
Jim Wilson - IT Manager
Kelco Industries
PO Box 160
58 Main Street
Milbridge, ME 04658
207-546-7989 - FAX 207-546-2791
http://www.kelcomaine.com
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
