Re: [Flightgear-devel] TaxiDraw-0.2.4 released
On 11/28/04 at 10:40 AM Durk Talsma wrote: I have a question. Would it be an idea to add a gate or parking editor function to taxidraw? The reason I'm asking is that I'm starting to think about ways to improve AI parking at the major airports. So eventually, for the major airports we would need to indicate at which exact coordinates aircraft could park. To me it seems this would be a logical extension of taxidraw. Any ideas? Hi Durk, This shouldn't be too much of a problem. TaxiDraw was originally conceived of as an Afcad like AI network editor, before morphing into a physical taxiway editor. Bear in mind that Bernie added something like this to fgsd, which you might be able to get working more quickly. Give me a shout offlist about what you need and what format if you want it added to TaxiDraw. Cheers - Dave This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.4 released
On 11/29/04 at 11:00 AM Martin Spott wrote: Hello David, David Luff wrote: This is purely a bug-fix release - there is another version in the works with some more features. The instructions to the key commands tell us which key to use in order to achieve which sort of movement (R,D,F,C for shifting objects around, J,K for rotating). Would you consider adding the step size to these instructions, for example how many minutes/seconds of shift or degrees of rotation per keypress ? OK, I'll try and remember to add that to the web and help docs before I do another release. FWIW, J,K = 0.1 degrees Shift+J, K = 3 degrees Ctrl+Shift+J, K = 0.01 degrees R, D, F, C move objects 0.5 meters, or 10 meters with shift down. Holding Shift whilst dragging a taxiway with the mouse constrains it to move in it's longitudional axis only. Cheers - Dave This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.4 released
David Luff wrote: J,K = 0.1 degrees Shift+J, K = 3 degrees Ctrl+Shift+J, K = 0.01 degrees R, D, F, C move objects 0.5 meters, or 10 meters with shift down. Thank you! Does anyone have a current copy of Robin's 'AptNavFAQ' ? Robin's pages on the X-Plane site have disappeared and the copy on the FlightGear pages is totally outdated, 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] TaxiDraw-0.2.4 released
On Tuesday, 30 November 2004 23:04, Arnt Karlsen wrote: ..or, which video cards can , and, can not use these extensions? (I can use that info now, I'm looking for a new card now.) Anything from the Geforce 256 era and up support most of the DXTC/S3TC texture compression formats whether it be ATI or nVidia. The Geforce 256 only supports the most important 3 of the 5 texture compression formats. There are 5 formats in total but only DXT1, DXT3 and DXT5 are implemented and supported in most cases. There is little interest in DXT2 and DXT4 which are premultiplied alpha formats. This extension is written against the OpenGL 1.2.1 specification. It is impossible to run most of the newer games nowdays with a card that does not support texture compression. All the big titles like FS2004, Doom3, Unreal Tournament 2003 rely heavily on texture compression. S3's texture compression scheme (S3TC) was licensed to Microsoft who incorporated it into DirectX. It is referred to as DXTC compression in Direct3D but S3TC in OpenGL. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.4 released
On Wed, 1 Dec 2004 17:39:43 + (UTC) Martin Spott [EMAIL PROTECTED] wrote: David Luff wrote: J,K = 0.1 degrees Shift+J, K = 3 degrees Ctrl+Shift+J, K = 0.01 degrees R, D, F, C move objects 0.5 meters, or 10 meters with shift down. Thank you! Does anyone have a current copy of Robin's 'AptNavFAQ' ? Robin's pages on the X-Plane site have disappeared and the copy on the FlightGear pages is totally outdated, They haven't disappeared; they just relocated (with a very slight path change). If you go off the links on the x-plane.org front page you'll get to them. Directly, for the FAQ, see: http://x-plane.org/home/robinp/AptNavFAQ.htm -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear pgp2PPrQRVVNN.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.4 released
On Wed, 1 Dec 2004 19:26:22 +0200, Paul wrote in message [EMAIL PROTECTED]: On Tuesday, 30 November 2004 23:04, Arnt Karlsen wrote: ..or, which video cards can , and, can not use these extensions? (I can use that info now, I'm looking for a new card now.) Anything from the Geforce 256 era and up support most of the DXTC/S3TC texture compression formats whether it be ATI or nVidia. The Geforce 256 only supports the most important 3 of the 5 texture compression formats. There are 5 formats in total but only DXT1, DXT3 and DXT5 are implemented and supported in most cases. There is little interest in DXT2 and DXT4 which are premultiplied alpha formats. This extension is written against the OpenGL 1.2.1 specification. It is impossible to run most of the newer games nowdays with a card that does not support texture compression. All the big titles like FS2004, Doom3, Unreal Tournament 2003 rely heavily on texture compression. S3's texture compression scheme (S3TC) was licensed to Microsoft who incorporated it into DirectX. It is referred to as DXTC compression in Direct3D but S3TC in OpenGL. ..aha. Thanks, Paul. -- ..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 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.4 released
On Mon, 29 Nov 2004 23:50:36 -0500, Chris wrote in message [EMAIL PROTECTED]: On Tue, 30 Nov 2004 06:33:36 +0200 Paul Surgeon [EMAIL PROTECTED] wrote: It's pretty neat technology. No decompression is required as reading a texture is done on the fly when it's required. If only a portion of the compressed texture is used in a scene then only the required pixels of the texture are decoded and used. One would be able to stick nearly 768MB of textures onto a video card with 128MB of VRAM. The IO saved is enormous if you were trying to send all those textures to the video card for each frame. It does sound really, really cool. One concern: how widespread is the availability of these two OpenGL extensions? ..or, which video cards can , and, can not use these extensions? (I can use that info now, I'm looking for a new card now.) -- ..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 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.4 released
On Sun, 28 Nov 2004 20:34:51 -0600 Curtis L. Olson [EMAIL PROTECTED] wrote: I can think of 4 approaches to defining taxiways and lines. [ snip ] 2. Draw the taxi lines as separate polygons over the top of the taxiways and runways. [ snip ] But this scheme would burn a lot of polygons and it would require some complex preprocessing of the line polygons to clip them against all the underlying triangles. That would be no small task ... (writing the code to do that.) 3. Cut the lines right into the geometry ... i.e. cut holes for the lines. [ snip ] . . .we'd still be burning a fairly high number of polygons. So while #2 and #3 hold the most promise in the near term, the fact is that they require a lot of polygons. If I remember correctly, the issue with using vmap1 data (rather than vmap0) to improve the accuracy of roads/railroads/land use contours/etc. is also polygon count, right? What I'm wondering is how well known the constraints here are? Presumably some time in the past, someone created a scenery tile that had tons and tons of polygons and their framerate went into the dirt. Was it really old hardware? How high was the visible poly count, and how bad did their framerate get hit? That kind of thing. IOW, do we know that fgfs framerates are basically polygon-count-limited at this point? Maybe this is just a fool's hope on my part, but perhaps we worry about this more than we need to? Maybe everything will be fine. -c P.S. Maybe even vmap1 would work. Or has someone tried it recently, and the results were awful? -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear pgpFO9PkXPhMC.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.4 released
Hello David, David Luff wrote: This is purely a bug-fix release - there is another version in the works with some more features. The instructions to the key commands tell us which key to use in order to achieve which sort of movement (R,D,F,C for shifting objects around, J,K for rotating). Would you consider adding the step size to these instructions, for example how many minutes/seconds of shift or degrees of rotation per keypress ? Thanks, 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] TaxiDraw-0.2.4 released
On Monday, 29 November 2004 04:34, Curtis L. Olson wrote: 2. Draw the taxi lines as separate polygons over the top of the taxiways and runways. We would need to use glPolygonOffset, and make sure we split all the taxiway lines at the borders of all the underlying surface triangles so that the taxilines always lay in the perfect plane of the underlying surface triangles. Number 2 is the route I was planning to take. There would be no need for an unlimited set of textures and we could add the black tire marks too, not just the taxiway lines. Clipping the lines against the underlying polygons is a bit tricky but not that hard. I was just going to float the polygons on top of each other with a *very* small offset so that there would be no z fighting and yet no visible floating. I'm not too sure how well this would work as I haven't reached that stage yet. round number.) That's 28Mb worth of texture, and if you do mipmapping, that's more like 56Mb of texture ... just for one tile and not a very high resolution. What do you do if you are near the corner and need 4 tiles at high resolution ... either you need to break this down into much smaller tiles so that you have only a few small areas at the highest res, or you need a ton of video ram, because you still need all the other textures loaded along with these per tile textures. And it would be nice to be able to do 1 or 2m per pixel which is just that much more video ram. That's why MS use DXT texture compression. The DXT (S3TC) texture compression formats use a form of lossy vector quantization to compress texture images by a ratio of 4:1 or 6:1. These formats are a standard part of Direct3D, and are available in OpenGL via the ARB_texture_compression and GL_EXT_texture_compression_s3tc extensions. Texture compression works very well for color maps. The textures are stored in compressed format which makes loading a lot quicker and saves lots of IO when being transferred to the video card. Without texture compression technology FS2004's scenery would not be possible. Anyway, sorry for the tangent ... From a wysiwyg editor stand point, #2 or #3 would probably be the easiest, and probably equivalent from the editing side. You define taxiway lines independent of the taxiway surface and you don't have to worry about combining basic textures with line primatives embedded in them. Actually I would only define the taxiway lines seperately for non-standard stuff. The taxiway lines would normally be drawn automatically based on the properties of the taxiway segments. #4 is probably better left for next year or the year after. :-) Number 4 would not be hard to implement later on. I'm using OpenGL so it would just be a matter of rendering to a texture and exporting the elevation data. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.4 released
On Mon, 29 Nov 2004 12:53:43 -0600, Curtis wrote in message [EMAIL PROTECTED]: Paul Surgeon wrote: Number 2 is the route I was planning to take. There would be no need for an unlimited set of textures and we could add the black tire marks too, not just the taxiway lines. Clipping the lines against the underlying polygons is a bit tricky but not that hard. I was just going to float the polygons on top of each other with a *very* small offset so that there would be no z fighting and yet no visible floating. I'm not too sure how well this would work as I haven't reached that stage yet. Unfortunately, it doesn't work as well as you'd like ... the z-buffer is finite resolution (usually 24 or 16 bit depth depending on how you ..not 32? have your card/display configured.) What this means is that a range of depths map to each possible depth buffer value. Usually the z-buffer is implemented so that there is much finer grained precision up close versus far away. Changing the near clip plane (pushing it away from you) has a big implact on z-buffer resolution. Changing the far plane has minimal impact. What you'll find then is at altitude, even a meter difference can map to the same depth buffer value, but with floating point rounding differences from frame to frame (as the view perspective moves), you'll get z-buffer fighting. You can use glPolygonOffset in some circumstances to work around the z-buffer problems but only if you are drawing polygons and only if the polygons really live in exactly the same plane factoring all floating point rounding possibilities. I.e. if the polygons don't share exactly the same verticies they likely will round different directions in some situations and you are back to having z-buffer fights. It's a nasty problem. I've seen some applications that do a good job of handling it, but they have obviously put in a *ton* of time working out the issues (and are probably only running on a single specific kind of hardware/video card.) That's why MS use DXT texture compression. The DXT (S3TC) texture compression formats use a form of lossy vector quantization to compress texture images by a ratio of 4:1 or 6:1. These formats are a standard part of Direct3D, and are available in OpenGL via the ARB_texture_compression and GL_EXT_texture_compression_s3tc extensions. Texture compression works very well for color maps. The textures are stored in compressed format which makes loading a lot quicker and saves lots of IO when being transferred to the video card. Without texture compression technology FS2004's scenery would not be possible. Do the textures stay compressed in video ram, does the texture render unit render from the compressed texture, or does it have to uncompress it in video ram before rendering it? If it can stay compressed all the time in video ram (I'm doubtful) then this would be a great savings. But if it is only compressed on your HD, then this isn't all that great of a thing ... good for reducing disk space and disk IO, but doesn't help the run time rendering issues all that much. Number 4 would not be hard to implement later on. I'm using OpenGL so it would just be a matter of rendering to a texture and exporting the elevation data. Yes, not so hard to do a naive implimentation that assumes infinite resources. But the difficulties arise with managing *huge* volumes of texture data on the video card, and to do that on todays hardware you probably have to get extremely clever, and your nice pristine implimentation would have to be hacked all over the place to work around real world limitations. :-( ..you guys are aware of these guys?: http://www.gpgpu.org/developer/ http://www.cma.uio.no/conferences/2004/gpu_workshop.html http://www.sintef.no/static/AM/gpu/ http://www.sintef.no/static/AM/gpu/webreferences.html -- ..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 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.4 released
On Monday, 29 November 2004 20:53, Curtis L. Olson wrote: I.e. if the polygons don't share exactly the same verticies they likely will round different directions in some situations and you are back to having z-buffer fights. It's a nasty problem. I've seen some applications that do a good job of handling it, but they have obviously put in a *ton* of time working out the issues (and are probably only running on a single specific kind of hardware/video card.) Hmmm ... that's not good news. The only way to make sure the polygons share the exact same vertices is to slice the lines into the underlying polygons which is a whole lot more work and increases the polygon count too. Plus you end up with seam artifacts which need to be worked around. :-\ Do the textures stay compressed in video ram, does the texture render unit render from the compressed texture, or does it have to uncompress it in video ram before rendering it? I'm not sure about that - I'll have to makes some inquiries and find out how video cards actually handle the rendering of compressed textures. There would be no point if all the textures were uncompressed at the same time into VRAM. The nice thing with compressed textures is that they are fairly simple to implement. The loading is the hardest part. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.4 released
On Tue, 30 Nov 2004 01:15:27 +0200 Paul Surgeon [EMAIL PROTECTED] wrote: On Monday, 29 November 2004 20:53, Curtis L. Olson wrote: Do the textures stay compressed in video ram, does the texture render unit render from the compressed texture, or does it have to uncompress it in video ram before rendering it? I'm not sure about that - I'll have to makes some inquiries and find out how video cards actually handle the rendering of compressed textures. There would be no point if all the textures were uncompressed at the same time into VRAM. From http://www.simforums.com/forums/forum_posts.asp?TID=4958PN=1 [ snip ] } The compressions are not meant to save disk drive space (plenty of it) } but to: } } -reduce the video card memory useage, as since the Geforce2, video } cards can directly render a compressed texture on a 3D polygon without } decompressing it [ snip ] -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear pgp1XF3p2GhAi.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] TaxiDraw-0.2.4 released
Chris Metzler writes: Paul Surgeon wrote: Curtis L. Olson wrote: Do the textures stay compressed in video ram, does the texture render unit render from the compressed texture, or does it have to uncompress it in video ram before rendering it? I'm not sure about that - I'll have to makes some inquiries and find out how video cards actually handle the rendering of compressed textures. There would be no point if all the textures were uncompressed at the same time into VRAM. From http://www.simforums.com/forums/forum_posts.asp?TID=4958PN=1 [ snip ] } The compressions are not meant to save disk drive space (plenty of it) } but to: } } -reduce the video card memory useage, as since the Geforce2, video } cards can directly render a compressed texture on a 3D polygon without } decompressing it [ snip ] This is true . but don't forget the gain achieved by reducing the disk to memory bandwith required just-need-bigger-disks'ly yours Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.4 released
On Mon, 29 Nov 2004 22:25:49 -0500 Norman Vine [EMAIL PROTECTED] wrote: This is true . but don't forget the gain achieved by reducing the disk to memory bandwith required Absolutely; but this issue (whether the video card can render the compressed textures without decompressing first) is what Paul and Curt were unsure of, if I'm following this. Of course, this also presumes that the guy I quoted knew what he was talking about. I know *I* don't know much about this stuff, thus don't know enough to say. -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear pgpesaHYWTr3e.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.4 released
On Tuesday, 30 November 2004 01:54, Chris Metzler wrote: [ snip ] } The compressions are not meant to save disk drive space (plenty of it) } but to: } } -reduce the video card memory useage, as since the Geforce2, video } cards can directly render a compressed texture on a 3D polygon without } decompressing it [ snip ] It's pretty neat technology. No decompression is required as reading a texture is done on the fly when it's required. If only a portion of the compressed texture is used in a scene then only the required pixels of the texture are decoded and used. One would be able to stick nearly 768MB of textures onto a video card with 128MB of VRAM. The IO saved is enormous if you were trying to send all those textures to the video card for each frame. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.4 released
On Tue, 30 Nov 2004 06:33:36 +0200 Paul Surgeon [EMAIL PROTECTED] wrote: It's pretty neat technology. No decompression is required as reading a texture is done on the fly when it's required. If only a portion of the compressed texture is used in a scene then only the required pixels of the texture are decoded and used. One would be able to stick nearly 768MB of textures onto a video card with 128MB of VRAM. The IO saved is enormous if you were trying to send all those textures to the video card for each frame. It does sound really, really cool. One concern: how widespread is the availability of these two OpenGL extensions? -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear pgpeZQZYAZHXF.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.4 released
On Wednesday 24 November 2004 18:22, David Luff wrote: I've put TaxiDraw-0.2.4 up at http://www.nottingham.ac.uk/~eazdluf/taxidraw.html. This is purely a bug-fix release - there is another version in the works with some more features. Changes from 0.2.3 to 0.2.4 are: I just downloaded and installed taxidraw for the first time. Looks neat and fairly easy to use. I have a question. Would it be an idea to add a gate or parking editor function to taxidraw? The reason I'm asking is that I'm starting to think about ways to improve AI parking at the major airports. So eventually, for the major airports we would need to indicate at which exact coordinates aircraft could park. To me it seems this would be a logical extension of taxidraw. Any ideas? Cheers, Durk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.4 released
Durk Talsma a écrit : On Wednesday 24 November 2004 18:22, David Luff wrote: I've put TaxiDraw-0.2.4 up at http://www.nottingham.ac.uk/~eazdluf/taxidraw.html. This is purely a bug-fix release - there is another version in the works with some more features. Changes from 0.2.3 to 0.2.4 are: I just downloaded and installed taxidraw for the first time. Looks neat and fairly easy to use. I have a question. Would it be an idea to add a gate or parking editor function to taxidraw? The reason I'm asking is that I'm starting to think about ways to improve AI parking at the major airports. So eventually, for the major airports we would need to indicate at which exact coordinates aircraft could park. To me it seems this would be a logical extension of taxidraw. Any ideas? That was the purpose of the taxi editor branch of fgsd. But this effort from Bernie B. has stalled now. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.4 released
Paul Surgeon wrote: In short we need a vastly improved TaxiDraw or a new replacement. The only hassle is that genairports cannot handle any new types of data so that would need modifying too. To my understanding is _not_ TaxiDraw or 'genairports' that produces hassle - TaxiDraw is just an application that plays on the keyboard of the current infrastructure. Instead, the key point is compatibility with Robin's airport database which instantiates the ongoing dependency of FlightGear on the X-Plane development. Although I heavily dislike this dependency I realize that one would'nt easily discard such an effort that has been so helpful over a long time. Whatever you do on the FG side you still should keep some two-way data exchange with X-Plane as an option. One could agree on the least common denominator: The taxiway layout described by the center, orientation, length, width and surface of a runway/taxiway. You always can add additional information for FG, but you should still be able to generate airports with 'basic' data - right from the X-Plane database - or export to the X-Plane format. I know, here I present that key argument _against_ my own beloved idea of generating airports from shapfiles or similar data :-/ I believe the first step is not to replace TaxiDraw but to improve/rewrite the airport generator to handle the current X-Plane format _plus_ whatever you'd like to add. If this is done, one could think about what to do with TaxiDraw, 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] TaxiDraw-0.2.4 released
Please let me respond to a couple of these points ... Paul Surgeon wrote: First we need to get away from single line taxiways. At the moment taxiways are handled like runways which limits them to rectangular shapes. We only support these kind of taxiways because that is the only kind of data we have available. If someone wanted to push forward with better taxiways, let's talk ... it's probably not too hard to add support to the genapts util, and hopefully not too hard to add something to taxidraw. In short we need a vastly improved TaxiDraw or a new replacement. The only hassle is that genairports cannot handle any new types of data so that would need modifying too. Sure, these tools would have to be developed in tandom ... that would be a natural way to do it. It doesn't necessarily make sense to support a bunch of formats in genapts that no one can create and for which no data exists. Similarly it doesn't make sense to be able to create data if it can't be used when building airports ... these things have to happen together. Ideally the taxiways, aprons, gates, etc should be able to be inserted into the scenery without the need to rebuild the scenery There are advantages and disadvantages to every approach ... to do a good job of inserting airports into the scenery, you need to know things about the airport. If these things change, it makes sense to rebuild the scenery around it. But, for airport designers, there's not necessarily immediate feedback. In the short term you can regenerate the airport model and copy it over the old one and that works, but if the apt outline changes at all there will be a border mismatch until the surrounding terrain is rebuilt. which as I understand it is nearly impossible unless you own a super computer with gigs of RAM. (See Jason Cox's hassles where he cannot even make a 1x1 degree tile with 700+ MB or RAM) I don't know ... I happily build the world on two 512Mb machines ... and the only place where I wished I had more RAM was when I split up the global shore line database into FG tiles, but that is already done so I don't have to do it again. Unfortunately all the 3D geometry and logic involved is time consuming and not trivial (at least not for my brain). Exactly ... it's non-trivial stuff. The basics aren't all that hard, but the details get tough ... edge matching tiles, working around and avoiding degenerate situations, etc. In short the setup we have now sucks and there will be no near term solution. One day someone will have a stab at it ... one day when the need becomes more pressing and someone is bored. :) I'm sure David would write us an excellent, feature filled TaxiDraw if he was paid to do it full time. Useful code contributions are rarely rejected ... Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.4 released
Erik Hofman wrote: Paul Surgeon wrote: First we need to get away from single line taxiways. At the moment taxiways are handled like runways which limits them to rectangular shapes. What would be nice is to be able to use AC3D files (for example) as taxiway imports (for example by handling it as 2D maps and skip the y-axis information), then we may and up with something like this: http:/www.ehtw.info/images/layout.jpg There's no reason why taxidraw (with a bit of hacking) couldn't draw a 3d view of the data ... and export it in various formats. It would be some effort, but wouldn't be rocket science. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.4 released
Martin Spott wrote: To my understanding is _not_ TaxiDraw or 'genairports' that produces hassle - TaxiDraw is just an application that plays on the keyboard of the current infrastructure. Instead, the key point is compatibility with Robin's airport database which instantiates the ongoing dependency of FlightGear on the X-Plane development. Although I heavily dislike this dependency I realize that one would'nt easily discard such an effort that has been so helpful over a long time. Whatever you do on the FG side you still should keep some two-way data exchange with X-Plane as an option. One could agree on the least common denominator: The taxiway layout described by the center, orientation, length, width and surface of a runway/taxiway. You always can add additional information for FG, but you should still be able to generate airports with 'basic' data - right from the X-Plane database - or export to the X-Plane format. I know, here I present that key argument _against_ my own beloved idea of generating airports from shapfiles or similar data :-/ I believe the first step is not to replace TaxiDraw but to improve/rewrite the airport generator to handle the current X-Plane format _plus_ whatever you'd like to add. If this is done, one could think about what to do with TaxiDraw, There has been some small amount of discussion with Robin about giving the FG project a code range that we would own. Each line in the apt.dat has a key code saying the type of info it contains, and so we could have a range of codes that are dedicated to FG use and would be guaranteed never to conflict with X-Plane code expantion. When Robin releases new data and Dave integrates our local changes that haven't yet been accepted by Robin, he could also integrate the specific FG info for all the airports we have specific FG info. This would produce a FG specific apt.dat file which could easily be stripped of the extra FG codes to return it to pristine X-Plane format. It also makes sense to talk with Robin about possible changes. He holds much sway in the X-Plane community so if they are planning new codes or features, it might make the most sense to coordinate with them to avoid duplication of effort ... and only introduce a FG specific code when there is no other recourse. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.4 released
Curtis L. Olson wrote: There has been some small amount of discussion with Robin about giving the FG project a code range that we would own. Each line in the apt.dat has a key code saying the type of info it contains, and so we could have a range of codes that are dedicated to FG use and would be guaranteed never to conflict with X-Plane code expantion. This sounds like a great chance: We could use these codes to define a set of useful complex standard geometries like the rounded gaps between taxiway intersections (center, orientation, distance between center and the most inner point of the round shape, radius of the round shape), curved taxiways with the option to implement a changing width (conus) and sort of that. If we select these geometries very careful the X-Plane folks might go ahead and adopt these additions, 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] TaxiDraw-0.2.4 released
On Sunday, 28 November 2004 23:22, Curtis L. Olson wrote: We only support these kind of taxiways because that is the only kind of data we have available. If someone wanted to push forward with better taxiways, let's talk ... it's probably not too hard to add support to the genapts util, and hopefully not too hard to add something to taxidraw. Well the data is available to do better taxiways. It's called hand drawn data. :) I tried to use TaxiDraw but it was too frustrating building taxiways with thousands of little rectangles just to smooth corners. It works but it's a painful process. I did start coding a new taxiway and airport designer but it's long way from even the alpha stage. My taxiways consist of several line segments joined together by nodes. Each node has properties such as the radius of the corner, how the center and edge lines meet the next node/intersection/runway, etc. Also there will be a manual mode where you can draw taxiways and taxiway lines of arbitary shapes and sizes to allow for non-standard taxiways and aprons. In short we're talking about dynamic length records and lots of them per airport. I do not know if it's a good idea to store all the data that I can generate into the XPlane database and would they want all our stuff rammed in there anyway? On the other hand if this data was available XPlane would probably be upgraded to use it and the taxiway/airport tools could be used for both communities. In the short term you can regenerate the airport model and copy it over the old one and that works, but if the apt outline changes at all there will be a border mismatch until the surrounding terrain is rebuilt. Unless of course you do a little trick that I was thinking about. 1. Find all the adjacent tiles that use the airport texture and cut them out leaving a big hole 2. Stitch in the new airport mesh 3. Fix up the holes around the edges I haven't looked into it yet but I think it could work. Maybe this is something that could be built into fgsd since it already has the basic framework in place for editing existing mesh. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.4 released
Paul Surgeon writes: First we need to get away from single line taxiways. At the moment taxiways are handled like runways which limits them to rectangular shapes. In short we need a vastly improved TaxiDraw or a new replacement. The only hassle is that genairports cannot handle any new types of data so that would need modifying too. Ideally the taxiways, aprons, gates, etc should be able to be inserted into the scenery without the need to rebuild the scenery which as I understand it is nearly impossible unless you own a super computer with gigs of RAM. (See Jason Cox's hassles where he cannot even make a 1x1 degree tile with 700+ MB or RAM) Unfortunately all the 3D geometry and logic involved is time consuming and not trivial (at least not for my brain). Hi Paul, I keep meaning to reply to some of your (and Chris M's) posts about taxiways, but since they always seem to require a carefully considered reply I never seem to find the time. I'll try to finish and post this one. I very much belong to the 'keep putting one foot in front of the other' school of thought - TaxiDraw current aims to solve the immediate problem of being able to edit the data format that we have at the moment. Now that it is largely functionally complete for this, I'm also keen to turn towards the problem of how to represent the taxiways better in the sim. In particular, I'd like to see proper curved yellow lines at intersections, and curved edge radii at intersections, instead of the current kludge where multiple small segments can be used to approximate a curved edge at an intersection. I don't see that it really makes a huge amount of difference whether this is accomplished via a wysiwyg type approach such as editing a 3D airport model directly in an openGL capable editor, or via a more 'latex' type approach in terms of specifying the layout with a tool such as TaxiDraw, and then compiling the output with genapts/TerraGear. Somewhere along the line both approaches are going to have to solve a similar set of problems. From here on, please bear in mind that my openGL knowledge is somewhat rudimentary. I'm extremely open to suggestions and corrections. The main problem that I can see is that the required texture set required to represent even a small number of all the possible combinations gets much larger than it is at the moment. If the yellow turn off lines start on the runway for instance, then practically every runway segment needs to be duplicated twice, once with turn-offs in one direction only, once with crossroads style turnoffs. When the taxiway texture gets stretched to make different width taxiways the centerline width will change, and may not match up well with the widths of the intersection textures. Corners of different radii will require a number of different grass/surface textures. All-in-all, this would greatly increase FlightGear's use of a finite texture budget in the current 'load them all at startup' scheme. I haven't even mentioned hold-line, gate and parking markings. The way I see it, we need some way to combine the taxiway and apron markings with the physical surface texture. I don't know anything about doing this at runtime, and am open to ideas on this. However, I can see ways (in my mind, admittedly!) of doing it at airport generation time, using genapts. Genapts could interperate (sp?) hints from TaxiDraw in the extra codes about radiussed corners and intersection markings, and programatically generate custom textures from a mixture of airport grass, surface [concrete|asphalt], and taxiway marking textures. These generated textures to be stored with the airport, not in the base texture directory. The missing piece of the jigsaw is then dynamic texture loading. This only works if FlightGear loads and unloads textures as needed, otherwise the texture budget is blown. However, this is something desperately needed anyway, something I've been gradually looking at for a while, and something I'm keen to look at more rigorously. So it's not a stopper problem. Anyway, I'd be interested in constructive comment as the the feasability of the above proposed approach, or possibly other approaches to consider. Once again, it's currently intersections I'm interested in - I'd like to be able to turn off the runway at the end of the roll-out on a curved yellow centerline. In short the setup we have now sucks and there will be no near term solution. One day someone will have a stab at it ... one day when the need becomes more pressing and someone is bored. :) I'm sure David would write us an excellent, feature filled TaxiDraw if he was paid to do it full time. I'd like to think that it's not too bad, and not too feature deficient at the moment for the job that it currently sets out to do ;-) Just my late night rant/opinion. Your rants always seem eminently reasonable :-) Cheers - Dave
Re: [Flightgear-devel] TaxiDraw-0.2.4 released
Paul Surgeon wrote: Well the data is available to do better taxiways. It's called hand drawn data. :) I tried to use TaxiDraw but it was too frustrating building taxiways with thousands of little rectangles just to smooth corners. It works but it's a painful process. Sure, the closer to reality you want to get with curves and corners, the harder it is to do with the current system, and it still doesn't look all that great because the texturing scheme gives away that there are lots of little pieces overlaying each other. I did start coding a new taxiway and airport designer but it's long way from even the alpha stage. I would vote for adding features to the taxidraw app. It sounds like Dave has been busy up to now just catching up with the existing format which is why he hasn't pushed forward with new stuff. My taxiways consist of several line segments joined together by nodes. Each node has properties such as the radius of the corner, how the center and edge lines meet the next node/intersection/runway, etc. Also there will be a manual mode where you can draw taxiways and taxiway lines of arbitary shapes and sizes to allow for non-standard taxiways and aprons. In short we're talking about dynamic length records and lots of them per airport. Arbitrary polygons would be nice for many taxiway and tiedown areas. It would also be nice to specify an arbitrary polygon border of the airport property. The FG apt.dat parser can handle variable length records just fine. The rigidity of the file format comes from limitations in the x-plane parser and Robin's preference towards outputting data in fixed-column format. So we just live with that since it really doesn't hurt anything. There's no reason why we can't add our own entries that have a more dynamic format. The hard issue with taxiways is that it would be nice to define the arbitrary concrete/asphalt areas separately from the painted lines. It would be nice from many perspectives to have these overlaid and drawn separately. The issues are 1. avoiding z-fighting with something like glPolygonOffset() but that can only work reliably if the underlying polygon structure is cut into the lines so that a line polygon always lies in the plane of an underlying surface rectangle. That get's a little hard to do. Another approach would be to cut in the yellow lines as actual geometry (i.e. make holes for them.) The down side to that is you get odd aliasing effects at a distance. Runways/taxiways are really the worst case scenario for just about any scheme you could think up. FSAA and anisotropic texture filtering definitely help minimize these problem, but are only possible to use on higher end cards. I do not know if it's a good idea to store all the data that I can generate into the XPlane database and would they want all our stuff rammed in there anyway? No, they wouldn't want our stuff, but we can either strip it out before we submit to Robin, or perhaps Robin could know to strip the stuff out himself. On the other hand if this data was available XPlane would probably be upgraded to use it and the taxiway/airport tools could be used for both communities. I'm sure that X-Plane would never do anything that appeared like it was thought up by FlightGear, but if it didn't appear that there was a direct link, they'd probably be ok with it. :-) Unless of course you do a little trick that I was thinking about. 1. Find all the adjacent tiles that use the airport texture and cut them out leaving a big hole 2. Stitch in the new airport mesh 3. Fix up the holes around the edges I haven't looked into it yet but I think it could work. Maybe this is something that could be built into fgsd since it already has the basic framework in place for editing existing mesh. That sounds hard ... :-| Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.4 released
David Luff wrote: I keep meaning to reply to some of your (and Chris M's) posts about taxiways, but since they always seem to require a carefully considered reply I never seem to find the time. I'll try to finish and post this one. I very much belong to the 'keep putting one foot in front of the other' school of thought - TaxiDraw current aims to solve the immediate problem of being able to edit the data format that we have at the moment. Now that it is largely functionally complete for this, I'm also keen to turn towards the problem of how to represent the taxiways better in the sim. Hi Dave, I hope you know how much your efforts are appreciated. As we move forward, it will be wonderful to have more and more FG users be able to submit airport upgrades to the FG/X-Plane airport data base. Now that it is largely functionally complete for this, I'm also keen to turn towards the problem of how to represent the taxiways better in the sim. I can think of 4 approaches to defining taxiways and lines. 1. Follow the same basic approach that we used for runway markings ... come up with a clever way to design a minimal set of textures that can be assembled into all the possible taxiway layout and marking schemes. As you suggest, this is almost an impossible task given the variety of marking schemes and intersections and such that exist ... plus taxi lines can run out into the runway which makes it even more problematic. We'd have to settle for some severe compromises if we went this direction. 2. Draw the taxi lines as separate polygons over the top of the taxiways and runways. We would need to use glPolygonOffset, and make sure we split all the taxiway lines at the borders of all the underlying surface triangles so that the taxilines always lay in the perfect plane of the underlying surface triangles. We could put a small amount of alpha on the edge of the lines to blend them in nicely with the underlying surface textures. This also has the advantage that the lines exist separately from the taxiway and runway textures eliminating the texture usage and combinatorial problems of #1. But this scheme would burn a lot of polygons and it would require some complex preprocessing of the line polygons to clip them against all the underlying triangles. That would be no small task ... (writing the code to do that.) 3. Cut the lines right into the geometry ... i.e. cut holes for the lines. This would probably be the easiest programatically because the code to do this priority clipping already exists. We would just lay the lines down first and they would own their areas ... the runway/taxiway surface polygons would fill in around the lines. This eliminates the need for doing glPolygonOffset (which isn't exactly platform independent and can have parameter tuning difficulties.) But we couldn't use the alpha edge trick of #2 any more, and we'd still be burning a fairly high number of polygons. 4. This last one intrigues me, but I don't think we have the hardware or computer power to do it today. We could draw the entire airport in 2D into a really large texture (or a couple large textures) and then create a fairly simple polygon mesh coverting the airport area. The large textures would be overlayed on the simple underlying mesh ... all the runways textures, lines, taxiways, etc. would be burned into this larger texture. The large texture could be created at run time based off of a set of simple base textures. We could really do any number of arbitrary layering and shapes and surface types all burned into the large airport texture. This sort of approach probably wouldn't work so well until video cards with a 1/2 or whole Gb of video ram are common place ... but it's an idea that really intrigues me. Heading off on a tangent ... MSFS does something sort of similar for the base terrain which allows them to do nice blending between land use types, but there are limitations to pulling off this technique on current consumer hardware ... it's intriguing though ... sort of like doing photo/satellite based scenery, but generating the textures yourself on the fly ... you could burn in roads, buildings, trees, and other objects, then match the burned in objects with precisely positioned autogen objects ... it would allow you to distribute scenery in more of a base/component/layered form and then render at runtime in various LODs intriguing, but I'm not sure that most people would be happy with the performance. Just a quick back of the envelope calculation for instance ... if we want 4 meter/pixel resolution (which isn't great) and we want to cover just a single tile, the memory requirements really balloon quickly. Let's say a tile is 8 miles x 8 miles. That's about 13x13 km or 13000x13000 meters. At 4m/px res, we would need a texture of 3072x3072 to cover that area (thats 3*1024 which is not quite 4m/px but is a nice round number.) That's 28Mb worth
Re: [Flightgear-devel] TaxiDraw-0.2.4 released
On November 28, 2004 09:34 pm, Curtis L. Olson wrote: I can think of 4 approaches to defining taxiways and lines. snip In 3D Studio, there is an option to do face mapping, which allows the user to do something like the followings very easily. http://www.cs.yorku.ca/~cs233144/sample1.jpg http://www.cs.yorku.ca/~cs233144/sample2.jpg The texture consists of one 32X32 bmp file. As far as I can tell, each polygon is being treated individually, and the UV map is distorted and orientated to match the shape of the polygon. This method allows the center line to remain center no matter how the taxiway twisted and change in width. Perhaps we can do the same in FlightGear? If plib supports 3ds format as well as it should, it will just be a matter of finding the right function in plib to do the job. As for runway/taxiway intersections and taxiway/taxiway intersections, we can use method 4 for these and only these areas. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.4 released
Martin Spott writes: David Luff wrote: I've put TaxiDraw-0.2.4 up at http://www.nottingham.ac.uk/~eazdluf/taxidraw.html. ftp://ftp.uni-duisburg.de/FlightGear/TaxiDraw/taxidraw-0.2.4-FreeBSD.bz2 ftp://ftp.uni-duisburg.de/FlightGear/TaxiDraw/taxidraw-0.2.4-IRIX.bz2 ftp://ftp.uni-duisburg.de/FlightGear/TaxiDraw/README.strange-binaries Wow, that's quick! I'll put a link up to them tomorrow. Thanks - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.4 released
David Luff wrote: Wow, that's quick! This was sort of a 'parallel build' - on three platforms ;-) It is primarily _your_ merit that the required changes for different platforms are that small, 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
