Re: [Flightgear-devel] XML SCripting
Mally wrote: You may not be a patent lawyer, but that's a convincing sounding explanation of the legal position. PS. I'm just wondering if you have any thoughts on my earlier question, i.e. whether what's being patented has to be something non-obvious? I didn't notice anything not obvious. They use XML as it was meant to be IMHO, actually the fact that XML allows this means that is actually an invention of the one who invented XML itself. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aerodynamic centre and 3D models
Lee Elliott wrote On Friday 13 February 2004 06:16, Jon Berndt wrote: True, but... This is a chunk of calculations running every frame. In the olden days, the cost would be too high. These days, it's not even a spec on a flea on the butt of an elephant in terms of the overall FDM calculations - which in turn are not much of a spec on a flea in the overall FlightGear calculations. Our Aerodynamic modelers always seemed to know where the empty weight CG was every frame without additional calculations. That's not the issue, though. We FDM guys know absolutely where everything is at all times within the FDMs. Yep:) Everything's right where we put it:) LeeE I'm about halfway through generating a 3d cockpit for the Seahawk model - are you going to move the origin of the model? I'd like a heads up, it will probably affect how I go about the rest of the work. Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Eye candy
On Friday 13 February 2004 22:27, Jon S Berndt wrote: Any chance of modeling wingtip vortices (when CL is high enough above some threshhold) and rocket engine exhaust? :-) Jon I've thought about trying this but I think it could only be really effective in level flight. As soon as you start banking the 'end' of whatever trail you're simulating will rotate (echos of the VRP issues:). For a very short trail this might not be noticable but for longer ones I think it's a bit of a show stopper. It would be possible to include curved trails in the model, and the select anim function could be used to select the appropriate model object, but then you'd need a wide range of trail objects. At first glance, this doesn't seem too bad, but then I think you'd really need several versions of each trail type so that you could switch between them to give the impression that the trail is changing throught time. Hmm... I don't think I've explained that bit very well... Consider an a/c in stable level flight where votices are being generated from the wing-tips. Even though the vortex trail may not change in length or shape, it's appreance will change from frame to frame, so you'd need to switch between several identically shaped and sized objects that are textured slightly differently to give the impression of change. If we could actually modify the model objects themselves then we could 'bend' the trails, and cut down on the number needed. But then we could also do wing flexing too. Before anyone starts thinking seriously about this, it would be very non-trivial to do, at least for the wings, where some objects would need to be 'bent' i.e. the wings and control surfaces, whereas other objects would have to simply translate i.e. wing mounted engine nacelles and U/C. For a simple object, like a vortex trail, bending might be feasible, and combined with scaling (which I think we already have), it might work ok. Another possiblity would be some sort of particle object handling where temporary objects could be generated, left for a while and then culled. We could then 'drop' a stream of these objects behind the a/c that're culled after a certain time. It'd probably need a lot of objects to work though, and it would also push up the object count of course. Both methods would need some carefull texturing. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
On Saturday 14 February 2004 13:07, Vivian Meazza wrote: Lee Elliott wrote On Friday 13 February 2004 06:16, Jon Berndt wrote: True, but... This is a chunk of calculations running every frame. In the olden days, the cost would be too high. These days, it's not even a spec on a flea on the butt of an elephant in terms of the overall FDM calculations - which in turn are not much of a spec on a flea in the overall FlightGear calculations. Our Aerodynamic modelers always seemed to know where the empty weight CG was every frame without additional calculations. That's not the issue, though. We FDM guys know absolutely where everything is at all times within the FDMs. Yep:) Everything's right where we put it:) LeeE I'm about halfway through generating a 3d cockpit for the Seahawk model - are you going to move the origin of the model? I'd like a heads up, it will probably affect how I go about the rest of the work. Regards Vivian That's great news. The only change that's likely to the Sea Hawk model will be to shift the origin to the nose;) This won't actually be too much of a problem and will only require simple offsets to the numbers in the anim and fdm files: Say I need to move the model 3 metres back and 0.1 metre up, then all we need to do is add 3 metres to all the 'x' measurements, and 0.1 to all the 'z' measurements in the fdm and anim files to line everything up again. (Heh!... or it might be _subtract_ 3 metres... maths was never my strong point) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Eye candy
Lee Elliott wrote On Friday 13 February 2004 22:27, Jon S Berndt wrote: Any chance of modeling wingtip vortices (when CL is high enough above some threshhold) and rocket engine exhaust? :-) Jon I've thought about trying this but I think it could only be really effective in level flight. As soon as you start banking the 'end' of whatever trail you're simulating will rotate (echos of the VRP issues:). For a very short trail this might not be noticable but for longer ones I think it's a bit of a show stopper. It would be possible to include curved trails in the model, and the select anim function could be used to select the appropriate model object, but then you'd need a wide range of trail objects. At first glance, this doesn't seem too bad, but then I think you'd really need several versions of each trail type so that you could switch between them to give the impression that the trail is changing throught time. Hmm... I don't think I've explained that bit very well... Consider an a/c in stable level flight where votices are being generated from the wing-tips. Even though the vortex trail may not change in length or shape, it's appreance will change from frame to frame, so you'd need to switch between several identically shaped and sized objects that are textured slightly differently to give the impression of change. If we could actually modify the model objects themselves then we could 'bend' the trails, and cut down on the number needed. But then we could also do wing flexing too. Before anyone starts thinking seriously about this, it would be very non-trivial to do, at least for the wings, where some objects would need to be 'bent' i.e. the wings and control surfaces, whereas other objects would have to simply translate i.e. wing mounted engine nacelles and U/C. For a simple object, like a vortex trail, bending might be feasible, and combined with scaling (which I think we already have), it might work ok. Another possiblity would be some sort of particle object handling where temporary objects could be generated, left for a while and then culled. We could then 'drop' a stream of these objects behind the a/c that're culled after a certain time. It'd probably need a lot of objects to work though, and it would also push up the object count of course. Both methods would need some carefull texturing. The second method could be very useful - drop tanks, ordinance, cockpit canopies, ejector seats, tyre smoke on landing. Not a high priority, I feel, but a nice to have. I want to do drop tanks on the hunter some time soon, but I can probably handle them well enough with the existing animations ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aerodynamic centre and 3D models
Lee Elliott Sent: 14 February 2004 13:35 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Aerodynamic centre and 3D models On Saturday 14 February 2004 13:07, Vivian Meazza wrote: Lee Elliott wrote On Friday 13 February 2004 06:16, Jon Berndt wrote: True, but... This is a chunk of calculations running every frame. In the olden days, the cost would be too high. These days, it's not even a spec on a flea on the butt of an elephant in terms of the overall FDM calculations - which in turn are not much of a spec on a flea in the overall FlightGear calculations. Our Aerodynamic modelers always seemed to know where the empty weight CG was every frame without additional calculations. That's not the issue, though. We FDM guys know absolutely where everything is at all times within the FDMs. Yep:) Everything's right where we put it:) LeeE I'm about halfway through generating a 3d cockpit for the Seahawk model - are you going to move the origin of the model? I'd like a heads up, it will probably affect how I go about the rest of the work. Regards Vivian That's great news. The only change that's likely to the Sea Hawk model will be to shift the origin to the nose;) This won't actually be too much of a problem and will only require simple offsets to the numbers in the anim and fdm files: Say I need to move the model 3 metres back and 0.1 metre up, then all we need to do is add 3 metres to all the 'x' measurements, and 0.1 to all the 'z' measurements in the fdm and anim files to line everything up again. (Heh!... or it might be _subtract_ 3 metres... maths was never my strong point) Then readjust all the animations to make them work correctly - fun eh? I'll try to make the cockpit reasonably independent of the origin - I've done it for instruments and I'll try and extend it to other stuff. Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Eye candy
On Saturday 14 February 2004 13:43, Vivian Meazza wrote: Lee Elliott wrote On Friday 13 February 2004 22:27, Jon S Berndt wrote: Any chance of modeling wingtip vortices (when CL is high enough above some threshhold) and rocket engine exhaust? :-) Jon I've thought about trying this but I think it could only be really effective in level flight. As soon as you start banking the 'end' of whatever trail you're simulating will rotate (echos of the VRP issues:). For a very short trail this might not be noticable but for longer ones I think it's a bit of a show stopper. It would be possible to include curved trails in the model, and the select anim function could be used to select the appropriate model object, but then you'd need a wide range of trail objects. At first glance, this doesn't seem too bad, but then I think you'd really need several versions of each trail type so that you could switch between them to give the impression that the trail is changing throught time. Hmm... I don't think I've explained that bit very well... Consider an a/c in stable level flight where votices are being generated from the wing-tips. Even though the vortex trail may not change in length or shape, it's appreance will change from frame to frame, so you'd need to switch between several identically shaped and sized objects that are textured slightly differently to give the impression of change. If we could actually modify the model objects themselves then we could 'bend' the trails, and cut down on the number needed. But then we could also do wing flexing too. Before anyone starts thinking seriously about this, it would be very non-trivial to do, at least for the wings, where some objects would need to be 'bent' i.e. the wings and control surfaces, whereas other objects would have to simply translate i.e. wing mounted engine nacelles and U/C. For a simple object, like a vortex trail, bending might be feasible, and combined with scaling (which I think we already have), it might work ok. Another possiblity would be some sort of particle object handling where temporary objects could be generated, left for a while and then culled. We could then 'drop' a stream of these objects behind the a/c that're culled after a certain time. It'd probably need a lot of objects to work though, and it would also push up the object count of course. Both methods would need some carefull texturing. The second method could be very useful - drop tanks, ordinance, cockpit canopies, ejector seats, tyre smoke on landing. Not a high priority, I feel, but a nice to have. I want to do drop tanks on the hunter some time soon, but I can probably handle them well enough with the existing animations I think drop tanks would be feasible but it would need some thinking about:) The fun bit will be counteracting the a/c manuevours after the tank has dropped so it falls straight even though the a/c may be climbing and banking. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
On Saturday 14 February 2004 13:52, Vivian Meazza wrote: Lee Elliott Sent: 14 February 2004 13:35 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Aerodynamic centre and 3D models On Saturday 14 February 2004 13:07, Vivian Meazza wrote: Lee Elliott wrote On Friday 13 February 2004 06:16, Jon Berndt wrote: True, but... This is a chunk of calculations running every frame. In the olden days, the cost would be too high. These days, it's not even a spec on a flea on the butt of an elephant in terms of the overall FDM calculations - which in turn are not much of a spec on a flea in the overall FlightGear calculations. Our Aerodynamic modelers always seemed to know where the empty weight CG was every frame without additional calculations. That's not the issue, though. We FDM guys know absolutely where everything is at all times within the FDMs. Yep:) Everything's right where we put it:) LeeE I'm about halfway through generating a 3d cockpit for the Seahawk model - are you going to move the origin of the model? I'd like a heads up, it will probably affect how I go about the rest of the work. Regards Vivian That's great news. The only change that's likely to the Sea Hawk model will be to shift the origin to the nose;) This won't actually be too much of a problem and will only require simple offsets to the numbers in the anim and fdm files: Say I need to move the model 3 metres back and 0.1 metre up, then all we need to do is add 3 metres to all the 'x' measurements, and 0.1 to all the 'z' measurements in the fdm and anim files to line everything up again. (Heh!... or it might be _subtract_ 3 metres... maths was never my strong point) Then readjust all the animations to make them work correctly - fun eh? I'll try to make the cockpit reasonably independent of the origin - I've done it for instruments and I'll try and extend it to other stuff. Vivian The only readjustments that would be needed are the simple x z offsets - all the axis would remain unchanged so, for example, the aileron axis numbers wouldn't need to be changed, just their location, in line with the simple x/z offsets. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Eye candy
Lee Elliott writes: On Friday 13 February 2004 22:27, Jon S Berndt wrote: Any chance of modeling wingtip vortices (when CL is high enough above some threshhold) and rocket engine exhaust? Another possiblity would be some sort of particle object handling where temporary objects could be generated, left for a while and then culled. We could then 'drop' a stream of these objects behind the a/c that're culled after a certain time. It'd probably need a lot of objects to work though, and it would also push up the object count of course. SSG supports 'particle systems' via the sgParticle class see PLIB / examples / src / ssg / dynamics / The easiest thing would probably be to write up a high level interface to a new ParticleStream class a time dependent collection of sgParticles and then insert these into the scenegraph with a scriptable binding Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Eye candy
On Saturday 14 February 2004 14:08, Norman Vine wrote: Lee Elliott writes: On Friday 13 February 2004 22:27, Jon S Berndt wrote: Any chance of modeling wingtip vortices (when CL is high enough above some threshhold) and rocket engine exhaust? Another possiblity would be some sort of particle object handling where temporary objects could be generated, left for a while and then culled. We could then 'drop' a stream of these objects behind the a/c that're culled after a certain time. It'd probably need a lot of objects to work though, and it would also push up the object count of course. SSG supports 'particle systems' via the sgParticle class see PLIB / examples / src / ssg / dynamics / The easiest thing would probably be to write up a high level interface to a new ParticleStream class a time dependent collection of sgParticles and then insert these into the scenegraph with a scriptable binding Cheers Norman A proper particle system would be a much better idea than trying to fake it with objects. Something for the future perhaps. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aerodynamic centre and 3D models
Norman Vine [EMAIL PROTECTED] said: Russell Suter writes: Jon S Berndt wrote: I don't see any advantage to your approach. By your responses, you give me no indication that you even understand what I'm saying. I seem to be alone in my dissent anyway... What you are planning will work just fine. snip Curiously looking forward to the kludges in the code in future code modules to adjust the radar displays for other aircraft locations :-) Could you be more specific about the nature of the kludge required for the radar display? Now is the time to look at the change that Jon has made and figure out the real ramifications rather than sitting back and doing nothing just so you can come back a year later and say I told you so. Dig in and really look at the problem, please. Believe it or not most of us do appreciate your insight :-) FWIW _all_ this patch does is allow the specification of a static location for the FDM to report aircraft position at in JSBsim. Previously it was reported from the current center of gravity. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] XML SCripting
Tony Peden wrote: PS. I'm just wondering if you have any thoughts on my earlier question, i.e. whether what's being patented has to be something non-obvious? Amazon: One-click ordering. I think the answer is no. Even if it's something that has to be non-obvious, that only means you have to convince the patent granter that it is non-obvious. 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] Aerodynamic centre and 3D models
Jim Wilson writes: Norman Vine [EMAIL PROTECTED] said: Please try to configure your mailer to not quote raw e-mail addresses in your replies. Let's not make the spam harvesters' life any easier... Russell Suter writes: By your responses, you give me no indication that you even understand what I'm saying. snip Curiously looking forward to the kludges in the code in future code modules to adjust the radar displays for other aircraft locations :-) Could you be more specific about the nature of the kludge required for the radar display? I certainly hope you are not planning on publishing the 'position' as reported by the FDM for things like collision detection and related instrumentation such as a radar display with out some kind of 'adjustment' No-digging-necessary'ly-yr's Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Eye candy
Norman Vine says Lee Elliott writes: On Friday 13 February 2004 22:27, Jon S Berndt wrote: Any chance of modeling wingtip vortices (when CL is high enough above some threshhold) and rocket engine exhaust? Another possiblity would be some sort of particle object handling where temporary objects could be generated, left for a while and then culled. We could then 'drop' a stream of these objects behind the a/c that're culled after a certain time. It'd probably need a lot of objects to work though, and it would also push up the object count of course. SSG supports 'particle systems' via the sgParticle class see PLIB / examples / src / ssg / dynamics / The easiest thing would probably be to write up a high level interface to a new ParticleStream class a time dependent collection of sgParticles and then insert these into the scenegraph with a scriptable binding I think my brain hurts. But if someone gives us the tools I'll do the modelling. After I've done the Seahawk. Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] XML SCripting
Curtis L. Olson writes: Tony Peden wrote: PS. I'm just wondering if you have any thoughts on my earlier question, i.e. whether what's being patented has to be something non-obvious? Amazon: One-click ordering. I think the answer is no. Even if it's something that has to be non-obvious, that only means you have to convince the patent granter that it is non-obvious. These arguments are really only valid *before* a patent is awarded and / or in a court case. i.e. the patent has been awarded and will stand as is pending a legal challenge sadly the time for public comment has come and gone Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
Norman Vine wrote: I certainly hope you are not planning on publishing the 'position' as reported by the FDM for things like collision detection and related instrumentation such as a radar display with out some kind of 'adjustment' No-digging-necessary'ly-yr's Collision detection could be an interesting point. Radar seems like a stretch unless you are *extremely* close to the target (at which point you probably aren't watching your radar anyway.) In RL you are probably going to get wierd results that close anyway. 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] Aerodynamic centre and 3D models
Jon S. Berndt wrote: IIRC, YASim provides for the origin at the nose tip too (or something close to that). YASim doesn't care, actually. It reports the output lat/lon/alt value as the location of the coordinate origin of the airframe (that is, the 0,0,0 referenced by all the coordinates it finds in the aircraft definition file). I've always suggested the nose as an obvious and hard-to-mistake location, but there's nothing in code to enforce that. If the aircraft lacks a well-defined nose, then we can pick something else; the only requirement is that all the FDM configurations and 3D models for a single aircraft agree. There's not need to unify conventions for across all possible aircraft. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aerodynamic centre and 3D models
Curtis L. Olson writes: Norman Vine wrote: I certainly hope you are not planning on publishing the 'position' as reported by the FDM for things like collision detection and related instrumentation such as a radar display with out some kind of 'adjustment' No-digging-necessary'ly-yr's Collision detection could be an interesting point. Radar seems like a stretch unless you are *extremely* close to the target (at which point you probably aren't watching your radar anyway.) In RL you are probably going to get wierd results that close anyway. Hmm.. conventional radar usage is perhaps a bit of a stretch but things such as automated landings use radar verification where being off by half the length of a 747 could lead to 'interesting' things .. there are other interesting uses for radar like things too that are most useful when you aren't necessarily watching the 'screen' * ALARM * ALARM * ALARM * Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aerodynamic centre and 3D models
Norman Vine said: Jim Wilson writes: I certainly hope you are not planning on publishing the 'position' as reported by the FDM for things like collision detection and related instrumentation such as a radar display with out some kind of 'adjustment' The _only_ difference between now and what we had before is now the position may be reported at a fixed location on the aircraft by JSBsim. Before it was reported at the _current_ center of gravity which varies according to load, fuel consumption, etc. I'm sorry to be so dense, but could some explain what this is going to mess up? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Eye candy
Lee Elliott wrote: I think drop tanks would be feasible but it would need some thinking about:) The fun bit will be counteracting the a/c manuevours after the tank has dropped so it falls straight even though the a/c may be climbing and banking. This is more of a code architecture issue. Once something has left the aircraft, it ought be be handed to a simple ballistics FDM or somesuch. Making it disappear from the aircraft model is as simple as adding a select animation and can be done right now. And you can set the weight tag to zero to get the FDM behavior correct. Running it under a separate FDM handler is something that the C++ code just doesn't support yet, though. It's probably not hugely difficult to make work, though. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aerodynamic centre and 3D models
Jim Wilson writes: Norman Vine said: Thanks for making the mailer fix :-) I certainly hope you are not planning on publishing the 'position' as reported by the FDM for things like collision detection and related instrumentation such as a radar display with out some kind of 'adjustment' The _only_ difference between now and what we had before is now the position may be reported at a fixed location on the aircraft by JSBsim. Before it was reported at the _current_ center of gravity which varies according to load, fuel consumption, etc. AFAIK In most systems if an object is represented by a point location it is expected that said location will be 'near' the center of the object in question. In the case of radar the center point of the 'target's on-screen echo' when extrapolated to account for the 'display properties' is most often close to the center point of the object 'sensed'. I know it is really much more complicated then this but ... it is certainly closer to the center point then one of the extremities unless that extremity and the center point line up on a vector emanating from the radar Note this has nothing to do with how FGFS has or will do things but reflects common practice and deviation from this will 'often' have to be accounted for. hence my original 'kludge' comment Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Eye candy
Andy Ross Lee Elliott wrote: I think drop tanks would be feasible but it would need some thinking about:) The fun bit will be counteracting the a/c manuevours after the tank has dropped so it falls straight even though the a/c may be climbing and banking. This is more of a code architecture issue. Once something has left the aircraft, it ought be be handed to a simple ballistics FDM or somesuch. Making it disappear from the aircraft model is as simple as adding a select animation and can be done right now. And you can set the weight tag to zero to get the FDM behavior correct. Running it under a separate FDM handler is something that the C++ code just doesn't support yet, though. It's probably not hugely difficult to make work, though. Andy I was thinking in the short term to move the tank away from the aircraft in an arc, then select it, and set the fuel to zero, and the empty weight to zero. Be nice to hand off to a separate FDM though. Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
Jim Wilson wrote: Vivian Meazza snip said: I'm about halfway through generating a 3d cockpit for the Seahawk model - are you going to move the origin of the model? I'd like a heads up, it will probably affect how I go about the rest of the work. If the model is already animated (and/or cockipit models positioned) I would recommend using this to reposition the model: http://www.flightgear.org/Docs/fgfs-model-howto.html#repositioning I should have known. It's already there! This is exactly the meta data I was talking about! With this, you can pick ***ANY*** static point in the model. A few seconds with a calculator and done! Since you can pick any static point, there is no need to calculate a new one. It's like paying double to use the toll road. I suspect these properties are applied anyway -- even if they are zero. I don't know if these are applied per frame or if they are applied once to the model. In the latter case, you can ride the toll road all day and only have to pay the toll once! -- 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] Aerodynamic centre and 3D models
On Fri, 2004-02-13 at 10:23, Russell Suter wrote: Jon Berndt wrote: So, instead of defining some arbitrary frame, _we_use_an_industry_standard_, which is the structural frame that the manufacturer defines, when available. It is always (in my experience) X positive aft, Y positive right, with the origin being seemingly arbitrary. I wouldn't go so far as to say this is an industry standard. FG is the first sim I've seen that uses this coordinate system. The one I've seen the most is X positive forward, Y positive right and Z positive down. Someone once told me this was named the Boeing system. On the sim I'm working on now, it's positive Y forward, positive X to the right and positive Z up. I'll admit that most of the sims I've worked on are relatively old in FORTRAN and C. There really are no industry standards here. Body axis, earth local, and earth fixed are commonly used in simulation. A system like our structural system is commonly used by manufacturing, ground ops, and flight ops folks. But even then, the origins vary from airplane to airplane. Don't get me wrong, I'm not saying this is a bad system, I'm just not sure I agree it is an industry standard... -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aerodynamic centre and 3D models
FWIW _all_ this patch does is allow the specification of a static location for the FDM to report aircraft position at in JSBsim. Previously it was reported from the current center of gravity. That's exactly right. Furthermore, if the VRP is set to the empty weight CG for an aircraft flight model, and the 3D modeler talks with the flight modeler to communicate where exactly the empty weight CG is (since it is the flight modeler that will be setting this location based on physical parameters), then everyone is happy, as well. The VRP code now in JSBSim simply allows an agreed upon point to be reported to FlightGear - whether it's the empty weight CG, or the nose tip, or the left wingtip, as long as it is agreed upon between the 3D modeler and the flight modeler, the rendition will come out looking right. There's nothing nefarious about the new code in JSBSim. Nothing that leads to a dead end. The big question seems to be about where the common reference point should be. Think about that one. Think about what each modeler will know. Think about what both will know. Think about whether the common visual reference should be the same (a convention) across all models so it doesn't lead to confusion. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aerodynamic centre and 3D models
There really are no industry standards here. Body axis, earth local, and earth fixed are commonly used in simulation. A system like our structural system is commonly used by manufacturing, ground ops, and flight ops folks. But even then, the origins vary from airplane to airplane. Yes, the origin varies widely in all the specifications I have seen, but the directions of the axes have all been the same (i.e. like our structural frame). As well, all of them have been measured in inches, too. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Eye candy
This is more of a code architecture issue. Once something has left the aircraft, it ought be be handed to a simple ballistics FDM or somesuch. Making it disappear from the aircraft model is as simple as adding a select animation and can be done right now. And you can set the weight tag to zero to get the FDM behavior correct. Running it under a separate FDM handler is something that the C++ code just doesn't support yet, though. It's probably not hugely difficult to make work, though. A simple ballistics FDM already exists, located at src/AIModel/AIBallistic.cxx, and it works nicely on its own. What is needed is for every FDM to have the ability to be a master or slave of any other FDM. When in slave mode the slave FDM will get its [x,y,z,pitch,roll,bank] info from the master. When released the slave will begin using its internal calculations. It wouldn't be hard to add this to AIBase (the base class for AIBallistic, AIAircraft and AIShip). Yasim and JSBSim could then have the master/slave ability added (JSBSim already has something like this, but it wasn't designed to work with all the other FDMs). I think we just need to define the interface for every FDM, and the struct for passing the [x,y,z,pitch,roll,yaw] data. If you want the slave FDM to effect the master, then it gets more complicated. A simple FDM, like AIAircraft, can ignore the effects of the slave, but a complex FDM, like Yasim or JSBSim, would probably want to be effected by the slave. For instance, if you make the JSBSim X-15 a slave to an AIAircraft B-52, then the B-52 can ignore the effects of the X-15. If the X-15 is a slave to the Yasim B-52, then the B-52 will probably want to figure in the effects of the X-15. One thing that needs more work is in ensuring that the master and slave models get drawn at the same time. I'm no graphics guy, so that's out of my league. I've noticed this is a problem when pulling up behind the AI KC-135 (or any AIAircraft object). The AI object appears to leap forward in about 20-foot bursts. It would look funny if the AIBallistic-based external fuel tank didn't follow the aircraft smoothly. Curt had the idea of using a central graphics manager to manage the drawing of all objects, and that might do the trick. Dave -- David Culp davidculp2[at]comcast.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
Russell Suter said: I suspect these properties are applied anyway -- even if they are zero. I don't know if these are applied per frame or if they are applied once to the model. In the latter case, you can ride the toll road all day and only have to pay the toll once! Exactly. From sgLoad3DModel (in SimGear/simgear/scene/model.cxx): ssgTransform * alignmainmodel = new ssgTransform; alignmainmodel-addKid(model); sgMat4 res_matrix; sgMakeOffsetsMatrix(res_matrix, props.getFloatValue(/offsets/heading-deg, 0.0), props.getFloatValue(/offsets/roll-deg, 0.0), props.getFloatValue(/offsets/pitch-deg, 0.0), props.getFloatValue(/offsets/x-m, 0.0), props.getFloatValue(/offsets/y-m, 0.0), props.getFloatValue(/offsets/z-m, 0.0)); alignmainmodel-setTransform(res_matrix); Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Eye candy
On Saturday 14 February 2004 17:48, Andy Ross wrote: Lee Elliott wrote: I think drop tanks would be feasible but it would need some thinking about:) The fun bit will be counteracting the a/c manuevours after the tank has dropped so it falls straight even though the a/c may be climbing and banking. This is more of a code architecture issue. Once something has left the aircraft, it ought be be handed to a simple ballistics FDM or somesuch. Making it disappear from the aircraft model is as simple as adding a select animation and can be done right now. And you can set the weight tag to zero to get the FDM behavior correct. Running it under a separate FDM handler is something that the C++ code just doesn't support yet, though. It's probably not hugely difficult to make work, though. Andy Agreed, a simple 'ballastics' FDM would be a far better solution, but then someone's got to design code it. Not my field;) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Eye candy
On Saturday 14 February 2004 14:48, Jim Wilson wrote: Lee Elliott [EMAIL PROTECTED] said: On Friday 13 February 2004 22:27, Jon S Berndt wrote: Any chance of modeling wingtip vortices (when CL is high enough above some threshhold) and rocket engine exhaust? :-) Jon If we could actually modify the model objects themselves then we could 'bend' the trails, and cut down on the number needed. Plib supports a tween function that does exactly this. It hasn't been added to fgfs animation support yet. Basically if you have two vertices (or identical _sets_ of vertices) positioned at the two extremes of your range of motion, the tween function will move them all proportionately between according to a 0.0 to 1.0 ratio value. Obviously you could bend or stretch or twist, or whatever you wanted to. This would be cool to have. Best, Jim Bendy wings on the B-52 would be nice;) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Eye candy
On Saturday 14 February 2004 18:35, Vivian Meazza wrote: Andy Ross Lee Elliott wrote: I think drop tanks would be feasible but it would need some thinking about:) The fun bit will be counteracting the a/c manuevours after the tank has dropped so it falls straight even though the a/c may be climbing and banking. This is more of a code architecture issue. Once something has left the aircraft, it ought be be handed to a simple ballistics FDM or somesuch. Making it disappear from the aircraft model is as simple as adding a select animation and can be done right now. And you can set the weight tag to zero to get the FDM behavior correct. Running it under a separate FDM handler is something that the C++ code just doesn't support yet, though. It's probably not hugely difficult to make work, though. Andy I was thinking in the short term to move the tank away from the aircraft in an arc, then select it, and set the fuel to zero, and the empty weight to zero. Be nice to hand off to a separate FDM though. Vivian While I think it might be feasible to drop a tank and have it appear to drop down from the a/c, and out of sight (and then quickly de-selected), I think trying to achieve any sort of realistic trajectory would be pushing it a bit. You've got to remember that the animation origins are relative to the a/c so after dropping something, you'd have to bare in mind that the a/c, and therefore the anim orign, are moving. If the a/c turns after dropping the tank it would be very difficult to keep the tank moving in a straight line with the available anim controls. The same thing applies to climbs or descents, but this would be less apparent from the a/c views. Would look a bit odd from the tower though:) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Eye candy
One feature in JSBSim that I began and have not yet finished (pending other things) is a parent/child capability. You can (for instance) load a Mk82 on an F-16 and the physical effects of the Mk82 will affect the F-16. The position is based on the position of the parent, and so is the orientation. However, the Mk82 position is not integrated, it always has a position based on the parent, UNTIL it is released. Then, the EOM begins integrating and the flyout is physics based. The child objects are each their own individual JSBSim objects in their own right, and each could be loaded and flown by itself. The JSBSim executive is sort of recursive in this way. Each would be addressable in a way that I think Tony set up with Properties, but I can't recall what it is. Technically, it is also possible for each droppable piece to have its own propulsion and flight control system, too. The possiblities there are quite broad. Unfortunately, my time is getting more limited by the day. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Eye candy
Jon Berndt wrote One feature in JSBSim that I began and have not yet finished (pending other things) is a parent/child capability. You can (for instance) load a Mk82 on an F-16 and the physical effects of the Mk82 will affect the F-16. The position is based on the position of the parent, and so is the orientation. However, the Mk82 position is not integrated, it always has a position based on the parent, UNTIL it is released. Then, the EOM begins integrating and the flyout is physics based. The child objects are each their own individual JSBSim objects in their own right, and each could be loaded and flown by itself. The JSBSim executive is sort of recursive in this way. Each would be addressable in a way that I think Tony set up with Properties, but I can't recall what it is. Technically, it is also possible for each droppable piece to have its own propulsion and flight control system, too. The possiblities there are quite broad. Unfortunately, my time is getting more limited by the day. Sounds VERY good. I'm sure you'll get round to it in due course. Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Eye candy
Lee Elliott wrote On Saturday 14 February 2004 18:35, Vivian Meazza wrote: Andy Ross Lee Elliott wrote: I think drop tanks would be feasible but it would need some thinking about:) The fun bit will be counteracting the a/c manuevours after the tank has dropped so it falls straight even though the a/c may be climbing and banking. This is more of a code architecture issue. Once something has left the aircraft, it ought be be handed to a simple ballistics FDM or somesuch. Making it disappear from the aircraft model is as simple as adding a select animation and can be done right now. And you can set the weight tag to zero to get the FDM behavior correct. Running it under a separate FDM handler is something that the C++ code just doesn't support yet, though. It's probably not hugely difficult to make work, though. Andy I was thinking in the short term to move the tank away from the aircraft in an arc, then select it, and set the fuel to zero, and the empty weight to zero. Be nice to hand off to a separate FDM though. Vivian While I think it might be feasible to drop a tank and have it appear to drop down from the a/c, and out of sight (and then quickly de-selected), I think trying to achieve any sort of realistic trajectory would be pushing it a bit. You've got to remember that the animation origins are relative to the a/c so after dropping something, you'd have to bare in mind that the a/c, and therefore the anim orign, are moving. If the a/c turns after dropping the tank it would be very difficult to keep the tank moving in a straight line with the available anim controls. The same thing applies to climbs or descents, but this would be less apparent from the a/c views. Would look a bit odd from the tower though:) LeeE Of course we would like a parent/child FDM system, and from all these postings is seems as if we nearly have. In the order of things, I don't think it is very high on the todo list. Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Eye candy
Actually, I was thinking of playing with wing flexing with the model that I am working on now, but I figured that I already had too many bells and whistles. I was going to divide each wing into about four sections and put them into a tree-like structure with all the engines, etc hanging off the group objects with the wing segments. Then you can rotate the inner group by a factor of the g-load, and again for each section. The effect should be cumulative at the tip, but I never tested it. There might be a problem with the pivot points not matching up when the wing is flexed though, you might have to do some translating too. This would be a great feature if anyone ever modeled the Voyager. Then the trick would be modeling the wingtip scrapes and deleting the wingtip lights, just like in real life! Josh Lee Elliott wrote: On Friday 13 February 2004 22:27, Jon S Berndt wrote: Any chance of modeling wingtip vortices (when CL is high enough above some threshhold) and rocket engine exhaust? :-) Jon I've thought about trying this but I think it could only be really effective in level flight. As soon as you start banking the 'end' of whatever trail you're simulating will rotate (echos of the VRP issues:). For a very short trail this might not be noticable but for longer ones I think it's a bit of a show stopper. It would be possible to include curved trails in the model, and the select anim function could be used to select the appropriate model object, but then you'd need a wide range of trail objects. At first glance, this doesn't seem too bad, but then I think you'd really need several versions of each trail type so that you could switch between them to give the impression that the trail is changing throught time. Hmm... I don't think I've explained that bit very well... Consider an a/c in stable level flight where votices are being generated from the wing-tips. Even though the vortex trail may not change in length or shape, it's appreance will change from frame to frame, so you'd need to switch between several identically shaped and sized objects that are textured slightly differently to give the impression of change. If we could actually modify the model objects themselves then we could 'bend' the trails, and cut down on the number needed. But then we could also do wing flexing too. Before anyone starts thinking seriously about this, it would be very non-trivial to do, at least for the wings, where some objects would need to be 'bent' i.e. the wings and control surfaces, whereas other objects would have to simply translate i.e. wing mounted engine nacelles and U/C. For a simple object, like a vortex trail, bending might be feasible, and combined with scaling (which I think we already have), it might work ok. Another possiblity would be some sort of particle object handling where temporary objects could be generated, left for a while and then culled. We could then 'drop' a stream of these objects behind the a/c that're culled after a certain time. It'd probably need a lot of objects to work though, and it would also push up the object count of course. Both methods would need some carefull texturing. LeeE ___ 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] Eye candy
Sounds VERY good. I'm sure you'll get round to it in due course. Vivian Did I say that? ;-) I think I may have a few weeks this summer *alone*. That's got opportunity written all over it. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Eye candy
Jon Berndt Sounds VERY good. I'm sure you'll get round to it in due course. Vivian Did I say that? ;-) I think I may have a few weeks this summer *alone*. That's got opportunity written all over it. Excellent. But summer is for real flying. Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aerodynamic centre and 3D models
Jim Wilson writes: Russell Suter said: I suspect these properties are applied anyway -- even if they are zero. I don't know if these are applied per frame or if they are applied once to the model. In the latter case, you can ride the toll road all day and only have to pay the toll once! Exactly. From sgLoad3DModel (in SimGear/simgear/scene/model.cxx): ssgTransform * alignmainmodel = new ssgTransform; alignmainmodel-addKid(model); sgMat4 res_matrix; sgMakeOffsetsMatrix(res_matrix, props.getFloatValue(/offsets/heading-deg, 0.0), props.getFloatValue(/offsets/roll-deg, 0.0), props.getFloatValue(/offsets/pitch-deg, 0.0), props.getFloatValue(/offsets/x-m, 0.0), props.getFloatValue(/offsets/y-m, 0.0), props.getFloatValue(/offsets/z-m, 0.0)); alignmainmodel-setTransform(res_matrix); Yup, something like that is how it's supposed to work but ... I remember your asking about how to set this up and that you didn't like the axis angle form that we were using but I hadn't realized that this code had actually changed ... hmm... I have to think about this for a while ... anyway see attached for a much quicker equivalent of the current code Norman mat_test.cxx Description: Binary data ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Eye candy
Andy Ross wrote: Running it under a separate FDM handler is something that the C++ code just doesn't support yet, though. It's probably not hugely difficult to make work, though. Thinking about: 1. inherit the main FDM's moments and forces 2. transpose them to the appropriate location. 3. Use that as the initial values for your ballistic FDM. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Eye candy
Or just have a command that creates an object at a certain point with a certain velocity vector and orientation. Josh Erik Hofman wrote: Andy Ross wrote: Running it under a separate FDM handler is something that the C++ code just doesn't support yet, though. It's probably not hugely difficult to make work, though. Thinking about: 1. inherit the main FDM's moments and forces 2. transpose them to the appropriate location. 3. Use that as the initial values for your ballistic FDM. 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
Re: [Flightgear-devel] Aerodynamic centre and 3D models
Norman Vine wrote: Hmm.. conventional radar usage is perhaps a bit of a stretch but things such as automated landings use radar verification where being off by half the length of a 747 could lead to 'interesting' things .. there are other interesting uses for radar like things too that are most useful when you aren't necessarily watching the 'screen' * ALARM * ALARM * ALARM * Actually: * Warning * Warning * * Warning * Warning * Or my favorite: * PULL UP * PULL UP* Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Eye candy
Lee Elliott wrote: Agreed, a simple 'ballastics' FDM would be a far better solution, but then someone's got to design code it. Which reminds me, an FDM (Yasim, UIUC/LaRCsim or JSBSim) could spawn an AIModel object which has (simple) ballistic trajectory support. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
Jim Wilson wrote: The _only_ difference between now and what we had before is now the position may be reported at a fixed location on the aircraft by JSBsim. Before it was reported at the _current_ center of gravity which varies according to load, fuel consumption, etc. I'm sorry to be so dense, but could some explain what this is going to mess up? The reported lat/lon/alt would swing around a certain other location when displayed on an external radar display. To correct that you would need the heading vector and the relative static CG distance and compute the actual rotational point. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aerodynamic centre and 3D models
The _only_ difference between now and what we had before is now the position may be reported at a fixed location on the aircraft by JSBsim. Before it was reported at the _current_ center of gravity which varies according to load, fuel consumption, etc. I'm sorry to be so dense, but could some explain what this is going to mess up? Say that initially JSBSim and the 3D model both agreed on where the center was - for JSBSim we simply report the CG location. OK, so the 3D model is flying along nicely - even took off nicely (since the CG matches where the 3D model rotates about in this example). Now, let's say we have fuel burnoff on one wing tank but not the other, so we end up with a CG that is two feet to the left of the fuselage at around the quarter chord (if you could even fly that, but humour me). The 3D model stil thinks the center of rotation is at the initially specified CG point, right? Now, when the aircraft lands, the FDM knows about all the contact points and where the CG is currently, and say one main gear (right) touches down well before the other. When the aircraft touches down the right gear, visually the right gear would hover above the runway some distance, because it is rotating about the initial CG, yet the FDM is rotating about the left-displaced CG, which has also a different altitude than is visually being shown Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Eye candy
Josh Babcock wrote: Or just have a command that creates an object at a certain point with a certain velocity vector and orientation. I think you still need the moments to get a decent traject match. Erik Josh Erik Hofman wrote: Andy Ross wrote: Running it under a separate FDM handler is something that the C++ code just doesn't support yet, though. It's probably not hugely difficult to make work, though. Thinking about: 1. inherit the main FDM's moments and forces 2. transpose them to the appropriate location. 3. Use that as the initial values for your ballistic FDM. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
On Saturday 14 Feb 2004 6:27 pm, Norman Vine wrote: snip AFAIK In most systems if an object is represented by a point location it is expected that said location will be 'near' the center of the object in question. In the case of radar the center point of the 'target's on-screen echo' when extrapolated to account for the 'display properties' is most often close to the center point of the object 'sensed'. I know it is really much more complicated then this but ... it is certainly closer to the center point then one of the extremities unless that extremity and the center point line up on a vector emanating from the radar Note this has nothing to do with how FGFS has or will do things but reflects common practice and deviation from this will 'often' have to be accounted for. Oo! Oo! but this is a simulator, isn't it? So won't it simulate the electromagnetic pulse from our aircraft's antenna, modify it for the medium between us and the target, query the position (of the nose :¬) and orientation of the target, calculate the effective radar cross-section, and return the reflection to the receiver? We wouldn't just draw a blip on a radar instrument screen, being a projection of X.target, Y.target, Z.target, would we? (OK, maybe if the target squawked). :-P Jonathan I've got a more serious observations on the Reference Point Skirmish, though. At least in the early part of the debate it would have helped if we had a diagram to refer to, just to get the nomenclature clear. A picture paints 1K words, etc. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] waves white flag
I give up. Sort of. I just want things to work out properly between the FDM and the 3D model. JSBSim now can provide the lat/lon/alt of a fixed point on the aircraft. This includes the possibility of providing an offset from the initial CG to the current CG. We can provide whatever is desired. I've proposed a solution that many of us agreed on at one point, and which I think makes sense given the perspectives of the two camps (FDM and 3D Model). I've made my argument. You can take it, or provide a different solution. We'll be happy to provide whatever is requested. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] waves white flag
Personally, I think the nose VRP makes a lot of sense. I think people are trying to make this a lot more complicated than it is. It's just a simple solution to a small problem. I vote Yea. Josh Jon Berndt wrote: I give up. Sort of. I just want things to work out properly between the FDM and the 3D model. JSBSim now can provide the lat/lon/alt of a fixed point on the aircraft. This includes the possibility of providing an offset from the initial CG to the current CG. We can provide whatever is desired. I've proposed a solution that many of us agreed on at one point, and which I think makes sense given the perspectives of the two camps (FDM and 3D Model). I've made my argument. You can take it, or provide a different solution. We'll be happy to provide whatever is requested. Jon ___ 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] Eye candy
Oh, yeah, that too. Josh Erik Hofman wrote: Josh Babcock wrote: Or just have a command that creates an object at a certain point with a certain velocity vector and orientation. I think you still need the moments to get a decent traject match. snip ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aerodynamic centre and 3D models
No. No. No. No. There need not be a prior agreement. The 3D modeler uses whatever origin suits. It appears in many cases that's the nose. Yes, yes. There has to be an understanding of the difference between the frames of reference (FDM and 3D model). If we are providing the position of the nose, and the 3D model has some arbitrary origin (that's *not* the nose) then it's not gonna work. I think you understand this. The point is, SOMEONE has to know how to relate the two frames of reference - THAT's what I mean by agreed-upon. Look, I understand 3D graphics. I wrote an application 15 years ago that took reams of simulation data and wrote an animation (frame-by-frame) to videotape using IRIX-GL (before there was OpenGL: http://www.hal-pc.org/~jsb/lambs.jpg). I've created often used shuttle 3D models for rendering under POV-Ray: http://www.hal-pc.org/~jsb/shuttlepov.html. I am trying to preclude confusion amongst the audience of 3D modelers and flight model creators. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aerodynamic centre and 3D models
Norman Vine wrote: Jim Wilson writes: Exactly. From sgLoad3DModel (in SimGear/simgear/scene/model.cxx): Yup, something like that is how it's supposed to work but ... I remember your asking about how to set this up and that you didn't like the axis angle form that we were using but I hadn't realized that this code had actually changed ... hmm... I have to think about this for a while ... This looks fine, I guess I was just surprised that I hadn't noticed the code change earlier, and since this is currently only called once for any model it isn't time sensitive either although we might as well use the 'faster' code :-) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] 3D Panel Instruments
I've started work on some 3D panel instruments. You can see them, in various stages of completion, in the latest CVS version of the pa28-161. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Portable unlink() / rmdir()
Honest, I'm not writing a windows virus here. :-) I am working on an fltk app to make it easier to install / uninstall 10x10 .tar.gz scenery chunks. I have the install part mostly working (via libtar / libz) so now I am looking at uninstalling. For unix I can do a depth first traversal of the subfolder calling unlink() and rmdir() to remove everything. Are these calls also available for windows? If not, what is the recommended way to do this? Thanks, 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] Thunderbird crash video
(Windows media video) http://www.wedda.demon.nl/tbird.wmv Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
Jon Berndt wrote: No. No. No. No. There need not be a prior agreement. The 3D modeler uses whatever origin suits. It appears in many cases that's the nose. Yes, yes. There has to be an understanding of the difference between the frames of reference (FDM and 3D model). If we are providing the position of the nose, and the 3D model has some arbitrary origin (that's *not* the nose) then it's not gonna work. Then what the H E double toothpicks are these properties for: */offsets/x-m* The distance to reposition the model along the x-axis. */offsets/y-m* The distance to reposition the model along the y-axis. */offsets/z-m* The distance to reposition the model along the z-axis. */offsets/heading-deg* The angle by which to rotate the model around the z-axis. */offsets/roll-deg* The angle by which to rotate the model around the x-axis. */offsets/pitch-deg* The angle by which to rotate the model around the y-axis. I think you understand this. The point is, SOMEONE has to know how to relate the two frames of reference - THAT's what I mean by agreed-upon. Of course someone must know this relationship. That doesn't mean they must be the same point. Someone must not only know the relationship but also be able to calculate, measure, or WAG a delta x,y,z between these two frames of reference and put them in the XML wrapper file. But the understanding need not be a prior agreement!!! So the answer is still NO! Personally, I have matched FDMs that I did not create with 3D models I did not create each with different frames of reference using something very similar to the /offsets/ properties. Look, I understand 3D graphics. I wrote an application 15 years ago that took reams of simulation data and wrote an animation (frame-by-frame) to videotape using IRIX-GL (before there was OpenGL: http://www.hal-pc.org/~jsb/lambs.jpg). I've created often used shuttle 3D models for rendering under POV-Ray: http://www.hal-pc.org/~jsb/shuttlepov.html. I mean no disrespect, nor do I question your ability. But, you don't seem to entirely understand the power of the offsets property. If the FDM reports a position, say the nose, as you intend to do. Now say that the 3D model has the origin at the tail. All is not lost. As long as someone can determine the deltas x,y,z between these two fixed points, these deltas become the /offsets/ properties in the XML wrapper file that tell the IG software how to shift the 3D model to the FDM's reported position. That JSBSim reported the nose is not significant. It's fixed point to fixed point but they don't need to be the same fixed point. I am trying to preclude confusion amongst the audience of 3D modelers and flight model creators. This is a false sense of security. Not all FDMs will use the nose, nor will all 3D models. There is another mechanism to correlate the two. That mechanism is the /offsets/ properties in the wraper file. Reread the section Jim Wilson referenced: http://www.flightgear.org/Docs/fgfs-model-howto.html#repositioning And, as Jim confirmed earlier, this mechanism ALWAYS happens, even if the offsets are 0,0,0. -- 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] Eye candy - Wing Bending
On Saturday 14 February 2004 22:10, Josh Babcock wrote: Actually, I was thinking of playing with wing flexing with the model that I am working on now, but I figured that I already had too many bells and whistles. I was going to divide each wing into about four sections and put them into a tree-like structure with all the engines, etc hanging off the group objects with the wing segments. Then you can rotate the inner group by a factor of the g-load, and again for each section. The effect should be cumulative at the tip, but I never tested it. There might be a problem with the pivot points not matching up when the wing is flexed though, you might have to do some translating too. This would be a great feature if anyone ever modeled the Voyager. Then the trick would be modeling the wingtip scrapes and deleting the wingtip lights, just like in real life! Josh So you read my discussion on irc.flightgear.org 2-3 weeks ago about my wing bending idea? I am working on wing bending too but i am still on working out how a physical model of this wing bending would look like in real life. Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Eye candy - Wing Bending
On Sunday 15 February 2004 08:39, [EMAIL PROTECTED] wrote: I am working on wing bending too but i am still on working out how a physical model of this wing bending would look like in real life. Upgrade: And how to simplify it and integrate it nicly into flightgear so that it is still fast enough. I also gave up the idea of limiting the number of wing sections to only 4, imho this should depend on the type of airplane, so i thought about a dynamic range of wing sections that can be adjusted to the type of airplane. This means: A glider would need more wing sections than a space shuttle. Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Portable unlink() / rmdir()
Curtis L. Olson writes: Honest, I'm not writing a windows virus here. :-) I am working on an fltk app to make it easier to install / uninstall 10x10 .tar.gz scenery chunks. I have the install part mostly working (via libtar / libz) so now I am looking at uninstalling. For unix I can do a depth first traversal of the subfolder calling unlink() and rmdir() to remove everything. Are these calls also available for windows? If not, what is the recommended way to do this? WIndows versions have a leading underscore _unlink( const char * ) _rmdir( const char * ) This is typical of POSIX calls on WIndows BTW this usually works well for this kind of thing google( SEARCH_STRING site:msdn.microsoft.com ) HTH Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
