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
