Re: [Flightgear-devel] AI Carrier with Aircraft, and the last JSBSim version
On lun 25 août 2008, Jon S. Berndt wrote: Hello, ... In order to get these data into the JSB FDM, the crude solution could be, to include the yasim calculation part into JSBSim. I feel that won't be the more elegant solution, and i am not sure that Jon would agree on it. :) Though, i am not aware, about the FG source organisation, i dare that question: Won't it be possible to calculate and to give on request ( when we are close to a Carrier ) these data. I mean, the cats and wires positions ? Cheers -- Gérard http://pagesperso-orange.fr/GRTux/ As posted by Dave in the JSBSim mailing list, I firmly agree: determining carrier location and orientation should not be an FDM specific function. This needs to be more configurable from the FlightGear side, so any FDM can take that information and do with it what it needs to do cat/hook ops. Jon YES, the problem won't be technical, but mainly a policy problem. Since that feature is included into YASim , I fear the answer (again, i got it..), for model which want carrier features, YASim answer the request :). I hope that the prize to do it, will not be too high. Cheers -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] AI Carrier with Aircraft, and the last JSBSim version
On mar 26 août 2008, gerard robin wrote: On lun 25 août 2008, Jon S. Berndt wrote: Hello, ... In order to get these data into the JSB FDM, the crude solution could be, to include the yasim calculation part into JSBSim. I feel that won't be the more elegant solution, and i am not sure that Jon would agree on it. :) Though, i am not aware, about the FG source organisation, i dare that question: Won't it be possible to calculate and to give on request ( when we are close to a Carrier ) these data. I mean, the cats and wires positions ? Cheers -- Gérard http://pagesperso-orange.fr/GRTux/ As posted by Dave in the JSBSim mailing list, I firmly agree: determining carrier location and orientation should not be an FDM specific function. This needs to be more configurable from the FlightGear side, so any FDM can take that information and do with it what it needs to do cat/hook ops. Jon YES, the problem won't be technical, but mainly a policy problem. Since that feature is included into YASim , I fear the answer (again, i got it..), for model which want carrier features, YASim answer the request :). I hope that the prize to do it, will not be too high. Cheers Sorry, I answer to myself, :) Though, more the prize is high, more the chances to obtain it, are large More seriously. Won't it be possible to get with a generic Nasal script? with the closest Carrier: The Catapults position with heading. The wire positions Left/right position. Like we have a generic aar.nas (though it is not usable for me, too generic ) we could have, a carrier.nas. I am not a Nasal expert, so can't do it. However, there is so many Nasal expert here ... :) Regards -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] AI Carrier with Aircraft, and the last JSBSim version
On Tue, Aug 26, 2008 at 11:23 AM, gerard robin [EMAIL PROTECTED] wrote: On mar 26 août 2008, gerard robin wrote: On lun 25 août 2008, Jon S. Berndt wrote: As posted by Dave in the JSBSim mailing list, I firmly agree: determining carrier location and orientation should not be an FDM specific function. This needs to be more configurable from the FlightGear side, so any FDM can take that information and do with it what it needs to do cat/hook ops. I might be misunderstanding something here, but currently the generic groundcache code returns catapults and wires: // Return the nearest catapult to the given point // pt in wgs84 coordinates. double get_cat(double t, const SGVec3d pt, SGVec3d end[2], SGVec3d vel[2]); // Return 1 if the hook intersects with a wire. // That test is done by checking if the quad spanned by the points pt* // intersects with the line representing the wire. // If the wire is caught, the cache will trace this wires endpoints until // the FDM calls release_wire(). bool caught_wire(double t, const SGVec3d pt[4]); // Return the location and speed of the wire endpoints. bool get_wire_ends(double t, SGVec3d end[2], SGVec3d vel[2]); // Tell the cache code that it does no longer need to care for // the wire end position. void release_wire(void); The FDM only has to use this information. I have done that for the wires, but I don't understand the catapult model so couldn't do the cats. -- Csaba/Jester - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] UNC, Argentina:JSBsim Compilation
On Tue, Aug 26, 2008 at 6:08 AM, Gonzalo Rubio [EMAIL PROTECTED] wrote: The objetive of the project is to fly both the real plane and the simulator at the same time and together with and adquisition data system compare both reality and virtual performance. I believe Curt does similar things. The reason i`m writing is because i dont have experience in C++ code compilation, i`ve downloaded the source code, but still have problems to achieve a correct compilation. Could anyone please explain me how you are doing to do this and guide me trough the process? You are welcome to join us in the #flightgear IRC channel for real-time help with compilation. -- Csaba/Jester - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Air Refueling was AI Carrier with Aircraft, and the last JSBSim version
On mar 26 août 2008, Melchior FRANZ wrote: I intend to merge Generic/aar.nas with Nasal/fuel.nas (which are almost the same already), and to offer a simple interface for special needs. The detection of a tanker (not necessarily a flying one) is a generic job, and so is refueling. The part that may differ is what happens with fuel that entered the aircraft. And for that we could just write the fuel amount to a property. An aircraft could then attach a listener to that which takes the fuel and does whatever it likes, and finally resets the property to zero. m. Hello Melchior, The specific air refueling and or fuel.nas makes problems if the Aircraft has some specific tank management, for instance Crusader has a specific transfer tank which feed the others, Blackbird has an other process in order to manage the balance and so on. In addition to it, we may want to start or not the refuel according to some specific animation , or electrical conditions or etc As, i told before, depending on the FDM we can, more or less, include part of these specific features into the FDM itself, JSBSim is able to take it. It is able to work from the property/systems/refuel/contact/property. Unfortunately since FG (some time ago 1 year may be 2 ) has got some modifications regarding the original aar. we need to activate that property/systems/refuel/contact/property. from a Nasal script. If we don't mind about these customized process, the aar.nas is a very good tool which makes the life, to models developers, very nice, having farniente :) Cheers NB: Regarding the new type probe/boom which is defined into into the model.xml with nasal, won't it be possible to define it, into the demo.xml file instead of it ? I know that the shape of the probe versus boom are not the same , however it will be easier to define a tanker KC135 with boom or probe according to the needs, An other refueling_demo.xml file with KC135 with probe -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT
* Curtis Olson -- 8/21/2008 5:46 PM: I also really like how svn handles group and user authentication ... it does it outside of the unix account system which makes the system much easier to manage. Unix permissions are well understood and not hard to handle. They are the most straightforward way to handle user rights. Not surprising, given that that's what they were invented for. But there are two add-ons for git to manage user permissions via a single system account. (I sent you a private mail about them a few weeks ago.) From the standpoint of taking small steps, I think it makes sense to migrate towards svn, and then we can still keep the git discussion open as a separate issue. In theory, yes. In practice I doubt it. Once we switched to SVN you will consider it good enough and won't seriously look at GIT again. Even our broken CVS setup was considered good enough for years, until today, although the creator of a directory now owns it, and you have to manually fix the permissions to let anyone else write to it. You didn't have time to fix that. For years. I don't like SVN much. Sure, change sets and moving files are something that we'd really need. But I find the .svn dirs messy and not trustworthy. Once I got a network interruption during updating, and I could not resume. (No, svn cleanup didn't help.) I had to check out everything again. But then again, I still don't really know how well GIT would work for us. It's perfect for text files -- for code. But it would make me a bit nervous if an aircraft developer commits several pointless updates of 5MB sound files. GIT can't compress that. We'd collect the whole pile on our disks. How much would disk space requirements grow each year? m. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Air Refueling was AI Carrier with Aircraft, and the last JSBSim version
On mar 26 août 2008, Melchior FRANZ wrote:
* gerard robin -- 8/26/2008 2:32 PM:
The specific air refueling and or fuel.nas makes problems if the Aircraft
has some specific tank management, for instance Crusader has a specific
transfer tank which feed the others, Blackbird has an other
process in order to manage the balance and so on.
With the generic interface an aircraft could just refuse to take any fuel,
based on electrical system, or whatever. The idea again is something like
this in fuel.nas (with merged in aar.nas):
fuel_interface.setDoubleValue(offered_amount);
var accepted_amount = fuel_interface.getValue();
if (!accepted_amount)
return;
if (accepted_amount 0)
fill_tanks(accepted_amount);
subtract_from_tanker(abs(accepted_amount));
Normally, no listener is attached to node fuel_interface, so the value
will be the same after reading in again, and all that was offered in this
cycle will be filled into all active tanks, just as it's the case now. But
an aircraft could attach a listener to that node:
setlistener(fuel_interface, func(n) {
if (don_t_feel_like_tanking) {
n.setDoubleValue(0);# no thanks; offer rejected
} else {
var amount = n.getValue();
do_fancy_stuff_with(amount);
n.setDoubleValue(-amount); # we took *and* distributed it
}
});
... or something.
Today i am not the best to evaluate your proposal, many others could say what
they want.
May be coming here, i will complicate things which are, i guess, requested
simple.
Generic is generic :)
As, i told before, depending on the FDM we can, more or less, include
part of these specific features into the FDM itself, JSBSim is able to
take it.
Yeah, I bet one could code Tetris within a JSBSim config file. Whether it
makes sense is a different matter. ;-)
hmmm Tetris, not sure. :)
Regarding the new type probe/boom which is defined into into the
model.xml with nasal, won't it be possible to define it, into the
demo.xml file instead of it ?
The refueling type must be known over MP/AI. It must also work for
aircraft piloted by a human. The demo XML file is the wrong place for
that. And then the refueling capacities are properties of the tanker,
not of a particular scenario. I agree, however, that using one model
for either refueling type (and select-animating the boom/probe model
based on that) would be a good idea.
m.
Oh right i forgot MP.
The other alternative could be to create an other
data/Models/Geometry/KC135/KC135_probe.xml file with the
nasal .setValue(probe),
We need, too, a other additional demo.xml file.
We save the .ac file which remain the same:)
--
Gérard
http://pagesperso-orange.fr/GRTux/
J'ai décidé d'être heureux parce que c'est bon pour la santé.
Voltaire
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] UNC, Argentina:JSBsim Compilation
On Tue, Aug 26, 2008 at 7:02 AM, Csaba Halász wrote: On Tue, Aug 26, 2008 at 6:08 AM, Gonzalo Rubio wrote: The objetive of the project is to fly both the real plane and the simulator at the same time and together with and adquisition data system compare both reality and virtual performance. I believe Curt does similar things. I've done something similar, but only with a pretty crude level of detail. Still, I'm fairly proud of the results. The first UAV platform I worked with was a Sig Rascal 110 (110 wing span.) With the help of aeromatic and one of the JSBSim developers (David?) we developed an initial approximate JSBsim model for the Rascal, and then based on my real life flight experience, I refined some of the model characteristics to get more realistic adverse yaw, roll rates, more realistic pitch moment relative to throttle change, etc. I then used this simulator model to develop a set of autopilot configurations (stages, gains, throw limits, etc.). At the same time, I was developing a flight computer that used the flightgear autopilot code (and property system, and xml parser.) By the time the flight computer was ready for real flight tests, I had moved on to an electric powered senior telemaster (8' wing span) for my development platform. The two airframes were similar enough, that the gains and setup developed with the Rascal simulator model worked out of the box on the real telemaster. I had stable wing leveling and stable pitch hold on my very first real world attempt with the Senior Telemaster. I was very proud of that result. The dynamics of the rascal and telemaster are different enough, that I had to do a bunch of subsequent tuning to optimize my controller, but the fact that it was convergent on the first try was really cool. (Worst case scenario is that the controller diverges and you begin shedding airframe parts in flight.) :-) For the future, I want to experiment with incorporating the nasal script engine into my flight computer. With that in place, I want to be able to write scripts to auto fly various flight test scenarios. The goal here would be to develop a set of very accurate and repeatable flight test profiles that are flown by the flight computer (as directed by the script engine at a high level). I think this would be a very useful and very powerful for characterizing the dynamics of a UAV. There's a chicken/egg issue here, but if you develop and refine the simulation model in parallel to developing and refining your autopilot configuration, I think you could boot strap yourself pretty quickly. And if we start building up a set of proven autopilot configurations for a variety of platforms, there will be an increasing likelihood that just about anyone can find a working start configuration, and then be able to refine it from there. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Air Refueling was AI Carrier with Aircraft, and the last JSBSim version
On Tue, 26 Aug 2008 16:03:32 +0200, gerard wrote in message [EMAIL PROTECTED]: Yeah, I bet one could code Tetris within a JSBSim config file. Whether it makes sense is a different matter. ;-) hmmm Tetris, not sure. :) ..err, if it can be done, or, if it makes sense? ;o) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Air Refueling was AI Carrier with Aircraft, and the last JSBSim version
Yeah, I bet one could code Tetris within a JSBSim config file. Whether it makes sense is a different matter. ;-) m. Heh. :-) Actually, the point I am interested in is that JSBSim has the capability to apply externally generated forces and moments to the aircraft. I suspect YASim has a similar capability. This is not JSBSim unique - it's simply a good practice. No FDM should have to handle all unique capabilities such as hook/catapult/tow rope, etc. It makes much more sense to handle simple forces and moments and let the calling application sort out the reasoning. Does that make sense? Jon - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] AI Carrier with Aircraft, and the last JSBSim version
On mar 26 août 2008, Melchior FRANZ wrote: * gerard robin -- 8/26/2008 11:23 AM: Won't it be possible to get with a generic Nasal script? with the closest Carrier: The Catapults position with heading. The wire positions Left/right position. Could be problematic. The involved subsystems are handled at different places in the main loop, which can easily cause synchronization problems. (aircraft - FDM update, carrier position - AI update, Nasal loops - event handler, visuals - view manager update). As Czaba wrote, letting the FDM do that (in connection with the fgfs interface code) is more promising. SNIP m. Yes and No, You are right with the wires, if their is any time delay i won't work correctly., and the AC will stop out of the carrier area. With Catapult it is less a problem, with answering time delay, i mean it should work. Catapults features need only to know the starting position with a more or less value precision: a carrier with 20 km speed does 5.6 meter per second = 0.50 1/10 sec = 0.05 1/100 sec The heading won't be a difficulty, the heading of the carrier is not quickly moving. -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] segfault at LFPG
On Sunday 24 August 2008 04:38:36 Csaba Halász wrote: At least 3 of us get immediate segfault most of the time if starting at LFPG. I got various backtraces, mostly from OSG. Sometimes there is a warning similar to this: Warning: deleting still referenced object 0xb2de7f08 of type 'PN3osg10ReferencedE' the final reference count was 0, memory corruption possible. Also, a ton of Use of global in material animation is no longer supported messages, don't know if that has anything to do with it. Anybody else seeing this? Any ideas? FWIW, I;m seeing an occasional segfault. Today, I managed to trap it using gdb. below is the complete stack trace. IIRC, 2D texture loading has been giving occasional problems. This particular error occurred in my new traffic manager version of Flightgear. It doesn't seem to make much of a difference, I guess. Cheers, Durk #0 0x7f3d24ca20e1 in osg::StateSet::compare () from /usr/local/lib64/libosg.so.43 #1 0x7f3d253467e0 in osgDB::SharedStateManager::find () from /usr/local/lib64/libosgDB.so.43 #2 0x7f3d25347488 in osgDB::SharedStateManager::process () from /usr/local/lib64/libosgDB.so.43 #3 0x7f3d25347688 in osgDB::SharedStateManager::apply () from /usr/local/lib64/libosgDB.so.43 #4 0x7f3d253466f1 in osgDB::SharedStateManager::share () from /usr/local/lib64/libosgDB.so.43 #5 0x0090554c in SGLoadTexture2D (staticTexture=true, path=value optimized out, options=value optimized out, wrapu=false, wrapv=true) at model.cxx:68 ---Type return to continue, or q return to quit--- #6 0x008d1d96 in SGMaterial::assignTexture (this=value optimized out, state=0x74e3910, [EMAIL PROTECTED], _wrapu=true, _wrapv=48, _mipmap=value optimized out) at ../../../simgear/scene/model/model.hxx:37 #7 0x008d1eed in SGMaterial::get_state (this=0x74e2d80, n=value optimized out) at mat.cxx:236 #8 0x008e7412 in SGLoadBTG ([EMAIL PROTECTED], matlib=0x725a3c0, calc_lights=true, use_random_objects=true, use_random_vegetation=true) at obj.cxx:394 #9 0x008dbb2d in SGReaderWriterBTG::readNode (this=0xd31140, [EMAIL PROTECTED], options=0x741d2b0) at SGReaderWriterBTG.cxx:73 #10 0x008dc51e in simgear::ModelRegistryCallbacksimgear::DefaultProcessPolicy, simgear::NoCachePolicy, simgear::NoOptimizePolicy, simgear::NoCopyPo---Type return to continue, or q return to quit--- licy, simgear::NoSubstitutePolicy::loadUsingReaderWriter ([EMAIL PROTECTED], opt=0x741d2b0) at ../../../simgear/scene/model/ModelRegistry.hxx:115 #11 0x008dc857 in simgear::ModelRegistryCallbacksimgear::DefaultProcessPolicy, simgear::NoCachePolicy, simgear::NoOptimizePolicy, simgear::NoCopyPolicy, simgear::NoSubstitutePolicy::readNode (this=0xd310d0, [EMAIL PROTECTED], opt=0x741d2b0) at ../../../simgear/scene/model/ModelRegistry.hxx:91 #12 0x00909e9f in simgear::ModelRegistry::readNode (this=0xd304d0, [EMAIL PROTECTED], opt=0x741d2b0) at ModelRegistry.cxx:500 #13 0x7f3d2532d599 in osgDB::readNodeFile () from /usr/local/lib64/libosgDB.so.43 #14 0x008df059 in simgear::TileEntry::obj_load ([EMAIL PROTECTED], geometry=0x7f3d1805cb00, is_base=true, options=0x1) at TileEntry.cxx:237 #15 0x008e1ae0 in simgear::TileEntry::loadTileByName ([EMAIL PROTECTED], options=0x741d2b0) at TileEntry.cxx:419 ---Type return to continue, or q return to quit--- #16 0x008f7edd in simgear::ReaderWriterSTG::readNode (this=0xd30f60, fileName=value optimized out, options=0x741d2b0) at ReaderWriterSTG.cxx:71 #17 0x008dc51e in simgear::ModelRegistryCallbacksimgear::DefaultProcessPolicy, simgear::NoCachePolicy, simgear::NoOptimizePolicy, simgear::NoCopyPolicy, simgear::NoSubstitutePolicy::loadUsingReaderWriter ([EMAIL PROTECTED], opt=0x741d2b0) at ../../../simgear/scene/model/ModelRegistry.hxx:115 #18 0x008dc857 in simgear::ModelRegistryCallbacksimgear::DefaultProcessPolicy, simgear::NoCachePolicy, simgear::NoOptimizePolicy, simgear::NoCopyPolicy, simgear::NoSubstitutePolicy::readNode (this=0xd31030, [EMAIL PROTECTED], opt=0x741d2b0) at ../../../simgear/scene/model/ModelRegistry.hxx:91 #19 0x00909e9f in simgear::ModelRegistry::readNode (this=0xd304d0, [EMAIL PROTECTED], opt=0x741d2b0) at ModelRegistry.cxx:500 #20 0x7f3d25302880 in osgDB::DatabasePager::DatabaseThread::dpReadRefNodeFile () from /usr/local/lib64/libosgDB.so.43 ---Type return to continue, or q return to quit--- #21 0x7f3d25308c76 in osgDB::DatabasePager::DatabaseThread::run () from /usr/local/lib64/libosgDB.so.43 #22 0x7f3d248d9eb0 in OpenThreads::ThreadPrivateActions::StartThread () from /usr/local/lib64/libOpenThreads.so.11 #23 0x7f3d28297040 in start_thread () from /lib64/libpthread.so.0 #24 0x7f3d23efa0cd in clone () from /lib64/libc.so.6 (gdb) bt #0 0x7f3d24ca20e1 in osg::StateSet::compare () from /usr/local/lib64/libosg.so.43 #1 0x7f3d253467e0 in osgDB::SharedStateManager::find
Re: [Flightgear-devel] Another OpenSource FlightSim based on OSG
On Monday 25 August 2008, Heiko Schulz wrote: Hi, Just a quick note: Today I found another OpenSource FlightSim which uses OSG. It is under GPL-licence, and has as features like: Carrier landing mission. Motion blur (-motion-blur). Sky dome. Sound effects (PLIB) Particle-system (improved explosions). Collision-detection. Can download satellite imagery and render spherical Earth using OSSIM. It uses our aircrafts, and looks quite nice. Maybe the source codes there are interesting for further developing of FlightGear? Look at: http://www.palomino3d.org/ Cheers HHS still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html That's interesting. I noticed that he hasn't got all the animations working yet and I couldn't find anything about the FDMs, but the ground cover imagery looks good. LeeE - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
