[Flightgear-devel] Route Manager
Hello all, What's the best way to Set and Get the waypoints that have been entered into the Route Manager? Gordon. This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. MBDA UK Limited, a company registered in England and Wales, registration number 3144919 whose registered office is at Six Hills Way, Stevenage, Hertfordshire, SG1 2DA, England. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __-- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] *** SPAM *** Re: Scene ambient and specularcolor changes
Erik Hofman wrote: After reading the comments I agree with it. I'll take some time to adjust the ambient accordingly. This has been committed to CVS now. Let me know what you think. (keep in mind that the darkest ambient color is defined in data/Lighting/ambient which has not been touched for ages). Erik -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] jsbsim wind correction in opposite direction
On mercredi 01 avril 2009, jean pellotier wrote: Jon S. Berndt a écrit : Yes, the difference stems from the need to know what the wind is bringing, and the vectorial definition of where it's going. The problem was that sometimes we just had a vector where we expected to see North, East, and Down, wind components. Well ... fine, but is that to or from. The convention was unspecified, and that caused confusion. From the FlightGear side, I can see winds being specified either way. In the flight dynamics code, however, I expect to see a wind velocity vector - the direction it's going. The question is, where does the conversion to the wind velocity vector form break? Jon After having seen in some places in last JSBSim code that wind direction is the direction the wind is toward, here's a patch that revert the values used in wind vector for JSBSim, that work for me, wind is now correctly applied. i didn't tested vertical composante . hope that helps jano OK Tested, with the Carrier to wind , now, when taking off, we do have the JSBSim aircraft getting the wind in front of The difference of velocity between air speed and ground speed is right. JSBSim.cxx wants that patch , the users too :) -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] *** SPAM *** Re: Scene ambient and specularcolor changes
Erik Erik Hofman wrote: After reading the comments I agree with it. I'll take some time to adjust the ambient accordingly. This has been committed to CVS now. Let me know what you think. (keep in mind that the darkest ambient color is defined in data/Lighting/ambient which has not been touched for ages). IMO, without any real data to judge it by, the specular adjustment is good enough. Ambient is still significantly too dark - on the side of an ac lit only by ambient light, it is just about black. In my experience, on the brightest days when the difference between ambient and diffuse is greatest, there is always enough ambient light to penetrate even the most intense shadows. I'll do a couple of screen shots later Vivian -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] *** SPAM *** Re: Scene ambient and specularcolor changes
On Fri, Apr 3, 2009 at 7:26 AM, Vivian Meazza wrote: Erik Hofman wrote: After reading the comments I agree with it. I'll take some time to adjust the ambient accordingly. This has been committed to CVS now. Let me know what you think. (keep in mind that the darkest ambient color is defined in data/Lighting/ambient which has not been touched for ages). IMO, without any real data to judge it by, the specular adjustment is good enough. Ambient is still significantly too dark - on the side of an ac lit only by ambient light, it is just about black. In my experience, on the brightest days when the difference between ambient and diffuse is greatest, there is always enough ambient light to penetrate even the most intense shadows. I'll do a couple of screen shots later One thing to possibly consider is that when we (someday) get back to having shadows cast by the aircraft, we may need to recalibrate some of these parameters. I recall long ago when I was trying to play with ambient/diffuse parameters for terrain, I quickly discovered a big part of the problem is the lack of dynamic range of a computer monitor. The diffuse lighting is based on the angle of the surface relative to the angle of the light source, and near dawn/dusk this gets really low. And because of the way opengl does the lighting math you can't really do anything about that (nor would you want to.) However, in order to get the scene brightness back up to something usable, you have to boost the ambient component of the lighting artificially high, and then all shadows go away. Contributing to the problem (I think) is that most of us view the scene in a normally lit room. If we forced everyone to only view FlightGear inside a perfectly dark room, I think we could do a little better. But this is a really hard problem. Very easy to get wrong, impossible to get right, very hard to get mostly right (or not distractingly wrong.) Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Elevation trouble with Scenery
I've been mucking around trying to build my own scenery for the last couple weeks, with a VAST amount of help from Geoff McLane. I've got it all working, and have been able to generate my own scenery. However, the elevation is coming out all messed up. Geoff has some photos of how it has come out available on his site: http://geoffair.net/tmp/cullam-01.htm Almost all the land data is appearing completely flat, at -m. There are a few pieces of land that appear at sea level. All airports are at sea level. I'm working on the scenery for the island of Newfoundland. I'm using the DEM data available from http://geobase.ca/geobase/en/data/cded/index.html\, which has a resolution of about 30m. According to the Terragear tools, this data is in the correct ASCII format, and is good to go for demchop. After running demchop on about 380 of these files, the folder containing the chopped elevation data is 131.1 MB. I then run genapts on my apt.dat file which was modified to include airports that aren't in the official apt.dat, and to correct their layouts. Again, there don't appear to be any problems. For my shapefile, I'm simply using the standard North American vmap0. This appears to have been prepared without incident. And then I run fgfs-construct. After the construction is done, my total folder size for everything just generated is 7.1 MB. This has GOT to be where the elevation data is disappearing, but I have no idea why. Obviously, there are massive ammounts of specifics that I could get into, but then this question would be huge and complex. So all I'm asking here is, does anybody have any idea where I should start looking to figure out where this went wrong? __ Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now http://ca.toolbar.yahoo.com.-- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Elevation trouble with Scenery
Hi there, did you ask on the forum about that? There's currently a good discussion going on about how to do it. There's also a few hints on what can go wrong. http://www.flightgear.org/forums/viewtopic.php?f=5t=3230 (Yes I know that this thread is about Windows but a lot of the things that went wrong are concerning paths. So _do_ please take a look at it.) But from what you've written, I've got the sneaking suspicion that you are using a weird version of terragear. At least I don't know about a tool called demchop - I only know one called hgtchop. Putting that aside, thre's more: Note that genapts also needs the elevation data. Also look out for any error message the tools spit out along the lines of cant find file somescenrytile.whatever extension. They should point you towards what's going wrong exactly. Maybe you've missed a few tiles, you need or they are in the wrong place. (One of the tools looks for the tiles in a set of hard-coded folders.) Cheers, Josef cullam Bruce-Lockhart schrieb: I've been mucking around trying to build my own scenery for the last couple weeks, with a VAST amount of help from Geoff McLane. I've got it all working, and have been able to generate my own scenery. However, the elevation is coming out all messed up. Geoff has some photos of how it has come out available on his site: http://geoffair.net/tmp/cullam-01.htm Almost all the land data is appearing completely flat, at -m. There are a few pieces of land that appear at sea level. All airports are at sea level. I'm working on the scenery for the island of Newfoundland. I'm using the DEM data available from http://geobase.ca/geobase/en/data/cded/index.html\, which has a resolution of about 30m. According to the Terragear tools, this data is in the correct ASCII format, and is good to go for demchop. After running demchop on about 380 of these files, the folder containing the chopped elevation data is 131.1 MB. I then run genapts on my apt.dat file which was modified to include airports that aren't in the official apt.dat, and to correct their layouts. Again, there don't appear to be any problems. For my shapefile, I'm simply using the standard North American vmap0. This appears to have been prepared without incident. And then I run fgfs-construct. After the construction is done, my total folder size for everything just generated is 7.1 MB. This has GOT to be where the elevation data is disappearing, but I have no idea why. Obviously, there are massive ammounts of specifics that I could get into, but then this question would be huge and complex. So all I'm asking here is, does anybody have any idea where I should start looking to figure out where this went wrong? Be smarter than spam. See how smart SpamGuard is at giving junk email the boot with the *All-new Yahoo! Mail * http://ca.promos.yahoo.com/newmail/overview2/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Elevation trouble with Scenery
cullam Bruce-Lockhart wrote: I've been mucking around trying to build my own scenery for the last couple weeks, with a VAST amount of help from Geoff McLane. I've got it all working, and have been able to generate my own scenery. However, the elevation is coming out all messed up. Geoff has some photos of how it has come out available on his site: http://geoffair.net/tmp/cullam-01.htm Almost all the land data is appearing completely flat, at -m. There are a few pieces of land that appear at sea level. All airports are at sea level. I'm working on the scenery for the island of Newfoundland. I'm using the DEM data available from http://geobase.ca/geobase/en/data/cded/index.html\, which has a resolution of about 30m. According to the Terragear tools, this data is in the correct ASCII format, and is good to go for demchop. After running demchop on about 380 of these files, the folder containing the chopped elevation data is 131.1 MB. I then run genapts on my apt.dat file which was modified to include airports that aren't in the official apt.dat, and to correct their layouts. Again, there don't appear to be any problems. If your airports are at sea level then there's a very good chance your processed DEM data is in the wrong directory. If you run genapts without any parameters ISTR you'll get a list of the directories it will search. Jon -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] RFC: graphics effects files
Hello, A couple of weeks ago I was asked for a sample of an effects file that uses my proposed changes to the property system; here it is. The syntax differs from current property system syntax in two ways: it uses vector types for some properties, and some properties can have a variance=dynamic attribute that indicates that a parameter can be animated and that graphics state that depends on it may need to be updated. Many people seem unconvinced by my arguments for new property types. That's fine; I'm still convinced that they are desirable :) One implementation reason that I would like to treat values like colors as vectors is that the underlying OSG type is a vector, so if the components are individual properties that can be written individually, the implementation choices for updating the OSG state are unattractive: 1) Write the full vector every time a component is changed. This means potentially 4 times the memory traffic to change a color, and leaves the values stored in OSG in an inconsistent state for a time. 2) Update all effects with dynamic components every frame. We have a lot of material animations, and their management is currently eats a lot of time in the update phase, so I'd like to avoid this. On the other hand, we may be updating most animations every frame anyway. 3) Record which effects have been changed, then update their OSG state. Complicated bookkeeping... If people really don't like the effects syntax, I might be willing to hold my nose and use the existing property implementation. I'm also not committed to having the effects properties be of class SGPropertyNode; they might be a subtype. ?xml version=1.0 encoding=utf-8 !-- An effect consists of parameters and techniques. The parameters section of an effect is a tree of values that describe, abstractly, the graphical appearence of objects that use the effect. Techniques refer to these parameters and use them to set OpenGL state or to set parameters for shader programs. Parameters can be declared to have a dynamic variance, which means that if their value is changed the corresponding value in the technique will be changed too. A technique can contain a predicate that describes the OpenGL functionality required to support the technique. The first technique with a valid predicate in the list of techniques is used to set up the graphics state of the effect. A technique with no predicate is always assumed to be valid. A technique can consist of several passes, which are run in sequence. One feature not fully illustrated in the sample below is that effects can inherit from each other. The parent effect is listed in the inherits-from form. The child effect's property tree is overlaid over that of the parent. This means that effects that inherit from the example default effect below could be very short, listing just new parameters and adding nothing to the techniques section; alternatively, a technique could be altered or customized in a child, listing (for example) a different shader program. Material animations will be implemented by creating a new effect that inherits from one in a model, overriding the parameters that will be animated. -- PropertyList effect namedefault-effect/name !-- inherits-fromanother-effect/inherits-from -- parameters material ambient type=vec4d 0.0 0.0 0.0 1.0 /ambient diffuse type=vec4d .5 .5 .5 1.0 /diffuse specular type=vec4d 0.3 0.3 0.3 1.0 /specular emissive type=vec4d variance=dynamic 0.0 0.0 0.0 1.0 /emissive shininess1.2/shininess /material texture0 texture2d imagecity.png/image filterlinear-mipmap-linear/filter !-- also repeat -- wrap-sclamp/wrap-s wrap-tclamp-to-edge/wrap-t !-- wrap-rclamp-to-border/wrap-r -- !-- float, signed-integer, integer -- internal-formatnormalized/internal-format /texture2d /texture0 texture1 texture2d imagedetail.png/image filterlinear-mipmap-linear/filter !-- also repeat -- wrap-sclamp/wrap-s wrap-tclamp-to-edge/wrap-t !-- wrap-rclamp-to-border/wrap-r -- !-- float, signed-integer, integer -- internal-formatnormalized/internal-format /texture2d /texture1 bump-height type=double.05/bump-height pattern-rotation type=vec4d0 0 1 1.5708/pattern-rotation /parameters technique predicate or less-equal value2.0/value glversion/ /less-equal and extension-supportedGL_ARB_shader_objects/extension-supported extension-supportedGL_ARB_shading_language_100/extension-supported
Re: [Flightgear-devel] RFC: graphics effects files
Hi, Well, for someone who don't have any ideas or knowledge about shaders, it looks really complicated at the first sight. On the other site, it looks a bit like the .osg-files, and with a bit diggin in, it would be understandable for me at least. I guess it is a bump map for the towns and cities, right? I would really know from the developers who are against this style of code are, what are the issues with this? Where are the main problems and what would be alternatives? Shader support would be a great step forward! Regards HHS-- PropertyList effect namedefault-effect/name !-- inherits-fromanother-effect/inherits-from -- parameters material ambient type=vec4d 0.0 0.0 0.0 1.0 /ambient diffuse type=vec4d .5 .5 .5 1.0 /diffuse specular type=vec4d 0.3 0.3 0.3 1.0 /specular emissive type=vec4d variance=dynamic 0.0 0.0 0.0 1.0 /emissive shininess1.2/shininess /material texture0 texture2d imagecity.png/image filterlinear-mipmap-linear/filter !-- also repeat -- wrap-sclamp/wrap-s wrap-tclamp-to-edge/wrap-t !-- wrap-rclamp-to-border/wrap-r -- !-- float, signed-integer, integer -- internal-formatnormalized/internal-format /texture2d /texture0 texture1 texture2d imagedetail.png/image filterlinear-mipmap-linear/filter !-- also repeat -- wrap-sclamp/wrap-s wrap-tclamp-to-edge/wrap-t !-- wrap-rclamp-to-border/wrap-r -- !-- float, signed-integer, integer -- internal-formatnormalized/internal-format /texture2d /texture1 bump-height type=double.05/bump-height pattern-rotation type=vec4d0 0 1 1.5708/pattern-rotation /parameters technique predicate or less-equal value2.0/value glversion/ /less-equal and extension-supportedGL_ARB_shader_objects/extension-supported extension-supportedGL_ARB_shading_language_100/extension-supported extension-supportedGL_ARB_vertex_shader/extension-supported extension-supportedGL_ARB_fragment_shader/extension-supported /and /or /predicate pass lightingtrue/lighting material ambientusematerial/ambient/use/ambient diffuseusematerial/diffuse/use/diffuse specularusematerial/specular/use/specular shininessusematerial/shininess/use/shininess /material texture-unit texture2dusetexture0/texture2d/use/texture2d /texture-unit texture-unit texture2dusetexture1/texture2d/use/texture2d /texture-unit shader-program uniform namebumpHeight/name typefloat/type usebump-height/use /uniform uniform namepatternRotation/name typevec4d/type usepattern-rotation/use /uniform vertex-shader Shaders/util.vert /vertex-shader vertex-shader Shaders/foo.vert /vertex-shader fragment-shader Shaders/foo.frag /fragment-shader /shader-program /pass /technique technique pass lightingtrue/lighting material ambientusematerial/ambient/use/ambient diffuseusematerial/diffuse/use/diffuse specularusematerial/specular/use/specular /material texture-unit texture2dusetexture0/texture2d/use/texture2d /texture-unit /pass /technique /effect /PropertyList Tim -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
