Re: [Flightgear-devel] Panel Building ?!?
Hi Vikki I have just finished doing a 737 panel which will be coming Eric's way in a couple of days.This was done as a 2D panel. I could not write two lines of C code to save myself but I found the XML files quite easy to learn.The main thing to remember with XML is cut and paste is your greatest friend.You can throw a panel together quite quickly if you know what code blocks to use. So if you are not into 3D modeling the 2D panel might be the best place to start. Cheers Innis The Mad Aussi _ Hot chart ringtones and polyphonics. Go to http://ninemsn.com.au/mobilemania/default.asp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D aircraft model origins
On Sunday 11 January 2004 15:58, Jim Wilson wrote: > Innis Cunningham <[EMAIL PROTECTED]> said: > > Take Lee's P51 it has its MRP at the nose. > > That's mine :-) I missed that - Yes, its definitely one of Jims. LeeE > > > It is my understanding that the offset system was devised primarily to > > allow MSFS A/C > > to be positioned correctly. > > The model offsets yes. The view offsets no. > > > I stand corrected if this is not the case. > > OK > > Best, > > Jim > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aircraft frames and reference points
>If you know everything about both frames all the time, then why is there ever > a need for any adjustment figure? Everything was calculated, all needed > reference points were known already from the VRM to the FDM, you didn't adjust > anything there was no need. The 3D model and the FDM are each know about their *own* frame. The FDM knows nothing about the 3D frame, and the 3D modeler frame knows nothing about the FDM frame[s]. Remember, we are talking about code here. It only does what we tell it to. The FDM side exists separate from the 3D code and vice versa. We have to tell them about each other, as it were. >Some of these factors weren't known at first if people can draw planes of any > relative size in the drawing program. You are figuring out the size > relationship somehow, it is not set if they can just draw the model any size. > If one person can draw it twice as large as another, and you can match the FDM > to it, then you are matching more than just the nose point somehow. You are > making your scale bigger somehow, or shrinking their drawing, if you can match > the bigger model. If not then you have to move your nose around to match, then > change every motion constant in the FDM to make a large drawn model act large, > and a small model act small. And even then the modeler has to draw it the right > size, they have to make the model 30 feet if it needs to be 30 feet. This is probably where the misunderstanding is coming in. It is a convention that the 3D modeler "composes" models in units of inches, or that the model is composed in units of feet and scaled by 12. It is known that the JSBSim FDM (for instance) uses dimensions of inches in the structural frame (an industry standard). The size relationship is a standard, it is a convention, it is not figured out dynamically. Maybe Jim can chime in, here. It is obvious that if the models were scaled in some odd, non-standard way, we'd need to fix them. >I know you're doing it correctly. The models, once adjusted, look and act > properly. It is your explanation of how the two reference frames fully match is > what's lacking. How come everyone else gets it? > You say no no we only adjust the nose, when really you are > doing other things too to match the visual and FDM frames with your adjustment > figure, even if you don't see it. You are making every point match in scale in > both frames, not just the nose. Your adjustment figure is from the nose in one > frame to a reference in the other. Your scale is either known > set or adjusted along with this adjustment through other factors. I don't have to deal with scale. If I *was* to create my own 3D model, I know that I need to use units of inches, and I know the frame that the FDM describes the aircraft in, so I could create a 3D model that would work out of the box. Obviously we have to live by certain rules. And we are not and never have said "no, no, no we only adjust the nose". What we intend to do - and what we do - is to correctly place the 3D model so that it's "virtual" CG is co-located with the CG as known by the FDM; but, we do this in an indirect way via the common VRP, out of necessity. >And when you get a new model, and move it around with your nose adjustment > figure, and aligning your reference point, you are aligning your CG's even if > you don't say you're aligning your CG's. That's the *idea*! Let me repeat: the 3D model really doesn't care about CG - it just wants a yaw, pitch and roll, and to be translated to the proper location. > Yes, they fall into alignment when you > get your reference points matched and your nose was in the right place. But how > is it you know when your reference point looks like it matches? By the CG. Yes. That's what we've been saying: the Visual Reference Point (VRP) is located by the FDM because the CG is known in structural coordinates at any time, and the VRP is know because we specified it in structural coordinates, so we always know the relative vector from the CG to the VRP (remember, the CG floats). By placing the nose (the common VRP) of the 3D model at the world-space coordinates that the FDM determines, the CG of the 3D visual model is located correctly - it's co-located with the CG as it is placed also according to where the FDM says it should be. The 3D coordinates that comprise an aircraft visual model do not change. If the nose VRP is located at (10,0,20) then it will always be at (10,0,20). If the FDM model for an aircraft has the common VRP located at -15,0,400 then it will always be *there*. The FDM calculates the position of the CG using the 6DoF equations of motion. The relative vector from the CG to the VRP as calculated by the FDM is the glue that ties the two frames together. > You > may look at only your reference point. But when you move the plane, and you're > saying 'hey it looks like we got the nose and reference point right', how do you > tell? > You judge it's motion relative
Re: [Flightgear-devel] Panel Building ?!?
On Sunday 11 January 2004 19:28, Jon Berndt wrote: > > Hi Folks and TIA! > > > > I'm thinking I want to get into building panels for FG > > aircraft. Either I am missing it or the tools for the job are > > vi, gimp, an XML reference and all the FG header files ?!? > > > > Any comments or suggestions appreciated! > > If you don't have any particular aircraft in mind to start out > with, IIRC the 747 needs some work! :-) I'll keep that one in mind, figuring out which one to work on was a bit of a challenge :-). I've got some kind of library location hell going on with the system all of a sudden and as soon as I can figure that out we'll see what we can do. Thanks & take care, Vikki -- Victoria Welch, WV9K/7, SysAdmin, Embedded Systems Designer. Like winter snow on summer lawn, time past is time gone. 'Two of the gravest general dangers to survival are the desire for comfort and a passive outlook.' -- U.S. Army Ranger Handbook ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Panel Building ?!?
> Hi Folks and TIA! > > I'm thinking I want to get into building panels for FG aircraft. > Either I am missing it or the tools for the job are vi, gimp, an > XML reference and all the FG header files ?!? > > Any comments or suggestions appreciated! If you don't have any particular aircraft in mind to start out with, IIRC the 747 needs some work! :-) Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear mouse pad
That's gotta be faked. I don't think even a Onyx 3000 InfinitePerformance could provide that kind of frame rate. If so, I really gotta know... Curtis L. Olson wrote: Hof Markus wrote: nice layout... is this a faked frame rate? ;-) if not pretty good. how come? Probably because Eric runs on sgi hardware. :-) Curt. -- Russ Conway's Law: "The structure of a system tends to mirror the structure of the group producing it." -- Mel Conway Datamation (1968) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Panel Building ?!?
Victoria Welch wrote: I'm thinking I want to get into building panels for FG aircraft. Either I am missing it or the tools for the job are vi, gimp, an XML reference and all the FG header files ?!? Actually, the preferred method would be Blender/AC3D, GIMP, and vi/emacs -- panel instruments made as proper 3D objects are the way to go, if you can manage it. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Panel Building ?!?
Victoria Welch wrote: I'm thinking I want to get into building panels for FG aircraft. Either I am missing it or the tools for the job are vi, gimp, an XML reference and all the FG header files ?!? Any comments or suggestions appreciated! I'll chime in with a couple comments. First off, yes this definitely looks intimidating at first glance, but give it a chance. Once you jump in and start working with the files, it's not nearly as bad as it might have first appeared. After you stare at xml for a bit, it does start to make sense and becomes much more human readable. I believe you can type "Shift-F3" to reload panel changes on the fly, so you can immediate test your change without needing to restart FlightGear or do any kind of compiling. That is *extremely* convenient when you are tweaking the instruments. There are numerous examples of panels, so in many case you could start by piecing together existing stuff. That get's you up and running quickly and then you can make aircraft specific changes at your liesure. So far, what I've said has mostly applied to 2d panels. If you are interested in building 3d panels, then you'll probably want tips and advice from the 3d panel experts (which isn't me.) :-) Regards, Curt. -- Curtis Olson Intelligent Vehicles Lab 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
[Flightgear-devel] Panel Building ?!?
Hi Folks and TIA! I'm thinking I want to get into building panels for FG aircraft. Either I am missing it or the tools for the job are vi, gimp, an XML reference and all the FG header files ?!? Any comments or suggestions appreciated! Thanks & take care, Vikki. -- Victoria Welch, WV9K/7, SysAdmin, Embedded Systems Designer. Like winter snow on summer lawn, time past is time gone. 'Two of the gravest general dangers to survival are the desire for comfort and a passive outlook.' -- U.S. Army Ranger Handbook ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS building fails, do I have a problem here?
Thanks very much Curt, out to you fg address as requested.
On Sunday 11 January 2004 18:19, Curtis L. Olson wrote:
> From what you've sent I'm not seeing anything obvious, but
> perhaps you could send me a) the console output of running the
> configure script and b) your entire config.log file. (Send these
> directly to me, not to the list.) What OS are you running?
>
> Curt.
>
> Victoria Welch wrote:
> > Hi Curt,
> >
> > Thanks for the response. I went through config log (~=2500
> > lines :) and am no more enlightended - see below :-(.
> >
> > On Sunday 11 January 2004 14:14, Curtis L. Olson wrote:
> >>Vikki,
> >>
> >>I don't see -lglut listed on the link command line. You
> >> probably want to rerun the configure script and make sure that
> >> the glut test there succeeds. If not, then look in your
> >> config.log to see exactly what failed.
> >
> > grep -inA 2 failed config.log | less
> >
> > 117:configure: failed program was:
> > 118-| #ifndef __cplusplus
> > 119-| choke me
> > --
> > 131:configure: failed program was:
> > 132-| #line 2718 "configure"
> > 133-| /* confdefs.h. */
> >
> > [ 24 more iterations of the last second one ]
> >
> > configure: exit 0
> >
> > I am not at all sure what I am looking for, but if it is saying
> > I don't have c++, well true, but I do have:
> >
> > {~/fgfs/FlightGear} $ g++
> > g++: no input files
> >
> > apparent problems with glut?!?:
> > --
> > 1233:configure:7842: checking for library containing
> > glutGetModifiers
> > 1234-configure:7873: gcc -o conftest -march=athlon-xp -O2 -g
> > -fomit-frame-pointer -mfpmath=sse -pipe -D_REE
> > NTRANT -I/usr/local/include -I/usr/X11R6/include -g
> > -L/usr/local/lib -L/usr/X11R6/lib conftest.c -lMesaGLU
> > -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -ldl -lm >&5
> > 1235-/tmp/cc2M1u2j.o(.text+0xa): In function `main':
> > 1236:/home/vw/fgfs/FlightGear/configure:7892: undefined
> > reference to `glutGetModifiers'
> > 1237-collect2: ld returned 1 exit status
> > 1238-configure:7876: $? = 1
> > --
> > --
> > 1288:configure:7918: gcc -o conftest -march=athlon-xp -O2 -g
> > -fomit-frame-pointer -mfpmath=sse -pipe -D_REE
> > NTRANT -I/usr/local/include -I/usr/X11R6/include -g
> > -L/usr/local/lib -L/usr/X11R6/lib conftest.c -lglut -l
> > MesaGLU -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -ldl -lm
> > >&5
> > 1289:/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/../../../libglut.
> >so: undefined reference to `glXBindChannelTo
> > WindowSGIX'
> > 1290:/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/../../../libglut.
> >so: undefined reference to `glXQueryChannelD
> > eltasSGIX'
> > 1291:/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/../../../libglut.
> >so: undefined reference to `glXChannelRectSy
> > ncSGIX'
> > 1292:/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/../../../libglut.
> >so: undefined reference to `glXChannelRectSG
> > IX'
> > 1293:/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/../../../libglut.
> >so: undefined reference to `glXQueryChannelR
> > ectSGIX'
> > 1294-collect2: ld returned 1 exit status
> > 1295-configure:7921: $? = 1
> >
> > Sorry to include so much stuff here, but I am lost :-(.
> >
> > Is it possible that I have the wrong version of glut? If so, I
> > would think that configure would blow out ?!?!
> >
> > Thanks & take care, Vikki.
> > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> >=-=-=-=-=-=-=-=-=-=-=-
> >
> >>Victoria Welch wrote:
> >>>Hi Folks,
> >>>
> >>> A couple days or so back I updated CVS and have not been
> >>> able to rebuild FG since. Not sure if I have a problem (most
> >>> likely I think) or if there is a problem with CVS:
> >>>==
> >>>Configure Summary
> >>>=
> >>>Prefix: /usr/local
> >>>Debug messages: yes
> >>>Automake version: automake (GNU automake) 1.5
> >>>Using FGEnvironment
> >>>Building with multiplayer support
> >>>threads: yes
> >>>Making all in tests
> >>>make[1]: Entering directory `/home/vw/fgfs/FlightGear/tests'
> >>>gcc -march=athlon-xp -O2 -g -fomit-frame-pointer -mfpmath=sse
> >>>-pipe -D_REENTRANT -g -L/usr/local/lib -L/usr/X11R6/lib -o
> >>>gl-info gl-info.o -lMesaGLU -lGL -lXmu -lXt -lSM -lICE -lXi
> >>>-lXext -lX11 -ldl -lm -ljpeg
> >>>gl-info.o(.text+0x147): In function `main':
> >>>/home/vw/fgfs/FlightGear/tests/gl-info.c:59: undefined
> >>>reference to `glutInit'
> >>>gl-info.o(.text+0x153):/home/vw/fgfs/FlightGear/tests/gl-info.
> >>>c
> >>>
> >>>:60: undefined reference to `glutInitDisplayMode'
> >>>
> >>>gl-info.o(.text+0x15f):/home/vw/fgfs/FlightGear/tests/gl-info.
> >>>c
> >>>
> >>>:61: undefined reference to `glutCreateWindow'
> >>>
> >>>collect2: ld returned 1 exit status
> >>>make[1]: *** [gl-info] Error 1
> >>>make[1]: Leaving directory `/home/vw/fgfs/FlightGear/tests'
> >>>make: *** [all-recursive] Error 1
> >>>
> >>>=
> >>>
> >>>I do have glut:
> >>>=
> >>>{
Re: [Flightgear-devel] CVS building fails, do I have a problem here?
From what you've sent I'm not seeing anything obvious, but perhaps you
could send me a) the console output of running the configure script and b)
your entire config.log file. (Send these directly to me, not to the list.)
What OS are you running?
Curt.
Victoria Welch wrote:
Hi Curt,
Thanks for the response. I went through config log (~=2500 lines :)
and am no more enlightended - see below :-(.
On Sunday 11 January 2004 14:14, Curtis L. Olson wrote:
Vikki,
I don't see -lglut listed on the link command line. You probably
want to rerun the configure script and make sure that the glut
test there succeeds. If not, then look in your config.log to see
exactly what failed.
grep -inA 2 failed config.log | less
117:configure: failed program was:
118-| #ifndef __cplusplus
119-| choke me
--
131:configure: failed program was:
132-| #line 2718 "configure"
133-| /* confdefs.h. */
[ 24 more iterations of the last second one ]
configure: exit 0
I am not at all sure what I am looking for, but if it is saying I
don't have c++, well true, but I do have:
{~/fgfs/FlightGear} $ g++
g++: no input files
apparent problems with glut?!?:
--
1233:configure:7842: checking for library containing
glutGetModifiers
1234-configure:7873: gcc -o conftest -march=athlon-xp -O2 -g
-fomit-frame-pointer -mfpmath=sse -pipe -D_REE
NTRANT -I/usr/local/include -I/usr/X11R6/include -g -L/usr/local/lib
-L/usr/X11R6/lib conftest.c -lMesaGLU
-lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -ldl -lm >&5
1235-/tmp/cc2M1u2j.o(.text+0xa): In function `main':
1236:/home/vw/fgfs/FlightGear/configure:7892: undefined reference to
`glutGetModifiers'
1237-collect2: ld returned 1 exit status
1238-configure:7876: $? = 1
--
--
1288:configure:7918: gcc -o conftest -march=athlon-xp -O2 -g
-fomit-frame-pointer -mfpmath=sse -pipe -D_REE
NTRANT -I/usr/local/include -I/usr/X11R6/include -g -L/usr/local/lib
-L/usr/X11R6/lib conftest.c -lglut -l
MesaGLU -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -ldl -lm >&5
1289:/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/../../../libglut.so:
undefined reference to `glXBindChannelTo
WindowSGIX'
1290:/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/../../../libglut.so:
undefined reference to `glXQueryChannelD
eltasSGIX'
1291:/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/../../../libglut.so:
undefined reference to `glXChannelRectSy
ncSGIX'
1292:/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/../../../libglut.so:
undefined reference to `glXChannelRectSG
IX'
1293:/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/../../../libglut.so:
undefined reference to `glXQueryChannelR
ectSGIX'
1294-collect2: ld returned 1 exit status
1295-configure:7921: $? = 1
Sorry to include so much stuff here, but I am lost :-(.
Is it possible that I have the wrong version of glut? If so, I
would think that configure would blow out ?!?!
Thanks & take care, Vikki.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Victoria Welch wrote:
Hi Folks,
A couple days or so back I updated CVS and have not been able
to rebuild FG since. Not sure if I have a problem (most likely
I think) or if there is a problem with CVS:
==
Configure Summary
=
Prefix: /usr/local
Debug messages: yes
Automake version: automake (GNU automake) 1.5
Using FGEnvironment
Building with multiplayer support
threads: yes
Making all in tests
make[1]: Entering directory `/home/vw/fgfs/FlightGear/tests'
gcc -march=athlon-xp -O2 -g -fomit-frame-pointer -mfpmath=sse
-pipe -D_REENTRANT -g -L/usr/local/lib -L/usr/X11R6/lib -o
gl-info gl-info.o -lMesaGLU -lGL -lXmu -lXt -lSM -lICE -lXi
-lXext -lX11 -ldl -lm -ljpeg
gl-info.o(.text+0x147): In function `main':
/home/vw/fgfs/FlightGear/tests/gl-info.c:59: undefined
reference to `glutInit'
gl-info.o(.text+0x153):/home/vw/fgfs/FlightGear/tests/gl-info.c
:60: undefined reference to `glutInitDisplayMode'
gl-info.o(.text+0x15f):/home/vw/fgfs/FlightGear/tests/gl-info.c
:61: undefined reference to `glutCreateWindow'
collect2: ld returned 1 exit status
make[1]: *** [gl-info] Error 1
make[1]: Leaving directory `/home/vw/fgfs/FlightGear/tests'
make: *** [all-recursive] Error 1
=
I do have glut:
=
{~/.fgfs} $ emerge -s glut
Searching...
[ Results for search key : glut ]
[ Applications found : 1 ]
* media-libs/glut
Latest version available: 3.7.1
Latest version installed: 3.7.1
Size of downloaded files: 2,479 kB
Homepage:
http://www.opengl.org/developers/documentation/glut/
Description: The OpenGL Utility Toolkit (GLUT)
=
So I am confused :-) - would much appreciate any comments on
this issue!
Thanks & take care, Vikki.
--
Curtis Olson Intelligent Vehicles Lab FlightGear Project
Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED]
Minneso
Re: [Flightgear-devel] FlightGear mouse pad
On Mon, 12 Jan 2004, Erik Hofman wrote: > Hi, > > Does anybody know a good place to print a mouse pad: > http://www.a1.nl/~ehofman/fgfs/gallery/fgfs-mousepad.png For somewhere UK based - www.fotopic.net. It's mainly an online photo album system, but you can also order prints, shirts, mugs, mouse mats, etc etc. (It's only fair to tell you that I'm their sysadmin :-) -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft frames and reference points
Jon Berndt wrote: We're not tricking ourselves into anything. Like we have mentioned numerous times before: We are providing the 3D model with a location in space where a known point should be co-located with. We still do (and always have) provide phi, theta, and psi, which are the same regardless of the point of reference. We know at all times the aircraft body-frame vector from the CG to the VRP (visual reference point). We know the body-to-local frame conversion matrix at any time. Thus, we know the real world location where the 3D model VRP should be placed so that the motion calculated by the FDM is properly reflected in the motion of the 3D model. Jon If you know everything about both frames all the time, then why is there ever a need for any adjustment figure? Everything was calculated, all needed reference points were known already from the VRM to the FDM, you didn't adjust anything there was no need. Some of these factors weren't known at first if people can draw planes of any relative size in the drawing program. You are figuring out the size relationship somehow, it is not set if they can just draw the model any size. If one person can draw it twice as large as another, and you can match the FDM to it, then you are matching more than just the nose point somehow. You are making your scale bigger somehow, or shrinking their drawing, if you can match the bigger model. If not then you have to move your nose around to match, then change every motion constant in the FDM to make a large drawn model act large, and a small model act small. And even then the modeler has to draw it the right size, they have to make the model 30 feet if it needs to be 30 feet. I know you're doing it correctly. The models, once adjusted, look and act properly. It is your explanation of how the two reference frames fully match is what's lacking. You say no no we only adjust the nose, when really you are doing other things too to match the visual and FDM frames with your adjustment figure, even if you don't see it. You are making every point match in scale in both frames, not just the nose. Your adjustment figure is from the nose in one frame to a reference in the other. Your scale is either known set or adjusted along with this adjustment through other factors. And when you get a new model, and move it around with your nose adjustment figure, and aligning your reference point, you are aligning your CG's even if you don't say you're aligning your CG's. Yes, they fall into alignment when you get your reference points matched and your nose was in the right place. But how is it you know when your reference point looks like it matches? By the CG. You may look at only your reference point. But when you move the plane, and you're saying 'hey it looks like we got the nose and reference point right', how do you tell? You judge it's motion relative the motion of the CG. You are matching the CG of the FDM to look in the right spot. Even if you say 'No, we are only looking at this other spot swinging around the way it should', you are really looking at it swinging around another point, the CG, when you check it visually. Like it or not that is how you are almost guaranteed to be aligning the visual model. There is very little else to accurately gague in a visual model in motion than 'is the model rotating correctly around the CG?' When you're aligning the visual with your number you're aligning the CG point, even if you do it through reference to some other reference point. Regardless, there is a 3 or 4 sentence explanation of exactly how every point in your FDM frame, and the entire visual model frame, match. This includes matching any model of any size. It can be said easily, without saying "We only align the nose, you're not getting it." You are leaving something out of your objective explanation of how they match. You put it all in no doubt with the relative points match since it works in the program. But there is a simple overall description of how it matches that is much more accurate than 'we just align the nose'. No wonder you've discussed it to the point of being blue in the face if you haven't got the simple full reference match description to rattle off. Don't worry about writing more trying to explain. If you guys aren't seeing the simple objective explanation I was originally asking for, you could write all day and never say it. I will look at the FDM adjustments and adjust several models. And put a different model of a different size on one and change the numbers until it works and see how the visual to FDM scaling is done. I will then come back and give you a 3 or 4 sentence explanation of how all points in the visual model match up and are adjusted for size and position to the FDM. Maybe a picture or two if it's needed for clarity. I am not the one not getting it. There is a simple relationship between the frame
Re: [Flightgear-devel] CVS building fails, do I have a problem here?
Hi Curt,
Thanks for the response. I went through config log (~=2500 lines :)
and am no more enlightended - see below :-(.
On Sunday 11 January 2004 14:14, Curtis L. Olson wrote:
> Vikki,
>
> I don't see -lglut listed on the link command line. You probably
> want to rerun the configure script and make sure that the glut
> test there succeeds. If not, then look in your config.log to see
> exactly what failed.
grep -inA 2 failed config.log | less
117:configure: failed program was:
118-| #ifndef __cplusplus
119-| choke me
--
131:configure: failed program was:
132-| #line 2718 "configure"
133-| /* confdefs.h. */
[ 24 more iterations of the last second one ]
configure: exit 0
I am not at all sure what I am looking for, but if it is saying I
don't have c++, well true, but I do have:
{~/fgfs/FlightGear} $ g++
g++: no input files
apparent problems with glut?!?:
--
1233:configure:7842: checking for library containing
glutGetModifiers
1234-configure:7873: gcc -o conftest -march=athlon-xp -O2 -g
-fomit-frame-pointer -mfpmath=sse -pipe -D_REE
NTRANT -I/usr/local/include -I/usr/X11R6/include -g -L/usr/local/lib
-L/usr/X11R6/lib conftest.c -lMesaGLU
-lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -ldl -lm >&5
1235-/tmp/cc2M1u2j.o(.text+0xa): In function `main':
1236:/home/vw/fgfs/FlightGear/configure:7892: undefined reference to
`glutGetModifiers'
1237-collect2: ld returned 1 exit status
1238-configure:7876: $? = 1
--
--
1288:configure:7918: gcc -o conftest -march=athlon-xp -O2 -g
-fomit-frame-pointer -mfpmath=sse -pipe -D_REE
NTRANT -I/usr/local/include -I/usr/X11R6/include -g -L/usr/local/lib
-L/usr/X11R6/lib conftest.c -lglut -l
MesaGLU -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -ldl -lm >&5
1289:/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/../../../libglut.so:
undefined reference to `glXBindChannelTo
WindowSGIX'
1290:/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/../../../libglut.so:
undefined reference to `glXQueryChannelD
eltasSGIX'
1291:/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/../../../libglut.so:
undefined reference to `glXChannelRectSy
ncSGIX'
1292:/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/../../../libglut.so:
undefined reference to `glXChannelRectSG
IX'
1293:/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/../../../libglut.so:
undefined reference to `glXQueryChannelR
ectSGIX'
1294-collect2: ld returned 1 exit status
1295-configure:7921: $? = 1
Sorry to include so much stuff here, but I am lost :-(.
Is it possible that I have the wrong version of glut? If so, I
would think that configure would blow out ?!?!
Thanks & take care, Vikki.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>
> Victoria Welch wrote:
> > Hi Folks,
> >
> > A couple days or so back I updated CVS and have not been able
> > to rebuild FG since. Not sure if I have a problem (most likely
> > I think) or if there is a problem with CVS:
> > ==
> > Configure Summary
> > =
> > Prefix: /usr/local
> > Debug messages: yes
> > Automake version: automake (GNU automake) 1.5
> > Using FGEnvironment
> > Building with multiplayer support
> > threads: yes
> > Making all in tests
> > make[1]: Entering directory `/home/vw/fgfs/FlightGear/tests'
> > gcc -march=athlon-xp -O2 -g -fomit-frame-pointer -mfpmath=sse
> > -pipe -D_REENTRANT -g -L/usr/local/lib -L/usr/X11R6/lib -o
> > gl-info gl-info.o -lMesaGLU -lGL -lXmu -lXt -lSM -lICE -lXi
> > -lXext -lX11 -ldl -lm -ljpeg
> > gl-info.o(.text+0x147): In function `main':
> > /home/vw/fgfs/FlightGear/tests/gl-info.c:59: undefined
> > reference to `glutInit'
> > gl-info.o(.text+0x153):/home/vw/fgfs/FlightGear/tests/gl-info.c
> >:60: undefined reference to `glutInitDisplayMode'
> > gl-info.o(.text+0x15f):/home/vw/fgfs/FlightGear/tests/gl-info.c
> >:61: undefined reference to `glutCreateWindow'
> > collect2: ld returned 1 exit status
> > make[1]: *** [gl-info] Error 1
> > make[1]: Leaving directory `/home/vw/fgfs/FlightGear/tests'
> > make: *** [all-recursive] Error 1
> >
> > =
> >
> > I do have glut:
> > =
> > {~/.fgfs} $ emerge -s glut
> > Searching...
> > [ Results for search key : glut ]
> > [ Applications found : 1 ]
> >
> > * media-libs/glut
> > Latest version available: 3.7.1
> > Latest version installed: 3.7.1
> > Size of downloaded files: 2,479 kB
> > Homepage:
> > http://www.opengl.org/developers/documentation/glut/
> > Description: The OpenGL Utility Toolkit (GLUT)
> >
> > =
> >
> > So I am confused :-) - would much appreciate any comments on
> > this issue!
> >
> > Thanks & take care, Vikki.
--
Victoria Welch, WV9K/7, SysAdmin, Embedded Systems Designer.
Like winter snow on summer lawn, time past is time gone.
'Two of the gravest general dangers to survival are the desire for
comfo
Re: [Flightgear-devel] FlightGear mouse pad
Might want to add some flags to the FG logo before doing the press. (Slovene?) - Matevz Jon Berndt wrote: cafepress.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Erik Hofman Sent: Sunday, January 11, 2004 5:12 PM To: FlightGear developers discussions Subject: [Flightgear-devel] FlightGear mouse pad Hi, Does anybody know a good place to print a mouse pad: http://www.a1.nl/~ehofman/fgfs/gallery/fgfs-mousepad.png Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear mouse pad
Hof Markus wrote: nice layout... is this a faked frame rate? ;-) if not pretty good. how come? Probably because Eric runs on sgi hardware. :-) Curt. -- Curtis Olson Intelligent Vehicles Lab 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
RE: [Flightgear-devel] 3D aircraft model origins
Sorry Jim. "Jim Wilson writes> Innis Cunningham <[EMAIL PROTECTED]> said: > Take Lee's P51 it has its MRP at the nose. That's mine :-) > Jim _ E-mail just got a whole lot better. New ninemsn Premium. Click here http://ninemsn.com.au/premium/landing.asp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear mouse pad
nice layout... is this a faked frame rate? ;-) if not pretty good. how come? Quoting Erik Hofman <[EMAIL PROTECTED]>: > Does anybody know a good place to print a mouse pad: > http://www.a1.nl/~ehofman/fgfs/gallery/fgfs-mousepad.png > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] FlightGear mouse pad
cafepress.com > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Erik Hofman > Sent: Sunday, January 11, 2004 5:12 PM > To: FlightGear developers discussions > Subject: [Flightgear-devel] FlightGear mouse pad > > > > > Hi, > > Does anybody know a good place to print a mouse pad: > http://www.a1.nl/~ehofman/fgfs/gallery/fgfs-mousepad.png > > Erik > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] FlightGear mouse pad
Hi, Does anybody know a good place to print a mouse pad: http://www.a1.nl/~ehofman/fgfs/gallery/fgfs-mousepad.png Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] 3D aircraft model origins
> > Any chance that would be happening soon? > > > > Best, > > > > Jim > > It's in work at this instant and nearly complete. > > Jon It's done. Beta version, anyhow. See the announcement in the JSBSim list. Jon -- Project Coordinator JSBSim Flight Dynamics Model http://www.jsbsim.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS building fails, do I have a problem here?
Vikki,
I don't see -lglut listed on the link command line. You probably want to
rerun the configure script and make sure that the glut test there succeeds.
If not, then look in your config.log to see exactly what failed.
Regards,
Curt.
Victoria Welch wrote:
Hi Folks,
A couple days or so back I updated CVS and have not been able to
rebuild FG since. Not sure if I have a problem (most likely I
think) or if there is a problem with CVS:
==
Configure Summary
=
Prefix: /usr/local
Debug messages: yes
Automake version: automake (GNU automake) 1.5
Using FGEnvironment
Building with multiplayer support
threads: yes
Making all in tests
make[1]: Entering directory `/home/vw/fgfs/FlightGear/tests'
gcc -march=athlon-xp -O2 -g -fomit-frame-pointer -mfpmath=sse -pipe
-D_REENTRANT -g -L/usr/local/lib -L/usr/X11R6/lib -o gl-info
gl-info.o -lMesaGLU -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11
-ldl -lm -ljpeg
gl-info.o(.text+0x147): In function `main':
/home/vw/fgfs/FlightGear/tests/gl-info.c:59: undefined reference to
`glutInit'
gl-info.o(.text+0x153):/home/vw/fgfs/FlightGear/tests/gl-info.c:60:
undefined reference to `glutInitDisplayMode'
gl-info.o(.text+0x15f):/home/vw/fgfs/FlightGear/tests/gl-info.c:61:
undefined reference to `glutCreateWindow'
collect2: ld returned 1 exit status
make[1]: *** [gl-info] Error 1
make[1]: Leaving directory `/home/vw/fgfs/FlightGear/tests'
make: *** [all-recursive] Error 1
=
I do have glut:
=
{~/.fgfs} $ emerge -s glut
Searching...
[ Results for search key : glut ]
[ Applications found : 1 ]
* media-libs/glut
Latest version available: 3.7.1
Latest version installed: 3.7.1
Size of downloaded files: 2,479 kB
Homepage:
http://www.opengl.org/developers/documentation/glut/
Description: The OpenGL Utility Toolkit (GLUT)
=
So I am confused :-) - would much appreciate any comments on this
issue!
Thanks & take care, Vikki.
--
Curtis Olson Intelligent Vehicles Lab 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
[Flightgear-devel] CVS building fails, do I have a problem here?
Hi Folks,
A couple days or so back I updated CVS and have not been able to
rebuild FG since. Not sure if I have a problem (most likely I
think) or if there is a problem with CVS:
==
Configure Summary
=
Prefix: /usr/local
Debug messages: yes
Automake version: automake (GNU automake) 1.5
Using FGEnvironment
Building with multiplayer support
threads: yes
Making all in tests
make[1]: Entering directory `/home/vw/fgfs/FlightGear/tests'
gcc -march=athlon-xp -O2 -g -fomit-frame-pointer -mfpmath=sse -pipe
-D_REENTRANT -g -L/usr/local/lib -L/usr/X11R6/lib -o gl-info
gl-info.o -lMesaGLU -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11
-ldl -lm -ljpeg
gl-info.o(.text+0x147): In function `main':
/home/vw/fgfs/FlightGear/tests/gl-info.c:59: undefined reference to
`glutInit'
gl-info.o(.text+0x153):/home/vw/fgfs/FlightGear/tests/gl-info.c:60:
undefined reference to `glutInitDisplayMode'
gl-info.o(.text+0x15f):/home/vw/fgfs/FlightGear/tests/gl-info.c:61:
undefined reference to `glutCreateWindow'
collect2: ld returned 1 exit status
make[1]: *** [gl-info] Error 1
make[1]: Leaving directory `/home/vw/fgfs/FlightGear/tests'
make: *** [all-recursive] Error 1
=
I do have glut:
=
{~/.fgfs} $ emerge -s glut
Searching...
[ Results for search key : glut ]
[ Applications found : 1 ]
* media-libs/glut
Latest version available: 3.7.1
Latest version installed: 3.7.1
Size of downloaded files: 2,479 kB
Homepage:
http://www.opengl.org/developers/documentation/glut/
Description: The OpenGL Utility Toolkit (GLUT)
=
So I am confused :-) - would much appreciate any comments on this
issue!
Thanks & take care, Vikki.
--
Victoria Welch, WV9K/7, SysAdmin, Embedded Systems Designer.
Like winter snow on summer lawn, time past is time gone.
'Two of the gravest general dangers to survival are the desire for
comfort and a passive outlook.' -- U.S. Army Ranger Handbook
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] 3D aircraft model origins
[to Jim, in particular]
I have added code in JSBSim that calculates the relative position in local
frame ("world space", in units of feet) of the common Visual Reference Point
(VRP) with respect to the current CG. The nest thing I have to do is to
modify the lat/lon/alt that the FDM owns. The VRP offset now calculated (in
feet) must modify the lat/lon/alt that he FDM currently calculates, but it
will take some thought for me to figure out how to best do this. Anybody
have any hints?
Jon
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Duplicate node?
John Wojnaroski wrote: Walking thru some code yesterday, I noticed the following: In tilemgr.cxx at lines 319 and 321 there are two entries for adding taxi lights. Is that what is intended? Yeah you are right, there is a problem there. I have checked in a fix to CVS. Curt. -- Curtis Olson Intelligent Vehicles Lab 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
[Flightgear-devel] Re: external A/C lights
* Hof Markus -- Sunday 11 January 2004 19:52: > Where can strobe/landing .. lights added to a A/C model? > So you can see them in external view. I haven't seen one with C172, so I'm > unsure if FG supports this by now. Look at how Jim did it with his p51d: $ fgfs --aircraft=p51d m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] external A/C lights
Where can strobe/landing .. lights added to a A/C model? So you can see them in external view. I haven't seen one with C172, so I'm unsure if FG supports this by now. markus ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aircraft frames and reference points
Alan wrote: >Note this fact. If you have the CG point as the reference, then scale > matters very little to the motions of flying. Only the point reference makes > the models match reasonably well. You still need a distance measurement to know > the scale and work out CG shifts, where the nose, wheel, and tail really are, > etc though. Even the control forces off. But the motion point is not, for both > rotation and translation. The simulation world seldom works out like a hand in glove. There are always tradeoffs. We designed the current system to handle these *facts*: 1) The 3D modeler will not know or care about where the CG is. We often may inherit a visual model from another project. 2) The FDM designer knows (or must find out) the location of the CG on the aircraft frame (empty weight), the location of the gear bogies, the pilot eyepoint, etc. 3) The 3D modeler and the FDM designer must agree on something. A known fixed point would be a good thing to agree on. Since the CG shifts during flight, the nose tip is a good compromise. 4) As engineers, physicists, etc. (which are among our cadre of developers), we know about rotations, offsets, etc. 5) We're about ready to try this fix. We'll see how well it works. >You aren't just using the nose point. No matter how much you trick > yourselves into saying that you're only using the nose, and just > 'fixing it', you are really providing a distance reference back to another > point. We're not tricking ourselves into anything. Like we have mentioned numerous times before: We are providing the 3D model with a location in space where a known point should be co-located with. We still do (and always have) provide phi, theta, and psi, which are the same regardless of the point of reference. We know at all times the aircraft body-frame vector from the CG to the VRP (visual reference point). We know the body-to-local frame conversion matrix at any time. Thus, we know the real world location where the 3D model VRP should be placed so that the motion calculated by the FDM is properly reflected in the motion of the 3D model. Jon > It takes one point with full orientation, and another point to completely > match two reference frames. There is no way to get around that fact. What > you are really doing is having the nose point and a difference reference, and > then working everything out from that bringing everything into alignment. > That includes most importantly for visual motion to FDM motion match the CG. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft frames and reference points
Dude, give it up. You are wrong. Accept it and move on with your life. On Sun, 2004-01-11 at 09:13, Alan King wrote: > Jon Berndt wrote: > >>Jon Berndt wrote: > >> > >> > >>>Model Reference Point (MRP): This is the reference point that is agreed > >>>upon by both the aircraft modeler and the 3D model builder. > >> > >>I'd vote for calling it the "Visual Model Reference Point" because the > >>term model can still be used for the 3d model and he flight model. > >> > >>Erik > > > > > > True. > > > >Note this fact. If you have the CG point as the reference, then scale > matters very little to the motions of flying. Only the point reference makes > the models match reasonably well. You still need a distance measurement to know > the scale and work out CG shifts, where the nose, wheel, and tail really are, > etc though. Even the control forces off. But the motion point is not, for both > rotation and translation. > >You aren't just using the nose point. No matter how much you trick > yourselves into saying that you're only using the nose, and just 'fixing it', > you are really providing a distance reference back to another point. It takes > one point with full orientation, and another point to completely match two > reference frames. There is no way to get around that fact. What you are really > doing is having the nose point and a difference reference, and then working > everything out from that bringing everything into alignment. That includes most > importantly for visual motion to FDM motion match the CG. > >If you look across all your models of all scales, you will see that your > adjustments all bring the CG point of the visual model to the CG point of the > FDM. The CG to nose distance will be different, but that's in the offset > combined with whatever the FDM does with the offset to find the CG point. > > >Take all of the models. Put all of the nose points at exactly the same spot. > put the FDM nose point there. Note that you have a range of CG's based on how > large the plane drawing is. And your 'nose fix adjustment' is the distance to > some other point. Then your FDM works out the CG point of each size model from > that other known adjustment and your CG is in the right place in both models. > We already put all the nose points into one spot. If your alignment system only > needs the nose point to match in the FDM and the visual model, then set the FDM > nose to a known point, put all the visual nose points there, and your models > will all work no matter what size. This doesn't work, even though all of your > nose points are now correctly known. It doesn't work because you need a nose > point known, plus another number to some other reference point. This other > reference gives you scale, and then put all other points in their place. Most > importantly to visual motion, it lets you put your CG where it goes on the > visual model. > >That was my original point, it is impossible to have just the nose point on > the visual model and not have anything else and have everything match regardless > of scaling between the FDM and the visual. You have to have some other > reference fix, that lets your FDM bring it's CG into alignment of where it > should be on the visual model. That you are hiding it from the model creator so > they don't have to find the CG of the visual model is a great idea. That you > are hiding it from yourselves though by saying you're 'fixing the nose point' > isn't as good. You're sliding everything around with this adjustment, not just > the nose point. And while it brings everything into line, the single most > important thing to how the model moves is getting the CG correct. You don't > have some arbitrary fixed point on the nose of both models that makes everything > line up. You have a fixed point on the visual model only. You then move it > around on your FDM model with your adjustment, until the CG is where is should > be for the visual model so the motion looks correct. If you double the scale of > the picture, you have to adjust your nose to CG distance through your > adjustment, even if that uses some other common reference point to get the CG in > the FDM. Your adjustment is fixing where the nose should be, relative to some > other point, so that that other point is where it should be, so that the CG is > now also calculated in the right position in the visual model. > >You don't have a 'nose point does everything' system. That adjustment isn't > some minor little tweak to your system. That 'adjustment' carries every bit as > much weight in aligning the system as the nose point. Using the nose point > first lets the model creator make the model without reference to scale, which is > great. But it just means that someone on the FDM side is fixing the scale later > through the adjustment, not that the nose point is the only thing and nothing > else
RE: [Flightgear-devel] fdm: fcs components
Quoting Jon Berndt <[EMAIL PROTECTED]>: > > When resetting the integrator, would you always want to reset the outputs > (current, and all previous outputs) to ZERO? I haven't thought about it very long, but for my application (desc. below) it was best to hold the I to 0 while Integrator not in use. This should be the same like a long reset I thougt. We can also use a set to OSETTO (Output set to) property, maybe this covers all needed cases. Asuming that a reset is a OSETTO 0 Yes, I think this would be nice. RESET <0 => I/ reset, /O set to OSETTO property 0 => no change >0 => /O only set OSETTO property. I don't know what you ment in case <0 to reset the I/ property? I can't imagine one case needing this, but good to have. So if you can reset this, you should also have a ISETTO property to set it. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] 3D aircraft model origins
> Jon S Berndt <[EMAIL PROTECTED]> said: > > I have still not delivered on my promise to provide the reference > > point to FlightGear. I don't know what we do for the C-172, in order > > to place it correctly. > > > > Any chance that would be happening soon? > > Best, > > Jim It's in work at this instant and nearly complete. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] fdm: fcs components
Quoting Jon Berndt <[EMAIL PROTECTED]>: > > Markus: > > If there was a RESET capability for the filters, it would be driven by > > non-zero value in the Reset attribute (which would need to be added to the > > FGFilter class). maybe you are right, it was a quickfix (10 mins) w/ first contact of jsb classes. :-) maybe I built in to wrong ones. I bound a second Input Property Node to use it as reset, an I think it should work as it is now. > > I think your proposed change to FGFilter might be very close to what is > > needed. > I am thinking that if the value of the Reset parameter is negative then all > inputs and outputs are initialized to 0.0, if positive the outputs are reset > to 0.0. If equal to 0 (an integer) then nothing is done. How does that > sound? this sounds fine... I only used !=0 to hold the integrator output to 0, so maybe the reset has to be != 0 for 2 cycles, to completly reset, but that didn't matter for my application. Yours sounds nice, to use also input resets. But be sure to hold this feature documented ;-) ... otherwise some people won't get what they expect the filter to do. markus ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft frames and reference points
Jon Berndt wrote: Jon Berndt wrote: Model Reference Point (MRP): This is the reference point that is agreed upon by both the aircraft modeler and the 3D model builder. I'd vote for calling it the "Visual Model Reference Point" because the term model can still be used for the 3d model and he flight model. Erik True. Note this fact. If you have the CG point as the reference, then scale matters very little to the motions of flying. Only the point reference makes the models match reasonably well. You still need a distance measurement to know the scale and work out CG shifts, where the nose, wheel, and tail really are, etc though. Even the control forces off. But the motion point is not, for both rotation and translation. You aren't just using the nose point. No matter how much you trick yourselves into saying that you're only using the nose, and just 'fixing it', you are really providing a distance reference back to another point. It takes one point with full orientation, and another point to completely match two reference frames. There is no way to get around that fact. What you are really doing is having the nose point and a difference reference, and then working everything out from that bringing everything into alignment. That includes most importantly for visual motion to FDM motion match the CG. If you look across all your models of all scales, you will see that your adjustments all bring the CG point of the visual model to the CG point of the FDM. The CG to nose distance will be different, but that's in the offset combined with whatever the FDM does with the offset to find the CG point. Take all of the models. Put all of the nose points at exactly the same spot. put the FDM nose point there. Note that you have a range of CG's based on how large the plane drawing is. And your 'nose fix adjustment' is the distance to some other point. Then your FDM works out the CG point of each size model from that other known adjustment and your CG is in the right place in both models. We already put all the nose points into one spot. If your alignment system only needs the nose point to match in the FDM and the visual model, then set the FDM nose to a known point, put all the visual nose points there, and your models will all work no matter what size. This doesn't work, even though all of your nose points are now correctly known. It doesn't work because you need a nose point known, plus another number to some other reference point. This other reference gives you scale, and then put all other points in their place. Most importantly to visual motion, it lets you put your CG where it goes on the visual model. That was my original point, it is impossible to have just the nose point on the visual model and not have anything else and have everything match regardless of scaling between the FDM and the visual. You have to have some other reference fix, that lets your FDM bring it's CG into alignment of where it should be on the visual model. That you are hiding it from the model creator so they don't have to find the CG of the visual model is a great idea. That you are hiding it from yourselves though by saying you're 'fixing the nose point' isn't as good. You're sliding everything around with this adjustment, not just the nose point. And while it brings everything into line, the single most important thing to how the model moves is getting the CG correct. You don't have some arbitrary fixed point on the nose of both models that makes everything line up. You have a fixed point on the visual model only. You then move it around on your FDM model with your adjustment, until the CG is where is should be for the visual model so the motion looks correct. If you double the scale of the picture, you have to adjust your nose to CG distance through your adjustment, even if that uses some other common reference point to get the CG in the FDM. Your adjustment is fixing where the nose should be, relative to some other point, so that that other point is where it should be, so that the CG is now also calculated in the right position in the visual model. You don't have a 'nose point does everything' system. That adjustment isn't some minor little tweak to your system. That 'adjustment' carries every bit as much weight in aligning the system as the nose point. Using the nose point first lets the model creator make the model without reference to scale, which is great. But it just means that someone on the FDM side is fixing the scale later through the adjustment, not that the nose point is the only thing and nothing else matters. That adjustment is just as critical to the alignment of the systems as the initial point. It takes both, the nose point isn't 'it' like some of you have tried to imply. There was something else to your system, which there had to be to bring the FDM and the visual model frames into full alignment. No singl
[Flightgear-devel] Duplicate node?
Hi Walking thru some code yesterday, I noticed the following: In tilemgr.cxx at lines 319 and 321 there are two entries for adding taxi lights. Is that what is intended? JW ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D aircraft model origins
Lee Elliott <[EMAIL PROTECTED]> said: > How about the frontmost point on the leading edge of the main-wings at the > root - or would that be snafu'd by LEXs? e.g. F-18. Could be a bit iffy on I think that actually would be the nose on a space shuttle model. ;-) One question that came up before was, "what about a hot air ballon?". There isn't anything that won't be confusing in some way. So it's going to require further qualification in some cases...which a comment in the FDM config will take care of. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D aircraft model origins
Innis Cunningham <[EMAIL PROTECTED]> said: > All the model is is 1 vertices flying in close formation Haha! That's about it for some of my modeling work. Gotta try and keep that vertex count down :-) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] 3D aircraft model origins
Innis Cunningham <[EMAIL PROTECTED]> said: > Take Lee's P51 it has its MRP at the nose. That's mine :-) > It is my understanding that the offset system was devised primarily to allow > MSFS A/C > to be positioned correctly. The model offsets yes. The view offsets no. > I stand corrected if this is not the case. OK Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] fdm: fcs components
> Markus: > > If there was a RESET capability for the filters, it would be driven by > non-zero value in the Reset attribute (which would need to be added to the > FGFilter class). > > I think your proposed change to FGFilter might be very close to what is > needed. > > Jon I am thinking that if the value of the Reset parameter is negative then all inputs and outputs are initialized to 0.0, if positive the outputs are reset to 0.0. If equal to 0 (an integer) then nothing is done. How does that sound? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] fdm: fcs components
Markus: If there was a RESET capability for the filters, it would be driven by non-zero value in the Reset attribute (which would need to be added to the FGFilter class). I think your proposed change to FGFilter might be very close to what is needed. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] fdm: fcs components
Markus: When resetting the integrator, would you always want to reset the outputs (current, and all previous outputs) to ZERO? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aircraft frames and reference points
> Jon Berndt wrote: > > > Model Reference Point (MRP): This is the reference point that is agreed > > upon by both the aircraft modeler and the 3D model builder. > > I'd vote for calling it the "Visual Model Reference Point" because the > term model can still be used for the 3d model and he flight model. > > Erik True. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] fdm: fcs components
I don't quite follow what is being done.
Jon
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Hof Markus
> Sent: Saturday, January 10, 2004 1:37 PM
> To: FlightGear developers discussions
> Subject: RE: [Flightgear-devel] fdm: fcs components
>
>
> Hi, enjoy your kids birthday. I got one Version running, but
> don't know if you
> like this way of implementaion, You maybe want to create an extra
> Node for this
> property.
>
> I took the keyword: RESET and any other input than 0 resets and holds the
> integrator to 0.
>
> Here is the patch:
> [EMAIL PROTECTED]:~/dl/fltgear/FlightGear-0.9.3/src/FDM/JSBSim/filtersjb
> $ diff -2 -u
> FGFilter.cpp FGFilter.cpp.orig
> --- FGFilter.cpp2004-01-10 20:04:25.0 +0100
> +++ FGFilter.cpp.orig 2004-01-10 19:44:09.0 +0100
> @@ -94,10 +94,4 @@
>OutputNode = PropertyManager->GetNode( sOutputIdx );
> }
> -else if (token == "RESET")
> -{
> - // Set the RESET as INPUT[1]
> -*AC_cfg >> token;
> -InputNodes.push_back( resolveSymbol(token) );
> -}
> else cerr << "Unknown filter type: " << token << endl;
>}
> @@ -177,13 +171,5 @@
> break;
>case eIntegrator:
> - if( InputNodes.size() == 2 )
> - {
> - if ( ( InputNodes[1]->getDoubleValue() ) == 0 )
> - Output = Input * ca + PreviousInput1 * ca +
> PreviousOutput1;
> - else
> - Output = 0;
> - }
> - else
> - Output = Input * ca + PreviousInput1 * ca +
> PreviousOutput1;
> +Output = Input * ca + PreviousInput1 * ca + PreviousOutput1;
> break;
>case eUnknown:
>
>
>
> Quoting Jon Berndt <[EMAIL PROTECTED]>:
>
> > This is a programming issue I'll tryu and get to ASAP. Today,
> though, is my
> > twin boys' second birthday.
> >
> > > -Original Message-
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED] Behalf Of
> Hof Markus
> > > Sent: Saturday, January 10, 2004 8:10 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: [Flightgear-devel] fdm: fcs components
> > >
> > >
> > > I have a pitch hold function modelled for the A320, activeted if
> > > Input = 0.
> > > If the A/C is in pitch-rate command, the Integrator for pitch
> > > hold is becoming
> > > more and more.
> > >
> > > How do I reset an Integrator component based on a switch like
> > > elevator-cmd-norm=0?
> > >
> > > thx
> > > markus
> > >
> > > PS: I hope you know what I mean, this seems to be not my day for
> > > explainations
> > > :))
> > >
> > >
> > > ___
> > > Flightgear-devel mailing list
> > > [EMAIL PROTECTED]
> > > http://mail.flightgear.org/mailman/listinfo/flightgear-devel
> >
> >
> > ___
> > Flightgear-devel mailing list
> > [EMAIL PROTECTED]
> > http://mail.flightgear.org/mailman/listinfo/flightgear-devel
> >
>
>
> ___
> Flightgear-devel mailing list
> [EMAIL PROTECTED]
> http://mail.flightgear.org/mailman/listinfo/flightgear-devel
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft frames and reference points
Jon Berndt wrote: Model Reference Point (MRP): This is the reference point that is agreed upon by both the aircraft modeler and the 3D model builder. I'd vote for calling it the "Visual Model Reference Point" because the term model can still be used for the 3d model and he flight model. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D aircraft model origins
I've been watching this thread with some interest. May I say how impressed I am with all that has been achieved so far. FWIW I thought I describe my experience of modelling a 3d aircraft. At the outset I used the nose as the origin of both the model and the FDM (YASIM in this case). The 3d model appeared to move around the nose in flight - clearly wrong. I followed Lee's example and moved the 3d model's origin to the CofG (derived from the YASIM calculations). The 3D model now looks right in flight. I note that Jim Wilson in his P51 model has used the nose as the origin, but has had to adjust all the views to the CofG in the 'p51d-YASIM-set' file so that the model appears to manoeuvre correctly. Either approach seems to work. Neither allows for the any change in the CofG, but since this is small in comparison to the scale of the model this does not really affect the appearance in flight. You pays yer money and takes yer choice. But you have to do one or the other to make it look right - using the nose as the origin and not adjusting the standard views looks wrong. I'm now going to follow Innes and retire into my bunker. Vivian Meazza (despite the name - English) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: 3D aircraft model origins
Hi, I fully agree with the MRP idea. It is just an arbitrary point in the model. Alan, I don't see a real argument in this translation you talk about. The computonal cost of this single translation is peanuts compared to the computations done elsewhere in flightgear. Also If you prefer to have the POS for the origin of your models you can use POS=MRP for you and you are done. So, I think everyone can be happy with the MRP thing! Greetings Mathias -- Mathias FrÃhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
