RE: [Flightgear-devel] Eye candy
Vivian Meazza wrote Andy Ross wrote Vivian Meazza wrote: I think it should work, and it _looks_ as if it does: certainly when you browse internal properties it looks right, but I can't set the second [1] tank to zero. I'm still fuzzy. Do you mean that you can't set the property to zero at all, or that the property goes to zero but YASim doesn't do the right thing? I agree, the configuration looks correct to me. Andy I've now done some more testing. I've now set up my keyboard so that I can adjust the property - all works. However, the weight property of the second tank cannot be set via the property browser. The problem _seems_ to lie in the Properties Browser. Now we need to be able to set the fuel property ... Vivian I've now got a model working, sort of, with drop tanks. At the moment it's only partly realistic, because the fuel can't be managed correctly yet. I've modelled the pylons as vertical stabilisers and the droptanks as weights. Separation looks OK from the cockpit view, and reasonable from external views, provided that the aircraft is straight and level. I note that when full fuel tanks are jettisoned, there isn't much sign of nearly a ton being released from the aircraft. I was looking for at least a flick from the accelerometer. Does it happen too fast for the instrument to pick it up? There is a detectable, but small, trim change as I would expect. Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Eye candy
Andy Ross Vivian Meazza wrote: I've just done some proof-of-principle work on drop tanks with YASim. I set up some weight elements for the pylons and for the dry weight of the tanks, and some fuel tanks to match. [...] However, the bad news is that I can't set _one_ of the drop tank weights to zero (odd that), and none of the tank fuel contents. YASim doesn't currently support setting fuel tank contents, though, it treats the /sim/consumables/ properties as writables only; it doesn't read them. This wouldn't be too hard to fix. So I discovered. I believe we need this function if we are to simulate drop tanks correctly, unless you can think of another way. We also need to be able to control tank usage, so that we can use drop tanks first then internal tanks. I haven't fully investigated, but I presume that this is not possible right now. I'm not clear on the problem you are having with the weight tag. You can associate any property with the weight; just use different names and you can set them in any combination. Yes, this problem was interesting. I set up 2 weights thus: /yasim/weights/tank-100gal-lbs[0] /yasim/weights/tank-100gal-lbs[1] By using yasim weights pylon-inboard-lbs type=double45/pylon-inboard-lbs tank-100gal-lbs type=double150/tank-100gal-lbs !-- dry weight - left -- tank-100gal-lbs type=double150/tank-100gal-lbs !-- dry weight - right -- /weights /yasim I used 'browse internal properties' to access both so I could test the operation of setting to zero to simulate jettison. Both entries _look_ OK, however, I could set /././...-lbs[0] to zero, but not the second tank [1]. I was trying to conform with what I saw as the convention for other tanks etc. I was being too subtle, I suppose, if I call them totally different names, it'll work fine. In fact there's no need for it unless I set up a failure mode in the future As I said - interesting, but I can work around it. Would be a neat way of doing it, and it would conform to the way of doing things in YASim. Grateful for your help Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Eye candy
Lee Elliott wrote Just to help confuse things a little, j/k are for spoilers, iirc, but as speed-brakes aren't supported in YASim (yet;) I've used the spoiler control. Kludged that one by using an extra, low lift, high drag flap on the horizontal stabiliser in the Hunter. CTRL B toggles it. Not neat, but works well enough. I look forward to its proper implementation idc. Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Eye candy
Vivian Meazza wrote: Yes, this problem was interesting. I set up 2 weights thus: /yasim/weights/tank-100gal-lbs[0] /yasim/weights/tank-100gal-lbs[1] Are you sure you got the weight definition right in the YASim configuration file? The property definitions look fine, but they're only half the problem. You need to tell YASim to read those properties, and where to put the mass value that it finds. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Eye candy
Andy Ross Vivian Meazza wrote: Yes, this problem was interesting. I set up 2 weights thus: /yasim/weights/tank-100gal-lbs[0] /yasim/weights/tank-100gal-lbs[1] Are you sure you got the weight definition right in the YASim configuration file? The property definitions look fine, but they're only half the problem. You need to tell YASim to read those properties, and where to put the mass value that it finds. Yes, pretty certain, coded thus: weight x=-6.85 y=2.83 z=-0.33 size=0.2 mass-prop=/yasim/weights/pylon-inboard-lbs/ weight x=-6.85 y=-2.83 z=-0.33 size=0.2 mass-prop=/yasim/hunter/weights/pylon-inboard-lbs/ weight x=-6.4 y=2.83 z=-0.72 size=0.5 mass-prop=/yasim/weights/tank-100gal-lbs[0]/ weight x=-6.4 y=-2.83 z=-0.72 size=0.5 mass-prop=/yasim/weights/tank-100gal-lbs[1]/ YASim didn't complain anyway, and the model flies just fine. My analysis is that the problem lies here: yasim weights pylon-inboard-lbs type=double45/pylon-inboard-lbs tank-100gal-lbs type=double150/tank-100gal-lbs !-- dry weight -- -- tank-100gal-lbs type=double150/tank-100gal-lbs !-- dry weight -- /weights /yasim I think it should work, and it _looks_ as if it does: certainly when you browse internal properties it looks right, but I can't set the second [1] tank to zero. Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Eye candy
Vivian Meazza wrote: I think it should work, and it _looks_ as if it does: certainly when you browse internal properties it looks right, but I can't set the second [1] tank to zero. I'm still fuzzy. Do you mean that you can't set the property to zero at all, or that the property goes to zero but YASim doesn't do the right thing? I agree, the configuration looks correct to me. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Eye candy
Andy Ross Vivian Meazza wrote: I think it should work, and it _looks_ as if it does: certainly when you browse internal properties it looks right, but I can't set the second [1] tank to zero. I'm still fuzzy. Do you mean that you can't set the property to zero at all, or that the property goes to zero but YASim doesn't do the right thing? I agree, the configuration looks correct to me. I can't set the property of the second tank to zero. So far as I can see, Yakima is doing the right thing. V ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Eye candy
Andy Ross wrote Vivian Meazza wrote: I think it should work, and it _looks_ as if it does: certainly when you browse internal properties it looks right, but I can't set the second [1] tank to zero. I'm still fuzzy. Do you mean that you can't set the property to zero at all, or that the property goes to zero but YASim doesn't do the right thing? I agree, the configuration looks correct to me. Andy I've now done some more testing. I've now set up my keyboard so that I can adjust the property - all works. However, the weight property of the second tank cannot be set via the property browser. The problem _seems_ to lie in the Properties Browser. Now we need to be able to set the fuel property ... Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Eye candy
Vivian Meazza wrote: I've just done some proof-of-principle work on drop tanks with YASim. I set up some weight elements for the pylons and for the dry weight of the tanks, and some fuel tanks to match. [...] However, the bad news is that I can't set _one_ of the drop tank weights to zero (odd that), and none of the tank fuel contents. YASim doesn't currently support setting fuel tank contents, though, it treats the /sim/consumables/ properties as writables only; it doesn't read them. This wouldn't be too hard to fix. I'm not clear on the problem you are having with the weight tag. You can associate any property with the weight; just use different names and you can set them in any combination. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Eye candy
On Monday 16 February 2004 22:12, Martin Spott wrote: Vivian Meazza [EMAIL PROTECTED] wrote: However, the bad news is that I can't set _one_ of the drop tank weights to zero (odd that), and none of the tank fuel contents. I was planning to use keys j/J/CTRLJ for jettison inner/outer/all. As memory serves (late evening ;) j/k are used for speed brakes on some aircraft, Martin. Just to help confuse things a little, j/k are for spoilers, iirc, but as speed-brakes aren't supported in YASim (yet;) I've used the spoiler control input for what is effectively the speed brake function. Get's even more interesting with the YF-23 as it's 'speed-brake' is opposite deflection of flaps and ailerons, controlled by the spolier control:) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Eye candy
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 The same option should then be used for all the weapons as well; let it be dumb bombs, rockets or missles. They will all start with certain vector of speed and some point in space and will then change it through time (effect of force of gravity and weapon's propulsion). The tankers should be treated like normal dumb bombs. - Matevz ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Eye candy - Wing Bending
kreuzritter wrote: 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. I think the tweening support should be added for this. Then you would have as many wing sections as you define in the 3d model. You would basically have two different version of the same object bot defined at their maximum and the tweening code will take care of the rest. I think the tweening code will be fast enough. To be prepared for the future you could already add three versions of the wing: a max positive and max negative bend version which should be turned off in the animations file for now, and a normal version which should be turned off when tweening is implemented. I haven't looked at tweening yet, but since plib already supports it, implementing it into the SimGear animation code would probably be not much of a problem. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Eye candy
On Samstag, 14. Februar 2004 22:33, 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. Sounds interresting. I have this in mind now for my timestepping changes. As I told you before in a private mail, many ideas for something like that in my head ... Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] Eye candy
Actually, I'm pretty sure that with nasal and the animations we have we can do exhaust cones right now. Just model a cone, assign it a translucent, emmisive materiel and then use nasal to turn it on and off. You can even make it get bigger and smaller with the animations. Don't know how to do the smoke though. Also, those little clouds that form over the wings at high lift would be cool too. Josh Jon S Berndt wrote: Any chance of modeling wingtip vortices (when CL is high enough above some threshhold) and rocket engine exhaust? :-) 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
Josh Babcock wrote Actually, I'm pretty sure that with nasal and the animations we have we can do exhaust cones right now. Just model a cone, assign it a translucent, emmisive materiel and then use nasal to turn it on and off. You can even make it get bigger and smaller with the animations. Don't know how to do the smoke though. Also, those little clouds that form over the wings at high lift would be cool too. Josh Jon S Berndt wrote: Any chance of modeling wingtip vortices (when CL is high enough above some threshhold) and rocket engine exhaust? The Hunter model has a rudimentary representation of gas turbine exhaust using XML animation I think smoke might be more difficult. Wingtip vortices, and afterburner cones have been done on the T38. Condensation clouds over wing surfaces would be fun: the conditions under which they form might be difficult to calculate. Something I wanted to do in the future Vivian Meazza ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Eye candy
This would be nice: http://www.dfrc.nasa.gov/Gallery/Photo/X-15/Small/EC68-1889.jpg :-) Jon Josh Babcock [EMAIL PROTECTED] wrote: Actually, I'm pretty sure that with nasal and the animations we have we can do exhaust cones right now. Just model a cone, assign it a translucent, emmisive materiel and then use nasal to turn it on and off. You can even make it get bigger and smaller with the animations. Don't know how to do the smoke though. Also, those little clouds that form over the wings at high lift would be cool too. Josh Jon S Berndt wrote: Any chance of modeling wingtip vortices (when CL is high enough above some threshhold) and rocket engine exhaust? :-) 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 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Eye Candy
Now I want all the planes rendered with that ! stF Norman Vine wrote: If you have a machine to run this on :-) http://www.daionet.gr.jp/~masa/rthdribl/index.html Norman ___ 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
