You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(612) |
Jun
(916) |
Jul
(1079) |
Aug
(536) |
Sep
(476) |
Oct
(354) |
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(143) |
2006 |
Jan
(828) |
Feb
(774) |
Mar
(1114) |
Apr
(795) |
May
(566) |
Jun
(857) |
Jul
(336) |
Aug
(412) |
Sep
(213) |
Oct
(385) |
Nov
(1065) |
Dec
(514) |
2007 |
Jan
(864) |
Feb
(501) |
Mar
(346) |
Apr
(357) |
May
(720) |
Jun
(598) |
Jul
(714) |
Aug
(275) |
Sep
(366) |
Oct
(428) |
Nov
(674) |
Dec
(1197) |
2008 |
Jan
(582) |
Feb
(357) |
Mar
(456) |
Apr
(314) |
May
(150) |
Jun
(188) |
Jul
(205) |
Aug
(440) |
Sep
(349) |
Oct
(705) |
Nov
(643) |
Dec
(781) |
2009 |
Jan
(684) |
Feb
(456) |
Mar
(450) |
Apr
(371) |
May
(294) |
Jun
(319) |
Jul
(199) |
Aug
(349) |
Sep
(570) |
Oct
(720) |
Nov
(547) |
Dec
(481) |
2010 |
Jan
(535) |
Feb
(680) |
Mar
(666) |
Apr
(345) |
May
(283) |
Jun
(216) |
Jul
(241) |
Aug
(195) |
Sep
(240) |
Oct
(350) |
Nov
(498) |
Dec
(452) |
2011 |
Jan
(550) |
Feb
(577) |
Mar
(439) |
Apr
(495) |
May
(343) |
Jun
(473) |
Jul
(287) |
Aug
(337) |
Sep
(481) |
Oct
(495) |
Nov
(409) |
Dec
(500) |
2012 |
Jan
(335) |
Feb
(490) |
Mar
(382) |
Apr
(464) |
May
(234) |
Jun
(255) |
Jul
(226) |
Aug
(266) |
Sep
(213) |
Oct
(201) |
Nov
(268) |
Dec
(186) |
2013 |
Jan
(196) |
Feb
(363) |
Mar
(164) |
Apr
(222) |
May
(146) |
Jun
(256) |
Jul
(126) |
Aug
(150) |
Sep
(196) |
Oct
(201) |
Nov
(270) |
Dec
(196) |
2014 |
Jan
(232) |
Feb
(282) |
Mar
(234) |
Apr
(189) |
May
(262) |
Jun
(132) |
Jul
(44) |
Aug
(157) |
Sep
(192) |
Oct
(164) |
Nov
(252) |
Dec
(71) |
2015 |
Jan
(147) |
Feb
(369) |
Mar
(641) |
Apr
(443) |
May
(213) |
Jun
(476) |
Jul
(211) |
Aug
(103) |
Sep
(275) |
Oct
(281) |
Nov
(275) |
Dec
(253) |
2016 |
Jan
(423) |
Feb
(463) |
Mar
(392) |
Apr
(456) |
May
(631) |
Jun
(411) |
Jul
(248) |
Aug
(265) |
Sep
(294) |
Oct
(323) |
Nov
(745) |
Dec
(508) |
2017 |
Jan
(689) |
Feb
(833) |
Mar
(940) |
Apr
(593) |
May
(937) |
Jun
(349) |
Jul
(283) |
Aug
(430) |
Sep
(523) |
Oct
(428) |
Nov
(374) |
Dec
(348) |
2018 |
Jan
(398) |
Feb
(329) |
Mar
(551) |
Apr
(698) |
May
(669) |
Jun
(819) |
Jul
(459) |
Aug
(419) |
Sep
(720) |
Oct
(568) |
Nov
(359) |
Dec
(454) |
2019 |
Jan
(490) |
Feb
(466) |
Mar
(489) |
Apr
(546) |
May
(435) |
Jun
(418) |
Jul
(342) |
Aug
(390) |
Sep
(271) |
Oct
(281) |
Nov
(325) |
Dec
(201) |
2020 |
Jan
(581) |
Feb
(158) |
Mar
(496) |
Apr
(1027) |
May
(774) |
Jun
(645) |
Jul
(354) |
Aug
(590) |
Sep
(315) |
Oct
(779) |
Nov
(1001) |
Dec
(872) |
2021 |
Jan
(878) |
Feb
(767) |
Mar
(754) |
Apr
(443) |
May
(523) |
Jun
(413) |
Jul
(201) |
Aug
(243) |
Sep
(257) |
Oct
(305) |
Nov
(336) |
Dec
(390) |
2022 |
Jan
(486) |
Feb
(512) |
Mar
(165) |
Apr
(103) |
May
(109) |
Jun
(135) |
Jul
(61) |
Aug
(194) |
Sep
(244) |
Oct
(279) |
Nov
(282) |
Dec
(145) |
2023 |
Jan
(441) |
Feb
(265) |
Mar
(240) |
Apr
(306) |
May
(250) |
Jun
(180) |
Jul
(171) |
Aug
(307) |
Sep
(404) |
Oct
(169) |
Nov
(172) |
Dec
(177) |
2024 |
Jan
(286) |
Feb
(141) |
Mar
(174) |
Apr
(149) |
May
(130) |
Jun
(250) |
Jul
(102) |
Aug
(159) |
Sep
(75) |
Oct
|
Nov
|
Dec
|
From: Florent R. <f.r...@fr...> - 2024-08-31 17:50:21
|
Le 31/08/2024, "merspieler" <mer...@al...> a écrit: > Oki, could you folks please do a sanity check before I copy > everything to ibiblio > https://de2mirror.flightgear.org/fgaddon/Aircraft-trunk/ Sorry, I'm not better suited than you for this. In this matter, I only did a small bit of Python code migration written by someone else—which would be James, AFAIK. Regards -- Florent |
From: merspieler <mer...@al...> - 2024-08-31 15:35:54
|
Oki, could you folks please do a sanity check before I copy everything to ibiblio https://de2mirror.flightgear.org/fgaddon/Aircraft-trunk/ On Sat Aug 31, 2024 at 5:00 PM CEST, Florent Rougon via Flightgear-devel wrote: > Hi, > > Le 31/08/2024, "merspieler" <mer...@al...> a écrit: > > > Thanks. I managed to run that script > > Is it normal that I get parse errors and unknown tag errors? > > I only ran it about once when migrating things to python3-flightgear, > but IIRC, yes: there are so many aircraft that fixing all the parse > errors would be... some work (in particular because this should be done > _by the respective aircraft maintainers_ so that they don't get merge > conflicts and we don't get automatic reappearance of fixed problems at > the next aircraft repo push by said maintainers). > > Please note that the place to get the 'flightgear' Python package is > FGMeta (which is not hosted at GitHub): > > https://sourceforge.net/p/flightgear/fgmeta/ci/next/tree/python3-flightgear/flightgear/ > > Regards |
From: Florent R. <f.r...@fr...> - 2024-08-31 15:00:34
|
Hi, Le 31/08/2024, "merspieler" <mer...@al...> a écrit: > Thanks. I managed to run that script > Is it normal that I get parse errors and unknown tag errors? I only ran it about once when migrating things to python3-flightgear, but IIRC, yes: there are so many aircraft that fixing all the parse errors would be... some work (in particular because this should be done _by the respective aircraft maintainers_ so that they don't get merge conflicts and we don't get automatic reappearance of fixed problems at the next aircraft repo push by said maintainers). Please note that the place to get the 'flightgear' Python package is FGMeta (which is not hosted at GitHub): https://sourceforge.net/p/flightgear/fgmeta/ci/next/tree/python3-flightgear/flightgear/ Regards -- Florent |
From: TheFGFSEagle <the...@gm...> - 2024-08-31 14:53:06
|
Oh, okay. That's reassuring ! :) Am Sa., 31. Aug. 2024 um 16:47 Uhr schrieb merspieler < mer...@al...>: > On Sat Aug 31, 2024 at 3:47 PM CEST, TheFGFSEagle wrote: > > IDK, is it a good idea to post an SSH key on a public mailing list ? > > Its only the public key... which, as the name suggests, can be public. > There's not much you can really do with this information. > > > _______________________________________________ > Flightgear-devel mailing list > Fli...@li... > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > |
From: merspieler <mer...@al...> - 2024-08-31 14:46:33
|
On Sat Aug 31, 2024 at 3:47 PM CEST, TheFGFSEagle wrote: > IDK, is it a good idea to post an SSH key on a public mailing list ? Its only the public key... which, as the name suggests, can be public. There's not much you can really do with this information. |
From: TheFGFSEagle <the...@gm...> - 2024-08-31 13:47:25
|
IDK, is it a good idea to post an SSH key on a public mailing list ? Am Sa., 31. Aug. 2024 um 15:36 Uhr schrieb merspieler < mer...@al...>: > On Fri Aug 30, 2024 at 3:47 PM CEST, James Turner wrote: > > And then we need to get the public SSH key for your machine added to > ibiblio by Curt, so the rsync to ibiblio works. > > This would be the key: > ssh-ed25519 > AAAAC3NzaC1lZDI1NTE5AAAAIMy44tGbyi+OMm/NXY0H4leuyfC0VVBdYfCaPinsLIt7 > fl...@de... > > > _______________________________________________ > Flightgear-devel mailing list > Fli...@li... > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > |
From: merspieler <mer...@al...> - 2024-08-31 13:35:19
|
On Fri Aug 30, 2024 at 3:47 PM CEST, James Turner wrote: > And then we need to get the public SSH key for your machine added to ibiblio by Curt, so the rsync to ibiblio works. This would be the key: ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIMy44tGbyi+OMm/NXY0H4leuyfC0VVBdYfCaPinsLIt7 fl...@de... |
From: merspieler <mer...@al...> - 2024-08-31 12:12:23
|
Thanks. I managed to run that script Is it normal that I get parse errors and unknown tag errors? On Sat Aug 31, 2024 at 1:55 PM CEST, TheFGFSEagle wrote: > https://github.com/FlightGear/fgmeta/tree/next/python3-flightgear > > Am Sa., 31. Aug. 2024 um 12:35 Uhr schrieb merspieler < > mer...@al...>: > > > On Fri Aug 30, 2024 at 3:47 PM CEST, James Turner wrote: > > > Then you ‘just’ need to have a cron job which runs ’svn up’ followed by > > ‘update_catalog.py path/to/catalog/config/dir’ and the script will generate > > & update the catalog and any changed zips. > > > > I'm getting this error when running the update-catalog.py script: > > Traceback (most recent call last): > > File "/storage/fgaddon-src/fgmeta/catalog/./update-catalog.py", line 14, > > in <module> > > from flightgear.meta import sgprops > > ModuleNotFoundError: No module named 'flightgear' > > > > Where do I find that module? > > > > > > _______________________________________________ > > Flightgear-devel mailing list > > Fli...@li... > > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > |
From: TheFGFSEagle <the...@gm...> - 2024-08-31 11:55:59
|
https://github.com/FlightGear/fgmeta/tree/next/python3-flightgear Am Sa., 31. Aug. 2024 um 12:35 Uhr schrieb merspieler < mer...@al...>: > On Fri Aug 30, 2024 at 3:47 PM CEST, James Turner wrote: > > Then you ‘just’ need to have a cron job which runs ’svn up’ followed by > ‘update_catalog.py path/to/catalog/config/dir’ and the script will generate > & update the catalog and any changed zips. > > I'm getting this error when running the update-catalog.py script: > Traceback (most recent call last): > File "/storage/fgaddon-src/fgmeta/catalog/./update-catalog.py", line 14, > in <module> > from flightgear.meta import sgprops > ModuleNotFoundError: No module named 'flightgear' > > Where do I find that module? > > > _______________________________________________ > Flightgear-devel mailing list > Fli...@li... > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > |
From: merspieler <mer...@al...> - 2024-08-31 10:34:45
|
On Fri Aug 30, 2024 at 3:47 PM CEST, James Turner wrote: > Then you ‘just’ need to have a cron job which runs ’svn up’ followed by ‘update_catalog.py path/to/catalog/config/dir’ and the script will generate & update the catalog and any changed zips. I'm getting this error when running the update-catalog.py script: Traceback (most recent call last): File "/storage/fgaddon-src/fgmeta/catalog/./update-catalog.py", line 14, in <module> from flightgear.meta import sgprops ModuleNotFoundError: No module named 'flightgear' Where do I find that module? |
From: <ajt...@v-...> - 2024-08-30 23:06:41
|
Correction :- I have replaced the _*2Tb*_ hard drive and 256GB SSD on my desktop Windows 10 machinewith an SSD. On 31/08/2024 00:00, ajt...@v-... wrote: > > I have replaced the 2Gb hard drive and 256GB SSD on my desktop Windows > 10 machinewith an SSD. > > The oLd SSD held the Windows OS and non-Flightgear stuff. Flightgear > and related projects were on the old hard drive, together with > accumulated archives etc.etc.etc. > > The good news is that FGaddon SVN Update now runs OK on first attempt > - i.e. no timeout ;) > > Alan > > > > _______________________________________________ > Flightgear-devel mailing list > Fli...@li... > https://lists.sourceforge.net/lists/listinfo/flightgear-devel |
From: <ajt...@v-...> - 2024-08-30 23:00:43
|
I have replaced the 2Gb hard drive and 256GB SSD on my desktop Windows 10 machinewith an SSD. The oLd SSD held the Windows OS and non-Flightgear stuff. Flightgear and related projects were on the old hard drive, together with accumulated archives etc.etc.etc. The good news is that FGaddon SVN Update now runs OK on first attempt - i.e. no timeout ;) Alan |
From: Florent R. <f.r...@fr...> - 2024-08-30 20:46:18
|
Hi, Le 30/08/2024, "merspieler" <mer...@al...> a écrit: > Right now, both fgdata and the svn checkout of trunk run into a time out... so > might take a little till I convince them to clone (fgdata I could work around > by rsyncing from a machine where I already got a copy, is there a trick for > svn? (I never used that before)) When I was testing this with FGData (a few years ago), I found that cloning it from SourceForge worked without timing out when performed over ssh, as explained here: https://wiki.flightgear.org/Scripted_Compilation_on_Linux_Debian/Ubuntu#For_the_curious:_the_SSH_way One can hope this also works for FGAddon using an svn+ssh:// URL (I haven't tried it, though). Regards -- Florent |
From: merspieler <mer...@al...> - 2024-08-30 17:40:49
|
On Fri Aug 30, 2024 at 4:48 PM CEST, merspieler wrote: > I will open a PR for when I'm done with the config (and probably also add the nix file that contains the "cron job" service and stuff so others (if they use nix) can re-deploy this quickly. Or someone gives me commit access? |
From: merspieler <mer...@al...> - 2024-08-30 14:49:16
|
On Fri Aug 30, 2024 at 3:47 PM CEST, James Turner wrote: > - a full clone of FGData on next > - a full checkout of FGAddon trunk > - clone of FGMeta to get the config files > - make your own copy of the config at: > > https://sourceforge.net/p/flightgear/fgmeta/ci/next/tree/catalog/fgaddon-catalog-ukmirror/ > > eg call it fgaddon-trunk-merspieler Right now, both fgdata and the svn checkout of trunk run into a time out... so might take a little till I convince them to clone (fgdata I could work around by rsyncing from a machine where I already got a copy, is there a trick for svn? (I never used that before)) I will open a PR for when I'm done with the config (and probably also add the nix file that contains the "cron job" service and stuff so others (if they use nix) can re-deploy this quickly. > And then we need to get the public SSH key for your machine added to ibiblio by Curt, so the rsync to ibiblio works. Will send that once I'm done with the setup > Then you ‘just’ need to have a cron job which runs ’svn up’ followed by ‘update_catalog.py path/to/catalog/config/dir’ and the script will generate & update the catalog and any changed zips. > > Then you do a similar setup for the stable-202 branch if you want that as well, but probably the rate of change is low we could skip it? Can I run it off of the same svn checkout or do I need a 2nd one for that? > One issue I’ve just realised is that because of how the revision numbers of .zips are tracked, doing this may reset them all to zero, which could cause weirdness. (They’re tracked locally on the machine running the script) Ideally we’d grab the existing catalog.xml from Ibilbio, and use that to set the current revision numbers on the first time you run update_catalog.py (which will generate *all* the zips …. on successive runs it only generates zips when an aircraft has changed). But anytwa Since I've already been running a mirror, I already have that... so I just need to point it at the existing path, right? Also... I noticed, that it still contained the old domain in that config, never got updated to when torsten gave me the de[12]mirror.flightgear.org domain. |
From: James T. <ja...@fl...> - 2024-08-30 13:48:01
|
> On 30 Aug 2024, at 13:36, merspieler <mer...@al...> wrote: > > On Fri Aug 30, 2024 at 12:17 PM CEST, James Turner wrote: >> Some good news, my, uh, ‘dealer’ in decommissioned servers has a continuing supply of them, so a replacement machine can be sourced. However since I need to physically drive it to our office, it won't be running for a few months. > > > Hey James... thanks for the headsup... > If its a few months... what will we do about it in the mean time? > Just leave downloads broken? And no FGAddons updates? > Or do we want a temporary solution for the mean time? > You said something about a full SVN checkout? > How big is that? If I got the space, I could run all of that > for now (with the explicite goal of only being a temporary > stop gap solution) Yep that’s a good idea. Downloads I can work around a different way, FGAddon is probably the one to fix. You need: - a full clone of FGData on next - a full checkout of FGAddon trunk - clone of FGMeta to get the config files - make your own copy of the config at: https://sourceforge.net/p/flightgear/fgmeta/ci/next/tree/catalog/fgaddon-catalog-ukmirror/ eg call it fgaddon-trunk-merspieler And then we need to get the public SSH key for your machine added to ibiblio by Curt, so the rsync to ibiblio works. Then you ‘just’ need to have a cron job which runs ’svn up’ followed by ‘update_catalog.py path/to/catalog/config/dir’ and the script will generate & update the catalog and any changed zips. Then you do a similar setup for the stable-202 branch if you want that as well, but probably the rate of change is low we could skip it? One issue I’ve just realised is that because of how the revision numbers of .zips are tracked, doing this may reset them all to zero, which could cause weirdness. (They’re tracked locally on the machine running the script) Ideally we’d grab the existing catalog.xml from Ibilbio, and use that to set the current revision numbers on the first time you run update_catalog.py (which will generate *all* the zips …. on successive runs it only generates zips when an aircraft has changed). But anytwa > > Since I'm running the only public terrasync mirrors, it would be great > if Torsten tells me, how I can get updates from the source directly > since so far I used ukmirror as source and since that's not running, > I'm not getting any updates there. > I’ll leave that for Torsten to explain, indeed. James |
From: merspieler <mer...@al...> - 2024-08-30 12:37:00
|
On Fri Aug 30, 2024 at 12:17 PM CEST, James Turner wrote: > Some good news, my, uh, ‘dealer’ in decommissioned servers has a continuing supply of them, so a replacement machine can be sourced. However since I need to physically drive it to our office, it won't be running for a few months. Hey James... thanks for the headsup... If its a few months... what will we do about it in the mean time? Just leave downloads broken? And no FGAddons updates? Or do we want a temporary solution for the mean time? You said something about a full SVN checkout? How big is that? If I got the space, I could run all of that for now (with the explicite goal of only being a temporary stop gap solution) Since I'm running the only public terrasync mirrors, it would be great if Torsten tells me, how I can get updates from the source directly since so far I used ukmirror as source and since that's not running, I'm not getting any updates there. regards, Nia |
From: Erik H. <er...@eh...> - 2024-08-30 12:09:52
|
On 8/30/24 12:17, James Turner wrote: > Some good news, my, uh, ‘dealer’ in decommissioned servers has a continuing supply of them, so a replacement machine can be sourced. However since I need to physically drive it to our office, it won't be running for a few months. I wish I has such a pusherman. Erik -- http://aeonwave.xyz High performance audio scenegraph and sound simulation. |
From: James T. <ja...@fl...> - 2024-08-30 10:18:23
|
> On 30 Aug 2024, at 09:17, James Turner <ja...@fl...> wrote: > > Unfortunately, the (donated) Dell PowerEdge I was using to run UKMIrror etc seems to have expired. Given it’s had an entire second life after being ‘decommissioned’ from its first job, it’s not done too badly, but now it’s refusing to POST. > > I can’t do a detailed investigation of the failure remotely, but the machine is probably beyond economic repair, given its age. I will check about replacing it but that depends on a few factors so no promises there. > Some good news, my, uh, ‘dealer’ in decommissioned servers has a continuing supply of them, so a replacement machine can be sourced. However since I need to physically drive it to our office, it won't be running for a few months. Kind regards, James |
From: James T. <ja...@fl...> - 2024-08-30 08:23:09
|
> On 23 Aug 2024, at 17:06, merspieler <mer...@al...> wrote: > > Downloads are hosted on the same system as ukmirror which is why its down as well! Unfortunately, the (donated) Dell PowerEdge I was using to run UKMIrror etc seems to have expired. Given it’s had an entire second life after being ‘decommissioned’ from its first job, it’s not done too badly, but now it’s refusing to POST. I can’t do a detailed investigation of the failure remotely, but the machine is probably beyond economic repair, given its age. I will check about replacing it but that depends on a few factors so no promises there. In terms of functionality that needs to be covered, there’s three basic pieces: - acting as a TerraSync mirror: this is easily done by using some standard scripting from Torsten D (and unlike the next two, we still have one mirror for it) - generating the catalog & zips for FGAddOn and uploading them to Ibiblio: all the scripts for this are in FGMeta (by design), so this is easy to replicate, just needs space for a full SVN checkout of FGAddOn, and then the keys/permissions from Curt to access our Ibilbio account for FTP uploading. The actual bandwidth needs and CPU needs are low. The zips are also mirrored to split the bandwidth load on Ibiblio, but this is not required. (this runs from a cron job, daily I think, or maybe every 6 hours) - being the staging server for nightly/pre-release builds from Jenkins, to avoid people downloading direct and killing Gene’s upstream bandwidth. Each of these bits of functionality is independent, both in terms of the files used and the permissions / authentication needed. Kind regards, James |
From: Patrick C. <pat...@gm...> - 2024-08-29 21:29:37
|
I wonder if that might also be applied in areas around highways, which are sometimes elevated above the surrounding terrain by a few feet. -Pat On Thu, Aug 29, 2024 at 1:32 PM Curtis Olson <cur...@gm...> wrote: > I don't know the answer to your question about where to find the code, but > I do have a comment/suggestion. > > Recently I was playing around with how to smooth terrain for airport areas > while carrying the underlying sense of the terrain and blending the > smoothed surface in naturally with the larger terrain tile. This is > something I worked on long ago for FlightGear and did the best I could at > the time, but was never fully satisfied with the results. This time around > I tried a bunch of smoothing ideas, resampling, splines, butterworth > filters, revisited some old ideas, and nothing was satisfying. Then I just > did the dumbest and most simple thing ... the equivalent of treating the > terrain elevation posts as pixels and running a gaussian blur over that > area and it was perfect ... exactly what I had hoped to achieve going back > to the early days of FlightGear ... but for the last 20 something years I > had been overthinking the problem and diving into exotic surface smoothing > techniques and none of that worked out. So keep it simple whenever you can! > > On Thu, Aug 29, 2024 at 11:47 AM Wayne Bragg <wlb...@gm...> wrote: > >> Hi all, does anyone know where the old ws2.0 rounding scripts used to >> smooth the ws2.0 NLCD is located? Either if currently available or back in >> git history? >> >> Now that I understand QGIS and Python a bit better than I did back then, >> I would really like to see that code and if I can adapt any of the >> techniques used in it for the ws3.0 NLCD. >> >> While I have made some more improvements to the smoothing of NLCD for the >> WS3.0 raster's, it's still not where I want it. I am continuing to look for >> ideas how to finish it off. I'm currently using combinations resampling and >> r.neighbors, but the raster size is growing considerably, and the >> processing time is increasing exponentially. >> >> I think there is still a possibility of using resample and line data or >> higher res shapefiles to cut the raster cover types with, but I was having >> a difficult time getting it to work. I need to revisit it again though now >> that I have a better overall understanding of GIS processing. There are >> many little quirks I learned along the way that can be problematic until >> you become aware of them. >> >> Anyway, thanks for any help pointing me to those old scripts. >> >> Wayne >> _______________________________________________ >> Flightgear-devel mailing list >> Fli...@li... >> https://lists.sourceforge.net/lists/listinfo/flightgear-devel >> > > > -- > Curtis Olson > _______________________________________________ > Flightgear-devel mailing list > Fli...@li... > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > |
From: Curtis O. <cur...@gm...> - 2024-08-29 17:31:51
|
I don't know the answer to your question about where to find the code, but I do have a comment/suggestion. Recently I was playing around with how to smooth terrain for airport areas while carrying the underlying sense of the terrain and blending the smoothed surface in naturally with the larger terrain tile. This is something I worked on long ago for FlightGear and did the best I could at the time, but was never fully satisfied with the results. This time around I tried a bunch of smoothing ideas, resampling, splines, butterworth filters, revisited some old ideas, and nothing was satisfying. Then I just did the dumbest and most simple thing ... the equivalent of treating the terrain elevation posts as pixels and running a gaussian blur over that area and it was perfect ... exactly what I had hoped to achieve going back to the early days of FlightGear ... but for the last 20 something years I had been overthinking the problem and diving into exotic surface smoothing techniques and none of that worked out. So keep it simple whenever you can! On Thu, Aug 29, 2024 at 11:47 AM Wayne Bragg <wlb...@gm...> wrote: > Hi all, does anyone know where the old ws2.0 rounding scripts used to > smooth the ws2.0 NLCD is located? Either if currently available or back in > git history? > > Now that I understand QGIS and Python a bit better than I did back then, I > would really like to see that code and if I can adapt any of the techniques > used in it for the ws3.0 NLCD. > > While I have made some more improvements to the smoothing of NLCD for the > WS3.0 raster's, it's still not where I want it. I am continuing to look for > ideas how to finish it off. I'm currently using combinations resampling and > r.neighbors, but the raster size is growing considerably, and the > processing time is increasing exponentially. > > I think there is still a possibility of using resample and line data or > higher res shapefiles to cut the raster cover types with, but I was having > a difficult time getting it to work. I need to revisit it again though now > that I have a better overall understanding of GIS processing. There are > many little quirks I learned along the way that can be problematic until > you become aware of them. > > Anyway, thanks for any help pointing me to those old scripts. > > Wayne > _______________________________________________ > Flightgear-devel mailing list > Fli...@li... > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Curtis Olson |
From: Wayne B. <wlb...@gm...> - 2024-08-29 16:46:37
|
Hi all, does anyone know where the old ws2.0 rounding scripts used to smooth the ws2.0 NLCD is located? Either if currently available or back in git history? Now that I understand QGIS and Python a bit better than I did back then, I would really like to see that code and if I can adapt any of the techniques used in it for the ws3.0 NLCD. While I have made some more improvements to the smoothing of NLCD for the WS3.0 raster's, it's still not where I want it. I am continuing to look for ideas how to finish it off. I'm currently using combinations resampling and r.neighbors, but the raster size is growing considerably, and the processing time is increasing exponentially. I think there is still a possibility of using resample and line data or higher res shapefiles to cut the raster cover types with, but I was having a difficult time getting it to work. I need to revisit it again though now that I have a better overall understanding of GIS processing. There are many little quirks I learned along the way that can be problematic until you become aware of them. Anyway, thanks for any help pointing me to those old scripts. Wayne |
From: TheFGFSEagle <the...@gm...> - 2024-08-28 21:14:36
|
Yup, I've got a patch that built fine … gonna take it to the test bench tomorrow morning ! ;) Am Mi., 28. Aug. 2024 um 23:11 Uhr schrieb Stuart Buchanan < stu...@gm...>: > Hi Chris, > > On Sat, Aug 24, 2024 at 9:45 AM Chris Boylan wrote: > >> Oops. Sorry, I sent it from my mobile which is never the ideal method for >> late night email. Take 2: >> >> Mainly for Stuart? How do you (or does anyone) know how to change the >> code to specify the normal and reflection maps in the regional materials >> xml's? I can see buildings.png and buildings-lightmap.png in tags but it >> seems (Fahim spotted this) that the default normal and reflection will >> always be used independent of the regional random buildings texture >> (currently there are only 2 for the whole world) >> Chris >> > > The relevant code is simgear/scene/tgdb/SGBuildingBin.cxx lines 847 to 855 > which inherits from Effects/buildings.eff and then overrides the main > texture and lightmap texture with the regional material values. > > It should be pretty easy to add the normal and reflection maps as well - > the "plumbing" would be the same as the _lightMapName variable in the same > file. > > -Stuart > _______________________________________________ > Flightgear-devel mailing list > Fli...@li... > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > |
From: Stuart B. <stu...@gm...> - 2024-08-28 21:10:31
|
Hi Chris, On Sat, Aug 24, 2024 at 9:45 AM Chris Boylan wrote: > Oops. Sorry, I sent it from my mobile which is never the ideal method for > late night email. Take 2: > > Mainly for Stuart? How do you (or does anyone) know how to change the code > to specify the normal and reflection maps in the regional materials xml's? > I can see buildings.png and buildings-lightmap.png in tags but it seems > (Fahim spotted this) that the default normal and reflection will always be > used independent of the regional random buildings texture (currently there > are only 2 for the whole world) > Chris > The relevant code is simgear/scene/tgdb/SGBuildingBin.cxx lines 847 to 855 which inherits from Effects/buildings.eff and then overrides the main texture and lightmap texture with the regional material values. It should be pretty easy to add the normal and reflection maps as well - the "plumbing" would be the same as the _lightMapName variable in the same file. -Stuart |