Re: [Flightgear-devel] view code. was Virtual Cockpit!
On Wed 6. March 2002 16:09, you wrote: > > That looks good -- a single, configurable view manager would be better > > than a few ad-hoc, hard-coded ones. You'll need to be able to specify > > a few more parameters (i.e. draw the 3D model, look towards the plane, > > reverse view direction [for external], etc.). > > So i'm trying to reorganize the code first :-) Hmm, I see that I'm second so I will wait until you finish the changes. Hope you will be succesfull. Regards, Madr -- Martin Dressler e-mail: [EMAIL PROTECTED] http://www.musicabona.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] view code. was Virtual Cockpit!
> > That looks good -- a single, configurable view manager would be better > than a few ad-hoc, hard-coded ones. You'll need to be able to specify > a few more parameters (i.e. draw the 3D model, look towards the plane, > reverse view direction [for external], etc.). > So i'm trying to reorganize the code first :-) But there are som properties which I fully don't understand pilot for what is this, it drive only if cur_fdm_state is copied to cur_view_fdm, but I don't know any case when isn't used current fdm. 0.00 pilot view 0.00 0.00 0.00 0.00 0.00 0.00 It is offset from CG? But only YASim set this values. 0.00 0.00 What is this ? chase view 180.0 0 25 180.00 0.00 25.00 What about this property system. The last I suggest doesn't allow to easy change via command line options. pilot view 0 0 0.0 0.0 0.0 true what more panel? hud? hear is tree of current values chase view 180.0 0 25 false what more panel? hud? hear is tree of current values Regards, Madr -- Martin Dressler e-mail: [EMAIL PROTECTED] http://www.musicabona.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] view code. was Virtual Cockpit!
On Tue, 2002-03-05 at 08:04, Alex Wolff wrote: > Hey people, > > Right, been a lurker for long enough and though I'd contribute to the tide > of email into your inboxes. > I still need to actually get flight gear to build on MSVC but once that is > done will be able to invest a bit of time into flightgear. > > > So... the question is... where to start? I'm tempted to try reorganising the > start-up code in main to get the FDM interface into a more modular (Init / > Bind / Update) pattern, ideally I'd like to get it separated enough that I > can start up flightgear fdm-less and choose a plane / fdm from a menu / > dialog box... that's my longish term goal anyway. I don't object to starting FDM-less, but it might be easier if you knew that FDM init doesn't take very long (at least to my observation) and that the reset menu item completely re-initializes it so that might be a good place to start. In other words, go ahead and start with an FDM and, let the user choose a different one (if desired) and internally trigger a reset with the new aircraft and FDM. >From a usability point of view, I think it would be better if the user got *something* he could fly by default. > > Anyway, the reason this is replied to under the view thread is that I was > thinking about the view code for a bit and thought that before you guys > started working on implementing a configurable system, it might be worth > considering the kinda things we'd want from it - for instance I think that > any ground view should at least have the option of: > > > ground > 1 //max distance from fdm before > switch out or 0 for none > > > 5 > 3 > 2 > no > > 130 > 130 > 80% > > on > off > on > > > Rotation&&Position //controls what if any >settings are > saved between view switches... //otherwise use startup settings > > > yes > yes > > yes > pi/4 > > 0 > pi > yes > > > yes > yes > > yes > 15 > > 80 > -15 > > > yes > yes > > yes > 100 > > 2000 > 100 > > > > you could also associate sound effects with rotation / pitch / zoom and > different ones for reaching limits. > Finally, what would be great is if we could associate a ssg node (with > special case for 2D things like panel) to each view that would let them have > something displayed right in front of them (eg. A car model for someone > parked at end of a runway, a vitual cockpit, etc. If we could specify > individual ssg nodes for rotation with view (i.e. pilots glasses for pilot > view... gun turret for gun view), pitch and zoom that would be even > better... > > Anyway, just some ideas... will leave the view code alone for the minute so > you guys can work on it. > > Alex Wolff > > > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] view code. was Virtual Cockpit!
Hey people, Right, been a lurker for long enough and though I'd contribute to the tide of email into your inboxes. I still need to actually get flight gear to build on MSVC but once that is done will be able to invest a bit of time into flightgear. So... the question is... where to start? I'm tempted to try reorganising the start-up code in main to get the FDM interface into a more modular (Init / Bind / Update) pattern, ideally I'd like to get it separated enough that I can start up flightgear fdm-less and choose a plane / fdm from a menu / dialog box... that's my longish term goal anyway. Anyway, the reason this is replied to under the view thread is that I was thinking about the view code for a bit and thought that before you guys started working on implementing a configurable system, it might be worth considering the kinda things we'd want from it - for instance I think that any ground view should at least have the option of: ground 1 //max distance from fdm before switch out or 0 for none 5 3 2 no 130 130 80% on off on Rotation&&Position //controls what if any settings are saved between view switches... //otherwise use startup settings yes yes yes pi/4 0 pi yes yes yes yes 15 80 -15 yes yes yes 100 2000 100 you could also associate sound effects with rotation / pitch / zoom and different ones for reaching limits. Finally, what would be great is if we could associate a ssg node (with special case for 2D things like panel) to each view that would let them have something displayed right in front of them (eg. A car model for someone parked at end of a runway, a vitual cockpit, etc. If we could specify individual ssg nodes for rotation with view (i.e. pilots glasses for pilot view... gun turret for gun view), pitch and zoom that would be even better... Anyway, just some ideas... will leave the view code alone for the minute so you guys can work on it. Alex Wolff ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] view code. was Virtual Cockpit!
Martin Dressler writes: > Thera are a lot of strange things in view code. It is initialized > here and there. There is also problem with lat,lon positions. The > code is too oriented towards FDM position not to viewer > position. It's not problem with current view modes, but it could be > problem with tower (or ground :) view. I agree -- it's a pretty serious mess (but it was useful having it up to now). I'm also planning to do some work on the view code, so let's make sure we don't end up duplicating each-others' work -- send in your changes frequently rather than saving them all up, and I'll do the same. Instead of rewriting from scratch, I'm thinking of trying to reorganize what we have first. Norm Vine did some of the work on the view code, and he knows an awful lot more than I do about how to write and optimize all the matrix and coordinate transforms. > > > > pilot > > > chase > > 25 > > > > chase > > 100 > > > > ground > >5 >3 >2 > > > > That looks good -- a single, configurable view manager would be better than a few ad-hoc, hard-coded ones. You'll need to be able to specify a few more parameters (i.e. draw the 3D model, look towards the plane, reverse view direction [for external], etc.). All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] view code. was Virtual Cockpit!
On Mon 4. March 2002 18:32, you wrote: > David Findlay wrote: > > I started FGFS with the property enabling the virtual cockpit, then > > used right click twice to get to the mode where you can move the mouse > > to move the viewpoint. The panel would stay at the bottom of the > > screen when I moved my mouse downwards. > > Ah, I see. David found this too. The problem here is that the mouse > scrolling code sets the view/offset-deg property, but not the > view/pitch-deg one. The code there is old, and seemingly obscure. > It's computing quats and matrices that no one appears to use. :) I'll > get a patch ready for the mouse scrolling soon. Thera are a lot of strange things in view code. It is initialized here and there. There is also problem with lat,lon positions. The code is too oriented towards FDM position not to viewer position. It's not problem with current view modes, but it could be problem with tower (or ground :) view. I will try to rewrite the view code from scratch, but with some reuse of code in next month. I want to get to code where you can specify as much as you want of view modes. pilot chase 25 chase 100 ground 5 3 2 I don't know if it is above my programing skills :-( Regards, Madr -- Martin Dressler e-mail: [EMAIL PROTECTED] http://www.musicabona.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
