Re: [Flightgear-devel] Compute ground elevation dynamically for STG format

[Mathias F. <Mat...@gm...>]

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