Re: [Flightgear-devel] [SPAM] No sound under Ubuntu 12.04
Hi Ignacio, My old .alsoftrc was forcing everything to be played through OSS (I guess that used to make sense back when OSS was the only reliable option, but now OSS seems to be broken). I simply deleted the .alsoftrc file from my home directory. Now OpenAL sees all the available options, and I get the following list when I run fgfs --show-sound-devices 0. "PulseAudio Default" 1. "Flight Sound X Analog Stereo via PulseAudio" 2. "Built-in Audio Analog Stereo via PulseAudio" 3. "ALSA Default" 4. "HDA ATI SB [VT1708S Analog] (hw:0,0) via ALSA" 5. "HDA ATI SB [VT1708S Digital] (hw:0,1) via ALSA" 6. "HDA ATI SB [VT1708S HP] (hw:0,2) via ALSA" 7. "Flight Sound X [USB Audio] (hw:2,0) via ALSA" 8. "PortAudio Default" 9. "No Output" (the "Flight Sound X" is a USB audio adapter for aviation headsets). Maxime On Thu, 24 May 2012 16:54:33 -0400 Ignacio Bravo wrote: > > Maxime, > > Can you please provide more details on how you solved this issue? I have also > upgraded > to Ubuntu 12.04 and my sound is gone in FG. I checked my home directory and I > don't > have any .alsoftrc directory there. IB > > > > Thanks to all for your answers and the hint about checking the OpenAL > > configuration - > > the problem was caused by a stale .alsoftrc config file that had persisted > > in my home > > directory across the OS upgrade. Sorry for the noise... > > > > > > > > You OpenAL intsallation might not be properly configured, check your > > > /etc/openal/alsoft.conf > > > and/or > > > ~/.alsoftrc > > > files. (If you have OpenAL-soft. The location in /etc may vary with > > > the distribution.) > > > > > > On my system I have > > > anders@sleipner:~$ cat ~/.alsoftrc > > > format = AL_FORMAT_STEREO16 > > > cf_level = 2 > > > drivers = alsa > > > [alsa] # ALSA backend stuff > > > device = plug:dmix > > > capture = plug:dsnoop > > > [wave] > > > file = /dev/null > > > > > > to make OpenAL use ALSA. > > > > > > Cheers, > > > > > > Anders > > > > > > -- > > sent from my armchair > > > > -- > > Live Security Virtual Conference > > Exclusive live event will cover all the ways today's security and > > threat landscape has changed and how IT managers can respond. Discussions > > will include endpoint security, mobile security and the latest in malware > > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > ___ > > Flightgear-devel mailing list > > Flightgear-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- sent from my armchair -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [SPAM] No sound under Ubuntu 12.04
Thanks to all for your answers and the hint about checking the OpenAL configuration - the problem was caused by a stale .alsoftrc config file that had persisted in my home directory across the OS upgrade. Sorry for the noise... Maxime On Thu, 24 May 2012 10:13:31 +0200 (CEST) Anders Gidenstam wrote: > On Thu, 24 May 2012, Maxime Guillaud wrote: > > > What I find suspicious is that no sound devices at all are detected, > > although I > > believe I have ALSA and Pulseaudio properly installed (including -dev > > packages). > > > > Any clues about what is going on and how to further debug this ? > > You OpenAL intsallation might not be properly configured, check your > /etc/openal/alsoft.conf > and/or > ~/.alsoftrc > files. (If you have OpenAL-soft. The location in /etc may vary with > the distribution.) > > On my system I have > anders@sleipner:~$ cat ~/.alsoftrc > format = AL_FORMAT_STEREO16 > cf_level = 2 > drivers = alsa > [alsa] # ALSA backend stuff > device = plug:dmix > capture = plug:dsnoop > [wave] > file = /dev/null > > to make OpenAL use ALSA. > > Cheers, > > Anders -- sent from my armchair -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] No sound under Ubuntu 12.04
Hi all, I am trying to compile FG under Xubuntu 12.04 using Brisa's script (version 1.31). At first sight the compilation went fine, however sound is not working: when I run fgfs I get the following error and no sound: AL lib: oss.c:169: Could not open /dev/dsp: No such file or directory Error: Audio device not available, trying default AL lib: oss.c:169: Could not open /dev/dsp: No such file or directory Error: Default Audio device not available. (and indeed there is no /dev/dsp device on my machine). A closer look at the compilation log (http://www.mguillaud.net/fg/compilation_log_20120523.txt) reveals that PLIB fails to compile due to some incompatibility with the OSS interface (the compilation script does not stop, though). Then I tried to build OSG, Simgear and FGFS against the PLIB version from the Ubuntu repositories instead - same result. Compilation goes fine, but running fgfs with "--show-sound-devices" produces the same errors as above, and then: unknown provided by unknown No. Device What I find suspicious is that no sound devices at all are detected, although I believe I have ALSA and Pulseaudio properly installed (including -dev packages). Any clues about what is going on and how to further debug this ? Maxime -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fixing fgfs-construct crashes
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 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 > wrote: > > > 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 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 > >> http://p.sf.net/sfu/rsa-sfdev2dev1 > >> ___ > >> Flightgear-devel mailing list > >> Flightgear-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/flightgear-devel > >> > > > > -- sent from my armchair -- 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
Hi Martin, Martin Spott wrote: > 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. Same as Peter, I was reluctant to do it so far since I have no prior experience with Git, and given the complexity of the tool, the probability of breaking something is just too high. > 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. Point well taken ! Maxime -- sent from my armchair -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fixing fgfs-construct crashes
Peter Sadrozinski wrote: > I would experiment with removing the code that removes the node. You'll be > trading one error for another, but it may help track this down. Actually, this is exactly what one of my commits is doing: https://gitorious.org/~maximeguillaud/papillon81/maxime-terragear-cs/commit/81a78602e09b67edd58b2cedacf09079239b0177 Bad nodes are detected but not removed. I put a minimal set of data that triggers the bug online here: http://www.mguillaud.net/fg/2794354/polygons-2794354.tgz Download it and run fgfs-construct with the following arguments: fgfs-construct --work-dir=. --output-dir=/storage2/work_europe/tmp/output --tile-id=2794354 Landmass SRTM-3 Road6.test You can have a look at what I get when I run my modified version of construct on this data here: http://www.mguillaud.net/fg/2794354/log-2794354.txt > 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. >From below it looks... black. If you want to take a look for yourself, here >are the terrain files: http://www.mguillaud.net/fg/2794354/terrain-2794354.tgz Just navigate to 51.751 lat/-9.333 lon. Maxime -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Fixing fgfs-construct crashes
James Turner wrote: > > Onwards with fixing the fgfs-construct crashes! I have had pretty good luck building complex scenery with a modified version of fgfs-construct. Here is what I did: Following advice by Peter Sadrozinski here on the list, I started from the code in papillon's terragear repo where GPC is replaced by clipper. I then applied a few patches, reducing various "epsilon" constants in the code which I think were too loose and caused inconsistencies in the clipper. You can find my code here (in the branch "custom_scenery_clean"): https://gitorious.org/~maximeguillaud/papillon81/maxime-terragear-cs/commits/custom_scenery_clean More specifically, the patches relevant to fgfs-construct are in commits 81a78602e09b67edd58b2cedacf09079239b0177 and 8601f66cf7cf00ffda38f57cee77ae991c42dab8. The second one uses the constant "SG_EPSILON" defined in Simgear. I reduced the value of this constant in simgear/constants.h: #define SG_EPSILON (DBL_EPSILON*10) (Note that I am using a different installation of Simgear for terragear and for fgfs, so I do not know if this change would have consequences on fgfs). With the above settings, I was able to process large amounts of scenery without any crash. So far I have tried a band covering Europe between 12 and 14 degrees East, i.e. going through Sicily, Italy, the Austrian Alps, the Czech Republic and Germany, Sweden and Norway, up to 69 degrees North. My scenery includes detailed terrain (fitted with 15m accuracy), the CORINE land cover, and OSM rail and roads up to the secondary network. The latest update in the BTG format seem to have fixed the "swirlies". You can see a few screenshots here: http://www.mguillaud.net/fg/scenery-gallery/ The only problem that prevents me from calling it final and generating custom scenery for all of Europe can be seen in the last screenshot: http://www.mguillaud.net/fg/scenery-gallery/fgfs-screen-008.png Sometimes, one polygon will have the correct shape but the material is wrong, and it appears all gray. This seems to occur only around roads. Any advice on this is appreciated. I had a chat with Martin Spott (hi Martin !) a few days ago and he mentioned that the bug is known, and proceeded to explain it to me, however I have not been able to relate his explanation to the code in fgfs-construct. I can provide a minimal set of files (3 roads) that trigger this problem, in case anyone can help with the debugging. Maxime -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
On Sat, 15 Oct 2011 08:53:45 + (UTC) Martin Spott wrote: > I think the only solution is to make GPC obsolete - either by replacing > GPC by something different but functional equivalent or "simply" (TM ;-) > by avoiding any polygon clipping in 'fgfs-construct' overall. For what it's worth... I am currently trying to generate custom scenery for all of Europe based on Corine + OSM data (similar to what I did for France some time ago: http://wiki.flightgear.org/Custom_France_Scenery), and I am also getting lost in the intricacies of fgfs-construct and crashes in GPC. I managed to make a few changes in the code that improved the situation: - conversely to what is suggested in README.gpc, I did not change the GPC_EPSILON constant (left it defined as DBL_EPSILON) - I completely disabled the removal of so-called "bad nodes" in poly_support.cxx However I did a lot of preprocessing of the data in Postgis before feeding it to fgfs-construct, hopefully removing the need for the hacks mentioned above. So far this configuration has proved very stable for me, and I was able to generate more than a hundred of 1x1 deg tiles without any crash. So far the only problems that remain seem to be located around the 0deg longitude area - there, I am still running into the problem of the NULL pointer in the GPC merge_right(). What I noticed so far lends me to think that there is a lot of code in terragear that is supposed to deal with imperfect input data - and should maybe be deactivated. Can anyone shed some light on what the "bad node" detection is supposed to achieve, for instance ? Also, the suggested increase of GPC_EPSILON is bound to introduce inconsistencies in the geometric routines - much better to clean up the input data). Unfortunately, there are many places in terragear where some arbitrary "epsilon" constants are hiding with unexpected effects - just run "grep -r '0\.' terragear-cs" and count the matches if you don't believe me. So maybe the problem is not in GPC after all but in what we feed it Maxime -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Custom textures and landtypes
Hi Cullam You want to look into src/BuildTiles/Clipper/priorities.hxx and priorities.cxx. Note that if you add types to materials.xml as well, the resulting scenery will not work properly with the "stock" FG. best, Maxime cullam Bruce-Lockhart wrote: > Hello, once again. Sorry to be posting so many questions on several subjects > sequentially. But things are going well, so I'm constantly running into new > things that I need to adapt and understand. > > I've created some customized textures for my scenery. They've been added to > the materials.xml file. However, I can't yet use them when running > fgfs-construct, as they aren't on the list that terragear is searching for in > the case switch. I know that I can easily implement them by overwriting some > of the normal terrain types, but I'd rather do it right and have them > properly named, not to mention still having all default terrain types still > available to me. > > What files do I need to amend this list in? I've been going through code, > trying to trace it all out, but I haven't managed to find it yet. I know > there's a case switch in BuildTiles/main.cxx that picks one of 25 cover > types. But those read an integer, and translate it to a string. I'm not sure > where I need to add my own textures to the integer list to be translated. > > I might even be investigating the wrong thing entirely. So the question is: > once I've created custom textures, and added them to the materials.xml file, > what else do I need to do to allow them to be used in fgfs-construct? > Thanks folks! > -cullam > > > __ > Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your > favourite sites. Download it now > http://ca.toolbar.yahoo.com. > > -- > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Hardware bottleneck for building scenery
Hi Cullam, Curtis Olson wrote: > Just a real quick reply here ... there is some code setup so the > process will kill itself if it runs longer than some period or > consumes too much memory. This was setup because some data cases > would blow up and lead to infinite loops and infinite memory expansion > (within some of our external libraries.) > > You may want to eliminate this code or expand the thresholds. I ran into the same issue when building my France scenery. The code that Curt mentioned is in terragear-cs/src/BuildTiles/Main/main.cxx, search for "setrlimit" and modify the maximum CPU time allowed to the process. As a less "hackish" solution, you might want to try the client-server architecture of terragear which doesn't run into this problem (a new process is respawned for each tile). A basic how-to can be found in section 4 of this page: http://www.terragear.org/docs/scenery-tutorial/fg-scenery-tutorial.html The client/server architecture brings you the additional benefit that you can get a speed-up on multicore machines by running one client per CPU core. hope this helps Maxime -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Which material to use for high-altitude
Martin Spott wrote: Maxime Guillaud wrote: I'd be happy to contribute to this. I will start by making available a write-up of my mapping between the Corine classes and the FG materials, since I spent quite some time on it. Oh yes, please. Feel free to re-use as much as you like from my schema as well as to propose changes wherever you think they fit, Martin. Hi Martin, all, I created a page on the wiki which summarizes the mapping between CORINE and FG materials that I used for the custom France scenery. It can be found here: http://wiki.flightgear.org/index.php/CORINE_to_materials_mapping . Hope this helps. Maxime -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Which material to use for high-altitude rocks in
Hi Martin, Martin Spott wrote: > At the current state, the latest release packages don't "know" about a > rock surface (material) type and therefore the users of release > packages will be unable to deal with Scenery which contains the such a > type. Thus, in order to ship proper "rock" surface with the Scenery, > users would not only have to add the respective texture to their setup > but also to modify the 'materials.xml" file in order to map the type to > the respective texure. > I understand this argument perfectly. That is why I am trying to have a Rock material available as soon as possible, because I think I might want to use it in the future ;) In the meantime, my latest scenery release only uses the default materials. > Adding new/more/missing land cover types to the Base Package is > certainly fine for the development tree - which obviously lacks a > representation for quite a few types - but leads to difficulties for > those who prefer to stick to a release package. Therefore I'd be happy > to get you involved into developing an extended set of cover types (for > example on the basis of CORINE) together with the respective textures > and to prepare a nice collection for the next release. > I'd be happy to contribute to this. I will start by making available a write-up of my mapping between the Corine classes and the FG materials, since I spent quite some time on it. Best regards, Maxime -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Which material to use for high-altitude rocks in scenery
Hi all, I am in the process of creating custom scenery for France (see http://wiki.flightgear.org/index.php/Custom_France_Scenery), and I am looking for advice regarding which material to use for rocky areas in mountains. I think that the rest of the scenery looks quite fine, but this particular point has been bugging me for a while. Currently, I am mapping the rocky areas (Corine landclass 332, "bare rocks") to the Dirt material. The effect on mountain tops is not very pleasing, as can be seen here: http://www.mguillaud.net/fg/fgfs-screen-022.jpg No other material seems to do the trick, however. In my opinion, the right way would be to add a "Rock" material to the materials.xml file, and to create the appropriate texture (this is in line with the information there : http://wiki.osgeo.org/wiki/LandcoverDB_CS_Detail, where a cs_rock type is defined). Is there any dev willing to implement this new Rock material (maybe with a temporary texture ?). A second question: looking at the screenshot linked above, not all materials currently support the (very nice) snow effect implemented through the shaders, which looks a bit odd on mountains with rich landcover information. Any hope to generalize this effect to all terrain textures ? I'm looking forward to your advice ! Maxime -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Newsletter August 2009
Martin Spott wrote: > I'm well familiar with reading French - thanks for the pointer ! > Apparently these use terms are quite different from those on the EEA > site. This really looks like we should incorporate French CORINE data > into our collection of land cover data for the World Scenery. I'll be > preparing an appropriate setup. > That would be great ! > The full license text is a bit more precise about 'similar' > 4.b) "You may distribute, publicly display, publicly perform, or > publicly digitally perform a Derivative Work only under the terms of > this License, a later version of this License with the same License > Elements as this License, or a Creative Commons iCommons license that > contains the same License Elements as this License". > > To my understanding (as well as the understanding of quite a few OSMers > to whom I've been talking about this issue) this doesn't permit to > distribute OSM-derived Scenery under the GPL. On the other hand, some > of the content which makes it into our Scenery is licensed under the > GPL. > ok. Meanwhile, my understanding is that I can distribute my OSM-based scenery under the Attribution-Share Alike Creative Commons license without problems. Correct ? cheers, Maxime -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Newsletter August 2009
Martin Spott wrote: > People have probably started wondering why those who claim to be busy > building and distributing World Scenery for FlightGear didn't jump on > the same track, using CORINE and OSM data as input for the World > Scenery, like Jake did with 'his' Innsbruck Scenery (as well as a > French fellow who's been building CORINE/OSM-based Scenery for Grenoble > and a few other places in France). (here is the french fellow jumping in the thread) > The background is pretty simple - our 'excuse' ;-) for not doing so: > Technically it's not a big deal to build FlightGear Scenery with CORINE > and OSM (and we've already done so for 'private' samples). Yet we have > to face the fact that neither of the two datasets ships under a License > which allows the distribution of Scenery under the GPL-affected > FlightGear umbrella (I'll leave the boring details out). > Thanks for those explanations, Martin. However, let me point out that the license for the CORINE data for France seems pretty flexible to me. (Note that this is true for France only, and that each country distributes their data with their own license terms.) The conditions of use can be found here: http://www.ifen.fr/clc/CORINE_Land_Cover_-_Condition_Utilisation.htm (in french only, sorry). This is not legalese, but states explicitly that any use (including re-distribution and commercial exploitation) is allowed, as long as it comes with a mention of the source (it doesn't say where the source must be mentioned). Is this incompatible with our goals ? As for the OSM data, their Creative Commons license (http://creativecommons.org/licenses/by-sa/2.0/) permits redistribution under the "same or similar" license. Could this not be the GPL ? Sorry for asking this, as I feel that those topics must have been discussed at length already, but I could not find any information in the archives or on the wiki. Maxime -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] shape-decode crash
Hi all,
I tracked down my problem with shape-decode to a case of uncaught
parallel lines in the function getIntersection in util.cxx. The
resulting computed intersection point was obviously very distant,
creating the strange coordinates that Curt noticed.
I fixed it by raising the "epsilon" constant from 1e-14 to 1e-12 (patch
attached).
Regards,
Maxime
Maxime Guillaud wrote:
Curtis Olson wrote:
A bucket coordinate of -593:2 suggests that this shapefile may contain
some bogus data. (or there could be a bug leading up to this) but I
believe the portion prior to the ":" represents a whole degree
coordinate of the bucket, so this should range from -180 to +179 for
latitude and -90 to +89 for longitude. -593 is completely outside of
possible reality. So the question is, is this a problem with the
shapefile data, or some problem processing the data in the
shape-decode code.
Regards,
Curt.
Thanks for spotting this, Curt ! Looking at the output of shape-decode,
it looks like the data read from the shapefile is reasonable:
Point 5 (0.609977, 46.997)
Point 6 (0.605342, 46.9964)
Point 7 (0.601051, 46.9955)
However, in the following processing steps the coordinates for point 7
appear wrong:
point = 6
0.605333, 46.9964, 0 - -2828.93, -570.523, 0
The relevant excerpt of the log is here: http://www.mguillaud.net/fg/log2
Anyone familiar with the internals of shape-decode (I am not) can
comment on this ?
Regards,
Maxime
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--- terragear-cs/src/Lib/Geometry/util.cxx.orig 2009-08-06 09:46:41.0 +0200
+++ terragear-cs/src/Lib/Geometry/util.cxx 2009-08-07 22:14:43.0 +0200
@@ -24,7 +24,7 @@
const Point3D &p2, const Point3D &p3,
Point3D &intersection)
{
-const double my_eps = 0.01;
+const double my_eps = 0.0001;
double u_num =
((p3.x()-p2.x())*(p0.y()-p2.y()))-((p3.y()-p2.y())*(p0.x()-p2.x()));
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] shape-decode crash
Curtis Olson wrote: > > A bucket coordinate of -593:2 suggests that this shapefile may contain > some bogus data. (or there could be a bug leading up to this) but I > believe the portion prior to the ":" represents a whole degree > coordinate of the bucket, so this should range from -180 to +179 for > latitude and -90 to +89 for longitude. -593 is completely outside of > possible reality. So the question is, is this a problem with the > shapefile data, or some problem processing the data in the > shape-decode code. > > Regards, > > Curt. Thanks for spotting this, Curt ! Looking at the output of shape-decode, it looks like the data read from the shapefile is reasonable: Point 5 (0.609977, 46.997) Point 6 (0.605342, 46.9964) Point 7 (0.601051, 46.9955) However, in the following processing steps the coordinates for point 7 appear wrong: point = 6 0.605333, 46.9964, 0 - -2828.93, -570.523, 0 The relevant excerpt of the log is here: http://www.mguillaud.net/fg/log2 Anyone familiar with the internals of shape-decode (I am not) can comment on this ? Regards, Maxime -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] shape-decode crash
Hi all,
shape-decode has been crashing on me for a certain shapefile and I can
not figure out why. I am using terragear-cs downloaded today from the
GIT repository. The rest of the toolchain runs fine.
shape-decode runs for a while and stops with the following error:
[...]
distance = 239.828
0.623843, 46.9914, 0
distance = 7.9
0.626076, 46.9898, 0
min = -2930.42, -592.671, 200 max = 0.62615, 46.997, -200
Bucket min = -180:0, -593:2
Bucket max = 0:2, 46:7
polygon spans tile boundaries
dx = 722 dy = 5117
terminate called after throwing an instance of 'sg_exception'
Aborted
A run under gdb yielded the following:
(gdb) run --max-segment 500 --line-width 6
/storage1/flightgear/scenery-dev/terrain/custom_road_rail_from_OSM/france/fg_railways
Railroad Railroad > log 2> log2
Starting program:
/storage1/flightgear/scenery-dev/terragear/install/terragear-cs/bin/shape-decode
--max-segment 500 --line-width 6
/storage1/flightgear/scenery-dev/terrain/custom_road_rail_from_OSM/france/fg_railways
Railroad Railroad > log 2> log2
[Thread debugging using libthread_db enabled]
[New Thread 0x7f866f54b6f0 (LWP 10926)]
Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7f866f54b6f0 (LWP 10926)]
0x7f866e447015 in raise () from /lib/libc.so.6
(gdb) bt
#0 0x7f866e447015 in raise () from /lib/libc.so.6
#1 0x7f866e448b83 in abort () from /lib/libc.so.6
#2 0x7f866ecebf94 in __gnu_cxx::__verbose_terminate_handler () from
/usr/lib/libstdc++.so.6
#3 0x7f866ecea396 in ?? () from /usr/lib/libstdc++.so.6
#4 0x7f866ecea3c3 in std::terminate () from /usr/lib/libstdc++.so.6
#5 0x7f866ecea4aa in __cxa_throw () from /usr/lib/libstdc++.so.6
#6 0x0041175a in tgChopNormalPolygon (pa...@0x7fff7756f220,
poly_ty...@0x7fff7756f130, sha...@0x7fff7756eda0, preserve3d=false) at
chop-bin.cxx:222
#7 0x00405b50 in processLine (psShape=0x202d870,
work_d...@0x7fff7756f220, poly_ty...@0x7fff7756f130, linewidth=6) at
shape-decode.cxx:545
#8 0x0040a5f1 in main (argc=4, argv=0x7fff7756f3c8) at
shape-decode.cxx:920
(gdb) list *0x0041175a
0x41175a is in tgChopNormalPolygon(std::string const&, std::string
const&, TGPolygon const&, bool) (chop-bin.cxx:208).
203 SG_LOG( SG_GENERAL, SG_DEBUG, " Bucket min = " << b_min );
204 SG_LOG( SG_GENERAL, SG_DEBUG, " Bucket max = " << b_max );
205
206 if ( b_min == b_max ) {
207 // shape entirely contained in a single bucket, write
and bail
208 clip_and_write_poly( path, index, poly_type, b_min,
shape, preserve3d );
209 return;
210 }
211
212 SGBucket b_cur;
This happens with the following shapefile:
http://www.mguillaud.net/fg/fg_railways.tgz
Note that I can run some other shapefiles through shape-decode without
problem. That particular file was generated by PostGIS using pgsql2shp.
It does not appear to be invalid.
Any advice ?
Regards,
Maxime
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] landcover info -> texture file mapping
Thanks to Martin and Curt for your answers. That helped a lot :) I will
post about my progress on the forums.
Maxime
Martin Spott wrote:
Hi Maxime,
Maxime Guillaud wrote:
Following the tutorial from the wiki
(http://wiki.flightgear.org/index.php/Using_the_Custom_Scenery_TerraGear_Toolset),
I was able to generate some scenery successfully. However, when I load
it into FG, it looks like many of the land use data types that I
included ("EvergreenBroadCover", "Deciduousbroadcover",
"Drycroppasturecover", "Evergreenbroadcover"...) map into the same
texture. I do not see the varitey of textures that I expect from looking
into my data/Textures/Terrain directory.
I _think_ (which means: I'm not entirely certain because I've never
tried the contrary) that material types are case sensitive. Thus,
according to TerraGear's 'src/BuildTiles/Clipper/priorities.cxx' as
well as the 'materials.xml' file (in the Base Package),
"Drycroppasturecover" should be "DryCropPastureCover". Otherwise
they're likely going to get mapped to the "Default" type, which
actually points to the same texture as - surprise, surprise -
"EvergreenBroadCover".
I found the page http://wiki.osgeo.org/wiki/LandcoverDB_CS_Detail but it
doesn't seem to answer my question...
Indeed. This page serves as a communication aid for a _future_
nomenclature of land cover types (yet it's classification is already
being partially honoured by nowadays Scenery developers).
Note that this document aims at dealing with just the 'raw' data, the
'true' land cover type. Whatever you feed into *-decode should finally
get translated into one of FlightGear's valid material type via the
"--area-type" flag.
Cheers,
Martin.
--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] landcover info -> texture file mapping
Hello,
Following my recent uncovering of detailed landcover information for
France (see
http://www.flightgear.org/forums/viewtopic.php?f=5&t=5105&sid=c3a960f7f3ee2f652973410a6d06ce9b),
I proceeded to generate custom scenery integrating this data.
Following the tutorial from the wiki
(http://wiki.flightgear.org/index.php/Using_the_Custom_Scenery_TerraGear_Toolset),
I was able to generate some scenery successfully. However, when I load
it into FG, it looks like many of the land use data types that I
included ("EvergreenBroadCover", "Deciduousbroadcover",
"Drycroppasturecover", "Evergreenbroadcover"...) map into the same
texture. I do not see the varitey of textures that I expect from looking
into my data/Textures/Terrain directory.
Can somebody explain the mapping mechanism between the "area string"
(that is fed to shape-decode during the scenery generation), and the
names of the texture files ? or point me to the relevant source code ?
I found the page http://wiki.osgeo.org/wiki/LandcoverDB_CS_Detail but it
doesn't seem to answer my question...
Maxime
--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
