Re: [Flightgear-devel] f16 model broken?
Istvan Marko wrote: Since the JSBSIM update some days ago the f16 model stopped working properly for me. The elevator appears to be oscillating randomly, it's seemingly in a different position for each frame update. This is visible in the model animation and the aircraft is uncontrollable. Does anyone else see this? I haven't seen it mentioned on the list yet so I am starting to wonder if it's something about my setup. Yes this is known. I have looked at it briefly, but because of time constrains I haven't found the time to fix this. The other JSBSIM models work fine. I am using the CVS HEAD as of now for both code and data. The F-16 model uses more of JSBSim than any other model so far. Changes in the code are more likely to affect the F-16 in some way. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some general questions
Ampere K. Hardraade wrote: I have found another thing that is quite interesting. May be this have something to do with the fact that the opacity of my objects is 98%, but FlightGear seem to have trouble displaying multiple partially transparent objects that are overlapping one another. Yes, but that's really an OpenGL problem rather than a FlightGear problem. For example, if I have a plane with a transparent circle in the middile, and behind it is another plane with a transparent circle in the middle, you won't be able to see the second plane at all through the transparent portion in the first plane. (Semi) transparent objects should be sorted by distance from back to front. In some cases it is possible to determine the order beforehand In case of a HUD for example, it is best to define the canopy before the HUD because in the pilot seat every thing looks like it should be (yes knoe the F-16 has this problem right now) and from the outside few one barely would notice the difference. I believe Frederic has written an animation that does this automatically which is called alpha-test. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: problem with SGLookupFunction (patch included)
Alex Romosan wrote: Erik Hofman [EMAIL PROTECTED] writes: Unfortunately RTLD_DEFAULT isn't supported on all platforms (it isn't supported in IRIX anyhow). I think that if what you describe is the problem this really is a bug at your side. What happens is that the function pointer is copied to ftpr. So dlcose() should never be able to have any effects on this copy ?? dlclose() doesn't have the effect on the pointer. it just makes that pointer point to something non-existent once the handle becomes invalid, hence the core dump. Well, that's the part that I don't get. From the man pages: All objects loaded automatically as a result of invoking dlopen on the referenced object are also closed (however no object still open as a result of any dlopen command is closed until dlclose has closed the last open handle. You see, dlclose keeps a counter of the number of dlopen/dlclose calls and only removes the shared object when dlclose is called as many times as dlopen. FlightGear links directly to libGL, making the number of dlopen calls one more then the number of dlclose calls. This really is a bug in your shared library implementation, ot you have mangled your local copy of FlightGear in such a way that it's dlclosing libGL more than necessary. what you have there is bad programing practice. if you do a search for dlclose and dlsym you will see that nobody uses the pointer returned by dlsym() _after_ a call to dlclose() It's not bad programming practice. It's called knowing what you are doing. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] problem with SGLookupFunction (patch included)
Andy Ross wrote: Erik Hofman wrote: Unfortunately RTLD_DEFAULT isn't supported on all platforms (it isn't supported in IRIX anyhow). I think that if what you describe is the problem this really is a bug at your side. What happens is that the function pointer is copied to ftpr. So dlcose() should never be able to have any effects on this copy ?? I think the idea here is that dlclose() is unmapping the memory region associated with the shared library. The pointer still has the same value, but there are no page table entries associated with that address any more, so an instruction fetch from that address causes a segmentation fault. Yes there should be, dlopen/dlclose keep a counter for the number of dlopen *and dlclose calls and only removed the library when the number of dlclose calls equals the number of dlopen calls. Since FlightGear is linked to libGL at link time, the number of dlclose calls would always be one less than the number of dlopen calls. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some general questions
Erik Hofman wrote: Ampere K. Hardraade wrote: I have found another thing that is quite interesting. May be this have something to do with the fact that the opacity of my objects is 98%, but FlightGear seem to have trouble displaying multiple partially transparent objects that are overlapping one another. Yes, but that's really an OpenGL problem rather than a FlightGear problem. For example, if I have a plane with a transparent circle in the middile, and behind it is another plane with a transparent circle in the middle, you won't be able to see the second plane at all through the transparent portion in the first plane. (Semi) transparent objects should be sorted by distance from back to front. In some cases it is possible to determine the order beforehand In case of a HUD for example, it is best to define the canopy before the HUD because in the pilot seat every thing looks like it should be (yes knoe the F-16 has this problem right now) and from the outside few one barely would notice the difference. I believe Frederic has written an animation that does this automatically which is called alpha-test. alpha-test really works well for fully transparent object because it avoid blending by discarding fragments that have alpha below a clamp value. I also described a method for sorting objects in the animation file : http://baron.flightgear.org/pipermail/flightgear-devel/2004-June/028631.html HTH -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] f16 model broken?
On Fri, 25 Jun 2004 19:03:35 -0700, Istvan wrote in message [EMAIL PROTECTED]: Since the JSBSIM update some days ago the f16 model stopped working properly for me. The elevator appears to be oscillating randomly, it's seemingly in a different position for each frame update. ..the real thing does this too. This is visible in the model animation ..how much? As much as the real thing? AFAIK, the elevators bangs less an inch or so, around 50(?) times a sec, and should appear to see airflow head on(?), and alway below the elevators own stall angle to avoid a departure, an unrecoverable spin, tumble etc, those has claimed a dozen or so F16's. ..another question, is how much slapping do _we_ wanna show? More slaps than the framerate allows, won't be shown, so one idea could be just show the last jerk when the video is ready for every frame. and the aircraft is uncontrollable. ..without a flight control computer (FCC), correct, it slaps air around to keep the plane under pilot control. Orville and Wilbur also did this on their first few planes, and learned the hard way pitch stability is a good idea when flying around without a FCC. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...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. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] f16 model broken?
Since the JSBSIM update some days ago the f16 model stopped working properly for me. The elevator appears to be oscillating randomly, it's seemingly in a different position for each frame update. ..the real thing does this too. Erik's F-16 has been around for a while, and working. So, it may be some change I made recently. There have been a few changes to the FCS. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] problem with SGLookupFunction (patch included)
Erik Hofman wrote: Since FlightGear is linked to libGL at link time, the number of dlclose calls would always be one less than the number of dlopen calls. In which case the dlclose() is 100% guaranteed to be a noop anyway and can be safely removed. :) Seriously: consider the case where this symbol came out of a library that we *don't* link to statically. Then this would undeniably be a bug, because the library would be unmapped before the function could be called. Honestly, this code is just wrong. You don't close the library before calling functions in it, you just don't. Yes, the POSIX docs for dlclose() seem to imply that it should be safe as long as something else has a handle to libGL, but it's still not correct. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] f16 model broken?
Erik's F-16 has been around for a while, and working. So, it may be some change I made recently. There have been a few changes to the FCS. Jon I might add that my changes were to fix things that really were broken. :-) Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: problem with SGLookupFunction (patch included)
Erik Hofman [EMAIL PROTECTED] writes: Since FlightGear is linked to libGL at link time, the number of dlclose calls would always be one less than the number of dlopen calls. this is wrong. the whole idea of linking against a shared library is that you load only the symbols you need. it doesn't mean the library is loaded in memory all the times (that will defeat the whole idea of shared libraries). linking against a shred library doesn't count as a dlopen(). the address the library is loaded at depends on how libc implements it. for linux, the core dump happens when one uses kernel 2.6 and tls enabled. the point is that there is no guarantee the pointer is still valid once you call dlclose(). if you want to guarantee the pointer to the function is still valid after calling dlclose() you hvae to call dlopen() on libGL yourself one more time outside the lookup function. that way the library will stay in the memory all the time (but this is still not a good solution). the only good solution is to make sure you use the pointer before calling dlclose() and that means moving it out of SGLookupFunction() (and hence getting rid of SGLookupFunction). you should also do some error checking with dlerror() for completeness. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some general questions
That example shows how to re-order the objects if they are in the same mesh file. What should I do if the objects that I want to re-order are in two different mesh files? Thanks in advance, Ampere On June 26, 2004 06:16 am, Frederic Bouvier wrote: alpha-test really works well for fully transparent object because it avoid blending by discarding fragments that have alpha below a clamp value. I also described a method for sorting objects in the animation file : http://baron.flightgear.org/pipermail/flightgear-devel/2004-June/028631.htm l HTH -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some general questions
I meant, if in such XML file: ?xml version=1.0? PropertyList pathMD-11.3ds/path offsets z-m0/z-m x-m-25/x-m pitch-deg-0.5/pitch-deg /offsets !-- Cockpit -- model pathAircraft/MD11/Models/cockpit/cockpit.xml/path /model ... /PropertyList How do I change the ordering of MD11.3ds and the mesh that was referenced in cockpit.xml? Thanks in advance, Ampere On June 26, 2004 06:30 pm, Frederic Bouvier wrote: Ampere K. Hardraade wrote: That example shows how to re-order the objects if they are in the same mesh file. What should I do if the objects that I want to re-order are in two different mesh files? Thanks in advance, Ampere On June 26, 2004 06:16 am, Frederic Bouvier wrote: alpha-test really works well for fully transparent object because it avoid blending by discarding fragments that have alpha below a clamp value. I also described a method for sorting objects in the animation file : http://baron.flightgear.org/pipermail/flightgear-devel/2004-June/028631.htm l In the end, it is a scenegraph in memory, so it doesn't matter if the geometry is in 1 or more files. Animation works on objects loaded in memory. When you add a submodel ( for instance, an instrument ) to your main model, it ends up as a branch of the main model. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: f16 model broken?
Arnt Karlsen [EMAIL PROTECTED] writes: On Fri, 25 Jun 2004 19:03:35 -0700, Istvan wrote in message [EMAIL PROTECTED]: Since the JSBSIM update some days ago the f16 model stopped working properly for me. The elevator appears to be oscillating randomly, it's seemingly in a different position for each frame update. ..the real thing does this too. This is visible in the model animation ..how much? As much as the real thing? AFAIK, the elevators bangs less an inch or so, around 50(?) times a sec [...] The frequency could be right (I get around 25fps so hard to say) but the movement looks a lot more than an inch. As far as I can see the elevators constantly flicker across their whole range of possible positions. You might be on the right track though. I just experimented some more: If I start out with sitting on the runway, no wind, zero airspeed the elevators are steady. As soon as I start rolling, even at a low speed they go crazy. And the flickering doesn't stop even after I come to a full stop again. -- Istvan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
