Hi,
On Thursday, August 30, 2012 07:27:45 Renk Thorsten wrote:
Computing constant values at runtime is bad design and we should not do
that. No matter if we notice a significant increase in load time now or
not. The ground elevation at a specific point is well known at scenery
generation time and that is where the vertical position of an object has
to be computed. Not in the main loop at the moment of scenery loading
where computing time is precious.
Just my two cents from a mere scenery user perspective...
I think I understand where the idea comes from - like the floating tanks in
Seattle Int. Say someone wants to populate an airport with buildings -
there's the real layout and there is the Flightgear default scenery layout
- which are sometimes quite distinct (think of places like Courchevel or
Alpe d'Huez where the default layout, especially in terms of elevation, is
*really* off). He can get closer to the real layout by using custom scenery
where it exists (as in the case of Seattle) and place objects at their
actual position, but when this is submitted to the scenery database, the
objects float or sink.
So, people would like to populate close to the 'real' layout, but still do
something useful for the scenery database I guess, and it would be nice to
have a way to automatically place objects at a plausible elevation for
people who use default scenery and for those why use custom scenery.
Determining elevation runtime would do that - but there may be other ways
of achieving the same result - maybe alternative object positions can be
computed at custom scenery creation time and shipped with the custom
scenery file, overwriting the default declarations? I don't know how to
make this work in practice, but perhaps the discussion should focus on how
objects can be placed plausibly with minimum manual effort under the
assumption that there are users which use custom scenery and users which
use default scenery in the same place without making the computations
runtime?
I can see this. Sure.
It's a matter of fact that we have different scene sources. This is completely
independent of - if some of us like that or not. I personally think that it
would be very nice to have more of these stuff contributed to the official
scenery, but I can also see that there are some edges that at worst do not
allow this at any time.
So fine lets assume that we need to cope with that.
Ok, this addition solves some problems that are probably the worst for some of
us currently. Still fine - this is the reason for me that I did not change this
into a devel only option as suggested.
But I still think that everything that is officially published which is
obviously self consistent *shall* *not* *use* agl levels for the explained
reasons.
It's really no good idea to convert everything to AGL placed just because it's
there. Using this is *at* *best* sensible if you cannot solve that in a
different way.
There is so very often some ideas floating around which are really bad and
which are followed just because anybody talking about that stuff knows nothing
about what what's happening behind. And so very often from my point of view it
would take magnitudes of time to explain the very basics which are required to
understand the problem. I don't have this time.
And in this particular case *do* *not* *use* this! Please! Only if you cannot
get around that. And no, just for convenience is *in* *no* *way* this kind of
a reason!
And do never tell that I have not warned you!
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
