Re: [Flightgear-devel] OpenRTI / HLA
if you put the library files outside of x86_64-linux-gnu and x86_32-linux-gnu you would not be able to tell if the files are for 32 or 64 bit. That directory is part of the multi-arch specification. I don't think we want to take it out. Can this be fixed in the CMakeLists.txt? Is that the right solution? -Pat On Mon, 18 Mar 2013 00:41:03 +0100 Clement de l'Hamaide wrote: > Mathias, > > > Thanks, I have moved the rti libs below the simgear ones. > Does this help? > > Yes it works fine now ! Thanks you. > But a new mistake appers now, FG is not able to found libRTI-NG.so.1 > because the file is in > install/openrti/lib/x86_64-linux-gnu/libRTI-NG.so.1 I've fixed the > problem by moving all files outside of x86_64-linux-gnu/ directory > and now it works. > > Is it possible for you to change the CMakeLists.txt in order to > change the path like install/openrti/lib/libRTI-NG.so.1 ? We had a > similar problem some weeks ago about libsvn/subversion : > > http://code.google.com/p/flightgear-bugs/issues/detail?id=946#c10 > https://www.gitorious.org/fg/flightgear/commit/3b6436bfb8d5cfb180f7119fd01f365d1f79528e > > Thanks you, > Clément > -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OpenRTI / HLA
I ran a clean build of master/next using download_and_compile.sh -ei and everything under fgfs/flightgear built including fgviewer. Smoke test: Run with C172P at KSFO, takeoff for a run to half moon bay. Multiplayer working. So what needs testing with HLA? -Pat On Sun, 17 Mar 2013 15:30:47 +0100 Mathias Fröhlich wrote: > > Hi, > > On Thursday, March 07, 2013 18:26:46 Clement de l'Hamaide wrote: > > Mathias, some weeks ago I told you about a compilation problem for > > FG on Linux when RTI is enabled. You asked me to remind you of this > > problem later, this day is came :) > > Thanks, I have moved the rti libs below the simgear ones. > Does this help? > > Greetings > Mathias -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OpenRTI / HLA
Mathias, > Thanks, I have moved the rti libs below the simgear ones. Does this help? Yes it works fine now ! Thanks you. But a new mistake appers now, FG is not able to found libRTI-NG.so.1 because the file is in install/openrti/lib/x86_64-linux-gnu/libRTI-NG.so.1 I've fixed the problem by moving all files outside of x86_64-linux-gnu/ directory and now it works. Is it possible for you to change the CMakeLists.txt in order to change the path like install/openrti/lib/libRTI-NG.so.1 ? We had a similar problem some weeks ago about libsvn/subversion : http://code.google.com/p/flightgear-bugs/issues/detail?id=946#c10 https://www.gitorious.org/fg/flightgear/commit/3b6436bfb8d5cfb180f7119fd01f365d1f79528e Thanks you, Clément -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OpenRTI / HLA
Hi, On Thursday, March 07, 2013 18:26:46 Clement de l'Hamaide wrote: > Mathias, some weeks ago I told you about a compilation problem for FG on > Linux when RTI is enabled. You asked me to remind you of this problem > later, this day is came :) Thanks, I have moved the rti libs below the simgear ones. Does this help? Greetings Mathias -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OpenRTI / HLA
Now my question is what adjustments need to be made to cause cmake to put the openrti libs in the right place in the link, after the simgear libraries. The problem with fgviewer builds is exhibited by its compile command, found in the build tree at build/fgfs/utils/fgviewer/CMakeFiles/fgviewer.dir/link.txt it is invoked during the cmake as: cd /home/pac1/build/master/build-maint-ei/fgfs/utils/fgviewer # && /usr/bin/cmake -E cmake_link_script CMakeFiles/fgviewer.dir/link.txt --verbose=1 adapt the above to your build and try it. Does it fail? In link.txt, LibRtI-ng.so and libFedTime.so are in the link list BEFORE libSimGearScene.a libSimGearCore.a moving these two items AFTER the libSimgear static libraries makes the link work: -rdynamic /home/pac1/build/master/install-maint-ei/openrti/lib/i386-linux-gnu/libRTI-NG.so /home/pac1/build/master/install-maint-ei/openrti/lib/i386-linux-gnu/libFedTime.so Note that it does it right for the fgfs executable but does it wrong for the fgviewr executable. unchanged and modified link.txt files are attached. -Pat LIOn Thu, 07 Mar 2013 18:26:46 +0100 Clement de l'Hamaide wrote: > > Hi, > > Mathias, some weeks ago I told you about a compilation problem for FG > on Linux when RTI is enabled. You asked me to remind you of this > problem later, this day is came :) > > For remembering : > > > Clement wrote : > >> I'm really interested by your work about OpenRTI / HLA. I've added > >> the RTI > > >> support in the download_and_compile.sh brisa script's in order to > >> make it > > >> more "user-friendly" to use and participate to the development. I > >> compile > > >> SG and FG with -DENABLE_RTI=ON since some weeks but today FG > >> compilation > > >> crashed with this option :/ Here is the compilation log : > > >> http://pastebin.com/HnPSfyzs > > >> OpenRTI and SG compilation are fine. I've deleted my OpenRTI/FG/SG > >> build dir > > >> but the issue still here. Do you have a solution ? > > > Remind me to look at that past the Christmas days please. > > Today I gave a new try but the compilation still fails : > http://pastebin.com/grfbW2SG SG compilation works fine with > ENABLE_RTI=ON but FG compilation fails with it. Can you take a look > at it ? Let me know if you need more info, also I can make some > change in source code if you tell me what to change. > > Cheers, > Clément > > > > > /usr/bin/c++ -O3 -D__STDC_CONSTANT_MACROS -Wall -D_REENTRANT -DBOOST_MULTI_INDEX_DISABLE_SERIALIZATION -DBOOST_BIMAP_DISABLE_SERIALIZATION -O3 -DNDEBUG CMakeFiles/fgviewer.dir/fgviewer.cxx.o CMakeFiles/fgviewer.dir/Drawable.cxx.o CMakeFiles/fgviewer.dir/Renderer.cxx.o CMakeFiles/fgviewer.dir/SlaveCamera.cxx.o CMakeFiles/fgviewer.dir/Viewer.cxx.o CMakeFiles/fgviewer.dir/HLACamera.cxx.o CMakeFiles/fgviewer.dir/HLACameraClass.cxx.o CMakeFiles/fgviewer.dir/HLACameraManipulator.cxx.o CMakeFiles/fgviewer.dir/HLADrawable.cxx.o CMakeFiles/fgviewer.dir/HLADrawableClass.cxx.o CMakeFiles/fgviewer.dir/HLAEyeTracker.cxx.o CMakeFiles/fgviewer.dir/HLAEyeTrackerClass.cxx.o CMakeFiles/fgviewer.dir/HLAMPAircraft.cxx.o CMakeFiles/fgviewer.dir/HLAMPAircraftClass.cxx.o CMakeFiles/fgviewer.dir/HLAOrthographicCamera.cxx.o CMakeFiles/fgviewer.dir/HLAOrthographicCameraClass.cxx.o CMakeFiles/fgviewer.dir/HLAPerspectiveCamera.cxx.o CMakeFiles/fgviewer.dir/HLAPerspectiveCameraClass.cxx.o CMakeFiles/fgviewer.dir/HLAPerspectiveViewer.cxx.o CMakeFiles/fgviewer.dir/HLAPerspectiveViewerClass.cxx.o CMakeFiles/fgviewer.dir/HLARenderer.cxx.o CMakeFiles/fgviewer.dir/HLARendererClass.cxx.o CMakeFiles/fgviewer.dir/HLASceneObject.cxx.o CMakeFiles/fgviewer.dir/HLASceneObjectClass.cxx.o CMakeFiles/fgviewer.dir/HLAView.cxx.o CMakeFiles/fgviewer.dir/HLAViewClass.cxx.o CMakeFiles/fgviewer.dir/HLAViewer.cxx.o CMakeFiles/fgviewer.dir/HLAViewerClass.cxx.o CMakeFiles/fgviewer.dir/HLAViewerFederate.cxx.o CMakeFiles/fgviewer.dir/HLAWindowDrawable.cxx.o CMakeFiles/fgviewer.dir/HLAWindowDrawableClass.cxx.o -o fgviewer \ -rdynamic /home/pac1/build/master/install-maint-ei/openrti/lib/i386-linux-gnu/libRTI-NG.so \ /home/pac1/build/master/install-maint-ei/openrti/lib/i386-linux-gnu/libFedTime.so \ /home/pac1/build/master/install-maint-ei/simgear/lib/i386-linux-gnu/libSimGearScene.a \ /home/pac1/build/master/install-maint-ei/simgear/lib/i386-linux-gnu/libSimGearCore.a \ /home/pac1/build/master/install-maint-ei/simgear/lib/i386-linux-gnu/libSimGearCore.a \ -rdynamic /home/pac1/build/master/install-maint-ei/openrti/lib/i386-linux-gnu/libRTI-NG.so \ /home/pac1/build/master/install-maint-ei/openrti/lib/i386-linux-gnu/libFedTime.so \ /home/pac1/build/master/install/OpenSceneGraph/lib/libosgText.so \ /home/pac1/build/master/install/OpenSceneGraph/lib/libosgSim.so /home/pac1/build/master/install/OpenSceneGraph/lib/libosgDB.so /home/pac1/build/
Re: [Flightgear-devel] OpenRTI / HLA
Hi, Mathias, some weeks ago I told you about a compilation problem for FG on Linux when RTI is enabled. You asked me to remind you of this problem later, this day is came :) For remembering : > Clement wrote : >> I'm really interested by your work about OpenRTI / HLA. I've added the RTI >> support in the download_and_compile.sh brisa script's in order to make it >> more "user-friendly" to use and participate to the development. I compile >> SG and FG with -DENABLE_RTI=ON since some weeks but today FG compilation >> crashed with this option :/ Here is the compilation log : >> http://pastebin.com/HnPSfyzs >> OpenRTI and SG compilation are fine. I've deleted my OpenRTI/FG/SG build dir >> but the issue still here. Do you have a solution ? > Remind me to look at that past the Christmas days please. Today I gave a new try but the compilation still fails : http://pastebin.com/grfbW2SG SG compilation works fine with ENABLE_RTI=ON but FG compilation fails with it. Can you take a look at it ? Let me know if you need more info, also I can make some change in source code if you tell me what to change. Cheers, Clément -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OpenRTI / HLA
Hi, On Thursday, December 20, 2012 22:22:19 Clement de l'Hamaide wrote: > 1 ) > I'm really interested by your work about OpenRTI / HLA. I've added the RTI > support in the download_and_compile.sh brisa script's in order to make it > more "user-friendly" to use and participate to the development. I compile > SG and FG with -DENABLE_RTI=ON since some weeks but today FG compilation > crashed with this option :/ Here is the compilation log : > http://pastebin.com/HnPSfyzs > OpenRTI and SG compilation are fine. I've deleted my OpenRTI/FG/SG build dir > but the issue still here. Do you have a solution ? Remind me to look at that past the Christmas days please. > 2) > I'd be really happy to use/test HLA unfortunately I haven't found recent > documentation about it. I know about the wiki page > http://wiki.flightgear.org/FlightGear_HLA_support_(High_Level_Architecture) > but this page is not up to date. Looking at your source code it seems that > --hla=bi is no longer the > correct way to activate HLA, but more --hla --federation= Are you able > to tell me/us the current state of your work : Is it currently working ? > can we test ? how can we test ? what are the possible argument ? what is > your dev plan (current step, next step) ? Have we need to be connected to > an HLA server ? Can you explain a litttle bit how it works at architecture > level ? (Is it a centralized server routing every packet between user ? > similar to FGMS network ?) Documentation is flying around a lot. General ones and probably stuff that is too far away to be directly useful. Simgears hla classes should abstract us away from some of these details. I am not exactly convinced that this library is the best design so far, but at least it currently provides something to conveniently access that standard apis. And this should shield away the most popular problems with high algorithmic complexity. The same goes for the rti library below. I am regularily running with this enabled. Also testing a lot here. Currenty cleaning out a lot of proof of concept stuff that lingers around on my local disk. You still can use the the --hla= commands, but there is a shortcut --hla-local which optimizes away a lot of successive ,,, in the command line that I usually had. So, --hla-local=rti://localhost/FlightGear is a shortcut for a longer --hla= line. Steps are currently to clean out my disk and provide what is there. What will come in the shorter term is a standalone viewer that can sit on any of the configured views. There are beginnings of that checked in but there is a lot more in preparation. The fgai is just a brief sketch chat could be done in that corner. It already contains most if what is needed in complex infrastructure. You can inject vehicles and you can now get ground queries. I am for a long time running here also a brief python script which does about the same than fgai. While a scripting language is not fast enough to drive a lot of ai traffic, it is rather nice to do only a few such objects without much worries. Whatever happens here, if you are really driving a lot of ai models it requires a huge amount of thoughts to get that scalable. Updates to specific models as well as specific parts of those need to be updated in an sparse and intelligent way to make this somehow work. This includes the basic part of the fgai implementation which aims to have steady and differentiable movements. This is at this time not made use of so much, but the classes that I called something like *Physics* in there are mostly there to make sure that all components can see and even extrapolate the same steady movements than the originating component does. There is also infrastructure there to play some tricks with timing so that nobody needs to wait for ai traffic updates to arrive - they should just already be there. There is also a small gatweay application translating between the old multiplayer and hla that might go into the utils directory past the next release. So, I was pushed to put this code in the public, even if I personally think that there are still too much opportunities to break stuff. Well, with break I do not mean that it does not run or compile. With break I mean that people just put something together that works either for their private needs and they do not care further, or break in the sense that if you would know the bigger picture it would already be very clear that this cannot scale for the kind of use that will most probably happen in the not so distant future. I can really observe this in the scene and model area. I have really seen incredibly fast osg applications with stable framerates and nifty looking models. But the way we use osg and put together models leaves osg and below that the driver only little chance to be fast. Which leaves only little headroom for sensible further development. Getting back to components: Latencies are a critical part of running in multiple threads/ap
[Flightgear-devel] OpenRTI / HLA
Hi all, Hi Mathias, 1 ) I'm really interested by your work about OpenRTI / HLA. I've added the RTI support in the download_and_compile.sh brisa script's in order to make it more "user-friendly" to use and participate to the development. I compile SG and FG with -DENABLE_RTI=ON since some weeks but today FG compilation crashed with this option :/ Here is the compilation log : http://pastebin.com/HnPSfyzs OpenRTI and SG compilation are fine. I've deleted my OpenRTI/FG/SG build dir but the issue still here. Do you have a solution ? 2) I'd be really happy to use/test HLA unfortunately I haven't found recent documentation about it. I know about the wiki page http://wiki.flightgear.org/FlightGear_HLA_support_(High_Level_Architecture) but this page is not up to date. Looking at your source code it seems that --hla=bi is no longer the correct way to activate HLA, but more --hla --federation= Are you able to tell me/us the current state of your work : Is it currently working ? can we test ? how can we test ? what are the possible argument ? what is your dev plan (current step, next step) ? Have we need to be connected to an HLA server ? Can you explain a litttle bit how it works at architecture level ? (Is it a centralized server routing every packet between user ? similar to FGMS network ?) 3) I've worked on a project called "FGAIS" who is certainly related to your recent "fgai" tools. FGAIS is a modified FGMS server who inject live traffic (in real time from real life) into client session. In this way clients can see aircrafts in the FG sky like he could see them by his windows. For this I've contacted planefinder.net and they agreed to provide their data (only ADS-B). The source code is also ready to implement ship AI. Currently FGAIS work nice only for 1 client (if a second client come on the server I have a SegFault... I don't know why :/ ) You can find the source code here : https://gitorious.org/~f-jjth/fgms/f-jjths-fgms-0-x This modified FGMS server (called FGAIS project) needs SG. You just need to compile it and connect to him with FG client in an active area (LFPO, EDDF, KSFO...) and you will see a dozens of aircraft in your "MP list" : it's live traffic You are free to use any a part of this project if you are interested in it. Some links below : Source code : https://gitorious.org/~f-jjth/fgms/f-jjths-fgms-0-x Wiki page : http://wiki.flightgear.org/FGAIS Forum thread : http://www.flightgear.org/forums/viewtopic.php?f=23&t=17803 Provider : http://planefinder.net/ Since FG is now in a frozen state / debug period the 3) is not important for now but I'm interested to know your opinion about this project. Talking with Hooray on the forum I'm aware that RTI/HLA should be much better for this use. Thanks in advance Cheers, Clément -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
