Re: [Flightgear-devel] broken rendering for jpg server?
Birger Brunswiek wrote: Using FlightGear's 0.9.5 http jpg server I, sometimes, get incompletely rendered images. The scenery around is missing some of the triangles and they appear as grey, blueish spots This resembles me of rendering errors with not-that-uptodate XFree86/DRI drivers for ATI Radon. I remember that they got replicated in screenshots, probably in these JPEG images as well, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: crease for ac3d files and speedup
Ampere K. Hardraade wrote: On October 13, 2004 09:44, Frederic Bouvier wrote: You can't ask too much from an Intel Graphic processor. IIRC, it doesn't use dedicated memory for textures and buffers, but rather your main memory. My notebook, that features an ATI IGP, has a bios parameter to reserve memory for graphic operation. When I want to do 3d, I have to allocate more to the graphic processor and less to the OS. My AGP Apeture Size is 64MB, but framebuffer is 8MB. I have also assigned an addition of 64MB for video via XF86Config, but the result is still the same. Look in your *BIOS* settings. It isn't the AGP Aperture, it is the amount of main memory dedicated to graphic operations. You can't have good framerate if you only allocate 8Mb. I am afraid the additional 64Mb you have in XF86Config is allocated in system memory, not directly managed by the graphic chip. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] DOS line endings in base package
Ampere K. Hardraade wrote: I know. I am proposing that it may be a good idea to cut it down further so that the archive is around 40MB. I've just did some googling today, and I found that I am not the only one who see the size of the archive as a problem. I've been thinking about it and am more and more in favor of splitting up the download in the base package (including the C172 and some twin engine commuter) and an add-on package. The 3d models should then be saved in AC3d format (*.ac) because that is the file format that is used by FlightGear. (FYI Blender can import and export into *.ac file format) I am seeing a serious problem here: people thinks that FlightGear only supports AC3D! We really need to get those people to know that FlightGear supports variety of 3d formats. We especially need to stress that one can uses GMAX for modelling, so that people who have experience in modelling for MSFS would feel comfortable switching over, instead of asking what the heck is ac3d. I would request holding off stressing out the possible file formats we support right now. There has been some discussion behind the scenes that may affect the number and type of file formats we support. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] broken rendering for jpg server?
Martin Spott wrote: Birger Brunswiek wrote: Using FlightGear's 0.9.5 http jpg server I, sometimes, get incompletely rendered images. The scenery around is missing some of the triangles and they appear as grey, blueish spots This resembles me of rendering errors with not-that-uptodate XFree86/DRI drivers for ATI Radon. I remember that they got replicated in screenshots, probably in these JPEG images as well, Probably, they all use the same function now. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] broken rendering for jpg server?
Erik Hofman wrote: Martin Spott wrote: This resembles me of rendering errors with not-that-uptodate XFree86/DRI drivers for ATI Radon. I remember that they got replicated in screenshots, probably in these JPEG images as well, Probably, they all use the same function now. Aaah, I found an old example from summer last year - is this a similar effect ? http://document.ihg.uni-duisburg.de/bitmap/FGFS/artefact_01.png Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs]
Martin Spott wrote: Erik Hofman wrote: Update of /var/cvs/FlightGear-0.9/data/Aircraft/737/Models In directory baron:/tmp/cvs-serv23677/Aircraft/737/Models Modified Files: B737-300.ac Log Message: This one includes the smooth shaded 737 and tu154B as well as the adf instrument using the object order which is displayed right. Is this the patch provided by Mathias ? Yep. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Velocity, acceleration and rotational rates
Gerhard Wesp wrote: The parameters you need appear to be all there. Of course, nothing is documented so you're on your own... Documentation is also accepted for inclusion in CVS ... Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Digital filters
Hi all! I've added some digital low-pass filters to the autopilot code. You can now define four different types of digital filters inside the autopilot configuration file. The outputs from these filters could then be used as inputs to PID controllers. I've sent a readme file to Erik that explains how to configure the filters. Hopefully it will be in CVS soon. I've also removed the hardcoded filtering of the helper value: /autopilot/internal/pressure-rate. I know that the KAP140 uses this helper value, so it might affect the pitch axis performance of the default c172 autopilot. A quick grep in the Aircrafts directory showed that nothing else uses pressure-rate. If anyone else uses pressure-rate locally... well you have been warned. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] status of aircraft carrier
Mathias Fröhlich wrote a long time ago: Sent: 08 July 2004 10:38 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] status of aircraft carrier On Mittwoch, 7. Juli 2004 21:32, Vivian Meazza wrote: It would be a shame if we can't model individual wires, then we could experience hook-skip whereby the hook can miss all the wires. A chum of mine went around 14 times trying to catch a wire in a Gannet aboard HMS Hermes. But I think the 'wire-surface' would do quite well. Hmm, let me explain a bit. I for myself will be happy to model the relality in detail. That wire-surface has grown from an experience I have made during the past half year when I wanted to push changes into JSBSim. For example, I often proposed a mechanical system which much better models gears. This is not hard to do from my point of view. But Jon always told me that this stuff is tooo complicated and it is better to keep things as simple as possible. So that 'wire surface' has really grown from a extrapolation of my couterpart in JSBSim to the flightgear community ... ... I am happy with individual wires. It is a bit harder since we do only have the position of the hook at discrete times. But I have also thought about that: Does the surface spaned from the hook in the prevous timestep and the hook in this timestep intersect a wire? If yes we can have a propability where we catch. And if so apply two forces from the ends of the wire. So the API between the FDM and Flightgear will look something like a function taking a geometry of a rectangle and returning a bool which tells if a wire is caught and where the two points are where the wire leaves the deck. And as usual, how these two points move. It's very difficult to manoeuvre an aircraft onto a cat. You should consider modelling the self-aligning rollers and chocks which bodily shift the aircraft into the correct position. This need be no more than a area on the deck on which, if the main wheels are resting on it, a press of a key will automatically correctly position the aircraft. So with a little jump to the right :) Sounds sensible! A key press should signify when the pilot is ready for launch, then the cat should fire after a random interval after. The Jet Blast Deflectors (JBDs) could also be modelled. Hehe :) And a cat officer showing you where to taxi :) And all these guys with yellow and green and whatever jackets :) One by one. But yes ... I think I will put several hundred wires onto KSFO's runway to do the first tests :) I can provide more details if you are interested. Yes, whatever you fell that could be useful. References ... Thanks in advance! In the next couple of days or so I will have completed a model of a Seafire IIIc. It has a functioning hook, so I was set to wondering if there was any progress on the arrester wire project??? In the course of the work on Submodels, I realized that it should be possible to re-use some of that code to provide the location of the hook on a near frame-by-frame basis in geodetic terms. Intersection with a 'wire surface' should be possible to calculate. But then we need to apply a suitable force to the fdm. I wonder if a mega-brake would do the trick??? At least as a first try. A couple of pictures are at: http://myweb.tiscali.co.uk/vmeazza/FlightGear/seafire-001.jpg http://myweb.tiscali.co.uk/vmeazza/FlightGear/seafire-002.jpg Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: crease for ac3d files and speedup
* Curtis L. Olson -- Wednesday 13 October 2004 23:47: I haven't looked closely at the display list stuff. Are we being careful to free the display lists when we free the associated objects and remove them from the scene graph? Is this something that plib should automatically handle (but maybe isn't because we are the first to stress test it?) No, it doesn't look like plib accumulated DLists. I flew the Hunter again from KLAX to KSFO along the coast, then quite a while heading W, into the pacific. KLAX, right after taking off: 22k (i.e.: 22.000 DLists) coast: avg. ~18k (13K--22k, depending on the terrain; peaks at 30k) KSFO: 27k heading W, slowly falling to: 9k exiting from fgfs: 2960 The final 2960 DLists were not freed via glDeleteLists. But in any case: the DLists weren't the cause for excessive memory consumption. It could have been problems with KDE's artsdsp. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: crease for ac3d files and speedup
Melchior FRANZ wrote: * Curtis L. Olson -- Wednesday 13 October 2004 23:47: I haven't looked closely at the display list stuff. Are we being careful to free the display lists when we free the associated objects and remove them from the scene graph? Is this something that plib should automatically handle (but maybe isn't because we are the first to stress test it?) No, it doesn't look like plib accumulated DLists. I flew the Hunter again from KLAX to KSFO along the coast, then quite a while heading W, into the pacific. KLAX, right after taking off: 22k (i.e.: 22.000 DLists) coast: avg. ~18k (13K--22k, depending on the terrain; peaks at 30k) KSFO: 27k heading W, slowly falling to: 9k exiting from fgfs: 2960 The final 2960 DLists were not freed via glDeleteLists. But in any case: the DLists weren't the cause for excessive memory consumption. It could have been problems with KDE's artsdsp. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Those numbers (22k...9k) seam enormous to me. You say 13 to 22k depending on terrain... If I understand well we have one dlist per polygone ? Each terrain chunk (.btg) is loaded and stored in his ssg tree. A range and transform matrix is added at the top of this tree. Isn't it possible to have one Dlist for this whole tree ? Regards. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] broken rendering for jpg server?
Martin Spott wrote: Erik Hofman wrote: Martin Spott wrote: This resembles me of rendering errors with not-that-uptodate XFree86/DRI drivers for ATI Radon. I remember that they got replicated in screenshots, probably in these JPEG images as well, $ lspci|grep VGA 01:00.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX 5200] (rev a1) hmm... not realy a Radeon, or is it... $ rpm -q XFree86 XFree86-4.3.0-55 is that up-to-date enough? XF86Config says driver is nvidia. I'm not sure if that is the one that comes with XFree86 or the one NVidia provides on their website. Aaah, I found an old example from summer last year - is this a similar effect ? http://document.ihg.uni-duisburg.de/bitmap/FGFS/artefact_01.png sort of but not realy, I never have any problems with a screenshot. Also the missing parts tend to be smallish and a lot of them and they are never occour in the nearer sourounding i.e. the one on the bottom of the screenshot you provided would never come up in my case. Birger ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] FTP downloads
Hello, apparently people are downloading from the CD-Images/ directory like mad (about 200 FlightGear-Win32-0.9.5.img these days). Wouldn't it make sense to remove this outdated beast from the servers ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: crease for ac3d files and speedup
The Max is 8Mb. The other settings will make you cry. Is there anyway I can boost the memory allocaated for the frame buffer? Ampere On October 14, 2004 02:59, Frederic Bouvier wrote: Look in your *BIOS* settings. It isn't the AGP Aperture, it is the amount of main memory dedicated to graphic operations. You can't have good framerate if you only allocate 8Mb. I am afraid the additional 64Mb you have in XF86Config is allocated in system memory, not directly managed by the graphic chip. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
