Re: [Flightgear-devel] Future Weather System
Hi Stuart, I have checked in a version of the ground intersection routines that just use the bvh trees in the scenegraph. This should improove the run time behaviour for the ground queries. That should be even faster than the variant you tried since it avoids the extra computations/allocations that are required for building up a ground cache agound this point. If you experience any problems with this change please tell me. Greetings Mathias -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
Instead there are two shadings taking place:
1) Shading based on distance of the sprite to the sun. Effectively
we compare a vector from the center of the cloud to the sprite location
with the light normal.
2) Shading based on the vertical placement of the sprite in the cloud, so
lower sprites are shaded more. This is controlled by the
bottom-shade parameter.
I suspect that it is the latter that is misbehaving. IIRC the
bottom-shader is applied
as a factor to the lighting, so using a value of (say) 0.1 should
result in a dark cloud
bottom.
Upon further reflection - could it be the problem that I'm trying to
assemble a layer rather than fill a volume?
The bottom shading in 3dcloud.vert is controlled by a combination of
'shade' and 'cloud_height'. Your Nasal interface doesn't provide an option
to set 'cloud_height' explicitly, so I'm assuming it's the box height
determined from 'min-cloud-height-m' and 'max-cloud-height-m' as used by
add-cloud.
Now, in assembling a layer, I want the box to be essentially flat, i.e.
just distribute textures on a layer with very little extension in
altitude, such that the layer thickness is determined by the size of a
single sprite rather than the box size, i.e. the sprite height is larger
than the box height. See my cloud definition code below (it's all written
into a hash first before the property argument for cloud-add is
assembled, but the parameter names are pretty similar - in case you're
wondering, z-scale is just for my reference what should be there later and
in my current experiments simply inserted into the shader by hand)
if (subtype == small) {var mult = 0.7;}
else {var mult = 1.0;}
# characterize the basic texture sheet
cloudAssembly.texture_sheet = /Models/Weather/stratus_sheet1.rgb;
cloudAssembly.num_tex_x = 3;
cloudAssembly.num_tex_y = 2;
#characterize the cloud
cloudAssembly.bottom_shade = 0.4;
cloudAssembly.n_sprites = 20;
cloudAssembly.min_width = 1800.0 * mult;
cloudAssembly.max_width = 2200.0 * mult;
cloudAssembly.min_height = 1800.0 * mult;
cloudAssembly.max_height = 2200.0 * mult;
cloudAssembly.min_cloud_width = 2200.0 * mult * mult * mult;
cloudAssembly.min_cloud_height = 50.0 * mult * mult * mult;
cloudAssembly.z_scale = 0.5;
Case in point - while min_cloud_height is just 50 m, the height of a
texture sheet is 900-1100 m (originally twice that, but z-rescaling
shrinks it again).
I'm suspecting that somehow the shader doesn't expect that. Maybe cloud
height as passed to the shader should be max(box_height, texture_height)?
Or an optional parameter? In clouds_layered.vert, a hard-coded value of
1000 m works fine.
* Thorsten
--
BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts.
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos much more. Register early save!
http://p.sf.net/sfu/rim-blackberry-1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Future Weather System
2011/8/7 Mathias Fröhlich: I have checked in a version of the ground intersection routines that just use the bvh trees in the scenegraph. This should improove the run time behaviour for the ground queries. That should be even faster than the variant you tried since it avoids the extra computations/allocations that are required for building up a ground cache agound this point. If you experience any problems with this change please tell me. Thank you very much for doing this. It is indeed much faster than the previous queries, and much cleaner code than I think I could have written. I'm sure you've made Thorsten very happy indeed! -Stuart -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fwd: Generic Protocol Error -- Error opening serial device COM27 The system cannot find the file specified.
On Sat, 6 Aug 2011 23:09:44 -0400, Derrick wrote in message CAF74wjbov8xiA26W3_n2EA6HX04B2_8+U6mPn=9votkv8hu...@mail.gmail.com: OK so I found a solution, I think, I changed the COM port number to COM3. That seems to work but now FLIGHTGEAR will not accept inputs for some reason, when I set as shown below, FG just sits there and spins its wheels. If I set it up for output that works just fine. In addition to that I can't setup two generic protocols one for input and one for output, when I do that I just get an error can not open com port. I'm beginning to think that communication through the serial port doesn't work at all. C:\Program Files\FlightGear\bin\Win32\fgfs.exe --fg-root=C:\Program Files\FlightGear\data --fg-scenery=C:\Program Files\FlightGear\data\Scenery;C:\Program Files\FlightGear\scenery;C:\Program Files\FlightGear\terrasync --aircraft=f-14b --control=joystick --enable-random-objects --enable-ai-models --enable-clouds3d --fog-disable --geometry=1280x1024 --bpp=32 --texture-filtering=16 --timeofday=noon --atlas=socket,out,5,localhost,5500,udp --generic=serial,in,3,COM3,115200,FlightGear_GPI ..tried --generic=serial,in,3,\\.\COM3,115200,FlightGear_GPI? -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...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. -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
On Sun, Aug 7, 2011 at 11:24 AM, Thorsten Renk wrote:
Upon further reflection - could it be the problem that I'm trying to
assemble a layer rather than fill a volume?
The bottom shading in 3dcloud.vert is controlled by a combination of
'shade' and 'cloud_height'. Your Nasal interface doesn't provide an option
to set 'cloud_height' explicitly, so I'm assuming it's the box height
determined from 'min-cloud-height-m' and 'max-cloud-height-m' as used by
add-cloud.
Correct - the cloud is created with a width/height between the min/max values.
There are defaults, but I'm not sure they are what you are looking for! At
present they are as follows:
min-cloud-width-m, 500.0
max-cloud-width-m 1000.0
min-cloud-height-m, min-cloud-width-m
max-cloud-height-m, max-cloud-width-m
min-sprite-width-m, 200.0
max-sprite-width-m, min_sprite_width
min-sprite-height-m, min_sprite_width
max-sprite-height-m, max_sprite_width
I'm happy to change them to something else if it would be useful. I
suspect you might prefer the max values to always default to the min values?
Now, in assembling a layer, I want the box to be essentially flat, i.e.
just distribute textures on a layer with very little extension in
altitude, such that the layer thickness is determined by the size of a
single sprite rather than the box size, i.e. the sprite height is larger
than the box height. See my cloud definition code below (it's all written
into a hash first before the property argument for cloud-add is
assembled, but the parameter names are pretty similar - in case you're
wondering, z-scale is just for my reference what should be there later and
in my current experiments simply inserted into the shader by hand)
if (subtype == small) {var mult = 0.7;}
else {var mult = 1.0;}
# characterize the basic texture sheet
cloudAssembly.texture_sheet = /Models/Weather/stratus_sheet1.rgb;
cloudAssembly.num_tex_x = 3;
cloudAssembly.num_tex_y = 2;
#characterize the cloud
cloudAssembly.bottom_shade = 0.4;
cloudAssembly.n_sprites = 20;
cloudAssembly.min_width = 1800.0 * mult;
cloudAssembly.max_width = 2200.0 * mult;
cloudAssembly.min_height = 1800.0 * mult;
cloudAssembly.max_height = 2200.0 * mult;
cloudAssembly.min_cloud_width = 2200.0 * mult * mult * mult;
cloudAssembly.min_cloud_height = 50.0 * mult * mult * mult;
cloudAssembly.z_scale = 0.5;
Case in point - while min_cloud_height is just 50 m, the height of a
texture sheet is 900-1100 m (originally twice that, but z-rescaling
shrinks it again).
I'm suspecting that somehow the shader doesn't expect that. Maybe cloud
height as passed to the shader should be max(box_height, texture_height)?
Or an optional parameter? In clouds_layered.vert, a hard-coded value of
1000 m works fine.
I think the problem is that you are expecting the cloud height to
indicate the location
of sprite centers, wherease the code is expecting it to be the height
of the actual
cloud.
The code actually _subtracts_ the minimum texture height from the cloud
height to determine where to place sprite centers.
So, the height should always be greater than the minimum texture height.
In your example I would suggest setting
cloudAssembly.min_cloud_height = 50.0 * mult * mult * mul +
cloudAssembly.min_height
That should at least help the problem, though there may be other bugs there too.
BTW - this is all up for discussion. Just because I wrote the default
3D cloud code this
way doesn't mean to say that it's the correct approach!
-Stuart
--
BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts.
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos much more. Register early save!
http://p.sf.net/sfu/rim-blackberry-1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
I think the problem is that you are expecting the cloud height to indicate the location of sprite centers, wherease the code is expecting it to be the height of the actual cloud. The code actually _subtracts_ the minimum texture height from the cloud height to determine where to place sprite centers. So, the height should always be greater than the minimum texture height. Oops... In hindsight, a rather obvious explanation of what I'm seeing - a negative number created in the subtraction would of course invert the shading pattern seen later. Rather embarrassing... Thanks, I'll correct my code. * Thorsten -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
On Thu, Aug 4, 2011 at 12:51 PM, Thorsten Renk wrote: We should change the maximum to whatever you feel is sensible (40km?), and leave the default as it is (20km). I think my current maximum is 45 km, and for much more one needs a different tile structure anyway, so if we could get 45 km that'd be nice. I've made the small GUI dialog change required to allow users to get this up to 45km. However, I'm not sure we want to be over-riding the user's explicit preferences here. I can turn it around and use the value specified here for the cloud visible range of the old system - if that's not too confusing. I'm not quite sure what you mean, but certainly I think using a single visibility range property is a good idea. Perhaps we should look at integrating your routine to match a given fps value by adjusting cloud visibility range? Do we all agree that it makes sense to use cloud visibility range here, rather than random objects or such like? The advantage of using the cloud visibility range (and tree visibility range if I were to make it similarly dynamic) is that the effect of a change should be fairly subtle. Suddenly disabling (say) the urban shader will have quite a significant visual impact to the user. This probably needs a bit more thought. I'm also looking at ways to speed up the 3d clouds further by not rendering sprites at the back of the cloud (using the currently defunct cloud-density slider). The way this should be solved would be to generate Impostors of clouds where the view direction isn't changing much. Unfortunately the OSG implementation is Impostors doesn't work, and this is probably a lot of work. Yes, that's something I need to do. I think you've already implemented this in your codes. Can you point me at the best example shader/Effect? It's actually quite simple. You have: // Do the matrix multiplication by [ u r w pos]. Assume no // scaling in the homogeneous component of pos. gl_Position = vec4(0.0, 0.0, 0.0, 1.0); gl_Position.xyz = gl_Vertex.x * u; gl_Position.xyz += gl_Vertex.y * r * wScale; gl_Position.xyz += gl_Vertex.z * w * hScale; gl_Position.xyz += gl_Color.xyz; and I add just after that block gl_Position.z = gl_Position.z * zScale; (look into clouds-layered.vert where a value of 0.4 is hard-coded there). This is also now down (thanks to Torsten D. for the very fast merge). We now support a z-scale value which takes a value from 0.0 to 1.0. Default is 1.0. Great. Let me know what else you need and I'll put it near the top of my FG todo list. Wow :-) Thanks a lot! I think wrapping off and z-scaling are what limits my experiments most - otherwise I simply need time to catch up with texturing, parameter tuning, performance tests, but I'll keep you posted. Switching wrapping off is also supported, as of this morning. It is a global boolean property - /sim/rendering/clouds3d-wrap. It defaults to true. I haven't yet put any logic in to switch it on when global weather is enabled, so you'll need too manage it actively within Local Weather for the moment. That combined with Mathias' fantastic work to improve the speed of alt/mat checks via geodinfo() should mean you've got all you need. -Stuart -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Future Weather System
Hi, On Sunday, August 07, 2011 12:32:36 Stuart Buchanan wrote: 2011/8/7 Mathias Fröhlich: I have checked in a version of the ground intersection routines that just use the bvh trees in the scenegraph. This should improove the run time behaviour for the ground queries. That should be even faster than the variant you tried since it avoids the extra computations/allocations that are required for building up a ground cache agound this point. If you experience any problems with this change please tell me. Thank you very much for doing this. It is indeed much faster than the previous queries, and much cleaner code than I think I could have written. Hmm, thanks. I have now seen that this has overlapped a question from yours form yesterday evening. I just got up today morning, took a look outside - still no summer in mid europe - and decided to hack something. Then I just thought that this change might be good to have... :) Did you really measure again how much faster this is? Just some average rule of thumb? Greetings Mathias -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Future Weather System
2011/8/7 Mathias Fröhlich wrote: I have now seen that this has overlapped a question from yours form yesterday evening. I just got up today morning, took a look outside - still no summer in mid europe - and decided to hack something. Then I just thought that this change might be good to have... :) Same problem in Scotland :) Did you really measure again how much faster this is? Just some average rule of thumb? Running the same test as described above (Nasal geodinfo() called in 0.01 steps across a 1x1 degree area) in the same place, I got the following results from multiple runs of the code. Old scenery.cxx method: 5.78s - 6.15s Groundcache hack: 0.38 - 0.5s New scenery.cxx method: 0.1s - 0.12s The tests were run at different times, so there may be some environmental differences based on what else was running on my laptop etc. Nevertheless, that's a massive performance improvement over the old method, and a significant improvement over the groundcache hack I wrote. -Stuart -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fwd: Generic Protocol Error -- Error opening serial device COM27 The system cannot find the file specified.
Inputs: what inputs are you sending? Are they getting overwritten by internal processing? If you are inputting position and orientation (for instance) you need to turn off the internal flight dynamics engine (--fdm=null) If you are inputting control surface positions, you probably don't want a joystick plugged in, etc. On Sun, Aug 7, 2011 at 6:12 AM, Arnt Karlsen a...@c2i.net wrote: On Sat, 6 Aug 2011 23:09:44 -0400, Derrick wrote in message CAF74wjbov8xiA26W3_n2EA6HX04B2_8+U6mPn=9votkv8hu...@mail.gmail.com: OK so I found a solution, I think, I changed the COM port number to COM3. That seems to work but now FLIGHTGEAR will not accept inputs for some reason, when I set as shown below, FG just sits there and spins its wheels. If I set it up for output that works just fine. In addition to that I can't setup two generic protocols one for input and one for output, when I do that I just get an error can not open com port. I'm beginning to think that communication through the serial port doesn't work at all. C:\Program Files\FlightGear\bin\Win32\fgfs.exe --fg-root=C:\Program Files\FlightGear\data --fg-scenery=C:\Program Files\FlightGear\data\Scenery;C:\Program Files\FlightGear\scenery;C:\Program Files\FlightGear\terrasync --aircraft=f-14b --control=joystick --enable-random-objects --enable-ai-models --enable-clouds3d --fog-disable --geometry=1280x1024 --bpp=32 --texture-filtering=16 --timeofday=noon --atlas=socket,out,5,localhost,5500,udp --generic=serial,in,3,COM3,115200,FlightGear_GPI ..tried --generic=serial,in,3,\\.\COM3,115200,FlightGear_GPI? -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...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. -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How to turn off the 3D cockpit
? wrote: I am using the FG as simulator with HUD, but if I start the program like Cessna 172P, here is the view of 3D cockpit, how can I turn off the 3D cockpit when I use multi-screen? The 3D cockpit of our default Cessna is an integral part of the entire airframe 3D model. In order to get rid of the panel you might consider creating a custom AC3D model with the panel deleted. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fwd: Generic Protocol Error -- Error opening serial device COM27 The system cannot find the file specified.
On Sat, 6 Aug 2011, Derrick Washington wrote: OK, has anyone actually attempted this method, and got it too work, lol bcus I just tried it got the bluescreen of death twice. The syntax definitely does something but it also take the computer down, any suggestions? Typically when a BSOD happens it means that a driver or kernel process has lost its mind. Can you access that serial port with a terminal program without issue? Unless you've got 26 other serial ports on that machine, I'd strongly suggest researching what caused Windows to assign COM27 to your device. It's NOT typical behavior. g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.simpits.org/geneb - The Me-109F/X Project Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Political correctness is a doctrine, fostered by a delusional, illogical minority, and rabidly promoted by an unscrupulous mainstream media, which holds forth the proposition that it is entirely possible to pick up a turd by the clean end. -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fwd: Generic Protocol Error -- Error opening serial device COM27 The system cannot find the file specified.
Gene, Unless you've got 26 other serial ports on that machine, I'd strongly suggest researching what caused Windows to assign COM27 to your device. It's NOT typical behavior. You can assign any number you want to a COM port when it is driven by a USB-to-COM or Ethernet-to-COM adapter. Simply go to the Device Manager and set it between 1 and 255. There are a lot of make of these kind of device. Some are good, others not so ... Regards, -Fred -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fwd: Generic Protocol Error -- Error opening serial device COM27 The system cannot find the file specified.
On Sun, 7 Aug 2011, Frederic Bouvier wrote: Gene, Unless you've got 26 other serial ports on that machine, I'd strongly suggest researching what caused Windows to assign COM27 to your device. It's NOT typical behavior. You can assign any number you want to a COM port when it is driven by a USB-to-COM or Ethernet-to-COM adapter. Simply go to the Device Manager and set it between 1 and 255. I know that, but most of the time you don't specifically set a COM port number by hand - you let Windows pick the next un-used port #. g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.simpits.org/geneb - The Me-109F/X Project Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Political correctness is a doctrine, fostered by a delusional, illogical minority, and rabidly promoted by an unscrupulous mainstream media, which holds forth the proposition that it is entirely possible to pick up a turd by the clean end. -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Future Weather System
2011/8/7 Mathias Fröhlich wrote: Hi Stuart, I have checked in a version of the ground intersection routines that just use the bvh trees in the scenegraph. This should improove the run time behaviour for the ground queries. That should be even faster than the variant you tried since it avoids the extra computations/allocations that are required for building up a ground cache agound this point. If you experience any problems with this change please tell me. I think this may have broken YASim aircraft. I've tried a selection (dc3, dc-3, a4f) and they all start at 36,000ft altitude with 0 IAS. I suspect it might be an initialization order issue, I've raised it as bug 397 (http://code.google.com/p/flightgear-bugs/issues/detail?id=397) -Stuart -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fwd: Generic Protocol Error -- Error opening serial device COM27 The system cannot find the file specified.
Curt... I believe I'm just inputting control surface positions, however but I did have the remote plugged in, I'll make sure to unplug it on my next try. On Sun, Aug 7, 2011 at 11:10 AM, Curtis Olson curtol...@gmail.com wrote: Inputs: what inputs are you sending? Are they getting overwritten by internal processing? If you are inputting position and orientation (for instance) you need to turn off the internal flight dynamics engine (--fdm=null) If you are inputting control surface positions, you probably don't want a joystick plugged in, etc. On Sun, Aug 7, 2011 at 6:12 AM, Arnt Karlsen a...@c2i.net wrote: On Sat, 6 Aug 2011 23:09:44 -0400, Derrick wrote in message CAF74wjbov8xiA26W3_n2EA6HX04B2_8+U6mPn=9votkv8hu...@mail.gmail.com: OK so I found a solution, I think, I changed the COM port number to COM3. That seems to work but now FLIGHTGEAR will not accept inputs for some reason, when I set as shown below, FG just sits there and spins its wheels. If I set it up for output that works just fine. In addition to that I can't setup two generic protocols one for input and one for output, when I do that I just get an error can not open com port. I'm beginning to think that communication through the serial port doesn't work at all. C:\Program Files\FlightGear\bin\Win32\fgfs.exe --fg-root=C:\Program Files\FlightGear\data --fg-scenery=C:\Program Files\FlightGear\data\Scenery;C:\Program Files\FlightGear\scenery;C:\Program Files\FlightGear\terrasync --aircraft=f-14b --control=joystick --enable-random-objects --enable-ai-models --enable-clouds3d --fog-disable --geometry=1280x1024 --bpp=32 --texture-filtering=16 --timeofday=noon --atlas=socket,out,5,localhost,5500,udp --generic=serial,in,3,COM3,115200,FlightGear_GPI ..tried --generic=serial,in,3,\\.\COM3,115200,FlightGear_GPI? -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...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. -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fwd: Generic Protocol Error -- Error opening serial device COM27 The system cannot find the file specified.
OK So I believe I've got it to work on COM27 by using the \\.\COM27 syntax. I still have a problem sending and receiving at the same time, FG will not allow me to open up multiple generic serial protocols to the same COM port for in and out, only one at a time and bi directional doesn't seem to be supported. On Sun, Aug 7, 2011 at 12:39 PM, Gene Buckle ge...@deltasoft.com wrote: On Sun, 7 Aug 2011, Frederic Bouvier wrote: Gene, Unless you've got 26 other serial ports on that machine, I'd strongly suggest researching what caused Windows to assign COM27 to your device. It's NOT typical behavior. You can assign any number you want to a COM port when it is driven by a USB-to-COM or Ethernet-to-COM adapter. Simply go to the Device Manager and set it between 1 and 255. I know that, but most of the time you don't specifically set a COM port number by hand - you let Windows pick the next un-used port #. g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.simpits.org/geneb - The Me-109F/X Project Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Political correctness is a doctrine, fostered by a delusional, illogical minority, and rabidly promoted by an unscrupulous mainstream media, which holds forth the proposition that it is entirely possible to pick up a turd by the clean end. -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FlightGear Inputs
Hi
I need to know if the inputs coming from FG, while using a generic
protocol having binary mode set to true, are coming in as integers that need
to be converted to floating point or is FG actually sending in a floating
point word, a byte at a time? So my code to receive FG data looks something
like this
for ( int i = 0; i = 3; i++ ) { dummy_var = (dummy_var 8) |
rs232_uart1; }
return ( (float) dummy_var);
What I am wondering is, is the return ( (float) dummy_var); cast to a
float necessary, or is the number already in floating point format, if so
then I need to instruct my hardware to retrieve a full word at a time. I've
included the xml file just in case you guys have any questions about what
data I am asking FG to transmit.
?xml version=1.0?
PropertyList
generic
input
line_separator\n/line_separator
var_separator,/var_separator
chunk
nameThrottle (rad)/name
typeinteger/type
node/controls/engines/engine[0]/throttle/node
/chunk
chunk
nameAileron (rad)/name
typefloat/type
node/controls/flight/aileron/node
/chunk
chunk
nameElevator (rad)/name
typefloat/type
node/controls/flight/elevator/node
/chunk
chunk
namerudder (rad)/name
typefloat/type
node/controls/flight/rudder/node
/chunk
chunk
nameGears /name
typefloat/type
node/controls/gear/gear-down/node
/chunk
chunk
nameSteering /name
typefloat/type
node/controls/gear/steering/node
/chunk
/input
/generic
/PropertyList--
BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts.
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos much more. Register early save!
http://p.sf.net/sfu/rim-blackberry-1___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] How to turn off the 3D cockpit
Does Flightgear have any view like that? I have reference some one press c to turn off the panel, but it is not effect in default cessna -邮件原件- 发件人: Martin Spott [mailto:martin.sp...@mgras.net] 发送时间: 2011年8月8日 0:07 收件人: flightgear-devel@lists.sourceforge.net 主题: Re: [Flightgear-devel] How to turn off the 3D cockpit ? wrote: I am using the FG as simulator with HUD, but if I start the program like Cessna 172P, here is the view of 3D cockpit, how can I turn off the 3D cockpit when I use multi-screen? The 3D cockpit of our default Cessna is an integral part of the entire airframe 3D model. In order to get rid of the panel you might consider creating a custom AC3D model with the panel deleted. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Future Weather System
Hi, On Sunday, August 07, 2011 20:46:46 Stuart Buchanan wrote: I think this may have broken YASim aircraft. I've tried a selection (dc3, dc-3, a4f) and they all start at 36,000ft altitude with 0 IAS. I suspect it might be an initialization order issue, I've raised it as bug 397 (http://code.google.com/p/flightgear-bugs/issues/detail?id=397) I will look into this. Today evening. Mathias -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How to turn off the 3D cockpit
Set /sim/allow-toggle-cockpit to 'true' , then press 'c' 2011/8/7 金承德 jinchen...@gmail.com: Does Flightgear have any view like that? I have reference some one press c to turn off the panel, but it is not effect in default cessna -邮件原件- 发件人: Martin Spott [mailto:martin.sp...@mgras.net] 发送时间: 2011年8月8日 0:07 收件人: flightgear-devel@lists.sourceforge.net 主题: Re: [Flightgear-devel] How to turn off the 3D cockpit ? wrote: I am using the FG as simulator with HUD, but if I start the program like Cessna 172P, here is the view of 3D cockpit, how can I turn off the 3D cockpit when I use multi-screen? The 3D cockpit of our default Cessna is an integral part of the entire airframe 3D model. In order to get rid of the panel you might consider creating a custom AC3D model with the panel deleted. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
