Re: [Flightgear-devel] Default 3d clouds in Local Weather
Hi Stuart, > I'd really like the 3D cloud infrastructure to be used for all the > clouds, so > if there are features missing we should address them. > > Would it be possible to modify the 3D clouds so that they can be used for > the rain texture as well? For example, I could provide a sprite > distribution > on the surface of a cylinder rather than a sphere if that would help. Just a short answer to this part: All these objects (rain textures, Cirrus clouds,...) do not use the 3d cloud infrastructure because they are not 3d clouds. Cirrus and Cirrocumulus clouds are textures projected on a non-rotated but cruved surface (a bit like a saddle) - I see no straightforward way to get that with a shader, and I've never made any attempt work to render them as true 3d objects. (Technically, the reason is that they show fine detail with large variation, so cloudlets need to be large, and a preferred direction for the feathers - so whenever you rotate them, it shows immediately). Also in the literature, I haven't seen anyone who claimed to have generated true, rotating 3d Cirrus clouds). Cirrostratus and the larger Cirrocumulus don't have that problem, as they don't show preferred direction and have less fine detail - for those I needed z-scaling. Rain doesn't use a 3d but a 2d cylinder billboard rotation - I suppose that can be adapted to use with the shader easily enough by passing a parameter that tells which rotation is to be used if we want to do that. * Thorsten -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Openstreetmap vs. G**gl
I don't know the specific answer in this case, but it does illustrate one of the surpreme challenges in mixing different gis databases ... you end up with information from different sources, adhering to different standards, appropriate for different scales, using different datums, different surveying techniques etc. Sometimes manually processed or manually entered/created, processed in different ways, etc. etc. Asking a cartographer "where is it?" is just about as difficult a question as asking an astronomer "what time is it?" Curt. On Sat, Sep 10, 2011 at 5:54 PM, HB-GRAL wrote: > Hi all > > Unfortunately I just run into another problem with my map. > > This is what I see on my currently generated map using 8.10 taxiway data > and 8.50 runway data (this is no reference and a crude mixup of course, > I apologize in adnvance): > http://maptest.fgx.ch/screens/mapping.png > > But now, I discovered something really strange. I was looking to > different maps while exploring this area with FLightGear. > > This is what I see in with recent terrasynced scenery: > http://maptest.fgx.ch/screens/flightgear.png > > This is the same position on mpmap02 server: > http://maptest.fgx.ch/screens/google.png > > This is exactly the same position on OSM: > http://maptest.fgx.ch/screens/openstreetmap.png > > I am just curious why FlightGear and OSM have the same "accurate" > position, and Google map shows another one. > > I am sure, there are different problems, but some enlightenment will be > greatly appreciated here. > > Beside of that, where does this inexisting taxiway to the left come from > ? Is this a FlightGear feature ? Something like > "we-have-no-taxiways-so-there-is-probably-one-to-the-left" ? > > Cheers, Yves > > > > > > -- > Malware Security Report: Protecting Your Business, Customers, and the > Bottom Line. Protect your business and customers by understanding the > threat from malware and how it can impact your online business. > http://www.accelacomm.com/jaw/sfnl/114/51427462/ > ___ > 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 -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Openstreetmap vs. G**gl
Hi all Unfortunately I just run into another problem with my map. This is what I see on my currently generated map using 8.10 taxiway data and 8.50 runway data (this is no reference and a crude mixup of course, I apologize in adnvance): http://maptest.fgx.ch/screens/mapping.png But now, I discovered something really strange. I was looking to different maps while exploring this area with FLightGear. This is what I see in with recent terrasynced scenery: http://maptest.fgx.ch/screens/flightgear.png This is the same position on mpmap02 server: http://maptest.fgx.ch/screens/google.png This is exactly the same position on OSM: http://maptest.fgx.ch/screens/openstreetmap.png I am just curious why FlightGear and OSM have the same "accurate" position, and Google map shows another one. I am sure, there are different problems, but some enlightenment will be greatly appreciated here. Beside of that, where does this inexisting taxiway to the left come from ? Is this a FlightGear feature ? Something like "we-have-no-taxiways-so-there-is-probably-one-to-the-left" ? Cheers, Yves -- Malware Security Report: Protecting Your Business, Customers, and the Bottom Line. Protect your business and customers by understanding the threat from malware and how it can impact your online business. http://www.accelacomm.com/jaw/sfnl/114/51427462/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New experimental mapserver
I'm not sure the move to 8.50 will help in this regard. I see lots of 'holes' in the latest 8.50 data as well. Even more, probably, as it's common to have concrete taxiways surrounded by asphalt shoulders. I've seen holes between the two curves in this respect. Not on the roadmap yet, but maybe I can add another 'nudge' to expand these shoulders if they intersect a higher priority polygon. I have no thoughts on how to detect this right now, however. Pete On Sat, Sep 10, 2011 at 11:57 AM, HB-GRAL wrote: > Am 10.09.11 14:47, schrieb Christian Schmitt: > > Curtis Olson wrote: > > > >> I won't say this is perfect in all areas ... some areas have stray data > >> points or noise in the terrain data that confuses things. There's > always > >> a chance of a mismatch between airport location terrain location so that > >> we > >> are trying to put the airport on not quite the right underlying terrain. > >> My thoughts for future extensions of this code would be to allow for > >> creating specific tuning parameters for airports that didn't behave well > >> with the default parameters. > > > > An nice example where a high slope leads to bad results would be LFLJ, > > however, it is possible in such cases to use the --max-slope option in > > genapts. > > > > Chris > > > > After an import of apt.dat for a taxiway area of 10 x 10 degrees I get > about 60'000 of areas (or "holes") smaller than 1x1 meter. Ok, you can > say this is "reality" by accident, because no artificial surface can be > calculated perfectly, and this faults makes it more sexy then everything > else. But ... unfortunately, you wont see it at all. > > Now, cleaning the 2d polygons by grass with common tools like rmarea > reduce the imported data about 50 percent. Just for illustration, here > is an examples of a (probably) visually edited taxiway with taxidraw: > http://maptest.fgx.ch/screens/taxidraw.png > > I am sure that this very small hole you see here will produce a lot of > lag. My personal conclusion here is I really do not fear when we get > more points soon emulating curves. When this small areas and holes > disappear, we will probably get a lot of resources back. > > Personally I think we should stop people using taxidraw for taxiway > editing, at least for patching lines together to get polygons. > > Cheers, Yves > > > > > > -- > Malware Security Report: Protecting Your Business, Customers, and the > Bottom Line. Protect your business and customers by understanding the > threat from malware and how it can impact your online business. > http://www.accelacomm.com/jaw/sfnl/114/51427462/ > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Malware Security Report: Protecting Your Business, Customers, and the Bottom Line. Protect your business and customers by understanding the threat from malware and how it can impact your online business. http://www.accelacomm.com/jaw/sfnl/114/51427462/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New experimental mapserver
I was also directed to the ogr2ogr converter. The problem I had with both parsers so far, is the final output is too high level. I need the individual nodes and control points so I can create other useful structures. My initial parser keeps all of the information from the original file. For example, when adding the line data, I want to create polys offset from the contour edges (inside the poly for outer boundary and holes). I also want to offset the lights ( outside of the boundaries and holes). I am also calculating the convex hull for each poly so calculating the airport base, and the airport clearing becomes much easier, as I don't need to worry about the resulting polys becoming complex. This is a lot quicker before converting the curves to line segments. Pete On Fri, Sep 9, 2011 at 4:56 PM, Frederic Bouvier wrote: > I hope you all remember that there is already a 8.50 parser inside fg and > code to display airports in the MFD (with Bezier curves). > > Regards, > -Fred > > -- > > I've been using KATL to develop a 8.50 genapt parser for terragear. It > has noticeable sloping in the runways (when you get close to the ground with > the UFO). I would also like a 'worst case' location to test glPolygonOffset > once I get that far. > > You can see some progress here: > > http://flightgear.org/forums/viewtopic.php?f=5&t=13240 > > The last post was incorrect, I haven't run into the 64k ushort issue yet - > it's just that the poly base that Curt refers to isn't generated correctly > for the pavement polys yet. > > I plan on fixing that this weekend. > > > On Fri, Sep 9, 2011 at 3:49 PM, HB-GRAL wrote: > >> Am 09.09.11 19:33, schrieb Curtis Olson: >> > In addition, there is a fairly sophisticated (and I think cool) step >> where >> > we fit a natural curved surface across the airport elevation and used >> the >> > curved surface instead of raw SRTM points. This eliminates the "noise" >> in >> > the raw data and gives the airport surface a natural looking slope and >> > correct hills and valleys (in most cases.) >> >> Hi Curt >> >> Thank you very much taking time for this. >> >> Now this is very interesting, a curved surface with a natural looking >> slope and correct hills. Can you point me to an example for this ? I >> guess my current examples like KSFO and EHAM etc. do only provide really >> flat areas. I did not see any small hills and valleys in FlightGear >> unless I saw the some "artificial shaders" from Frederic Bouvier >> >> Hm, indeed, for the moment I was only looking to the two dimensional >> triangles and saw that genapts (or terragear) is calculating some small >> areas and probably "unnecessary" triangles like here at KSFO >> http://maptest.fgx.ch/screens/wired.png >> >> There are also a lot of duplicate items, or it looks like in the >> wire-frame view, but maybe this items are just very close to each other >> ... >> >> Anyway, how do you get the "natural" curved surface without height data >> ? How are you interpolating between points ? I will try to understand >> this. Of course, I should not be that lazy and should have a look to the >> genapts or terragear code instead, right ;-) >> >> Generally I see that I miss some points here with airport generation and >> it is very different from generating shapes for a map. >> >> Cheers, Yves >> >> >> -- >> Why Cloud-Based Security and Archiving Make Sense >> Osterman Research conducted this study that outlines how and why cloud >> computing security and archiving is rapidly being adopted across the IT >> space for its ease of implementation, lower cost, and increased >> reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/ >> ___ >> Flightgear-devel mailing list >> Flightgear-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/flightgear-devel >> > > > > -- > Why Cloud-Based Security and Archiving Make Sense > Osterman Research conducted this study that outlines how and why cloud > computing security and archiving is rapidly being adopted across the IT > space for its ease of implementation, lower cost, and increased > reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/ > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > > > > -- > Why Cloud-Based Security and Archiving Make Sense > Osterman Research conducted this study that outlines how and why cloud > computing security and archiving is rapidly being adopted across the IT > space for its ease of implementation, lower cost, and increased > reliability. Learn more. http://www.accelacomm.co
Re: [Flightgear-devel] New experimental mapserver
Am 10.09.11 21:56, schrieb Viktor Radnai: > Hi all, > > If you are looking for airports with extreme runway slope for testing, > may I suggest Lukla, Nepal (VNLK). If that one comes out looking right, > I'd say you've got the code sorted :) > > Cheers, > Vik > Lukla is just boring ;-) Other suggestions ? Cheers, Yves -- Malware Security Report: Protecting Your Business, Customers, and the Bottom Line. Protect your business and customers by understanding the threat from malware and how it can impact your online business. http://www.accelacomm.com/jaw/sfnl/114/51427462/ ___ 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 Sat, Sep 3, 2011 at 8:15 AM, Thorsten Renk wrote: > 1) placement in flat layer instead of curved OK. I'll get the fix for this committed as soon as I get the chance. > 2) clouds don't obscure some objects (newly discovered) This may be a problem related to the rendering order of objects with alpha layers. The clouds are in a different RenderBin from other objects. I'll take a look and see what's different about the Vegas tower - the fix may be simply to remove the alpha layer from the texture. The stratus and rain layer textures are going to be much more difficult to resolve. For the stratus layer, I thought by putting in the z-scaling parameter you would be able to use the 3D clouds modeling? I'd really like the 3D cloud infrastructure to be used for all the clouds, so if there are features missing we should address them. Would it be possible to modify the 3D clouds so that they can be used for the rain texture as well? For example, I could provide a sprite distribution on the surface of a cylinder rather than a sphere if that would help. That would allow us to work around the rendering bin problem. > 3) Antishading > > For some reason, I still get antishading in many situations even when I > make cloud size larger than texture size. Looks odd in many cases and > prevents me from adjusting the shade parameters. You mentioned finding a > bug? I thought I had seen a bug, but in fact I was getting confused between the sun and the full moon - at very wide angles of view they both look like white points ;) > If it's of any help, I can pack my current devel version of everything and > you can see for yourself what happens (with the understanding that only > specific settings in the gui are meaningful). If you can provide the parameters of a cloud that is exhibiting the problem, that would be most useful. > Apart from the issues above, there are some things to discuss and think > about: > > 4) Fading in poor visibility > > I'm now in the shader down to 0.1 for the fading factor in > > fogFactor = exp( -gl_Fog.density * fogCoord * 0.1); > > This looks too crisp in slightly hazy conditions, but I was basically > forced to the setting by rainy conditions with ~2-4 km visibility. What > happened otherwise was that clouds in that amount of haze faded so much > that blue sky became visible above where the overcast cloud layer should > have been drawn, which looks really bad. > > Maybe there shouldn't be a fixed number intended to fit all but a function > of visibility? Or a parameter to be passed on - although you mentioned > that passing too many parameters to the shader may lead to different > problems... Making it a function of visibility should be the way forward. I think that's what the gl_Fog.density is supposed to represent, so it may simply be a question of modifying the function further. Perhaps it shouldn't be exp()? Given the number of parameters being passed into other shaders, I'm less worried about the 3D cloud shader than I was. There's also the possibility of creating a second, more complex shader for use with high quality settings in the Rendering Options dialog. > 5) Specify top and bottom shade > > I mentioned that previously - it's not in any sense a 'must', but I think > it would allow for very cool visual effects if the system had the > possibility to shade clouds in a different way if there's a layer above > (or even do some simple ray intersection tests when drawing a tile for > greater realism). Again - would require to pass more parameters. I'm thinking that we need a top, middle and bottom shade, as the current model shades only from the middle of the cloud downwards. > I think that's pretty much it. There's still lots of parameter tuning to > be done on my side, and vertical motion of clouds still needs to be done, > but basically it's functional (see the screenshots I'm already producing) > - I haven't encountered any other problems so far. So we're clearly > getting somewhere :-) Excellent! -Stuart -- Malware Security Report: Protecting Your Business, Customers, and the Bottom Line. Protect your business and customers by understanding the threat from malware and how it can impact your online business. http://www.accelacomm.com/jaw/sfnl/114/51427462/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New experimental mapserver
Hi all, If you are looking for airports with extreme runway slope for testing, may I suggest Lukla, Nepal (VNLK). If that one comes out looking right, I'd say you've got the code sorted :) Cheers, Vik On 09/10/2011 02:47 PM, Christian Schmitt wrote: > Curtis Olson wrote: > >> I won't say this is perfect in all areas ... some areas have stray data >> points or noise in the terrain data that confuses things. There's always >> a chance of a mismatch between airport location terrain location so that >> we >> are trying to put the airport on not quite the right underlying terrain. >> My thoughts for future extensions of this code would be to allow for >> creating specific tuning parameters for airports that didn't behave well >> with the default parameters. > > An nice example where a high slope leads to bad results would be LFLJ, > however, it is possible in such cases to use the --max-slope option in > genapts. > > Chris > > -- > Malware Security Report: Protecting Your Business, Customers, and the > Bottom Line. Protect your business and customers by understanding the > threat from malware and how it can impact your online business. > http://www.accelacomm.com/jaw/sfnl/114/51427462/ > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Malware Security Report: Protecting Your Business, Customers, and the Bottom Line. Protect your business and customers by understanding the threat from malware and how it can impact your online business. http://www.accelacomm.com/jaw/sfnl/114/51427462/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New experimental mapserver
Am 10.09.11 14:47, schrieb Christian Schmitt: > Curtis Olson wrote: > >> I won't say this is perfect in all areas ... some areas have stray data >> points or noise in the terrain data that confuses things. There's always >> a chance of a mismatch between airport location terrain location so that >> we >> are trying to put the airport on not quite the right underlying terrain. >> My thoughts for future extensions of this code would be to allow for >> creating specific tuning parameters for airports that didn't behave well >> with the default parameters. > > An nice example where a high slope leads to bad results would be LFLJ, > however, it is possible in such cases to use the --max-slope option in > genapts. > > Chris > After an import of apt.dat for a taxiway area of 10 x 10 degrees I get about 60'000 of areas (or "holes") smaller than 1x1 meter. Ok, you can say this is "reality" by accident, because no artificial surface can be calculated perfectly, and this faults makes it more sexy then everything else. But ... unfortunately, you wont see it at all. Now, cleaning the 2d polygons by grass with common tools like rmarea reduce the imported data about 50 percent. Just for illustration, here is an examples of a (probably) visually edited taxiway with taxidraw: http://maptest.fgx.ch/screens/taxidraw.png I am sure that this very small hole you see here will produce a lot of lag. My personal conclusion here is I really do not fear when we get more points soon emulating curves. When this small areas and holes disappear, we will probably get a lot of resources back. Personally I think we should stop people using taxidraw for taxiway editing, at least for patching lines together to get polygons. Cheers, Yves -- Malware Security Report: Protecting Your Business, Customers, and the Bottom Line. Protect your business and customers by understanding the threat from malware and how it can impact your online business. http://www.accelacomm.com/jaw/sfnl/114/51427462/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] substantial base package size increase
On Sat, 10 Sep 2011, Curtis Olson wrote: > I just noticed when I pushed out the latest developer snapshot build that > our setup.exe size has grown from about 410 Mb to 500+ Mb. I think (?) this > may be the new dds textures? I'm not making a judgement, or calling for a > particular action here, but it might be worth thinking/discussing if there > is a way to push the size back down, or are we ok with 500Mb+ (1/2 a Gb) on > our setup.exe size? > You remember worrying about it when it crossed 10MB? :) Does the installer tool have a way to build a "web" installer that will allow the initial download to be small and then pull data down as it installs it? That would allow the introduction of some granularity in the installer as well - people could get the bits they want and not download the stuff they don't. 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. -- Malware Security Report: Protecting Your Business, Customers, and the Bottom Line. Protect your business and customers by understanding the threat from malware and how it can impact your online business. http://www.accelacomm.com/jaw/sfnl/114/51427462/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] substantial base package size increase
I just noticed when I pushed out the latest developer snapshot build that our setup.exe size has grown from about 410 Mb to 500+ Mb. I think (?) this may be the new dds textures? I'm not making a judgement, or calling for a particular action here, but it might be worth thinking/discussing if there is a way to push the size back down, or are we ok with 500Mb+ (1/2 a Gb) on our setup.exe size? Thanks, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Malware Security Report: Protecting Your Business, Customers, and the Bottom Line. Protect your business and customers by understanding the threat from malware and how it can impact your online business. http://www.accelacomm.com/jaw/sfnl/114/51427462/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New experimental mapserver
Curtis Olson wrote: > I won't say this is perfect in all areas ... some areas have stray data > points or noise in the terrain data that confuses things. There's always > a chance of a mismatch between airport location terrain location so that > we > are trying to put the airport on not quite the right underlying terrain. > My thoughts for future extensions of this code would be to allow for > creating specific tuning parameters for airports that didn't behave well > with the default parameters. An nice example where a high slope leads to bad results would be LFLJ, however, it is possible in such cases to use the --max-slope option in genapts. Chris -- Malware Security Report: Protecting Your Business, Customers, and the Bottom Line. Protect your business and customers by understanding the threat from malware and how it can impact your online business. http://www.accelacomm.com/jaw/sfnl/114/51427462/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New experimental mapserver
On Fri, Sep 9, 2011 at 2:49 PM, HB-GRAL wrote: Hi Curt > > Thank you very much taking time for this. > > Now this is very interesting, a curved surface with a natural looking > slope and correct hills. Can you point me to an example for this ? I > guess my current examples like KSFO and EHAM etc. do only provide really > flat areas. I did not see any small hills and valleys in FlightGear > unless I saw the some "artificial shaders" from Frederic Bouvier > Hi Yves, every airport is an example of this, but maybe "hills and valleys" is a bad description on my part. What it amounts to is that airports try to be as flat as possible, but even flat areas aren't often as flat as we might first think. Go to any detailed airport chart and look at the runway elevations for the ends of each runway. Another way to think about this is that if you make all the airports completely flat, you will have to deal with "cliffs" around the edges ... either the airport is sunk down at some parts, and raised up in others relative to the surrounding terrain. Albuquerque, NM is one of the worst offenders I found. You can't fit a "flattened" airport into the surrounding terrain without the result looking awful. One solution would be to adjust the terrain to blend in with the airport and that would be an ok thing to do. But the problem is that I like to torment myself. Here is approximately what I came up with. 1. Sample the raw terrain elevation across a regular grid that covers the area of the airport. 2. I pick a 3d function that is sufficiently "curvy" so that it can flex enough to reasonably match the terrain surface, but stiff enough so that it doesn't have all kinds of crazy ups and downs. Then I do a least squares fit of this function to the data. For example, let's say my function is z = a*x^2 + b*y^2 + c*x*y + d*x + e*y + f. Then the least squares fit would pick the "best" coefficients: a, b, c, d, e, & f to fit this function through the sampled terrain data. Very much like a best fit of a line through x, y data except extended to 3d with a bit more complicated function. 3. Now that I have the coefficients for this function, I can use this function to adjust the elevations of everything on the airport surface. The cool thing is that now when you look at an airport built on crazy terrain with maybe a valley falling away between two runways on one side, the edges all around the airport match up reasonably well with the surrounding terrain. I won't say this is perfect in all areas ... some areas have stray data points or noise in the terrain data that confuses things. There's always a chance of a mismatch between airport location terrain location so that we are trying to put the airport on not quite the right underlying terrain. My thoughts for future extensions of this code would be to allow for creating specific tuning parameters for airports that didn't behave well with the default parameters. > Hm, indeed, for the moment I was only looking to the two dimensional > triangles and saw that genapts (or terragear) is calculating some small > areas and probably "unnecessary" triangles like here at KSFO > http://maptest.fgx.ch/screens/wired.png > > There are also a lot of duplicate items, or it looks like in the > wire-frame view, but maybe this items are just very close to each other ... > Very likely this is a result of items very close to each other ... especially if the airport designer placed or sized anything visually. One huge problem you run into over and over and over and over again in terragear/genapts work is numerical precision. Things just get weird when you get a gap between polygons that is about the size of one bit difference between two double floating point values. Logically correct polygon manipulation code can blow up due to small numerical problems. And when you throw real world data (and the whole world) at your code, you *will* find every possible way that numerical issues can blow up your code. Anyway, how do you get the "natural" curved surface without height data > Well it's terragear so we have all the processed srtm heigh data already available to just use. > ? How are you interpolating between points ? I will try to understand > this. Of course, I should not be that lazy and should have a look to the > genapts or terragear code instead, right ;-) > Once we do the least squares fit of our function, then we can look up a z value for any x, y point within our airport area. > Generally I see that I miss some points here with airport generation and > it is very different from generating shapes for a map. > Hope that helps clarify a bit. Curt -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Malware Security Report: Protecting Your Business, Customers, and the Bottom Line. Protect your business and customers by understan
Re: [Flightgear-devel] New experimental mapserver
Am 09.09.11 22:56, schrieb Frederic Bouvier: > I hope you all remember that there is already a 8.50 parser inside fg and > code to display airports in the MFD (with Bezier curves). > > Regards, > -Fred > Does this parser handle both types, 8.10 and 8.50 format ? As I understand 8.50 is only intermediate and contains a lot of "old" features without beziers. One problem remains here for me at the moment, to display the "beziers" or "curved" polygons on my exeperimental map, I may need an improved apt.dat importer/parser once. I am really impressed about all the work already done in the whole "airport and scenery area", the original one in the terragear toolchain, now the work coming up by Peter (and all the work I could not point out here, I am sure I miss some stuff due the lack of my developing experience). Cheers, Yves -- Malware Security Report: Protecting Your Business, Customers, and the Bottom Line. Protect your business and customers by understanding the threat from malware and how it can impact your online business. http://www.accelacomm.com/jaw/sfnl/114/51427462/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
James Turner wrote: > If you regularly pull+build 'next', please try a cmake based build, and > report any issues you encounter - CMake should work 'out of the box' on > Mac (Makefiles or XCode), Linux (32- and 64- bit) and Windows > (VisualStudio 2008 and 2010 - mingw and cygwin may need some fixes). I have used CMake in the Gentoo packages pretty much from the start, but right now I'm experiencing some problems: all is good as long as I have libsvn support enabled in SG and FG. When I disable it in SG and want to recompile FG afterwards (also disabled, of course), I get a linking error for Terrasync: Linking CXX executable terrasync [ 47%] Building CXX object src/FDM/CMakeFiles/fgFDM.dir/UIUCModel/uiuc_auto_pilot.cpp.o /usr/lib/gcc/x86_64-pc-linux- gnu/4.5.3/../../../../lib64/libsgthreads.a(SGThread.cxx.o): In function `SGThread::~SGThread()': (.text+0x41): undefined reference to `pthread_detach' /usr/lib/gcc/x86_64-pc-linux- gnu/4.5.3/../../../../lib64/libsgthreads.a(SGThread.cxx.o): In function `SGThread::start()': (.text+0xce): undefined reference to `pthread_create' /usr/lib/gcc/x86_64-pc-linux- gnu/4.5.3/../../../../lib64/libsgthreads.a(SGThread.cxx.o): In function `SGThread::join()': (.text+0x116): undefined reference to `pthread_join' collect2: ld returned 1 exit status make[2]: *** [utils/TerraSync/terrasync] Error 1 make[1]: *** [utils/TerraSync/CMakeFiles/terrasync.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs I don't know if this is caused by the recent cmake changes or rather by the threads class rewrite... HTH Chris -- Malware Security Report: Protecting Your Business, Customers, and the Bottom Line. Protect your business and customers by understanding the threat from malware and how it can impact your online business. http://www.accelacomm.com/jaw/sfnl/114/51427462/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Links for new FlightGear pilots
Am Sat, 10 Sep 2011 10:18:27 +0200 schrieb Jörg Emmerich : > Well - yes - I am rather disappointed That is not surprising! Technically seen, it is correct that Latex is the most flexible format, from which you can derive most other types, but that doesn't lessen the nice content you provided, imho. I think you overestimate the effort to convert to Latex. Have a look at http://www.lyx.org ! Maybe you can just copy&paste your text to this opensource WYSIWYG Editor, eleminate the glitches and save it as latex? Since lyx doens't hide the generated latex code from the user, it is even a good tool to learn latex (and latex, btw, is always a good thing to know!). If nothing helps, don't resignate, but be keen to provide your work as an external documentation. There are aircrafts at individual hangars all around the net, why shouldn't there be a "third party" manual? But, admitted, one merged "uber manual" would be a nice thing! Regards, Joe -- Malware Security Report: Protecting Your Business, Customers, and the Bottom Line. Protect your business and customers by understanding the threat from malware and how it can impact your online business. http://www.accelacomm.com/jaw/sfnl/114/51427462/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
Hi, On Saturday, September 10, 2011 10:46:03 Durk Talsma wrote: > Thanks; looking at /usr/share/cmake/Modules, I see that I have a > "Findosg.cmake" file, as well as several "Findosg*.cmake" files, but no > "FindOpenSceneGraph.cmake". FWIW, this is one an opensuse 10.0, running > cmake version 2.6 - patch 2 > > Just double checking on my laptop, I do note that cmake 2.8.3 does work as > advertised. Is there any way to get this to work on older distributions? > > I probably need to upgrade my 3 yr. old distro anyhow, because yesterday I > also ran into a git error, which would require an upgrade. But, it's not > something I'm really looking forward doing right now... Ok, then it's probably best to deinstall the distros cmake and install cmake from sources. Or may be cmake has some binary distributions that fits your needs. Greetings Mathias -- Malware Security Report: Protecting Your Business, Customers, and the Bottom Line. Protect your business and customers by understanding the threat from malware and how it can impact your online business. http://www.accelacomm.com/jaw/sfnl/114/51427462/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
Hi Durk, On Saturday, September 10, 2011 10:28:22 Frederic Bouvier wrote: > FindOpenSceneGraph.cmake is in the Cmake distribution, in the share > directory. You certainly need to tell Cmake where the installed OSG is. Correct, this should be cmake provided. So, cmake does not find its own files. How and where did you install cmake? Greetings Mathias -- Malware Security Report: Protecting Your Business, Customers, and the Bottom Line. Protect your business and customers by understanding the threat from malware and how it can impact your online business. http://www.accelacomm.com/jaw/sfnl/114/51427462/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
- Mail original - > hi Fred, > On 10 Sep 2011, at 10:28, Frederic Bouvier wrote: > > > Hi Durk, > > > > > > FindOpenSceneGraph.cmake is in the Cmake distribution, in the share > > directory. You certainly need to tell Cmake where the installed > > OSG is. > > > > Regards, > > -Fred > > > > Thanks; looking at /usr/share/cmake/Modules, I see that I have a > "Findosg.cmake" file, as well as several "Findosg*.cmake" files, but > no "FindOpenSceneGraph.cmake". FWIW, this is one an opensuse 10.0, > running cmake version 2.6 - patch 2 > > Just double checking on my laptop, I do note that cmake 2.8.3 does > work as advertised. Is there any way to get this to work on older > distributions? > > I probably need to upgrade my 3 yr. old distro anyhow, because > yesterday I also ran into a git error, which would require an > upgrade. But, it's not something I'm really looking forward doing > right now... We are using Cmake 2.8 -Fred -- Malware Security Report: Protecting Your Business, Customers, and the Bottom Line. Protect your business and customers by understanding the threat from malware and how it can impact your online business. http://www.accelacomm.com/jaw/sfnl/114/51427462/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
hi Fred, On 10 Sep 2011, at 10:28, Frederic Bouvier wrote: > Hi Durk, > > > FindOpenSceneGraph.cmake is in the Cmake distribution, in the share > directory. You certainly need to tell Cmake where the installed OSG is. > > Regards, > -Fred > Thanks; looking at /usr/share/cmake/Modules, I see that I have a "Findosg.cmake" file, as well as several "Findosg*.cmake" files, but no "FindOpenSceneGraph.cmake". FWIW, this is one an opensuse 10.0, running cmake version 2.6 - patch 2 Just double checking on my laptop, I do note that cmake 2.8.3 does work as advertised. Is there any way to get this to work on older distributions? I probably need to upgrade my 3 yr. old distro anyhow, because yesterday I also ran into a git error, which would require an upgrade. But, it's not something I'm really looking forward doing right now... Cheers, Durk -- Malware Security Report: Protecting Your Business, Customers, and the Bottom Line. Protect your business and customers by understanding the threat from malware and how it can impact your online business. http://www.accelacomm.com/jaw/sfnl/114/51427462/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
Hi Durk,
- Mail original -
> >
> > If you regularly pull+build 'next', please try a cmake based build,
> > and report any issues you encounter - CMake should work 'out of
> > the box' on Mac (Makefiles or XCode), Linux (32- and 64- bit) and
> > Windows (VisualStudio 2008 and 2010 - mingw and cygwin may need
> > some fixes).
> >
>
> Hi James,
>
> I'm trying to build a Cmake build on linux, and I'm running into the
> following problem:
>
> CMake Error at CMakeLists.txt:76 (find_package):
>Could not find module FindOpenSceneGraph.cmake or a configuration
>file for
>package OpenSceneGraph.
>
>Adjust CMAKE_MODULE_PATH to find FindOpenSceneGraph.cmake or set
>OpenSceneGraph_DIR to the directory containing a CMake
>configuration file
>for OpenSceneGraph. The file will have one of the following
>names:
>
> OpenSceneGraphConfig.cmake
> openscenegraph-config.cmake
>
> Looking at simgear/CMakeModules, I do see a FindSvnClient.cmake, but
> no FindOpenSceneGraph.cmake. Is there any chance this file hasn't
> been committed to git yet?
>
> FWIW, I have my source tree organized as:
>
> ${HOME}/src/OpenSceneGraph*
> ${HOME}/src/flightgear-git/simgear
> ${HOME}/src/flightgear-git/simgear-build
> ${HOME}/src/flightgear-git/simgear-cmake
>
> ${HOME}/src/flightgear-git/flightgear
> ${HOME}/src/flightgear-git/flightgear-build
> ${HOME}/src/flightgear-git/flightgear-cmake
> ${HOME}/src/fgdata
>
> (Where OpenSceneGraph* refers to a number of separate directories:
> OpenSceneGraph for SVN/trunk, OpenSceneGraph-2.8.1, and
> OpenSceneGraph-2.9.11)
FindOpenSceneGraph.cmake is in the Cmake distribution, in the share directory.
You certainly need to tell Cmake where the installed OSG is.
Regards,
-Fred
--
Malware Security Report: Protecting Your Business, Customers, and the
Bottom Line. Protect your business and customers by understanding the
threat from malware and how it can impact your online business.
http://www.accelacomm.com/jaw/sfnl/114/51427462/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
>
> If you regularly pull+build 'next', please try a cmake based build, and
> report any issues you encounter - CMake should work 'out of the box' on Mac
> (Makefiles or XCode), Linux (32- and 64- bit) and Windows (VisualStudio 2008
> and 2010 - mingw and cygwin may need some fixes).
>
Hi James,
I'm trying to build a Cmake build on linux, and I'm running into the following
problem:
CMake Error at CMakeLists.txt:76 (find_package):
Could not find module FindOpenSceneGraph.cmake or a configuration file for
package OpenSceneGraph.
Adjust CMAKE_MODULE_PATH to find FindOpenSceneGraph.cmake or set
OpenSceneGraph_DIR to the directory containing a CMake configuration file
for OpenSceneGraph. The file will have one of the following names:
OpenSceneGraphConfig.cmake
openscenegraph-config.cmake
Looking at simgear/CMakeModules, I do see a FindSvnClient.cmake, but no
FindOpenSceneGraph.cmake. Is there any chance this file hasn't been committed
to git yet?
FWIW, I have my source tree organized as:
${HOME}/src/OpenSceneGraph*
${HOME}/src/flightgear-git/simgear
${HOME}/src/flightgear-git/simgear-build
${HOME}/src/flightgear-git/simgear-cmake
${HOME}/src/flightgear-git/flightgear
${HOME}/src/flightgear-git/flightgear-build
${HOME}/src/flightgear-git/flightgear-cmake
${HOME}/src/fgdata
(Where OpenSceneGraph* refers to a number of separate directories:
OpenSceneGraph for SVN/trunk, OpenSceneGraph-2.8.1, and OpenSceneGraph-2.9.11)
Cheers,
Durk
--
Malware Security Report: Protecting Your Business, Customers, and the
Bottom Line. Protect your business and customers by understanding the
threat from malware and how it can impact your online business.
http://www.accelacomm.com/jaw/sfnl/114/51427462/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Links for new FlightGear pilots
Well - yes - I am rather disappointed Especially because i looked again, but cannot find any of my suggested improvements in the latest "getstart", in regards to structuring, referencing, and looks. In addition I did not really see an answer to Curtis question, that started that all - I get that kind of questions every week during my ATCing - and hoped I had an answer. But as I said at the beginning: Our dev.group had done quite some job designing the "getstart" quite some time ago - which I thought I could contribute to, especially from a more USERs-viewpoint. But I surely will not set up a competitive environment against that basically good work. Just let me beg for one last wish: Please spend that now "getstart" at least a little cosmetic treatment! Somehow I do not believe that the pictures shown in it represent todays FlightGears possibilities, especially in regards to scenery! Look e.g. the title-picture - but also several others inside. (Yes - I know: The work that counts is the (hidden) engineering - but what sells it, is the (outside visible) marketing!). I will now complete my announced task to finalize the German translation, based on the "getstart". And I will keep the EN/version as is on my homepage - but will not provide a direct link to it for standard users. If anybody anytime wants to use it or parts of it for FlightGear - he is welcome to do so. I hope: No harm done joe -- Malware Security Report: Protecting Your Business, Customers, and the Bottom Line. Protect your business and customers by understanding the threat from malware and how it can impact your online business. http://www.accelacomm.com/jaw/sfnl/114/51427462/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
