Re: [Flightgear-devel] shaders for flightgear
Arnt Karlsen wrote: ..in sim's, it's legal to buzz town, no? ;-) No, FAA and JAA regulations for simulators forbid that ... Erik (;-)) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Radio Hardware.
folks: i''d like to offer my (bleated) thanks to curtis olson, john wojnaroski and manuel bessler for taking the time to respond to yet another newbie. i've received some good pointers from you all. it looks as if there are several approaches i could take to interfacing a stack of simulated radios to the FG sim. i guess i'm going to have to roll up my sleeves and dive into the code base. one additional approach has occurred to me though, and i wonder if you all can offer an opinion. it's been said that there are two approcahes to my problem: 1) write a module that will run once per frame and handle control inputs and display outputs on my hardware. 2) write a network client that is telnet based and send packets over the net. it occurrs to me that if FG supports telnet, that there must be a class somewhere that handles socket based communication. since sockets also make a fairly elegant for of IPC on a unix system, i was thinking that developing a class (or subclass) for this purpose might work out well with minimum impact to the existing code. could anyone commenton this idea please? in closing, i'd also like to ask if there is any sort of technical reference dosumentation that would allow a new coder to begin exploring the project. thanks to all, and best regards, martin pardee ___ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] contrails
From sky-writing it's a short step to contrails. Here's a screenshot of a first stab at contrails. Of course it will look better with something besides my white boxes! http://home.comcast.net/~davidculp2/contrail.jpg This contrail contains a bunch of submodels that have a life-span of four seconds, so the trail terminates itself at a distance of four seconds behind the airplane. The submodels, which use the puff.ac visual model, are released at 0.01 second intervals, however the real interval is limited to some larger amount due to frame rate. The contrail visual model will have to be tubular to avoid gaps between submodels. This isn't in the code base yet, but I'll send on later today. Next step is to define a contrail-level item for the environment system (with a default value of 3 ?) to set the contrail level, and then have the environment system set a boolean property, like /environment/contrails, to true when the user is above the contrail level. The submodel can then use /environment/contrails as a trigger. Dave -- David Culp [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Radio Hardware.
martin pardee wrote: folks: i''d like to offer my (bleated) thanks to curtis olson, john wojnaroski and manuel bessler for taking the time to respond to yet another newbie. i've received some good pointers from you all. it looks as if there are several approaches i could take to interfacing a stack of simulated radios to the FG sim. i guess i'm going to have to roll up my sleeves and dive into the code base. one additional approach has occurred to me though, and i wonder if you all can offer an opinion. it's been said that there are two approcahes to my problem: 1) write a module that will run once per frame and handle control inputs and display outputs on my hardware. I don't think it is possible to have a reliable data flow, and doing things every frame will slow the whole thing. 2) write a network client that is telnet based and send packets over the net. it occurrs to me that if FG supports telnet, that there must be a class somewhere that handles socket based communication. since sockets also make a fairly elegant for of IPC on a unix system, i was thinking that developing a class (or subclass) for this purpose might work out well with minimum impact to the existing code. Well, if you use the telnet protocol there is no impact on FG code and it can work today. could anyone commenton this idea please? in closing, i'd also like to ask if there is any sort of technical reference dosumentation that would allow a new coder to begin exploring the project. You should have a look at fgfsclient.cxx in the FG/script/exmaple subtree (on the cvs). The script/python subtree has also good examples of what can be done using the telnet protocol. The server side of the telnet protocol can be found in the src/Natwork/props.* files. Also FG must be lauched with --props=5501 to activate the server side. Now you juste have to find the properties that you need and the property browser is handy for that. thanks to all, and best regards, martin pardee ___ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Radio Hardware.
On Sat, Aug 28, 2004 at 07:25:29AM -0700, martin pardee wrote:
it occurrs to me that if FG supports telnet, that there must be a class
somewhere that handles socket based communication. since sockets also make a
fairly elegant for of IPC on a unix system, i was thinking that developing a
class (or subclass) for this purpose might work out well with minimum impact to
the existing code.
Not sure if the existing code can do it, but it shouldn't be too hard to
add support for unix sockets/fifos.
the README.IO in the source distribution under docs-mini says (in mine
anyways, my CVS is several months old):
medium = { serial, socket, file, etc. }
... it should be possible to add if its not there yet.
The only problem could be that file-based sockets/fifos might not be
portable across all OSs.
in closing, i'd also like to ask if there is any sort of technical reference
dosumentation that would allow a new coder to begin exploring the project.
I'm primarily interested in the hardware side of your project...
Are you building the radio stack yourself or are you buying some ?
Regards,
Manuel
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] contrails
We could also simulate the condense effect by this (when in right combination of temerature and rel. humidity, water drops appear behind the engine). Texture for this puff should be a bit more transparent, but should vary as well. It should last for more than 4 seconds as well and should slowly scale up (like the real condense lines when you look at them from the ground). - Matevz David Culp wrote: From sky-writing it's a short step to contrails. Here's a screenshot of a first stab at contrails. Of course it will look better with something besides my white boxes! http://home.comcast.net/~davidculp2/contrail.jpg This contrail contains a bunch of submodels that have a life-span of four seconds, so the trail terminates itself at a distance of four seconds behind the airplane. The submodels, which use the puff.ac visual model, are released at 0.01 second intervals, however the real interval is limited to some larger amount due to frame rate. The contrail visual model will have to be tubular to avoid gaps between submodels. This isn't in the code base yet, but I'll send on later today. Next step is to define a contrail-level item for the environment system (with a default value of 3 ?) to set the contrail level, and then have the environment system set a boolean property, like /environment/contrails, to true when the user is above the contrail level. The submodel can then use /environment/contrails as a trigger. Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] contrails
We could also simulate the condense effect by this (when in right combination of temerature and rel. humidity, water drops appear behind the engine). That would be nice. In the interim I'll have the contrail level default to 3 feet, and make it user-settable in the startup configs. Texture for this puff should be a bit more transparent, but should vary as well. The trouble with transparent puffs is that they change transparency when they overlap. Textured might work out better. Here's a nice reference photo: http://www.airliners.net/open.file/638942/M/ It should last for more than 4 seconds as well and should slowly scale up (like the real condense lines when you look at them from the ground). A 4-second trail looks like it has about 50 puffs in it (I'm guessing). At some point there is a limit to how many AI objects you want at one time, but I don't know where that point is. An 8 mile long contrail will take an airliner one minute to make, and that will require 750 puffs to build. I think we'll need a different system to build long contrails. As for the scaling, I don't know if that's possible. Does Plib support scaling an object over time? Dave -- David Culp [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] contrails
On Sat, 28 Aug 2004 17:34:47 -0500, David wrote in message [EMAIL PROTECTED]: We could also simulate the condense effect by this (when in right combination of temerature and rel. humidity, water drops appear behind the engine). That would be nice. In the interim I'll have the contrail level default to 3 feet, and make it user-settable in the startup configs. Texture for this puff should be a bit more transparent, but should vary as well. The trouble with transparent puffs is that they change transparency when they overlap. Textured might work out better. Here's a nice reference photo: http://www.airliners.net/open.file/638942/M/ ..both can be done, textured in the normal case, and transplarant in the still rather rare case of FG formation flight. ;-) It should last for more than 4 seconds as well and should slowly scale up (like the real condense lines when you look at them from the ground). A 4-second trail looks like it has about 50 puffs in it (I'm guessing). At some point there is a limit to how many AI objects you want at one time, but I don't know where that point is. An 8 mile long contrail will take an airliner one minute to make, and that will require 750 puffs to build. I think we'll need a different system to build long contrails. As for the scaling, I don't know if that's possible. Does Plib support scaling an object over time? ..a wild stab in the darkness: Does the clouds change in FG? ..a contrail is a cloud make by an engine (or more). If it's damp enough up there, contrails will grow into an overcast. If it's dry, contrails fade away, sometimes quickly, I've seen them form one plane length behind an airliner and gone in the next plane length. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] contrails
On Saturday 28 August 2004 23:34, David Culp wrote: We could also simulate the condense effect by this (when in right combination of temerature and rel. humidity, water drops appear behind the engine). That would be nice. In the interim I'll have the contrail level default to 3 feet, and make it user-settable in the startup configs. Texture for this puff should be a bit more transparent, but should vary as well. The trouble with transparent puffs is that they change transparency when they overlap. Textured might work out better. Here's a nice reference photo: http://www.airliners.net/open.file/638942/M/ It should last for more than 4 seconds as well and should slowly scale up (like the real condense lines when you look at them from the ground). A 4-second trail looks like it has about 50 puffs in it (I'm guessing). At some point there is a limit to how many AI objects you want at one time, but I don't know where that point is. An 8 mile long contrail will take an airliner one minute to make, and that will require 750 puffs to build. I think we'll need a different system to build long contrails. As for the scaling, I don't know if that's possible. Does Plib support scaling an object over time? Dave Something that sprung to mind: make the puffs quite a bit longer so that they overlap (possibly tapered or bulged a bit in the middle too) and use an alpha gradient on the texture. Make several different textures, with slightly different patterning and pump them out in sequences, making them slowly (counter?)rotate around their long axis. Finally use the texture blend anim function to fade them out just before they're deleted. Just a thought... I'm a bit busy atm, otherwise I'd try it. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] contrails
On Saturday 28 August 2004 23:34, David Culp wrote: We could also simulate the condense effect by this (when in right combination of temerature and rel. humidity, water drops appear behind the engine). That would be nice. In the interim I'll have the contrail level default to 3 feet, and make it user-settable in the startup configs. Texture for this puff should be a bit more transparent, but should vary as well. The trouble with transparent puffs is that they change transparency when they overlap. Textured might work out better. Here's a nice reference photo: http://www.airliners.net/open.file/638942/M/ It should last for more than 4 seconds as well and should slowly scale up (like the real condense lines when you look at them from the ground). A 4-second trail looks like it has about 50 puffs in it (I'm guessing). At some point there is a limit to how many AI objects you want at one time, but I don't know where that point is. An 8 mile long contrail will take an airliner one minute to make, and that will require 750 puffs to build. I think we'll need a different system to build long contrails. As for the scaling, I don't know if that's possible. Does Plib support scaling an object over time? Dave Oops - forgot. There is a scaling anim function already in FG and objects can certainly be scaled based on values in the property tree, so it should be possible to do it with Nasal. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Taildragger takeoff and landing
Sent: Tuesday, June 28, 2005 1:20 PM You might want to change the date on your PC. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
