Re: [Flightgear-devel] Compute ground elevation dynamically for STG format
Hi, I changed my technical solution in order to use the technical solution proposed by Mathias. I hope this git diff is more adapted : http://pastebin.com/30GD4ksE As you can see the parser is ready, I have tested with modified STG file and it works. Now I just need to implement the ground elevation calculator. I have just a doubt about the variable elev I'm not sure that's is a good idea to send it as parameter since send change it in the function. Let me know what is wrong, how to improve this little change code. About the ground elevation calculator I think you are more able to create it because you know how to do. Personally I don't see how to adapt you fgelev because he is create for standalone program. In this way I think it's not really possible to adapt it for runtime program. Let me know if you accept to create this calculator. Thanks in advance, Cheers, Clément -- 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] Compute ground elevation dynamically for STG format
Hi, On Sunday, August 26, 2012 11:20:38 Clement de l'Hamaide wrote: I changed my technical solution in order to use the technical solution proposed by Mathias. I hope this git diff is more adapted : http://pastebin.com/30GD4ksE This looks much better. And I think you agree that it is much simpler and probably less error prone. As you can see the parser is ready, I have tested with modified STG file and it works. Now I just need to implement the ground elevation calculator. I have just a doubt about the variable elev I'm not sure that's is a good idea to send it as parameter since send change it in the function. Let me know what is wrong, how to improve this little change code. About the ground elevation calculator I think you are more able to create it because you know how to do. Personally I don't see how to adapt you fgelev because he is create for standalone program. In this way I think it's not really possible to adapt it for runtime program. Let me know if you accept to create this calculator. Ok, I hope that nobody really picks that feature up except may be a few people having their home grown stg files. Especially I would strongly advise the scenery people doing the 'official scenery' - whatever this means currently - not to use the agl based objects for placement and instead precompute the mean sea level elevations instead. The next advise would have been to look into osgUtil::IntersectionVisitor and osgUtil::LineSegmentIntersector and run this on top of the already loaded base nodes. I have some pending changes in this file here, so please forgive me if I introduce a huger conflict with your local changes. So the upside of this is that I really already implemented but not tested the changes on top of what I had pending yesterday and provide agl based objects with the next push. BUT: Never complain that scenery loading takes a long time in ground level computations! You have been warned! 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] Compute ground elevation dynamically for STG format
Yes of course your solution is more easier ;) As said I'm not a great programmer but at least I try to do something. I'm not a simple asker who say Please do it for me I try to involve myself with my little and insufficient skills but at least I do something. I saw that you commited the feature ! With a lot of other changes (the style is completely changed) I have tested with 15 OBJECT_STATIC_AGL and I don't noticed difference of loading time. As soon as possible I hope to have the possibility to make test with a lot of object/large scenery in order to have a concrete evaluation of the possible impact. And I will report this test here. Thanks you for your help, Cheers, Clément -- 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
[Flightgear-devel] FW: Compute ground elevation dynamically for STG format
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. Cheers, Clément -- 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
[Flightgear-devel] (no subject)
hey there i hve got a problem with my in built flight gear map, it does not show data navaids even when i click on the data check boxany help will be appreciated . am using windows by the way regards madaliso best of luck-- 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
[Flightgear-devel] Rembrandt Compatibility and Triple Monitor Configuration: Hardware Recommendations?
Hi Everybody, As some of you probably know, FSWeekend 2012, Europe's largest Flight Simulation Event is approaching. As in previous year's I've committed myself again to organize (or help organizing) a booth. I've been keeping a fairly low profile recently, and consequently I'm a little out of the loop concerning the latest development, so I apologize up front if I ask something stupid. But, I obviously would like to showcase the latest developments in graphics, then project rembrand (and also canvas) come(s) to mind. In the past I've been running FlightGear on a triple monitor or even a four-monitor config at FSWeekend) configuration. Is this currently already possible with Rembrandt (or would it be possible by early November), and if so, what kind of hardware configuration would it require to run. FWIW, I currently have an intel Quad core (Intel (R) Core (TM)2 Quad Q6600 @ 2.40 Gh) to be precise), with 4 Gigs of RAM, and two GeForce 9800 GT cards. My preference would be to just upgrade the video cards, but I'd be interested in hearing about other's experiences. Is if going to be possible at all to run in Rembrandt mode using multiple monitors / video cards? Cheers, Durk -- 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
