[Flightgear-devel] Night textures: two files vs. textranslate
Dear all, I'm in the process of converting X-Plane scenery to FG. As far as I understood, X-Plane uses two separate texture files for day/night lighting. The FG wiki (http://wiki.flightgear.org/Howto:_Illuminate_faces#Changing_texture_if_illuminated) says This does not work with any version newer than v1.0! However, I just tried this with my GIT (compiled somewhen in Feb 2011), and it worked nicely. Is this way of night texturing deprecated/obsolete? Any significant downsides to it? I also tried the textranslate method, but when I put the day/night textures, say van.png and van_LIT.png each 256 x 256), into one file (512 x 256) and make up an .xml as described in the wiki, both day and night textures look distorted in FG. I assume the mapping specified in the .ac is no longer correct when I change the size of the texture file? I have no experience with UV mapping though. Any ideas? Tom signature.asc Description: This is a digitally signed message part. -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Night textures: two files vs. textranslate
Heiko, Emilian, thanks for your answers! @Heiko: The wiki article correctly describes the textranslate method. What puzzled me was that it says the previous, two-file solution would no longer work. Well, apparently it does here... http://flightgear.org/forums/viewtopic.php?f=5t=11870#p123517 @Emilian: I wasn't aware of that lightmap effect, thanks for the heads-up! It would certainly suit better here. Cheers, Tom signature.asc Description: This is a digitally signed message part. -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FG hangs on loading scenery when using many objects
Hey group, I've come across a problem with FG when many (static) objects are to be loaded on FG startup. Usually, on my (faily old) PC FG loads for about 20 seconds, then says loading scenery for about 6 seconds, and places me in the c172 ready for takeoff. During all this CPU load is at 100%. Now if I start FG with scenery that contains many ( 1000) objects, I get the following: - FG still loads for about 20 sec, then says loading scenery - about 3 seconds later, CPU load drops to ~20% and stays there - and FG never finishes startup --log-level=debug shows the main loop is running, I can use the menu, but I never end up in the c172, nor see anything else but the splash screen Starting at a nearby airport and flying into said scenery works. I can also teleport to this nearby airport while FG 'hangs', and then fly into said scenery flawlessly. I've created a test scenery [1] which uses TNCM terrain and 5000 instances of one object, furthermore, a script which lets me reduce the number of objects in the .stg. If I use 3100 objects, everything is fine. 3200 objects, and FG hangs. 100% repeatable, though I did not narrow down the threshold number further. However, the threshold number seems to depend on - the object(s) loaded - CPU load: If I have another process running (mplayer, for example) which consumes some CPU, FG now also hangs for the 3100 objects case (which would otherwise load fine if there was no other demanding process). It appears as if FG somewhat locks up if the initial scenery is not loaded within a certain wall clock time. Any ideas? Cheers, Tom - Git from 5 Sep 2011 - Gentoo Linux - GeForce 7600 GS (running ancient nvidia drivers 180.29) fgfs --prop:/sim/frame-rate-throttle-hz=30 --disable-random-objects --geometry=1920x1190+0+0 --atlas=socket,out,1,localhost,5500,udp --fg-root=/home/tom/daten/fgfs/src/fgdata --season=summer --fg-scenery=/home/tom/fgfs/home/Scenery-Manual:/home/tom/fgfs/home/Scenery-TerraSync:/home/tom/daten/fgfs/src/fgdata/Scenery:/home/tom/fgfs/home/Scenery-1.0.1 --aircraft=c172p --airport=TNCM --log-level=alert --prop:/sim/rendering/multi-sample-buffers=true --prop:/sim/rendering/multi-samples=2 --prop:/sim/ai-traffic/enabled=false --prop:/sim/traffic-manager/enabled=false --prop:/sim/atc/enabled=false --timeofday=dawn --enable-real-weather-fetch --control=joystick --disable-auto-coordination [1] http://www.mediafire.com/?n9uftx7vil98btz 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG hangs on loading scenery when using many objects
Hi Geoff, thanks for testing! Indeed, I forgot the texture, sorry about that. It is included in a new package: http://www.mediafire.com/?q99zyzkyu2tw04w For further testing, I wrote a small python script which fills a rectangular area at EHLE (because it's mostly flat there, so I can use hardcoded elevation) with an arbitraty number of objects (all copies of that coco palm). Could you please give it a try and see if you find any strange behaviour with, say, 5k, 10k, 20k objects? Usage: backup Objects/e000n50/e005n52/3040154.stg first! tar xzf Objects.tar.gz cd Objects/e000n50/e005n52 ./place_objs.py 5000 then start fgfs at EHLE On machine (much slower than yours: Pentium 4 2.4 GHz, 1.5GB DDR), FG hangs when using ~2300 objects. Thanks, Tom 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG hangs on loading scenery when using many objects
Hi Jon! I've seen something similar before, it's incredibly annoying, and I suspect you'll eventually track it down to a typo in an stg file. I've also had typos/missing objects in .stgs before, causing similiar effects. However, for testing, I'm creating the .stg with a very simple python script, placing the same object over and over at different locations. I am pretty sure it's not a typo or such. Cheers, Tom #!/usr/bin/env python import numpy as np import sys obj=Juliana-CocoPalmSeedling.ac alt=-5 hdg=0 mid_x=5.519707 mid_y=52.456022 size_x=0.0050 size_y=0.0050 num_x=num_y=int(sys.argv[1])**0.5 X = np.linspace(-0.5*size_x, 0.5*size_x, num_x) + mid_x Y = np.linspace(-0.5*size_y, 0.5*size_y, num_y) + mid_y f = open(3040154.stg, w) for y in Y: for x in X: f.write(OBJECT_STATIC %s %1.10g %1.10g %g %g\n % (obj, x, y, alt, hdg)) f.close() 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG hangs on loading scenery when using many objects
Hey Csaba,
hey Geoff,
thanks a lot for looking into this!
void SGPagedLOD::forceLoad(osgDB::DatabasePager *dbp, FrameStamp*
framestamp, ? ? ? ? ? ? ? ? ? ? ? ? ???NodePath path)
{
? ? //SG_LOG(SG_GENERAL, SG_ALERT, SGPagedLOD::forceLoad(
? ? //getFileName(getNumChildren()) ));
And now the crazy part! If I uncomment this logging, everything
suddenly works, even with 20k objects:
Same here -- uncommenting this part in simgear/scene/model/SGPagedLOD.cxx
fixes the issue for me, too. 20k objects were loaded within 10 sec on my P4
2.4 GHz, though frame rate is ~5 then...
Cheers,
Tom
signature.asc
Description: This is a digitally signed message part.
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of 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-d2dcopy2___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Generating ground textures on the fly?
I've been playing with populating my home airport's area with buildings derived from OSM floorplan data. I think having many buildings in the correct place greatly improves realism over the current random buildings/sparse static models, especially when you know the area. However, now the buildings obviously don't match with ground textures or random trees. Any bright ideas how to achieve this? I know I could follow the photoscenery approach and pre-render special materials and masks for a couple of cities, but that just doesn't scale. I wonder how x-plane 10 does this? Could we generate the texture on the fly? Based on landclass and road data? I could see a number of advantages/disadvantages here as compared to our current, generic textures: + much better autogen scenery possible: many textured streets/railroads without additional scenery vertices + shared models with an individual piece of ground texture + get rid of sharp landclass borders + possibly improved resolution - eats much more video ram and CPU (but then I have 3 out of 4 idle cores ATM) - probably totally incompatible with the current terragear toolchain I know C/C++ and would be happy to start tinkering with this part at some point. But I know next to nothing about OSG, OpenGL, and shaders. Graphics gurus: is there any better way to do this? Cheers, Tom -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Generating ground textures on the fly?
Hi James, Thank you for your input! I wasn't aware there is such thing as fgviewer. It's definately a good starting point, I will have a look at it. Oh, and if you can do IRC, I'm sure the guys in #fg_scenery would be delighted to discuss what you've done and a whole range of possibilities :) If by what you've done you refer to the OSM building generation: I haven't done rocket science yet. Just a couple of python scripts and some facade and roof textures. Clustered the buildings as you suggested on the forums and added a LOD animation, and now I get decent frame rates with impressive building coverage. I know there's a perl script around which does the same -- but I'm just not a perl guy. Cheers, Tom -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Generating ground textures on the fly?
Hi Thorsten, Thank you, too! This becomes a performance issue eventually - see Paris (France). Random buildings scale well for memory and performance because they're numerous instances of the same building, so just the various positions need to be stored separately - a city full of unique buildings needs to store each building uniquely. The basic idea doesn't really scale well. It looks impressive, and scales well enough on my machine, which isn't really high end: i5-2500k, GT640TI. The basic idea would be: Based on landclass data and OSM roads, generate a unique hi-res texture for a few km out. (maybe using a base texture and overlays as you desribe below.) Gradually reduce texture resolution for terrain further out. (I did some rough estimate which indeed showed I need plenty of video RAM, but not several GBs.) Regenerate the textures as the camera moves. I have no idea if current CPUs/GPUs are fast enough for such a scheme. Or if there's a better way to achive this. This is why I'm asking you guys. This isn't as impressive as you think - the kind of graphics card that can deal with 11.000 unique terrain texture sheets in the scene (you need something of that magnitude, see the numbers worked out here http://wiki.flightgear.org/Procedural_Texturing#Photo_texturing ) is also the kind of graphics card which can go through millions of vertices. Terrain that is 100km out doesn't need 1m/px resolution. I'm certainly thinking of a LOD scheme here, so I won't need 11.000 unique texture sheets. + shared models with an individual piece of ground texture Well, but how does FG know how this is supposed to look? Obviously, if you would do it manually, you would blend the individual ground texture against the surrounding. This is exactly how I'd do it. Which is bad, because it means you need non-local information to get the task done. I don't get this yet: why is blending the texture against the surrounding bad, and what's the problem with non-local information? You'd also want to generate different patterns in Europe, the US, Asia,... Yes, I'd be happy to generate different patters for different countries. If the code supports it, artists will step in here. No, resolution will in fact go much down because of the memory limit. In the current scheme using a finite set of terrain textures with procedural overlays, we can achieve cm-sized resolution on ground features. Great. Can we have overlays for a finite set of buildings? In the end, if I could make a wishlist how to design the scenery rendering, I would probably separate hires sharp features like roads out and describe them via vertices and pass the informtion on landclass distribution via a meta-texture with relatively coarse resolution and build the actual textures procedurally everywhere based on the relative distribution densities of features coming from the meta-texture. Unique buildings would then need to be registered on the meta-texture in the scenery generation stage, the actual procedural terrain cover would be generated runtime on the GPU. Sounds like a good plan to me. As for the Intel graphics argument, I'm with Gene. Cheers, Tom -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain self-shading
On a related note, the thread highlights that our tree textures are rather small, so our trees look quite blocky. Stuart, I created new textures for tropical trees a while ago, and I intend to improve central European tree textures in the near future. Thorsten suggested [1] separating foilage and trunk; is this what you have in mind? Im just waiting for the right weather to take pictures of the trunks -- and then of course, for the trees become green again -- but then I can provide hi- res tree textures. Tom [1] http://www.flightgear.org/forums/viewtopic.php?f=5t=19265sid=d60eca7e515a1fcd8f7a8e881aba1a3cstart=15#p179241 -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain self-shading (plain text)
Sorry for that HTML-crap. Here's the plain text again. On a related note, the thread highlights that our tree textures are rather small, so our trees look quite blocky. Stuart, I created new textures for tropical trees a while ago, and I intend to improve central European tree textures in the near future. Thorsten suggested [1] separating foilage and trunk; is this what you have in mind? I'm just waiting for the right weather to take pictures of the trunks -- and then of course, for the trees become green again -- but then I can provide hi- res tree textures. Tom [1] http://www.flightgear.org/forums/viewtopic.php?f=5t=19265sid=d60eca7e515a1fcd8f7a8e881aba1a3cstart=15#p179241 -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Atmospheric Light Scattering
Henri, Thorsten only said, that _if_ you ask him to remove ALS because of concern for users without good graphics cards, you should aks FredB as well to remove Rembrandt, because the same argument would apply. Not doing it just shows that different standards are applied which is simply unfair. First , it is not because i am unable to write English correctly, i can't understand it written. Suggesting to ask for removing Rembrandt gives enough to conclude. You clearly don't get this right, and therefore draw the wrong conclusions. As Stefan said, have someone who understands English better explain this to you in your language. @Thorsten: I love ALS. @FredB: I love Rembrandt. And of course I'd love to see both combined. I'm pretty sure that at some point in the future they will be. Why Thorsten has not given up on this yet is just beyond me. This is not a discussion, it's just handwaving and accusations. I'm just very glad, that he didn't give up. So instead, I can enjoy as much of the great flying experience as I can get during the long winter months. +1 Tom -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Lightmap question
Dear shader experts, Can I have a single-channel lightmap, and still use a vec3d in my model.xml to end up with green or red (or whatever) light rendered? As in (roughly) on_screen_color[0] = lightmap-grey-value * vec3d[0] * texture[0] on_screen_color[1] = lightmap-grey-value * vec3d[1] * texture[1] on_screen_color[2] = lightmap-grey-value * vec3d[2] * texture[2] where texture is the base model texture? Docs/README.model-combined.eff says lightmap-color type=vec3d n=0 1.0 1.0 1.0 /lightmap-color - the color of the light for the red channel in the light-map. etc for green and blue channels, but when I use this line, FG complains Failed to load xml: Unrecognized data type 'vec3d' Failed to load model: Unrecognized data type 'vec3d' I guess this works only for multi-channel lightmaps? I.e. with lightmap-multi type=int1/lightmap-multi My .xml looks like this: effect inherits-fromEffects/model-combined-deferred/inherits-from parameters lightmap-enabled type=int1/lightmap-enabled texture n=3 imagetex/DSCF9503_noroofsec_pow2_LM.png/image wrap-srepeat/wrap-s wrap-trepeat/wrap-t /texture !--lightmap-color type=vec3d n=0 1.0 5.0 0.2 /lightmap-color -- lightmap-factor type=float n=01.0/lightmap-factor /parameters object-nameb606/object-name object-nameb610/object-name /effect Tom A. (aka radi) -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Lightmap question
You can do what you want, but not inline in the model.xml file - the type=vec3d is not recognized anywhere outside an effect and is causing the error. Do your effect config in a local .eff file, then inherit from that in your model. Thanks Vivian, I wasn't aware of that. Works great now. Tom -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] osm2city.py
Dear list, in particular Stuart, please let me 'officially' announce my project osm2city.py [1,2] here. This python script takes OSM floor plans and generates 3D buildings for use with flightgear. I'm planning to develop this into a procedural city generator which would take a street network and then reasonably places (random) buildings. The ultimate goal is (obviously) to improve FG's representation of cities. It's at a rather early stage, and for the moment I prefer python for quick prototyping. BUT, I know quite some C/C++, and compile from latest GIT sources regularly. In the future, I'm definately willing to move this into FG (in one form or another). Tom [1] http://wiki.flightgear.org/Osm2city.py [2] http://flightgear.org/forums/viewtopic.php?f=5t=19625 -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] osm2city.py
James, Could the floor-plan data be pulled live from OSM servers, or does it need to be processed offline before hand? We have most of the infrastructure to pull data from web-services already in place. Currently data is processed offline before hand. Basically, it parses the OSM xml, generates a list of building outlines, discards some based on their area, simplifies the outlines, clusters them into ~500x500m blocks and different LODs, then writes .ac, .xml, and .stgs. OSM parsing is by far the most expensive, easily taking 10 minutes for 50k buildings. Once that's done, the remaining parts take maybe 1 minute in total. In C++, this would be faster, of course. Are you thinking of a terrasync-like thing here, where users get OSM buildings (where available) on-the-fly? In addition to what Stuart said, this might be quite expensive in terms of bandwidth. The OSM download (buildings only!) was ~40MB for the 25x25km LOWI area. Curt, Would this data set include airport hangar buildings as well? At the moment, the code knows only the floor plans. No streets, no runways, no land-use. But it'll certainly process such data in the future, and then could use some heuristics (some OSM buildings are labeled Terminal 1 or so) to apply terminal/hangar textures to buildings at airports. Hadn't thought of this before, but yes, this way we could rather easily populate some airports with 'semi-generic' terminal/hangar buildings. Stuart, Thanks for pointing me at fgelev. I'll give it a try. If I had a limited number of complex (as in 8 vertices per model) shared models, and place a total of 5 instances in a scene, could this be made to occupy significantly less RAM than 5 individual models? Gijs, Thanks for your comments! I'm aware that OSM building coverage is basically non-existant in large parts of the world. Street coverage is much better, that's why I also aim at procedurally generating cities just from a street network. Meanwhile, a forum user (vanosten, http://flightgear.org/forums/viewtopic.php?f=5t=17598) who's interested in exactly that offered to join forces. Since I've already invested ~3 months here and remarkably didn't get bored (in fact, quite on the contrary), I'm confident we'll get there eventually ;) I know of bob.pl, but I just cant read perl... When there are buildings, you'll often find that they are drawn as big blocks, rather than individual houses. True, unfortunately. Plus, _if_ there are many tiny individual houses, they'll kill framerate (backed by some experience with LOWI now). Appropriate textures might help here. Before I could create some sensible buildings for New York I had to add height tags; all skyscrapers were simply lacking that data. Why not simply assume a sensible distribution of buildings heights in this case? I've played with that some days ago, and found it looks quite reasonable: http://ubuntuone.com/0X0KcYJbRgUtIldtasWyMo http://ubuntuone.com/1LaEKT6pOtf6zxXItpKmPA http://ubuntuone.com/0jsCECjmKMaooP4wrHHwH7 Thomas -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] fgelev
Hi, can someone (Mathias?) please enlighten me about fgelev usage? Skimming through the source, I understand that I need to provide --fg-root and --fg-scenery, but how do I specify which location to probe? fgelev --fg-root $FG_ROOT --fg-scenery $FG_SCENERY EOF 13.0 51.0 EOF doesn't seem to work. Tom -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58041391iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] terragear.git: gdalchop.cxx undef reference to sgWriteLong
I'm trying to compile terragear.git on a fresh Manjaro Linux, but linking fails on gdalchop.cxx with gdalchop.cxx:(.text+0x4f4): undefined reference to `sgWriteLong(gzFile_s*, int)' gdalchop.cxx:(.text+0x4ff): undefined reference to `sgWriteInt(gzFile_s*, int)' gdalchop.cxx:(.text+0x578): undefined reference to `sgWriteShort(gzFile_s*, short)' sgWriteLong exists in libSimGearCore.a (so do the others): $ nm -gC /home/tom/daten/fgfs/cvs-build/git-2013-09-19-osg-3.0.1/lib/libSimGearCore.a | grep sgWriteLong 0450 T sgWriteLong(void*, int) 0540 T sgWriteLongLong(void*, long) U sgWriteLong(void*, int) and /home/tom/daten/fgfs/cvs-build/git-2013-09-19-osg-3.0.1/lib/libSimGearCore.a is included in the linker command line. No idea if it's relevant, but I had to compile GDAL from source since I couldn't find it in Manjaro's packages. Any ideas? Tom -- Boost version: 1.54.0 -- Found the following Boost libraries: -- system -- thread -- SimGear include directory: /home/tom/fgfs/cvs-build/git-2013-09-19-osg-3.0.1/include -- found SimGear version: 2.99.0 (needed 2.12.0 or higher) -- looking for static SimGear libraries -- found SimGear libraries -- Performing Test SIMGEAR_COMPILE_TEST -- Performing Test SIMGEAR_COMPILE_TEST - Success -- Found CGAL 4.2 -- Build type: Release -- USING CXXFLAGS = ' -frounding-math -O3 -DNDEBUG' -- USING EXEFLAGS = ' ' -- Targetting Unix Makefiles -- Using /usr/bin/c++ compiler. -- Requested component: Core -- Requested component: MPFR -- Requested component: GMP -- Configuring done -- Generating done -- Build files have been written to: /home/tom/daten/fgfs/src/terragear /usr/bin/cmake -H/home/tom/fgfs/src/terragear -B/home/tom/daten/fgfs/src/terragear --check-build-system CMakeFiles/Makefile.cmake 0 /usr/bin/cmake -E cmake_progress_start /home/tom/daten/fgfs/src/terragear/CMakeFiles /home/tom/daten/fgfs/src/terragear/CMakeFiles/progress.marks make -f CMakeFiles/Makefile2 all make[1]: Entering directory `/home/tom/daten/fgfs/src/terragear' make -f src/Lib/terragear/CMakeFiles/terragear.dir/build.make src/Lib/terragear/CMakeFiles/terragear.dir/depend make[2]: Entering directory `/home/tom/daten/fgfs/src/terragear' cd /home/tom/daten/fgfs/src/terragear /usr/bin/cmake -E cmake_depends Unix Makefiles /home/tom/fgfs/src/terragear /home/tom/fgfs/src/terragear/src/Lib/terragear /home/tom/daten/fgfs/src/terragear /home/tom/daten/fgfs/src/terragear/src/Lib/terragear /home/tom/daten/fgfs/src/terragear/src/Lib/terragear/CMakeFiles/terragear.dir/DependInfo.cmake --color= make[2]: Leaving directory `/home/tom/daten/fgfs/src/terragear' make -f src/Lib/terragear/CMakeFiles/terragear.dir/build.make src/Lib/terragear/CMakeFiles/terragear.dir/build make[2]: Entering directory `/home/tom/daten/fgfs/src/terragear' make[2]: Nothing to be done for `src/Lib/terragear/CMakeFiles/terragear.dir/build'. make[2]: Leaving directory `/home/tom/daten/fgfs/src/terragear' /usr/bin/cmake -E cmake_progress_report /home/tom/daten/fgfs/src/terragear/CMakeFiles 43 44 45 46 47 48 49 50 51 52 53 54 55 [ 16%] Built target terragear make -f src/Prep/GDALChop/CMakeFiles/gdalchop.dir/build.make src/Prep/GDALChop/CMakeFiles/gdalchop.dir/depend make[2]: Entering directory `/home/tom/daten/fgfs/src/terragear' cd /home/tom/daten/fgfs/src/terragear /usr/bin/cmake -E cmake_depends Unix Makefiles /home/tom/fgfs/src/terragear /home/tom/fgfs/src/terragear/src/Prep/GDALChop /home/tom/daten/fgfs/src/terragear /home/tom/daten/fgfs/src/terragear/src/Prep/GDALChop /home/tom/daten/fgfs/src/terragear/src/Prep/GDALChop/CMakeFiles/gdalchop.dir/DependInfo.cmake --color= make[2]: Leaving directory `/home/tom/daten/fgfs/src/terragear' make -f src/Prep/GDALChop/CMakeFiles/gdalchop.dir/build.make src/Prep/GDALChop/CMakeFiles/gdalchop.dir/build make[2]: Entering directory `/home/tom/daten/fgfs/src/terragear' Linking CXX executable gdalchop cd /home/tom/daten/fgfs/src/terragear/src/Prep/GDALChop /usr/bin/cmake -E cmake_link_script CMakeFiles/gdalchop.dir/link.txt --verbose=1 /usr/bin/c++-frounding-math -Wall -D_REENTRANT -DNO_OPENSCENEGRAPH_INTERFACE -O3 -DNDEBUG CMakeFiles/gdalchop.dir/gdalchop.cxx.o -o gdalchop -L/home/tom/fgfs/cvs-build/git-2013-09-19-osg-3.0.1/lib -rdynamic -lmpfr -lgmp /home/tom/fgfs/cvs-build/git-2013-09-19-osg-3.0.1/lib/libCGAL_Core.so /home/tom/fgfs/cvs-build/git-2013-09-19-osg-3.0.1/lib/libCGAL.so -lboost_thread -lboost_system ../../Lib/terragear/libterragear.a -lgdal -lz /home/tom/daten/fgfs/cvs-build/git-2013-09-19-osg-3.0.1/lib/libSimGearCore.a /home/tom/daten/fgfs/cvs-build/git-2013-09-19-osg-3.0.1/lib/libSimGearCore.a -lpthread -lz -lrt -lmpfr -lgmp /home/tom/fgfs/cvs-build/git-2013-09-19-osg-3.0.1/lib/libCGAL_Core.so /home/tom/fgfs/cvs-build/git-2013-09-19-osg-3.0.1/lib/libCGAL.so -lboost_thread -lboost_system /home/tom/daten/fgfs/cvs-build/git-2013-09-19-osg-3.0.1/lib/libSimGearCore.a -lpthread -lrt
Re: [Flightgear-devel] terragear.git: gdalchop.cxx undef reference to sgWriteLong
Hi Rebecca, Thanks for the pointers! Yes, I compile SG myself, but the version TG would link against might have been compiled on Ubuntu (I'm migrating to Manjaro). Compiling everything again solved my problem. Most likely an ID-10T error. Tom -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13. http://pubads.g.doubleclick.net/gampad/clk?id=64545871iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] procedural bridge generation
With my python coding for OSM buildings in FG coming along nicely, I recently thought about creating semi-generic bridges. Is anyone else working on this? Or is anyone aware of an open source procedural bridge generator? Searching the net mostly turned out stuff for Houdini etc. Tom -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13. http://pubads.g.doubleclick.net/gampad/clk?id=64545871iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgelev
the first element appears to be an label so the input format is label lon lat\n Thanks Stuart, that works! Tom -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13. http://pubads.g.doubleclick.net/gampad/clk?id=64545871iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] procedural bridge generation
Hi Adrian, I was thinking to circumvent the Terragear toolchain completely (for now), and 'just' generate 3d bridge models based on OSM data. These could then go into the scenery DB, perhaps with a tag that indicates they were automatically generated. I _guess_ the next scenery build will include OSM roads, so the location of the bridges should be fine? BTW: I recall there were plans to including other OSM objects. Is there some progress beyond what's listed in http://wiki.flightgear.org/OpenStreetMap_import ? Tom -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Moving menus (aka, usability)
The Autopilot menu change does make sense (although there may possibly be a case for keeping such a flight-critical menu rapidly accessed at the top level?) I don't see this need. When I'm in a hurry, I use my left hand to enter a keyboard shortcut, rather than taking my right hand off the most critical flight controls to grab the mouse and navigate to/through a menu. the control key is usually one of the easiest modifiers to find on a keyboard Mhh.. personally, I'd slightly prefer the shift key over the control key for the most important two-key-shortcuts. Using one hand (remember, the other hand is on the stick;), shift enables a slightly larger range than control: I can somewhat easily type shift+5, whereas control+5 becomes a little difficult. Tom -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
