Re: [Flightgear-devel] FW: Compute ground elevation dynamically for STG format
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
Re: [Flightgear-devel] FW: Compute ground elevation dynamically for STG format
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 am well aware of the individual patches of custom scenery vs. a single global scenery effort debate and that my suggestion effectively is to support custom scenery better which may not be in line with the official policy - but I appreciate the huge difference in experiencing Courchevel in the default and in the custom version, and I would not want to miss that experience). * Thorsten -- 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] FW: Compute ground elevation dynamically for STG format
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. I can think of one scenario where the information offset from ground aka AGL is necessary. This is when the scenery gets recreated and the ground elevation changes. In that case, objects may float above or sink into the ground with a fixed altitude. IMHO, our scenery database needs to know about that offset to create the correct altitude for an object in the scenery. I would not want to see _any_ object in the scenery with a position specified by AGL. If that feature helps scenery developers to _temporary_ place objects, may I suggest that this code is enclosed in #ifdef's and only enabled during compile time with a special CMAKE switch and never enabled for a release? Torsten -- 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] FW: Compute ground elevation dynamically for STG format
Hi, On Monday, August 27, 2012 10:57:57 Torsten Dreyer wrote: If that feature helps scenery developers to _temporary_ place objects, may I suggest that this code is enclosed in #ifdef's and only enabled during compile time with a special CMAKE switch and never enabled for a release? That's possible. We can guard this with a cmake configure time variable. 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
Re: [Flightgear-devel] FW: Compute ground elevation dynamically for STG format
On Sunday, August 26, 2012 21:04:53 Clement de l'Hamaide wrote: I have done some test. Here is the result : Nb of objectWithout _AGLWith _AGL 0 20.4s 20.4s 500 21.4s 21.4s 5 000 21.6s 23.4s 15 000 24.0s 29.9s 30 000 27.2s 39.1s 100 000 52.1s 95.6s For information, TerraSync has 1 100 000 thus when I try to load 15 000 object I tried to load 1% of the entire TerraSync database in at once. And with 100 000 it's 10% of the entire TerraSync database. Of course it's not realist since objects are placed everywhere in the world in this way 1 STG file can't contains 1% of the entire TerraSync database. For example if the whole LOWI region (less than 4000 objects) was transformed with _AGL the loading time will increase of less than 2 seconds. As LOWI is one of the most advanced scenery it's a good comparison. With these test I can conclude that the _AGL tag can increase the loading time (and it's normal) but it's insignificant because FG doesn't load more than 5000 objects at once since tiles are loaded step by step. That's what I was trying to say to you. It might be the case that you do not see a huge problem today, but given you will see some changes in future scenery this will come up. To me, for that argument I just no not care at all what todays scenery just do by accident. Where accident I mean in this particular case that we have currently few triangles in the scene - which is good for many reasons including the one you are talking about. But it's clear to me that it's just a matter of time until we have something more finegrained. Then this will be more of an issue. Really, think about how such an algorithm works that you need to implement this feature, what computational compexity is sitting behind this and under which curcumstances this hurts. So not to be harsh, but to really judge about if this will be a problem or not I expect you to understand the above *in* *detail*. Then once you understood that, think about what is probably happeing next to the scenery. Then think about how people typically act in this kind of projects and see how the probability is that we will in the not so far future get scenery where it will be way more of a problem. How these claims all affect each other is left as an exercise ... Also you will find that today convenient to give agl numbers. But Trust me, there are plenty of people out there who do not care at all about your convenience. They want the scenery and they think about why this is taking longer when you use this feature widely. And the only answer is in the end: for no sensible reason - we can equally well precompute these elevations. And given your numbers I am surprised very bad how huge the impact already is with the current scenery. If you personally want to wait longer - I personally don't care. But please, in any officially published scenery, do *not* use this agl numbers and instead precompute the elevations! Thanks for reporting that it works so far. 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
