Re: [Flightgear-devel] Compute ground elevation dynamically for STG format
Hi, Hmm, I am not sure if we want this. It's really a few lines code thing to implement above ground placing of objects. The point is that this is a task that could be done once when the model is integrated into a scene. So, why the hell should we do that *every* time the scene is loaded? Just for convenience? ... which is where I tend to say: No, not for that reason ... I have read well what you can do with that. Sure, but in the end this is *nothing* that delivers a different value on each load of the scenery - given the scenery below is the same. Really it seems like this is not a huge problem today. And if you do a test case with a few of these elevation numbers this does not matter - I am pretty sure that this works pretty fine for a few of these elevations and for todays scenery. But I had seen scenery where even the runway markings were done with individial polygons. Not that this fact could be source for an other lengthy discussion about whther this is sensible or not, but also this means once you have this kind of scenery and consistently use your proposed feature, you *will* wait a long time to finish this kind of scenery loading. And no, do not just compare loading a single tile. Really consider what happens when you load the paris scenery with *all* houses placed in this way. > The first part is pretty advanced, the second part is mainly already create > by Mathias with the new "fgelev" tool. I hope that "fgelev" can be adapted > for a runtime execution. With my changes, SG compilation works fine, but > even if I haven't touched FG files (I have only touched > "ReaderWriterSTG.cxx") FG doesn't compile :/ I'm a little bit surprised > that SG compilation is a success but FG compilation fails since I haven't > touched FG source code. fgelev is written purely to support the scenery generation process for the svn scenery. This is just the tool that I wrote to replace some really old tool where the source vanished and that is used by the scenery generation process for the svn scenery to place the objects. The tool itself is only written to support some database scripting together with awk and sed to give the right SELECT BLA FROM BLUBBER statements. So currently the output/usage of fgelev is not really thought for everybody use. It's just in the git so that the sourcecode cannot vanish anymore :) Do I understand right, you want to start fgelev to get the scenery elevation while loading scenery? That's something I would like to avoid on any price. The problem is solved with a few lines of c++ so easy that I would never take this burden of relying on sometihg error prone like only loading scenery correctly when some binary is found in the path or all is installed right in the right paths and so on... This is really a task for inline c++ ... Also, the bounding volumes might not be present in some variants of the scenery being loaded. So, relying on this as the fgelev visitor does is a bad idea. This is because you will not need these bounding volume trees for every type of application. Imagine you want to have a viewer only application that never does ground queries - which is on the works - you do not want to spend the extra time for computing these tree just to make no use of them. Therefore you can switch off generation if these trees. But consequently that means you need to rely on a different mechanism for this purpose. The implementation is not harder but different. Also the direction where the bounding volumes will move is that they will not just cover individual leafs in the scenegraph as they do today. A single leaf ground query object will in some time in the future cover a whole tile of static geometry. Only moving parts will show up individually. This is to improove lookup times for parts of the simulation that really need to do these lookups often and fast. But this collides with the need of scenery loading were you do not yet have the full tile loaded - you are actualy in process of loading it by composing the tile from the buildings placed above agl. In this case you would need collision geometries that do *not* cover the whole tile. Which is either something you have to compute at that point or you need to resort to processing linear lists for what you want to do. Which means that the computational cost per agl placement will raise considerably. And no, the next idea to structure the scenegraph like a collision geometry for the scenery loading reason is bad for rendering, the scenegraph should be optimized for rendering the collision tree should be optimized for collisions and both needs collide in some ways. In terms of computation time - people scream about loading times for scenery . all the arguments provided here are targeted to shorten the times. Either compute the bounding volumes which are costly or spend something longer in determinging the ground elevation of former loaded scenery. Which wart do you want to have? I a
[Flightgear-devel] Compute ground elevation dynamically for STG format
Hi all, My message is mostly destined to Mathias Froehlich since he seems to be mainly involved in this part of FG but of course every help is welcome. I would like add a new feature to the STG parser. Some months ago I had already added the possibility to give the pitch and roll (with the help of Anders). Now I want add the possibility to compute the ground elevation dynamically in order to add object in the scenery without elevation information. Currently the STG parser requires this kind of line : OBJECT_SHARED Models/Communications/radio-medium.xml -121.287778 37.008056 2500.00 180 0.0 0.0 Where "2500.00" is the elevation data of the object. A lot of objects are often simply at ground level. Thus I would like to give the possibility to interpret this kind of line : OBJECT_SHARED Models/Communications/radio-medium.xml -121.287778 37.008056 GND 180 0.0 0.0 OBJECT_SHARED Models/Communications/radio-medium.xml -121.287778 37.008056 GND-108.254 180 0.0 0.0 OBJECT_SHARED Models/Communications/radio-medium.xml -121.287778 37.008056 GND+56.3 180 0.0 0.0 As you can see the "GND" tag means that the object is simply at ground elevation. Also we can give an optional offset (positive or negative) for adjustment. Of course the current way of working need to continue to work ! I have already began to change the source code in order to make working together the "old" parser and "maybe future" parser. The "GND" tag give a big advantage, imagine if you can place object in FG just by giving lat/lon and FG computes himself the elevation of object. In this way we can place object without FG. We can place object with an automatic script or using just a map available on the web. Also, with this new feature, we can use the same object line with different elevation terrain, everybody know that a lot of custom scenery exist everywhere on the web and often the ground elevation is not the same in these custom scenery and in TerraSync terrain. This feature solves the problem. Since I am a partisan of the "do it yourself" mostly recommended in Open Source project I have already modified SG source code. Here is my <> : http://pastebin.com/vT2xE6ii I plan to organize the change in 2 part : first part is "detect the GND tag and optional offset", second part is "compute the ground elevation with the lon/lat and optional offset" The first part is pretty advanced, the second part is mainly already create by Mathias with the new "fgelev" tool. I hope that "fgelev" can be adapted for a runtime execution. With my changes, SG compilation works fine, but even if I haven't touched FG files (I have only touched "ReaderWriterSTG.cxx") FG doesn't compile :/ I'm a little bit surprised that SG compilation is a success but FG compilation fails since I haven't touched FG source code. I need some help to solve this FG compilation fail because I'm not a great programmer, I have only C++ base skills. In the SimGear changes I use boost::regex (I think it's better to use boost library isn't it ?) so I have included the library with #include in this way SG compilation works fine. But now FG compilation fails because boost::regex_basic and a lot of other boost library are missing. And I don't understand why since only SG use boost::regex library. The failed compilation log of FG is here : http://pastebin.com/zU4csueP I have done a lot of investigation and research on the web, I have consulted a lot of tutorial, example, documentation (cmake, boost), C++ forum (stackoverflow, developpez) without solve this problem. I think it's a cmake problem, maybe I need add something in CMakeLists.txt but since I'm far to be a cmake guru I can't find the solution. Please can you help me to solve this problem ? After that I can continue my implementation ;) Hoping that you can found interest in this new feature, Thanks in advance, Cheers, Clément -- 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] FlightGear Usability
On Sat, Aug 11, 2012 at 9:40 PM, Stuart Buchanan wrote: > 2) Joystick configuration. All of the people reading this list are > more than competent to write their own joystick XML config file, but > it's something that I see huge numbers of posts about on the forum, > from people who do not have enough knowledge to edit an XML file. I'm > now looking into whether we could configure joysticks within FG > itself. My aim is a UI to allow users to change bindings on-the-fly > and save the results. This is now checked in as the new Joystick Configuration item under the Help menu, which replaces the Joystick Information dialog. This dialog allows you to see what each of your axes and buttons do, plus reconfigure your joystick in-sim with immediate feedback. Updated joystick configuration files are written on-the-fly to $FG_HOME/Input/Joystick/, which is now read from by FG when the Input Subsystem is reloaded. The dialog re-loads the input, so your changes take effect immediately. If you have some more complicated bindings, you should be able to retain them by selecting "Custom" from the axis or button selector, but this has had limited testing, and I suspect needs a bit more work to become robust. I've also got a bit more work to do adding instructions, and possibly a deadband option, but the function is basically complete. Feedback is welcome as always. I've intentionally limited the set of axes and buttons that can be configured to avoid over-loading new users. If you feel there are important bindings missing, please let me know. -Stuart -- 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
