Re: [Flightgear-devel] X-Plane 850 file format support committed
Frederic Bouvier wrote: As I already wrote, it looks like many bezier nodes are ignored and displayed as straight nodes. This was quite clear - I just didn't understand why ;-) Nevertheless, steadily we're getting there: http://mapserver.flightgear.org/map/?lon=-122.3749lat=37.61897zoom=15layers=000B00TTFF Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] X-Plane 850 file format support committed
Jon Stockill wrote: Curtis Olson wrote: I wonder what tricks and approaches the gaming community uses for drawing clear and realistic roads? The problem with cutting the lines into the surface as polygons is that (1) you explode the polygon count and (2) you have hard aliased edges which can become distracting in the distance. Cooking the lines into the surface texture gets rid of the aliasing problem, but then you explode your texture memory requirements and need to do a lot of work to generate those textures on the fly If you generate the textures on the fly, then texture memory requirements don't need to explode. However, fancy texture management is then required. Also, drawing credible roads quickly gets complex if you try to do things like lane markers and intersections. You also lose the polygon material mapping if you're just going to have a surface (presumably generated from just SRTM data) with the generated texture draped over it. IMHO this is a huge benefit of what we have already, since that's what allows us to have things like amphibious aircraft, operate aircraft from roads (I'm thinking of the harrier, jaguar, air ambulance operations etc etc) and generally ensure a nice bumpy landing when you have to choose a field for your glider because you ran out of altitude before you made it back home. AFAIK this is something pretty unique to FlightGear - we should think very carefully before dropping it. You can get the material property by testing against the vector outline that's used to render the texture. Tim -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] X-Plane 850 file format support committed
- Martin Spott a écrit : http://frbouvi.free.fr/flightsim/KSFO-850.png Ah, thanks for comparing. My reference airfields look correct, therefore I was under the impression that the v8.50 KSFO layout is flawed. It doesn't look like a numerical precision issue but obviously there's a fault at my end. As I already wrote, it looks like many bezier nodes are ignored and displayed as straight nodes. -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://fgsd.sourceforge.net/ FlightGear Scenery Designer -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] X-Plane 850 file format support committed
Hi, I committed the support to read new X-Plane 850 file format in flightgear. That doesn't mean that airports will look different in current scenery because TerraGear tools have not been updated yet, but this is the first step to support the format. Here are two screenshots comparing the ground radar with the different data : http://frbouvi.free.fr/flightsim/KSBD-810.png http://frbouvi.free.fr/flightsim/KSBD-850.png The Google Maps link: http://tinyurl.com/n9khev You should notice the smooth curves in the 850 screenshot. The parser should read current data normally, and nobody should see the difference until we change the data. Please shout if you find something broken or overlooked. (actually something is broken in the 777 ground radar, but it's not me ;-) ) Curt wrote (about linear features) : Fred, were you thinking of cutting these lines into the surface (with hard polygon edges) or drawing them over the top like with a glPolygonOffset() approach? Or something else? It would be really great to be able to add taxi lines and other markings to our airports. I didn't really thought about it yet. I am open to ideas. Does the .btg file format support the glPolygonOffset approach ? Regards, -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery http://fgsd.sourceforge.net/FlightGear Scenery Designer -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] X-Plane 850 file format support committed
You might want to look into /OpenSceneGraph/include/osgSim/OverlayNode Cheers Norman On Jun 14, 2009, at 10:19 AM, Curtis Olson wrote: Hi Fred, Glad to see someone is starting to nibble at the 8.50 format and figure it out. If you are developing code that takes the bezier outlines and can turn that into a polygon representation, then it shouldn't be terribly difficult to add that into genapts. For lines and markings, I think the easiest path in the short term will be to cut those into the surface. However, this can explode the polygon count and rendering load so we need to be careful, but it should be manageable if we don't get too crazy with lots of small segments around curves to make them look perfectly smooth. I've never played around with glPolygonOffset in the context of btg files (terragear/genapts) so I don't believe there's any support there. It's difficult because airport surfaces are curved and are not planar, so most likely any use of glPolygonOffset will not be perfect and there will be places where the lines z-fight with the underlying surface ... unless we really go crazy with a large offset value in which case the lines could bleed through some of the surfaces when they should be hidden behind them. Still it might be worth playing around with to see what kind of results are actually achievable. I wonder what tricks and approaches the gaming community uses for drawing clear and realistic roads? The problem with cutting the lines into the surface as polygons is that (1) you explode the polygon count and (2) you have hard aliased edges which can become distracting in the distance. Cooking the lines into the surface texture gets rid of the aliasing problem, but then you explode your texture memory requirements and need to do a lot of work to generate those textures on the fly, or generate them once and store them. And drawing the lines on top using glPolygonOffset is hard to do well when you are dealing with non-planer surfaces and the visual result of glPolygonOffset (at least historically) has not been consistent across different video cards and vendors. It's a difficult challenge to do well. Regards, Curt. On Sun, Jun 14, 2009 at 6:56 AM, Frederic Bouvier wrote: Hi, I committed the support to read new X-Plane 850 file format in flightgear. That doesn't mean that airports will look different in current scenery because TerraGear tools have not been updated yet, but this is the first step to support the format. Here are two screenshots comparing the ground radar with the different data : http://frbouvi.free.fr/flightsim/KSBD-810.png http://frbouvi.free.fr/flightsim/KSBD-850.png The Google Maps link: http://tinyurl.com/n9khev You should notice the smooth curves in the 850 screenshot. The parser should read current data normally, and nobody should see the difference until we change the data. Please shout if you find something broken or overlooked. (actually something is broken in the 777 ground radar, but it's not me ;-) ) Curt wrote (about linear features) : Fred, were you thinking of cutting these lines into the surface (with hard polygon edges) or drawing them over the top like with a glPolygonOffset() approach? Or something else? It would be really great to be able to add taxi lines and other markings to our airports. I didn't really thought about it yet. I am open to ideas. Does the .btg file format support the glPolygonOffset approach ? Regards, -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery http://fgsd.sourceforge.net/FlightGear Scenery Designer -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for
Re: [Flightgear-devel] X-Plane 850 file format support committed
Hi Fred, Glad to see someone is starting to nibble at the 8.50 format and figure it out. If you are developing code that takes the bezier outlines and can turn that into a polygon representation, then it shouldn't be terribly difficult to add that into genapts. For lines and markings, I think the easiest path in the short term will be to cut those into the surface. However, this can explode the polygon count and rendering load so we need to be careful, but it should be manageable if we don't get too crazy with lots of small segments around curves to make them look perfectly smooth. I've never played around with glPolygonOffset in the context of btg files (terragear/genapts) so I don't believe there's any support there. It's difficult because airport surfaces are curved and are not planar, so most likely any use of glPolygonOffset will not be perfect and there will be places where the lines z-fight with the underlying surface ... unless we really go crazy with a large offset value in which case the lines could bleed through some of the surfaces when they should be hidden behind them. Still it might be worth playing around with to see what kind of results are actually achievable. I wonder what tricks and approaches the gaming community uses for drawing clear and realistic roads? The problem with cutting the lines into the surface as polygons is that (1) you explode the polygon count and (2) you have hard aliased edges which can become distracting in the distance. Cooking the lines into the surface texture gets rid of the aliasing problem, but then you explode your texture memory requirements and need to do a lot of work to generate those textures on the fly, or generate them once and store them. And drawing the lines on top using glPolygonOffset is hard to do well when you are dealing with non-planer surfaces and the visual result of glPolygonOffset (at least historically) has not been consistent across different video cards and vendors. It's a difficult challenge to do well. Regards, Curt. On Sun, Jun 14, 2009 at 6:56 AM, Frederic Bouvier wrote: Hi, I committed the support to read new X-Plane 850 file format in flightgear. That doesn't mean that airports will look different in current scenery because TerraGear tools have not been updated yet, but this is the first step to support the format. Here are two screenshots comparing the ground radar with the different data : http://frbouvi.free.fr/flightsim/KSBD-810.png http://frbouvi.free.fr/flightsim/KSBD-850.png The Google Maps link: http://tinyurl.com/n9khev You should notice the smooth curves in the 850 screenshot. The parser should read current data normally, and nobody should see the difference until we change the data. Please shout if you find something broken or overlooked. (actually something is broken in the 777 ground radar, but it's not me ;-) ) Curt wrote (about linear features) : Fred, were you thinking of cutting these lines into the surface (with hard polygon edges) or drawing them over the top like with a glPolygonOffset() approach? Or something else? It would be really great to be able to add taxi lines and other markings to our airports. I didn't really thought about it yet. I am open to ideas. Does the .btg file format support the glPolygonOffset approach ? Regards, -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery http://fgsd.sourceforge.net/FlightGear Scenery Designer -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] X-Plane 850 file format support committed
Curtis Olson wrote: Glad to see someone is starting to nibble at the 8.50 format and figure it out. If you are developing code that takes the bezier outlines and can turn that into a polygon representation, then it shouldn't be terribly difficult to add that into genapts. I'd like to remind that we are (I am) maintaining a complete set of runways as well as taxiways/aprons at our repository known as Landcover-DB as closed polygons with beziers properly cut into smaller segments, merged together from v8.50 where available and v8.10 for the rest. Different representations (distinct runway threshold positions for example) or various combinations are available as well. These are available for export into different formats like ESRI Shapefiles and a lot more - please request if you think it might be useful for further development. If you load shapefiles into QGIS, it would, for example, look like this shot: http://foxtrot.mgras.net/bitmap/FGFS/KSFO-861.png Not that, as shown here, not all v8.50 airfields match the quality measures we would expect - just take the northern part of taxiways L (east of 19L) as an example. This doesn't mean that we should not go for v8.50, I'm just trying to point out that we should consider selecting carefully. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] X-Plane 850 file format support committed
Martin Spott a écrit : If you load shapefiles into QGIS, it would, for example, look like this shot: http://foxtrot.mgras.net/bitmap/FGFS/KSFO-861.png Not that, as shown here, not all v8.50 airfields match the quality measures we would expect - just take the northern part of taxiways L (east of 19L) as an example. This doesn't mean that we should not go for v8.50, I'm just trying to point out that we should consider selecting carefully. Are you sure you have the latest data, or you are not suffering a numerical precision problem ? Compare your screenshot with what is displayed in the ground radar : http://frbouvi.free.fr/flightsim/KSFO-850.png -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery http://fgsd.sourceforge.net/FlightGear Scenery Designer -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] X-Plane 850 file format support committed
Curtis Olson wrote: I wonder what tricks and approaches the gaming community uses for drawing clear and realistic roads? The problem with cutting the lines into the surface as polygons is that (1) you explode the polygon count and (2) you have hard aliased edges which can become distracting in the distance. Cooking the lines into the surface texture gets rid of the aliasing problem, but then you explode your texture memory requirements and need to do a lot of work to generate those textures on the fly You also lose the polygon material mapping if you're just going to have a surface (presumably generated from just SRTM data) with the generated texture draped over it. IMHO this is a huge benefit of what we have already, since that's what allows us to have things like amphibious aircraft, operate aircraft from roads (I'm thinking of the harrier, jaguar, air ambulance operations etc etc) and generally ensure a nice bumpy landing when you have to choose a field for your glider because you ran out of altitude before you made it back home. AFAIK this is something pretty unique to FlightGear - we should think very carefully before dropping it. Jon -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] X-Plane 850 file format support committed
Frederic Bouvier wrote: Martin Spott a écrit : http://foxtrot.mgras.net/bitmap/FGFS/KSFO-861.png Not that, as shown here, not all v8.50 airfields match the quality measures we would expect - just take the northern part of taxiways L (east of 19L) as an example. This doesn't mean that we should not go for v8.50, I'm just trying to point out that we should consider selecting carefully. Are you sure you have the latest data, or you are not suffering a numerical precision problem ? Compare your screenshot with what is displayed in the ground radar : http://frbouvi.free.fr/flightsim/KSFO-850.png Ah, thanks for comparing. My reference airfields look correct, therefore I was under the impression that the v8.50 KSFO layout is flawed. It doesn't look like a numerical precision issue but obviously there's a fault at my end. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
