Re: [Flightgear-devel] RFC: graphics effects files
Tim Moore wrote: 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. I have two questions after reading this: 1. Will ambient/r, ambient/g and ambient/b still be supported in other locations besides xml embedded effects en techniques? 2. As I see this now this is a way to define custom (not hardcoded) effects. This means only a small number of these configuration files will be created and probably only by developers who know what they are doing. Am I right? If both answers are 'yes' then I see no problem with adding it, otherwise there's still gonna be a bit of discussion I guess. Erik -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
Heiko Schulz wrote: 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! True, but there are tow ways of doing it; * hardcode the effects that are needed * add the ability to make custom, configurable effects files. To be honnest, I don't expect that many custom effects files will be created and the ones that are created are going the be used by almost all modellers. This sounds like hardcoded will be just fine. Erik -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
* Tim Moore -- Saturday 04 April 2009: A couple of weeks ago I was asked for a sample of an effects file that uses my proposed changes to the property system; And a few weeks later I still object to these property changes, and will do so as often as it is brought up again. And for all the same reasons! m. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Problems generating scenery for Australia
Hi all, I am having a problem generating scenery with srtm2 data for Australia the problem is that I can hgtchop the files up ok, but when generating airports I keep getting error as follows, genapts --input=/DATA/src/fg/data/Airports/apt.dat.gz --work=./work/ --airport=YSCB 21 |grep -v Next |grep -v result Input file = /DATA/src/fg/data/Airports/apt.dat.gz Terrain sources = ./work//SRTM2-Africa-3 ./work//SRTM2-Australia-3 ./work//SRTM2-Eurasia-3 ./work//SRTM2-Islands-3 ./work//SRTM2-North_America-3 ./work//SRTM2-South_America-3 ./work//DEM-USGS-3 ./work//SRTM-30 Work directory = ./work/ Nudge = 10 Longitude = -180:180 Latitude = -90:90 Data version = 810 Building YSCB Runway count = 2 Taxiway count = 90 e140s40/e149s36/5393832 18 -35.302717 149.196184 1 BCN 14 -35.300541 149.1998900 0 ATC Tower 19 -35.290601 149.196704 1 WS 19 -35.300404 149.185850 1 WS 19 -35.299599 149.197176 1 WS 19 -35.311538 149.198463 1 WS 19 -35.313744 149.191470 1 WS Building runway = 17x Runway num = '17x' Reverse displaced threshold = 214 Runway num = '12x' gen vasi 17x gen vasi 17x gen ALSF/SALS lights 17x length hdg = 360 left heading = 270 rwylt1 = 2 app1 = 1
Re: [Flightgear-devel] RFC: graphics effects files
* Vivian Meazza -- Saturday 04 April 2009: less-equal? texture0, texture1. ? ambientusematerial/ambient/use/ambient ? I did't even look at that. The vector properties (that have already been rejected before) were enough for me to reject the whole second attempt to get this in. But I agree with all your points. This does also not make sense to me: vertex-shader Shaders/util.vert /vertex-shader Why should any part of fgfs (or external apps) have to deal with stripping quotes around strings? Should be: vertex-shaderShaders/util.vert/vertex-shader or probably even better vertex-shader-path. m. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
Tim Moore 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
Re: [Flightgear-devel] Scene ambient and specularcolor changes
There seemed to be a problem with my mail since I noticed in the archives there were some replies to my previous post about this item. I've tweaked the values some more and think I've got it just about right (or good enough) this time. Erik -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scene ambient and specularcolor changes
Erik There seemed to be a problem with my mail since I noticed in the archives there were some replies to my previous post about this item. I've tweaked the values some more and think I've got it just about right (or good enough) this time. Erik The ambient light is still too low here. I've recalibrated my screen - and here's the result: ftp://ftp.abbeytheatre2.org.uk/fgfs/Light/Seahawk%20-%201.jpg ftp://ftp.abbeytheatre2.org.uk/fgfs/Light/Seahawk%20-%202.jpg I can fix it here, to my entire satisfaction, so if everyone else is happy, don't worry. Vivian -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scene ambient and specularcolor changes
* Vivian Meazza -- Saturday 04 April 2009: I can fix it here, to my entire satisfaction, so if everyone else is happy, don't worry. I can't really say much about this, as I'm using a rather old and not so great monitor that I don't seem to be able to calibrate correctly. But I agree that the ambient has now become significantly darker. I just can't say if that's right or wrong. :-/ m. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Problems with terragear and building Australian scenery
Hi all, been a while since I last tried this (about 3 years) and I am experiancing a few issues. I have STRM2 data that has been hgtchop'ed ok into ./work//SRTM2-Australia-3 , but when I run genapt it complains that the dem data dosn't exist ie genapts --input=/DATA/src/fg/data/Airports/apt.dat.gz --work=./work/ --airport=YSCB 21 |grep -v Next |grep -v result Input file = /DATA/src/fg/data/Airports/apt.dat.gz Terrain sources = ./work//SRTM2-Africa-3 ./work//SRTM2-Australia-3 ./work//SRTM2-Eurasia-3 ./work//SRTM2-Islands-3 ./work//SRTM2-North_America-3 ./work//SRTM2-South_America-3 ./work//DEM-USGS-3 ./work//SRTM-30 Work directory = ./work/ Nudge = 10 Longitude = -180:180 Latitude = -90:90 Data version = 810 Building YSCB Runway count = 2 Taxiway count = 90 e140s40/e149s36/5393832 18 -35.302717 149.196184 1 BCN 14 -35.300541 149.1998900 0 ATC Tower 19 -35.290601 149.196704 1 WS 19 -35.300404 149.185850 1 WS 19 -35.299599 149.197176 1 WS 19 -35.311538 149.198463 1 WS 19 -35.313744 149.191470 1 WS Building runway = 17x Runway num = '17x' Reverse displaced threshold = 214 Runway num = '12x' gen vasi 17x gen vasi 17x gen ALSF/SALS lights 17x length hdg = 360 left heading = 270 rwylt1 = 2 app1 = 1
Re: [Flightgear-devel] *** SPAM *** Re: Scene ambient and specularcolor changes
Melchior FRANZ wrote: * Vivian Meazza -- Saturday 04 April 2009: I can fix it here, to my entire satisfaction, so if everyone else is happy, don't worry. I can't really say much about this, as I'm using a rather old and not so great monitor that I don't seem to be able to calibrate correctly. But I agree that the ambient has now become significantly darker. I just can't say if that's right or wrong. :-/ To be honest both screenshots don't look too bad to me :-/ But if it's going to be adjusted it needs to be done in Data/Lighting/ambient Erik -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems with terragear and building Australian scenery
Hi Jason, Not sure why you did two posts of the same thing, but... Maybe it is political? You do know that the 'missing' DEM information is Capital Hill, Canberra ;=)) Tile e140s40/e149s36/5393832 is centered lat,lon -35.3125,149.125 and in Google Earth that looks like 'Capital Hill' ;=() Seriously, you show you have - 5393848 -35.0625,149.125 through to 5393851 -35.0625,149.875 so your DEM data sort of runs out at -35.0625, while you want down to -35.3125... You do NOT say WHERE you got this DEM information from... That is, what DEM/SRTM 'raw' data did you start with? Where did you download it from? What TG tool did you use to 'chop' it into .arr.gz? With this information, may be able to help more. Regards, Geoff. PS: I do not really think it is 'political' ;=)) On Sat, 2009-04-04 at 18:57 +1100, Jason Cox wrote: Hi all, been a while since I last tried this (about 3 years) and I am experiancing a few issues. I have STRM2 data that has been hgtchop'ed ok into ./work//SRTM2-Australia-3 , but when I run genapt it complains that the dem data dosn't exist ie genapts --input=/DATA/src/fg/data/Airports/apt.dat.gz --work=./work/ --airport=YSCB 21 |grep -v Next |grep -v result Input file = /DATA/src/fg/data/Airports/apt.dat.gz Terrain sources = ./work//SRTM2-Africa-3 ./work//SRTM2-Australia-3 ./work//SRTM2-Eurasia-3 ./work//SRTM2-Islands-3 ./work//SRTM2-North_America-3 ./work//SRTM2-South_America-3 ./work//DEM-USGS-3 ./work//SRTM-30 Work directory = ./work/ Nudge = 10 Longitude = -180:180 Latitude = -90:90 Data version = 810 Building YSCB Runway count = 2 Taxiway count = 90 e140s40/e149s36/5393832 18 -35.302717 149.196184 1 BCN 14 -35.300541 149.1998900 0 ATC Tower 19 -35.290601 149.196704 1 WS 19 -35.300404 149.185850 1 WS 19 -35.299599 149.197176 1 WS 19 -35.311538 149.198463 1 WS 19 -35.313744 149.191470 1 WS Building runway = 17x Runway num = '17x'
Re: [Flightgear-devel] Problems with terragear and building Australian scenery
Geoff, sorry for the double post, but I thought I had issues with my old and new email address. Anyway,the original hgt source was from e0srp01u.ecs.nasa.gov/srtm/version2/Australia This was 'wget' from the site back '06 and unfortunatly not available now. I am cutting up the hgt file with 'gtchop 1 HGT/S38E150.hgt SRTM2-Australia-3/' and it shows no errors. Jason On Sat, 2009-04-04 at 13:32 +0200, Geoff McLane wrote: Hi Jason, Not sure why you did two posts of the same thing, but... Maybe it is political? You do know that the 'missing' DEM information is Capital Hill, Canberra ;=)) Tile e140s40/e149s36/5393832 is centered lat,lon -35.3125,149.125 and in Google Earth that looks like 'Capital Hill' ;=() Seriously, you show you have - 5393848 -35.0625,149.125 through to 5393851 -35.0625,149.875 so your DEM data sort of runs out at -35.0625, while you want down to -35.3125... You do NOT say WHERE you got this DEM information from... That is, what DEM/SRTM 'raw' data did you start with? Where did you download it from? What TG tool did you use to 'chop' it into .arr.gz? With this information, may be able to help more. Regards, Geoff. PS: I do not really think it is 'political' ;=)) On Sat, 2009-04-04 at 18:57 +1100, Jason Cox wrote: Hi all, been a while since I last tried this (about 3 years) and I am experiancing a few issues. I have STRM2 data that has been hgtchop'ed ok into ./work//SRTM2-Australia-3 , but when I run genapt it complains that the dem data dosn't exist ie genapts --input=/DATA/src/fg/data/Airports/apt.dat.gz --work=./work/ --airport=YSCB 21 |grep -v Next |grep -v result Input file = /DATA/src/fg/data/Airports/apt.dat.gz Terrain sources = ./work//SRTM2-Africa-3 ./work//SRTM2-Australia-3 ./work//SRTM2-Eurasia-3 ./work//SRTM2-Islands-3 ./work//SRTM2-North_America-3 ./work//SRTM2-South_America-3 ./work//DEM-USGS-3 ./work//SRTM-30 Work directory = ./work/ Nudge = 10 Longitude = -180:180 Latitude = -90:90 Data version = 810 Building YSCB Runway count = 2 Taxiway count = 90 e140s40/e149s36/5393832 18 -35.302717 149.196184 1 BCN 14 -35.300541 149.1998900 0 ATC Tower 19 -35.290601 149.196704 1 WS 19 -35.300404 149.185850 1 WS 19 -35.299599 149.197176 1 WS
Re: [Flightgear-devel] Problems with terragear and building Australian scenery
Jason Cox wrote: Geoff, sorry for the double post, but I thought I had issues with my old and new email address. Anyway,the original hgt source was from e0srp01u.ecs.nasa.gov/srtm/version2/Australia This was 'wget' from the site back '06 and unfortunatly not available now. I am cutting up the hgt file with 'gtchop 1 HGT/S38E150.hgt SRTM2-Australia-3/' and it shows no errors. There's your problem - the data is 3 arcsec, not 1, so effectively you've shrunk it to 1/3 of its original size. Re-run hgtchop with 3 instead of 1. Jon -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems with terragear and building Australian scenery
Jon, Thanks I will setting running again :) On Sat, 2009-04-04 at 13:11 +0100, Jon Stockill wrote: Jason Cox wrote: Geoff, sorry for the double post, but I thought I had issues with my old and new email address. Anyway,the original hgt source was from e0srp01u.ecs.nasa.gov/srtm/version2/Australia This was 'wget' from the site back '06 and unfortunatly not available now. I am cutting up the hgt file with 'gtchop 1 HGT/S38E150.hgt SRTM2-Australia-3/' and it shows no errors. There's your problem - the data is 3 arcsec, not 1, so effectively you've shrunk it to 1/3 of its original size. Re-run hgtchop with 3 instead of 1. Jon -- ___ 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] Problems with terragear and building Australian scenery
On Sat, 2009-04-04 at 13:11 +0100, Jon Stockill wrote: Jason Cox wrote: Geoff, sorry for the double post, but I thought I had issues with my old and new email address. Anyway,the original hgt source was from e0srp01u.ecs.nasa.gov/srtm/version2/Australia This was 'wget' from the site back '06 and unfortunatly not available now. I am cutting up the hgt file with 'gtchop 1 HGT/S38E150.hgt SRTM2-Australia-3/' and it shows no errors. There's your problem - the data is 3 arcsec, not 1, so effectively you've shrunk it to 1/3 of its original size. Re-run hgtchop with 3 instead of 1. Jon Hi Jason, Maybe Jon has hit the point - try 3 instead of 1 ;=)) thanks, Jon... And I think the 'new' location of the data is :- NASA_WGET=ftp://e0srp01u.ecs.nasa.gov/srtm/version2/SRTM3/Australia; But I have found a MISSING DEM block. I tried to do Sydney, but found no S40E150 on the above FTP site I found - OZSET=S31E150 S31E151 S31E152 S31E153 S32E150 S32E151 \ S32E152 S32E153 S32E159 S33E150 S33E151 S33E152 S34E150 \ S34E151 S35E150 S35E151 S36E150 S37E150 S38E150 But could not find data for say S40E150??? My only alternative was to switch to using GLOBE data... Cut from my makesyd script... # (b) Try USGS DEM files USEUSGS=1 # DEM data # source = http://edcwww.cr.usgs.gov/products/elevation/gtopo30/gtopo30.html USGS_URL=http://edcftp.cr.usgs.gov/pub/data/gtopo30/global/; USGS_MIRROR=http://www1.gsi.go.jp/geowww/globalmap-gsi/gtopo30/data/global/; # OZ_USGS=http://edcftp.cr.usgs.gov/pub/data/gtopo30/global/e140s10.tar.gz; If you find any other (free) DEM/SRTM data for OZ, I would be most interested... Regards, Geoff. PS: You can get my full makesyd script from :- http://geoffair.net/tmp/makesyd but it requires you have VMAP0 in a specific directory, but maybe you are not using VMAP0... and be aware it FAILS. See my developing page - http://geoffair.net/tmp/newscenery.htm -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems with terragear and building Australian scenery
Geoff, part of my plan is try and incorporate mif topo's into the mix of elevation. I had a script somewhere that used Fred's fgsd xml format to overlay the topo's elevation data on a tile and then export from fgsd to build a new tile :) Jason On Sat, 2009-04-04 at 14:36 +0200, Geoff McLane wrote: On Sat, 2009-04-04 at 13:11 +0100, Jon Stockill wrote: Jason Cox wrote: Geoff, sorry for the double post, but I thought I had issues with my old and new email address. Anyway,the original hgt source was from e0srp01u.ecs.nasa.gov/srtm/version2/Australia This was 'wget' from the site back '06 and unfortunatly not available now. I am cutting up the hgt file with 'gtchop 1 HGT/S38E150.hgt SRTM2-Australia-3/' and it shows no errors. There's your problem - the data is 3 arcsec, not 1, so effectively you've shrunk it to 1/3 of its original size. Re-run hgtchop with 3 instead of 1. Jon Hi Jason, Maybe Jon has hit the point - try 3 instead of 1 ;=)) thanks, Jon... And I think the 'new' location of the data is :- NASA_WGET=ftp://e0srp01u.ecs.nasa.gov/srtm/version2/SRTM3/Australia; But I have found a MISSING DEM block. I tried to do Sydney, but found no S40E150 on the above FTP site I found - OZSET=S31E150 S31E151 S31E152 S31E153 S32E150 S32E151 \ S32E152 S32E153 S32E159 S33E150 S33E151 S33E152 S34E150 \ S34E151 S35E150 S35E151 S36E150 S37E150 S38E150 But could not find data for say S40E150??? My only alternative was to switch to using GLOBE data... Cut from my makesyd script... # (b) Try USGS DEM files USEUSGS=1 # DEM data # source = http://edcwww.cr.usgs.gov/products/elevation/gtopo30/gtopo30.html USGS_URL=http://edcftp.cr.usgs.gov/pub/data/gtopo30/global/; USGS_MIRROR=http://www1.gsi.go.jp/geowww/globalmap-gsi/gtopo30/data/global/; # OZ_USGS=http://edcftp.cr.usgs.gov/pub/data/gtopo30/global/e140s10.tar.gz; If you find any other (free) DEM/SRTM data for OZ, I would be most interested... Regards, Geoff. PS: You can get my full makesyd script from :- http://geoffair.net/tmp/makesyd but it requires you have VMAP0 in a specific directory, but maybe you are not using VMAP0... and be aware it FAILS. See my developing page - http://geoffair.net/tmp/newscenery.htm -- ___ 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] *** SPAM *** Re: Scene ambient and specularcolor changes
Erik Melchior FRANZ wrote: * Vivian Meazza -- Saturday 04 April 2009: I can fix it here, to my entire satisfaction, so if everyone else is happy, don't worry. I can't really say much about this, as I'm using a rather old and not so great monitor that I don't seem to be able to calibrate correctly. But I agree that the ambient has now become significantly darker. I just can't say if that's right or wrong. :-/ To be honest both screenshots don't look too bad to me :-/ But if it's going to be adjusted it needs to be done in Data/Lighting/ambient This is how I think it should look, and arguably it's still a little dark: ftp://ftp.abbeytheatre2.org.uk/fgfs/Light/Seahawk%20-%203.jpg ftp://ftp.abbeytheatre2.org.uk/fgfs/Light/Seahawk%20-%204.jpg I'm doing a small adjustment in light.cxx - seems to work: float ambient = _ambient_tbl-interpolate( deg ) + (0.25 + 0.75 * visibility_inv/10); Not sure that I fancy tinkering around in Data/Lighting/ambient - someone has obviously taken a lot of care to craft that one. 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
* Vivian Meazza -- Saturday 04 April 2009: This is how I think it should look, Does indeed look much better here (on my *still* quite bad monitor ;-). m. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
And a few weeks later I still object to these property changes, and will do so as often as it is brought up again. And for all the same reasons! m. How would it be better, and would all what Tim wants to do, be still possible? -- ___ 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] Scene ambient and specularcolor changes
Vivian Meazza wrote: I'm doing a small adjustment in light.cxx - seems to work: float ambient = _ambient_tbl-interpolate( deg ) + (0.25 + 0.75 * visibility_inv/10); Not sure that I fancy tinkering around in Data/Lighting/ambient - someone has obviously taken a lot of care to craft that one. Well you *are* since you are adding 0.25 to ambient. In fact this changes [0.04 - 0.2] to [0.254 - 0.45] Erik -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] ufo.nas and divide by zero
Hi! I have got range exception when flying UFO. Looking in sources open that problem is in ufo.nas line 420: me.marker = Model.new(Aircraft/ufo/Models/marker.ac, geo.Coord.new().set_xyz(0, 0, 0)); When passing zeros to geo.Coord.set_xyz(), there is devide by zero in function SGGeodesy::SGCartToGeod(). This puts NAN to Elevation. Problem can be fixed in two ways: 1 Change ufo.nas to initialize geo.Coord using function set_latlon(0, 0, 0). Or was some reason to put model at the Earth center? 2 Fix SGGeodesy::SGCartToGeod() to test input point is (0, 0, 0), and put to output (0, 0, 0) without calculations. Or solve it in some other way to avoid divide by zero. Can somebody consider this and make fix in CVS? With respect, Alex _ Drag n’ drop—Get easy photo sharing with Windows Live™ Photos. http://www.microsoft.com/windows/windowslive/products/photos.aspx-- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
* Heiko Schulz -- Saturday 04 April 2009:
How would it be better, and would all what Tim wants to do,
be still possible?
The features that Tim is talking about (effects and stuff), and
the XML and property tree representation do IMHO not have much
to do with each other.
How can separate values be stored without vector property type:
Just like now. Every property (red/green/...) is a an actual
*property* (i.e. an SGPropertyNode). But we had that aleady ...
What the best solution for the dynamic attribute is probably
depends on the case. How often do we expect such color properties
to change? Many of them in every frame? Or just a few every few
minutes?
One solution could be to have the properties just like now
(with children possibly tied to memory):
color/{red,green,blue,alpha}
Add a listener to the parent color, and trigger it when all
color properties have been set, so that the code can update
whatever needs to be updated. The triggering happens with
SGPropertyNode::fireValueChanged(). This can be nicely done
with a few helper functions. Of course, triggering the parent
would have to be done manually in the property browser or via
telnet, but that's certainly not the main use case and is IMHO
acceptable.
No intrusive changes with multiple bad side effects needed.
m.
--
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
Melchior
* Heiko Schulz -- Saturday 04 April 2009:
How would it be better, and would all what Tim wants to do,
be still possible?
The features that Tim is talking about (effects and stuff), and
the XML and property tree representation do IMHO not have much
to do with each other.
How can separate values be stored without vector property type:
Just like now. Every property (red/green/...) is a an actual
*property* (i.e. an SGPropertyNode). But we had that aleady ...
What the best solution for the dynamic attribute is probably
depends on the case. How often do we expect such color properties
to change? Many of them in every frame? Or just a few every few
minutes?
One solution could be to have the properties just like now
(with children possibly tied to memory):
color/{red,green,blue,alpha}
Add a listener to the parent color, and trigger it when all
color properties have been set, so that the code can update
whatever needs to be updated. The triggering happens with
SGPropertyNode::fireValueChanged(). This can be nicely done
with a few helper functions. Of course, triggering the parent
would have to be done manually in the property browser or via
telnet, but that's certainly not the main use case and is IMHO
acceptable.
No intrusive changes with multiple bad side effects needed.
As I see it this proposal would satisfy the many who want to retain the
red green etc. tags and would appear to meet the requirements of OSG.
But I sure there are other solutions, or I might be getting it totally
wrong.
I hope the best is not getting in the way of good enough.
Vivian
--
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
On Saturday 04 April 2009, Melchior FRANZ wrote:
* Heiko Schulz -- Saturday 04 April 2009:
How would it be better, and would all what Tim wants to do,
be still possible?
The features that Tim is talking about (effects and stuff), and
the XML and property tree representation do IMHO not have much
to do with each other.
How can separate values be stored without vector property type:
Just like now. Every property (red/green/...) is a an actual
*property* (i.e. an SGPropertyNode). But we had that aleady ...
What the best solution for the dynamic attribute is probably
depends on the case. How often do we expect such color properties
to change? Many of them in every frame? Or just a few every few
minutes?
One solution could be to have the properties just like now
(with children possibly tied to memory):
color/{red,green,blue,alpha}
Add a listener to the parent color, and trigger it when all
color properties have been set, so that the code can update
whatever needs to be updated. The triggering happens with
SGPropertyNode::fireValueChanged(). This can be nicely done
with a few helper functions. Of course, triggering the parent
would have to be done manually in the property browser or via
telnet, but that's certainly not the main use case and is IMHO
acceptable.
No intrusive changes with multiple bad side effects needed.
m.
I too think the that the real issue here is the representation in
the property tree, not functionality. As long as the data is
available in the property tree it shouldn't affect the
functionality at all because it'll be trivial to convert from the
current property tree representation of the data to the form
required by OSG.
I still can't see a good reason to make changes to the way the
property tree represents data unless the overhead of accessing
three or four property tree nodes, instead of just one, has a
significant impact on performance.
How frequently does this data need to be accessed?
LeeE
--
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] access violation in FGFontCache
Hi! In GUI style I put one font for and . This give access violation error. The problem is in FGFontCache destructor. Class FGFontCache contains two Maps : TexFontMap _texFonts and PuFontMap _puFonts. _texFonts contains fonts being read from the data/Fonts. PuFontMap contains fnt structure which is referencing to texfont from _texFonts. A number of fnt structures from _puFonts can refer to a single texFont. In destructor fnt::~fnt() member fnt::texfont is deleted. But fnt::texfont is a copy of fntTexFont* from _texFonts. So when second fnt structure is deleting it try to delete the fntTexFont which was deleted at previous step. This deleting of deleted structure leads to Access Violation. Second possible problem is in FGFontCache destructor. _puFonts map is deleted here but not _texFonts map. Can this lead to memory leak? With respect, Alex _ Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! http://spaces.live.com/spacesapi.aspx?wx_action=createwx_url=/friends.aspxmkt=en-us-- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems generating scenery for Australia
Have you tried inverting the Y-axis? ;-) (Sorry, in the light of the recent prank pulled by YouTube, I couldn't resist.) Jason Cox wrote: Hi all, I am having a problem generating scenery with srtm2 data for Australia the problem is that I can hgtchop the files up ok, but when generating airports I keep getting error as follows, genapts --input=/DATA/src/fg/data/Airports/apt.dat.gz --work=./work/ --airport=YSCB 21 |grep -v Next |grep -v result Input file = /DATA/src/fg/data/Airports/apt.dat.gz Terrain sources = ./work//SRTM2-Africa-3 ./work//SRTM2-Australia-3 ./work//SRTM2-Eurasia-3 ./work//SRTM2-Islands-3 ./work//SRTM2-North_America-3 ./work//SRTM2-South_America-3 ./work//DEM-USGS-3 ./work//SRTM-30 Work directory = ./work/ Nudge = 10 Longitude = -180:180 Latitude = -90:90 Data version = 810 Building YSCB Runway count = 2 Taxiway count = 90 e140s40/e149s36/5393832 18 -35.302717 149.196184 1 BCN 14 -35.300541 149.1998900 0 ATC Tower 19 -35.290601 149.196704 1 WS 19 -35.300404 149.185850 1 WS 19 -35.299599 149.197176 1 WS 19 -35.311538 149.198463 1 WS 19 -35.313744 149.191470 1 WS Building runway = 17x Runway num = '17x' Reverse displaced threshold = 214 Runway num = '12x' gen vasi 17x gen vasi 17x gen ALSF/SALS lights 17x
[Flightgear-devel] [PATCH] Wildfire integration for the PBY Catalina
Hi, This small patch makes water dropped from Gerard's nice PBY Catalina extinguish wildfires. http://www.gidenstam.org/FlightGear/misc/WildFire/PBY-Catalina.diff Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
Let me jump in with my thoughts of the day.
Typically in the FlightGear project we have welcomed additive changes (aka
new features.)
We do not seem to be averse to complicated systems, complicated code,
complicated configuration files. Just look at some of the things we can do
with the gui configuration and all the things we can do with nasal.
With all due respect to Melchior, I don't think he has presented a strong
case against adding vectors into the property system. The examples he
listed early in this discussion really did not carry a lot of strength and
several of his points could be easily dismissed. If there is a strong case
to be made, I don't think it has been made yet.
With all due respect to Tim, slightly more compact xml representation for a
couple small parts of a couple files isn't a strong argument for adding new
complicated code.
Arrays of like elements have been part of computer programming every since I
saw my first computer program in 1983 ... probably well before that even.
Right now, I find it really hard to see why we would absolutely refuse a
submission that adds functionality without changing existing functionality.
FlightGear is full of example of this sort of thing. I just don't see why
the heels are dug so far in on this one
So in my view if we are discussing the addition of a feature that is
immediately useful for some developers, and it does not harm existing code
or features, but simply adds functionality, then this is right in line with
typical FlightGear development procedure.
If there is any one who doesn't want this particular code added, I think the
burden is on them to put forth a very strong case for why not. What
specifically is harmed? What specifically will break? What specific corner
are we painting ourselves into? And if a legitimate concern is raised,
then hopefully Tim can come back and address that. But so far I haven't
seen any concern that hasn't been reasonably addressed already by Tim.
If we say that we won't allow new code if there is already some way to do
most of what the new code does in some other way, then we might as well get
rid of nasal, because we can already do everything that nasal does in C++.
And why would we have migrated to C++ since we could already do everything
we wanted in C. Why would we add a menu and dialog system when we can
already do everything with command line options and keystrokes? Why make a
Mac version when there is already a windows version? I can think back to
early in the project when adding the property system itself was a highly
controversial move. The clear answer to why we've added much of our code
and features is convenience; ease of use ... and maybe only for a few
developers or end users ... not necessarily for everyone.
So after hearing all the discussion (maybe I'm forgetting something, but I
can't think of what that might be) I am having a really difficult time
seeing why we would prevent the addition of new code that simply adds
functionality without harming or changing or removing existing
functionality.
Without seeing anything so far that I would consider a compelling argument
against, I vote for giving Tim the green light here. Developer convenience
has almost always been a good enough reason in the past.
Best regards,
Curt.
On Sat, Apr 4, 2009 at 11:14 AM, LeeE l...@spatial.plus.com wrote:
On Saturday 04 April 2009, Melchior FRANZ wrote:
* Heiko Schulz -- Saturday 04 April 2009:
How would it be better, and would all what Tim wants to do,
be still possible?
The features that Tim is talking about (effects and stuff), and
the XML and property tree representation do IMHO not have much
to do with each other.
How can separate values be stored without vector property type:
Just like now. Every property (red/green/...) is a an actual
*property* (i.e. an SGPropertyNode). But we had that aleady ...
What the best solution for the dynamic attribute is probably
depends on the case. How often do we expect such color properties
to change? Many of them in every frame? Or just a few every few
minutes?
One solution could be to have the properties just like now
(with children possibly tied to memory):
color/{red,green,blue,alpha}
Add a listener to the parent color, and trigger it when all
color properties have been set, so that the code can update
whatever needs to be updated. The triggering happens with
SGPropertyNode::fireValueChanged(). This can be nicely done
with a few helper functions. Of course, triggering the parent
would have to be done manually in the property browser or via
telnet, but that's certainly not the main use case and is IMHO
acceptable.
No intrusive changes with multiple bad side effects needed.
m.
I too think the that the real issue here is the representation in
the property tree, not functionality. As long as the data is
available in the property tree it shouldn't affect the
Re: [Flightgear-devel] RFC: graphics effects files
On Sat, 4 Apr 2009, Tim Moore wrote:
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.
If efficiency is of the outermost concern you could tie each of the
components of a double vec[4] to properties, e.g.
color/{red,green,blue,alpha}. That would make it possible for the internal
C++ code to use the vector representation while still preserving a nicely
structured and typed property tree for external access.
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.
If you really must have it, please put it in a subtype.
Cheers,
Anders
--
---
Anders Gidenstam
WWW: http://www.gidenstam.org/FlightGear/
--
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
* Curtis Olson -- Sunday 05 April 2009: Without seeing anything so far that I would consider a compelling argument against, I vote for giving Tim the green light here. Developer convenience has almost always been a good enough reason in the past. OK. Unfortunately, this is a route that I can't go with the project. I better watch that from outside. I still claim ownership of the bo105 and will probably continue maintaining it after a longer pause (if I can keep my commit rights until then). All other areas that I maintained are free for adoption (gui, fg/nasal, new hud, voice, input). Good luck m. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
On Sat, Apr 4, 2009 at 3:05 AM, Melchior FRANZ mfr...@aon.at wrote: * Tim Moore -- Saturday 04 April 2009: A couple of weeks ago I was asked for a sample of an effects file that uses my proposed changes to the property system; And a few weeks later I still object to these property changes, and will do so as often as it is brought up again. And for all the same reasons! Hi Melchior, Let me ask this on the list. Since the beginning of time, computers have included the concept of arrays. Since the birth of the property system in FlightGear, it has supported booleans, integer, floating point, and double floating point types. The property system has also always supported character arrays. The property system supports implicit conversions between types if that is asked for, and always makes it's best attempt. But if you ask for something nonsensical or poorly defined, you will get something back based on the rules of the system, but it may not make a lot of sense. If you try to extract the floating point value of a string (aka character array) you get something back based on the rules of the system, but what if you try to retrieve the floating point value of abcdefg. It doesn't make sense, you probably won't get a useful answer although you will get something. It's up to the calling routine to make sensible requests. It's always been that way, it will always be that way. Now, the message I am getting here is that some people think it's unacceptable to also support double or float arrays within the property system. It can't be because arrays are messy because we already support character arrays. It can't be because some conversions wouldn't make sense, because we already have that situation. It can't be because it makes the property subsystem too complex, because Melchior, to be fair, you are the king of creating very complicated systems (with correspondingly high functionality.) I don't mean that as a diss ... I'm just observing that you have put together some highly complex systems full of subtle nuance within the flightgear code base. I don't have time to follow along with IRC so I can only see what is posted to the mailing list, so I very well could be missing key parts of this discussion. But honestly, I am really having trouble understanding the objection here. I fail to see what is going to break, what is going to end, what harm is going to be done. Is there a direct conflict in logic? Is there a non-othogonality in design? Is there some behind the scenes fued going on that I'm (thankfully) unaware of ... in that case I'll quit trying to draw out logical reasons for your objections? I'm married so I'm continually caught trying to find logical explanations where there are none. :-) I'm not suggesting that's the case here, but if it is, we might as well say it clearly so I don't have to waste my time trying to understand what's going on. I asked Tim if it would make sense to just support generic double or float arrays in the property system ... just like we support character arrays. However, he replied that you were even more opposed to that than specific color or position array types. Again, I fail to understand why. I could be easily missing something here, I'm not claiming I have an all seeing eye. But if someone makes an assertion I don't understand, or supports it with reasons that don't make sense to me, I have trouble buying that assertion. I've always had that problem, and it's my own personal failing I know. I think it's a good thing I didn't sign up for military duty here when I was a kid because of that. But at the end of the day here, I haven't seen why Tim's contribution is unreasonable, or what makes it so different from other contributions that have added functionality to the code base. I'm trying to guess here at what it might be and haven't stumbled on anything I can point to. Really, why is it so unacceptable? 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] Seawind
Taking a break from the serious stuff ... or rather, switching over to the serious stuff... :-) This afternoon the winds were almost nothing, so I walked down to a nearby lake and flew my Seawind EP which is a radio controlled sea plane. The conditions couldn't have been more perfect and I had several nice flights, a couple touch and goes, and had fun just scooting around the lake up on step. If I can avoid crashing, it should be perfect for those warm summer evenings the hour or two right before it gets dark when everything calms down and the wind goes to zero ... Unfortunately I was the only one out there so I couldn't get any live action shots, but there is a promotional video I linked to so you can see about what it looks like in action. The ice is almost completely melted off the lake, but as you can see, we haven't started the spring green up yet. Chance of snow again tonight and tomorrow ... uf da as they say they say in these parts ... http://baron.flightgear.org/~curt/Models/Current/SeaWindEP/ 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
