[Flightgear-devel] Southwest Colorado Scenery - beta 3
http://www.stattosoftware.com/flightgear/Durango.zip I have hope as the file size actually went down in this build, but perhaps something else went awry. The only change is remapping Scrub to ShrubCover. Please let me know if this works. In other news, this is 3 square degrees of scenery - I have now generated data for 24 of the 28 square degrees which make up the state of Colorado, so when this build works, watch out. Yours John -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Southwest Colorado Scenery - beta 3
On Sun, 2011-11-20 at 23:03 -0800, J. Holden wrote:
http://www.stattosoftware.com/flightgear/Durango.zip
I have hope as the file size actually went down in this build, but
perhaps something else went awry.
The only change is remapping Scrub to ShrubCover. Please let me
know if this works.
In other news, this is 3 square degrees of scenery - I have now
generated data for 24 of the 28 square degrees which make up the state
of Colorado, so when this build works, watch out.
Yours
John
Hi John,
I have added it like this:
$ export FG_SCENERY=${FG_HOME}/statto/durango:${FG_SCENERY}
I have extracted the content of the ZIP file to
${FG_HOME}/statto/durango.
I think, there is still something wrong with the elevation data, because
just take a look:
http://flightgear.mxchange.org/pub/screenshots-master/fgfs-screen-031.png
http://flightgear.mxchange.org/pub/screenshots-master/fgfs-screen-032.png
Regards,
Roland
signature.asc
Description: This is a digitally signed message part
--
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader properties and dialog
On 20 Nov 2011, at 22:19, Vivian Meazza wrote: I can’t see any reason for the dependency between 3d clouds and Material Shaders, but Stuart might enlighten us. I don't think there is any particularly good reaon for the dependency, for either the trees or the clouds. I'm away at the moment but will look at uncoupling them later in the week. -Stuart -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader properties and dialog
In any case, the 3 frame rate killers here are 3d Clouds, Trees, and AITraffic. Compared to these, the effect on frame rate by shaders is trivial. Not for me. For me, the landmass effect at quality 3.5 (or 4? - I can't check without computer) is the killer - with nothing else enabled, it brings be down from 60 to 12 fps. 3dclouds can be adjusted as needed with the distance slider - having a similar slider for trees rather than having to hack materials.xml would be rather nice. Landmass being so expensive, I can 1) have landmass off completely to run other shaders at high quality setting (which is what I'm doing, so I always have to shift the snow line as high as possible to not get artefects because some terrain doesn't show snow now) 2) run all shaders at low quality, even those which run fine for me at high quality settings So I am very much in favour of a more detailed dialog which allows me to select quality levels of shaders individually (with the convention that quality zero is off). * Thorsten -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader properties and dialog
Stuart Buchanan wrote: I don't think there is any particularly good reaon for the dependency, for either the trees or the clouds. I'm away at the moment but will look at uncoupling them later in the week. Don't forget to pick up your virtual bottle of fine Whisky (note the spelling) afterwards, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders vs. frame rate;
Am 20.11.11 12:55, schrieb Anders Gidenstam: On Sun, 20 Nov 2011, ThorstenB wrote: Since some effects may be aircraft specific it might be useful to make the advanced dialog dynamic - one way would be to add a checkbox for each *-effect property found in /sim/rendering/shaders/ . Potentially scenery objects or MP aircraft might load some new effects (general or not) so the set of control properties might change (grow) at runtime. Cheers, Anders Me, personally: +10 for this proposal here from Anders (saying more to myself, its not a vote I know). Hm, getting such a useful menu, I hope this does not shift the impact from shaders to the GUI itself. (While designing such a menu in recent prehistoric GUI might look like a mission impossible, but I am sure we can get it.) Another question is probably where this inherits-from-system goes at the moment. I.e. 737-300 733reflect.eff inherits from reflect effects, but sets most values again/new, while i.e. 747-400 744reflect.eff makes really use of inheriting, changing only the values that have to be changed. I dont know if this could affect performance too, the 737-300 example ? 737-300 is a good example anyway, it inherits also from clouds. Does this mean switching off the cloud shaders switch contrails off too ? nameEffects/733reflect/name inherits-fromEffects/reflect/inherits-from nameEffects/contrail/name inherits-fromEffects/cloud/inherits-from nameEffects/contrail2/name inherits-fromEffects/cloud/inherits-from Cheers, Yves -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] How to draw customized stuff in the FG?
I have an application which use FlightGear as a displaying background. meanwhile, the purpose of the application is to draw something around the airport showcasing different effects influenced by natural environments. Now, it is difficult for me to find the entry to start out to do the task in hundreds of FG's folds and files. Does anyone have some tutorials to complete the mission? At the very start, i just want to illustrate a cube or a sphere around some tall buildings like towers around the airport. Need your help -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader properties and dialog
Thanks for the feedback/ideas so far! Hope to get some more throughout the week. Vivian wrote: This proposal doesn’t seem to address the problem namely that 3d clouds and Random Vegetation (trees) require Material Shaders to be checked in the gui It does, partly. As I said, the 3D clouds require a source edit (which I'm incapable of), so those are still shader dependant, but the trees are uncoupled by my merge. Do note that there is bug #494 that makes it appear broken. Vivian wrote: the Shader options are not greyed out when the slider is at 0 (shaders OFF), thus it might be inferred that shaders are active when they aren’t Valid point. Will take care of that. Vivian wrote: the effect on frame rate by shaders is trivial Allowing people to switch individual shaders on/off isn't just a matter of framerates. On my old computer for example, I am unable to use the bumpmap shader. Most other shaders work fine though. The current dialog forces me to disable all shaders, just because that single one doesn't work on my machine. Doesn't work as in breaks my aircraft in hunderts of pieces. Vivian wrote: It actually breaks the water shader effect In what way? As far as I can see it works fine here... Vivian wrote: The Snow-line slider has been moved to Global weather which implies that it is: a. weather related b. only applicable to Global Weather. Neither is true – it is an arbitrary value, and it applies to all conditions. Right. The snow line is a rather strange thing. I agree that it's better of in the rendering dialog for now (especially because it also works with local-weather). Will move it back. Stuart wrote: I don't think there is any particularly good reaon for the dependency, for either the trees or the clouds. I'm away at the moment but will look at uncoupling them later in the week. See my comment to vivian about the trees. Would be nice if you could look at the clouds! Thorsten wrote: 3dclouds can be adjusted as needed with the distance slider - having a similar slider for trees rather than having to hack materials.xml would be rather nice. +1 and a density slider as well. I'll see if I can update the merge-request today. Cheers, Gijs -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader properties and dialog
On 21 Nov 2011, at 13:01, Gijs de Rooy wrote: Thanks for the feedback/ideas so far! Hope to get some more throughout the week. Just to add my opinion (since this was partly my suggestion) My key concern is that most people (even developers) don't care about 'material shaders', so long as things work, and they get sufficient FPS. They want a control to give them more FPS if things are slow! Hence the desire to have the clouds and trees be de-coupled from the 'big global shader switch' This raised the point, that the current checkboxes are also bad, because they combine several shaders. What I'd prefer, then, is a single quality slider (where 0 = 'no shaders'), and then an advanced / debug dialog, as already suggested by many other people, where I can toggle each individual shader by hand, when one causes problems - which does happen during shader development :) (And it would be really good if this list included aircraft-specific shaders, because sometimes an MP aircraft loads, and I get render errors from OSG due to a bad shader) Ideally (from a UX point of view), most users would only ever touch the slider - no additional parameters for snow line / tree density / etc. However, that's something that can be improved over time. James -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader properties and dialog
Hi Gijs I would be very happy with a reflect checkbox/property once. Just to remember issue #295 (stalled, why?), this one is still broken with my ati on osx, osg trunk. It is not broken at all, but it still produce this renderbin draw errors filling my fgfs log to a huge file running flightgear. I started to avoid aircrafts using this shader, but now I am runnung into the same problems when I start in multiplayer mode with material shaders enabled. Cheers, Yves Am 21.11.11 14:01, schrieb Gijs de Rooy: Thanks for the feedback/ideas so far! Hope to get some more throughout the week. Vivian wrote: This proposal doesn’t seem to address the problem namely that 3d clouds and Random Vegetation (trees) require Material Shaders to be checked in the gui It does, partly. As I said, the 3D clouds require a source edit (which I'm incapable of), so those are still shader dependant, but the trees are uncoupled by my merge. Do note that there is bug #494 that makes it appear broken. Vivian wrote: the Shader options are not greyed out when the slider is at 0 (shaders OFF), thus it might be inferred that shaders are active when they aren’t Valid point. Will take care of that. Vivian wrote: the effect on frame rate by shaders is trivial Allowing people to switch individual shaders on/off isn't just a matter of framerates. On my old computer for example, I am unable to use the bumpmap shader. Most other shaders work fine though. The current dialog forces me to disable all shaders, just because that single one doesn't work on my machine. Doesn't work as in breaks my aircraft in hunderts of pieces. Vivian wrote: It actually breaks the water shader effect In what way? As far as I can see it works fine here... Vivian wrote: The Snow-line slider has been moved to Global weather which implies that it is: a. weather related b. only applicable to Global Weather. Neither is true – it is an arbitrary value, and it applies to all conditions. Right. The snow line is a rather strange thing. I agree that it's better of in the rendering dialog for now (especially because it also works with local-weather). Will move it back. Stuart wrote: I don't think there is any particularly good reaon for the dependency, for either the trees or the clouds. I'm away at the moment but will look at uncoupling them later in the week. See my comment to vivian about the trees. Would be nice if you could look at the clouds! Thorsten wrote: 3dclouds can be adjusted as needed with the distance slider - having a similar slider for trees rather than having to hack materials.xml would be rather nice. +1 and a density slider as well. I'll see if I can update the merge-request today. Cheers, Gijs -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fixing fgfs-construct crashes
Hello Maxime, I had also noticed more instances of the grey poly with clipper than GPC. As an experiment, on Saturday, I spent several hours gutting fgfs-construct down to the bones. Although the grey polys didn't disappear completely, I got Clipper producing as good results as GPC did. The areas I still see problems are on tile boundaries, and osm roads. I'm at work right now, but will download your tarball tonight to if it's useful. I have also been trying to reproduce the issue on the simplest possible case. This could save some time. I think the grey polys are the default material. I was going to verify this tonight by assigning bogus materials to some well known land-class. I think the solution to this whole issue is to bring fgfs-construct .btg generation closer to how the genapt works - keeping the material information around with each poly through the clipping process. This is a necessary requirement to be able to generate good texture coordinates for linear data as well. I think I will work on this in parallel with the texture mapped roads / streams. Pete On Sun, Nov 20, 2011 at 4:31 PM, Maxime Guillaud m...@mguillaud.net wrote: Hi Peter, Any news on the topic of the gray polygons ? I have been experimenting more with this, and I can confirm that it occurs only when clipper is enabled. If this can help, I have isolated a simple dataset (much simpler than last time) that triggers the bug. It is just one landmass polygon with a handful of vertices. This data is here: http://www.mguillaud.net/fg/2794338/2794338.tgz (I also include the fitted elevation, since I don't know if this data interacts with the bug). The bug occurs with fgfs-construct built from the code in papillon's tg850 branch (i.e. with clipper), with or without my attempts at adjusting the epsilon constants that can be found here and there in the code. I run fgfs-construct --work-dir=[..] --output-dir=[...] --tile-id=2794338 SRTM-3 Landmass , and the gray area is around -9.40025/51.5005 degrees. Any insight on this issue is appreciated... Maxime On Sat, 12 Nov 2011 21:52:56 -0500 Peter Sadrozinski psadrozin...@gmail.com wrote: I have verified that the problem lies in using clipper. Using the same simple data with GPC works. It appears clipper can sometimes produce clockwise winded polys. I'm working on a fix now. Pete On Sat, Nov 12, 2011 at 7:59 PM, Peter Sadrozinski psadrozin...@gmail.comwrote: Hi Martin, I've been reluctant to move to the official repository mostly because of very little understanding of GIT. I'm a bit more confident, now, so I don't see it as a big problem. I think most of the work we are doing (alternate clipping library, 850 format) should be considered experimental, however. I'm pretty sure we want to keep the main branch concentrated on fixing problems with detailed landclass. We seem to be breaking terragear pretty good as of late :) Maxime: I have an experiment for you to try - could you take the UFO under those grey sections of scenery, and look up at them? I think the normals have swapped. Chris mentioned this happening with the skirt around the airport, and I hadn't seen it until a recent update. Looks like something broke recently. Pete On Sat, Nov 12, 2011 at 2:38 PM, Martin Spott martin.sp...@mgras.net wrote: Hi Maxime and others, Maxime Guillaud wrote: You can find my code here [...] I'm just starting to recover from a couple of _really_ tight days (including a nice PostgreSQL conference PGConf.DE where I gave a talk about our geodata collection and in-database processing), therefore I'm not yet ready to provide comprehensive responses. Anyhow there's one point I'd like to emphasize: I know it's really cool to maintain private source repositories ;-) but for increasing the overall success of building FlightGear scenery I'd think it would be really beneficial to keep the various development efforts in close relation and sync. Thus I'd invite everyone who's serious about improving the TerraGear toolchain to create a branch in the main repository in order to develop their specific features/changes there - not only but also because this would simplify tracking of the various changes. The former terragear-cs main repository at MapServer was already open to (almost) everybody who asked and now that it's moved over to Gitorious there's really no more excuse not to create branches inside the main repo :-) Best regards, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now
Re: [Flightgear-devel] Shaders vs. frame rate;
Spoke too soon. The trees look great, but the frame rate hit makes it unusable (from 30-35 to 2-4) even with the other shaders disabled. On Sun, Nov 20, 2011 at 5:49 PM, Gary Carvell gary.carv...@gmail.com wrote: Thank you! I haven't had seen trees in FlightGear for ages (can't run with shaders). I didn't realize the trees were supported at all without shaders. Could that fix be applied automatically so the trees are visible whether shaders are on or off? Gary On Sun, Nov 20, 2011 at 5:52 AM, Gijs de Rooy gijsr...@hotmail.com wrote: Hi all! Martin wrote: Does anyone know how to have the random trees without all this ? In Effects/trees.eff, comment out/remove line 23. !--property/sim/rendering/shader-effects/property-- If you would like to use the dialog to toggle the trees, you'll also need to edit gui/dialogs/rendering.xml and comment out line 200 to 202: !--enable property/sim/rendering/shader-effects/property /enable-- The Material Shaders options was meant (as far as I understand it) to disable all shader stuff with a single click. When the checkbox is checked, one an finetune what shaders need to be enabled, via the other checkboxes. The problem right now is that some of the shaders (eg. the reflection stuff and lightmap) only depend on that single Material Shaders property. It would be better if every single shader can be en/disabled via its own property/checkbox. But then we might end up with a pretty large rendering dialog... Cheers, Gijs -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader properties and dialog
On Mon, 21 Nov 2011, Gijs de Rooy wrote: Aircraft shaders are supposed to appear on the list one day, but Emillian is currently combining most (if not all) of the aircraft-shaders in one file. It's probably better to wait on him before we do something about aircraft shaders. Or we define the interface we want to have between the shaders and the dialog now so Emillian can use it for his combined shader and others for their own shaders (e.g. I don't think the very aircraft specific balloon envelope shader will be part of the combined aircraft shader :). Someone recently mentioned that he'd like to be able to set the quality level of each shader, which makes quite good sense even if not all shaders have different quality levels - but for those level 0 is off and anything above would be on. If we could presume that no shader will have more than, say, 5 quality levels a suitable interface could be that each shader creates a /sim/rendering/shaders/foo-effect-quality property. Though, if we'd want to go fancy we could decide on (e.g.) /sim/rendering/shaders/foo-effect/quality /sim/rendering/shaders/foo-effect/max-quality (assuming 0 is the minimum/off) /sim/rendering/shaders/foo-effect/description (useful for the dialog) Making a dialog that dynamically displays a slider for all /sim/rendering/shaders/foo-effect-quality properties should not be a problem. E.g. the fuel and payload dialog displays a variable number of fuel tanks and payload items based on the properties present in the tree. Cheers, Anders -- --- Anders Gidenstam WWW: http://gitorious.org/anders-hangar http://www.gidenstam.org/FlightGear/ -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Southwest Colorado Scenery - beta 3
Roland, thank you for the screenshots! From your screenshots it looks to me as if the ShrubCover worked this time around as this was the cause of the null-elevation ocean areas in the first two builds. The other elevation errors, do they still drop down to zero elevation as well? If so, then there is a problem with another land cover type. I fear it's an error with the SRTM data, though. Cheers John -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Southwest Colorado Scenery - beta 3
It looks like there are a number of holes in the SRTM-1 data. I don't know if GRASS can export HGT files using r.out.binary so I'm not sure if I can fill nulls, so I'll have to go back and re-generate the scenery using SRTM-3 data. Cheers John -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Southwest Colorado Scenery - beta 3
On Sun, 20 Nov 2011, J. Holden wrote: http://www.stattosoftware.com/flightgear/Durango.zip I have hope as the file size actually went down in this build, but perhaps something else went awry. The only change is remapping Scrub to ShrubCover. Please let me know if this works. In other news, this is 3 square degrees of scenery - I have now generated data for 24 of the 28 square degrees which make up the state of Colorado, so when this build works, watch out. You'll need to get a car model set up so you can race down Pike's Peak. :) g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. 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. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] various databases +- ground truth ;
HB-GRAL wrote: Thank you very much for providing this service ! These days I am working for a small publication for an organisation. Just found this image here to have in the publication: http://maptest.fgx.ch/screens/ksfo.png Oh my, what a crappy Scenery, all the airport boundaries are just plain wrong and the field elevations are at minimum 10 feet off. Must have been a group of dumb jerks building this Scenery, without the slightest idea about accuracy in aviation. Fix it ! Now !! ;-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader properties and dialog
Am 21.11.11 22:08, schrieb Arnt Karlsen: On Mon, 21 Nov 2011 14:55:34 +0100, HB-GRAL wrote in message 4eca5856.6060...@sablonier.ch: Hi Gijs I would be very happy with a reflect checkbox/property once. Just to remember issue #295 (stalled, why?), this one is still broken with my ati on osx, osg trunk. It is not broken at all, but it still produce this renderbin draw errors filling my fgfs log to a huge file running flightgear. I started to avoid aircrafts using this shader, but now I am runnung into the same problems when I start in multiplayer mode with material shaders enabled. ..you have a commandline suggestion I can try to try reproduce this bug? Hi Arnt Starting i.e. b29 and Material Shaders enabled. We can also share the issue in my log, I start with c172p at KSFO 10L and you take the b29 at 10R. Cheers, Yves -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Mpserver07 temporarily down
Hi all, In case someone may have noticed, mpserver07 is down. We lost one of our cable modems, and the ISP cannot get someone out here until tomorrow. When we went with a static IP address in 2010, the ISP gave us an additional modem unit. Now we have two running, and apparently one of them has failed and their static IP system will not work with just the one. But the online technician couldn't even access the main unit, so they have to send someone out tomorrow to attend to it. But since we have a business account (needed for the static IP), they will try to get here within 24 hours. So with any luck, it will be fixed tomorrow and the server will be back online. I apologize for any inconvenience this might cause. TB -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
