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
Re: [Flightgear-devel] Compute ground elevation dynamically for STG format
Hi Mathias,
I understand that the fact to compute the elevation every time scenery is
loaded is not a way to improve loading time.
X-Plane give the possibility to compute the elevation of an object, FSX do the
same, and FlyLegacy do the same. Only FG require absolutely the elevation of
object.
If other simulator do that, why FG can't do that ? I haven't heard that FSX
scenery loading take 1 hour or X-Plane scenery loading take 1 hour, therefore
the feature is available. Thus I think we can test to implement the feature and
see if the loading time is really impacted. If other simulator have reasonable
time of loading with this feature, why FG can't have the same reasonable time
of loading with this feature ?
I keep in mind that the time of loading can be impacted, but I would like to
test the feature before to say No it's not possible because the loading time
will increase enormously!
About the boost library, I done this choice because I thought it was better for
computation. But as I said I'm only a little C++ programmer and if you say :
don't use boost for this feature is better. I trust you ;)
I'm totally open to other solutions. The important part in this feature is
really to leave FG compute the elevation of the object if the user don't give
the elevation data.
To be honest, the little git diff provided in my precedent mail take me 1 day
and 1 night (I'm definitely not a good C++ programmer). You say that you can
implement the complete feature in 1 or 2 hours. In this way it's maybe better
that I stop to code on my side and leave you implement this.
In this way you use the technique that you want/prefer.
After reading your mail, it seems that my choices and technical solution are
not appropriate at all.
You introduce another solution : OBJECT_SHARED_AGL
Models/Communications/radio-medium.xml -121.287778 37.008056 2.30
180 0.0 0.0
As I said I'm open to every solution, if you think that it's better to use this
solution I'm ok. your solution give the same possibility than my solution
(indicate ground elevation + optional offset) But with your solution we can
skip these line in case of use of a viewer (as you speak about a future viewer)
with a simple condition like : IF ( viewer is used ) { skip OBJECT_SHARED_AGL
OBJECT_STATIC_AGL line }
With this feature I really want to be independent of the terrain elevation. A
lot of scenery exist everywhere on the web and use different terrain elevation.
This feature is a real solution to these problem of different terrain
elevation.
Also this feature give the possibility to use external tools for object
positioning. For example this tools :
http://www.youtube.com/watch?v=dajvfna0CaM Moreover this feature give the
possibility to user to use objects distributed by TerraSync out of the terrain
distributed by TerraSync, and it works also in reverse, TerraSync can use
object that are not specially placed with TerraSync terrain. In this way
TerraSync is winner with this feature.
With all these elements and elements in my precedent mail I can affirm you that
this feature is really welcome. Also if other Flight Sim have implemented this
feature it's because it's useful.
Are you able to propose your technical solution and start to write some C++
lines ? or can we experiment my changes since I have already started to write
some C++ lines ?
Let me know what are you ready to do, your plan, your solution. Even if I'm not
the coder, I'm interested by your choices and solutions for this feature.
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, 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
