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 am targeting of getting rid of them at all places where it's not strictily necessery - at least not introducing something like this just for the sake of 'it's way more convenient if I do over and over again the same costly computation' ... If we want to do this, I can write a patch for this may be within a one or two hours that really fits the bill of the above points. No external processes, not the same scenery visitor that fgelev uses and just a little more string handling in the stg files. Just use something that purely relies on scenery as being loaded by osg. > 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 <boost/regex.hpp> 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. Ah, I also hope that we do not introduce an other boost dependency. IMO boost does not provide anything that we can not implement with almost the same runtime complexity using the standard library. Boost just introduces a dependency on a foreign package that is not needed. So I should have started this discussion when the first line was checked in, but I want to avoid introducing more of that where it's not needed. So in the end, what do you need. You need to distinguish between a number and the word GND. So this is somethig do can do easily without any regexp. Regexps can have a very bad runtime complexity. And for just that purpose I do not think that we should use a regexp as this could be solved by a simple few line string sourcecode change. So, for the discussion about boost, you just see that it's not required at all at that point. Or alternatively introduce an other OBJECT_SHARED_AGL tag or somethig close to this, where you just know that the altitude number is meant to be an agl number instead of above sealevel. That's really easy to do and has almost no side effects of any kind. > Hoping that you can found interest in this new feature, I had that request offline many years ago and multiple times. But up to now I did not implement this. And it's really not because it's hard - it's because I think its better done differently. If you want to solve this problem for your handmade elevations I more tend to extend fgelev to introduce a possibility to process an stg file directly. So when you really want to adapt your stg files you can then run that on a source stg and you arrive at a final stg that has the final elevations in it? That would still provide you with what you want to do but the elevation query will not happen at every scenery load? Really think about what you want to have. It's not that we cannot talk about that kind of feature, it's just that I think that there is a very narrow window where this kind of feature makes sense. Greetings Mathias ------------------------------------------------------------------------------ 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
