Re: [Flightgear-devel] cessna c172p cockpit (2) + ambient light level.
Hello, Hi Everybody,thank you for all your replies. I have downloaded and compiled 2.4.0 from the website. I have cloned fgdata on my local machine. Until I compile 2.5.0 from git, I am cheating by using the data from 2.4.0 + symlinks to the c127p and Instruments-3d folders from fgdata from git. I don't know how evil that is, but this is only temporary. Between 2.5.0 and 2.4.0 is already a difference in look, especially in lighting. And comparing 2.4.0 with 1.9.1 is- well- comparing apples and oranges. 1.9.1 was using plib, 2.4.0 is using OSG and has the shader effect system. Skydome has massiv changed and so the lighting. Btw: you have heard that in just two months we will have 2.6.0? I have a question regarding the amount of ambient light. It seems to have changed a lot since 1.9.1. This is particularly obvious when flying towards the sun. On my monitor, with a gamma close to 2.2, the panel and the instruments are getting hard to read. This will not be a problem with glass cockpits. I imagine the sky + skydome illumination model has been modified improve realism on the landscape. Please look at this screengrab, and click on the following one:https://picasaweb.google.com/lh/photo/T1tLqlebp0PPJRdQDXXZ8LtBKth8brfvXTX_6GVpOLg I saw a post by Curtis Olson regarding non-illuminated sides of materials, but the Cessna materials ambient values don't seem wrong.http://sourceforge.net/mailarchive/message.php?msg_id=24093698 The ambient values are slightly off, but nothing to worry about: www.hoerbird.net/C172pambient.jpg With fixed ambient values: www.hoerbird.net/C172pambient_avf.jpg A small hint from me which can save lifes: When developing, especially on the most important default aircraft, make sure that you have the latest Developement version aka latest GIT. FGFS reached critical mass and the developement process is quite stunning for an OpenSource project. Cheers Heiko -author of the 3d-exterior and panel c172p- -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cessna 172p cockpit improvement
Ron Jensen wrote: I just noticed the c172p.xml (FDM) in FGData doesn't match the one in JSBSim. What's your conclusion ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] cessna c172p cockpit (2) + ambient light level
Hi Everybody,I am reposting this for legibility. The paragraphs were missing in the previous post. Thank you for all your replies. I have downloaded and compiled 2.4.0 from the website. I have cloned fgdata on my local machine. Until I compile 2.5.0 from git, I am cheating by using the data from 2.4.0 + symlinks to the c127p and Instruments-3d folders from fgdata from git. I don't know how evil that is, but this is only temporary. The good news is that I haven't seen any duplicate work done on the new cockpit. There is a new EGT instrument. I will punch a hole in the panel geometry for it. I have a question regarding the amount of ambient light. It seems to have changed a lot since 1.9.1. This is particularly obvious when flying towards the sun. On my monitor, with a gamma close to 2.2, the panel and the instruments are getting hard to read. This will not be a problem with glass cockpits. I imagine the sky + skydome illumination model has been modified improve realism on the landscape. Please look at this screengrab, and click on the following one:https://picasaweb.google.com/lh/photo/T1tLqlebp0PPJRdQDXXZ8LtBKth8brfvXTX_6GVpOLg I saw a post by Curtis Olson regarding non-illuminated sides of materials, but the Cessna materials ambient values don't seem wrong.http://sourceforge.net/mailarchive/message.php?msg_id=24093698 Please let me know your comments.ThanksStephan. -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-commitlogs] TerraGear / Custom
Hi Peter, what you're describing sounds familiar. Ralf and I had been observing at least two characteristic types of failures: 1.) An airfield hole (or a road) cutting a landcover polygon into two parts of which the (much) smaller one was left without centroid after clipping. 2.) A centroid sitting in a very thin edge of a polygon which resulted from clipping at small angles, in a so-called sliver whereas the sliver was later removed (cleaned) from the polygon without relocating the centroid. For the long-term I'm in favour of doing all this polygon-processing in GRASS because GRASS takes care of the topological consistency - at least as long as you don't force it not to do so. In preparation of a talk last month I did a few pictures from experiments (in PostGIS and GRASS) by creating a buffer around all the road lines - my experimental OSM line feature layer on the MapServer: http://mapserver.flightgear.org/map/?lon=6.5045lat=51.23036zoom=15layers=0BTTFTFF This turns all the various road lines into one single polygon layer, ready for clipping against the land cover: http://foxtrot.mgras.net/bitmap/FGFS/EDLN-OpenLayers-RoadCover.png which I'm then cutting out of the landcover. http://foxtrot.mgras.net/bitmap/FGFS/EDLN-OpenLayers-RoadCutout.png Images had been rendered via MapServer right from the PostGIS DB and delivered by OpenLayers. The underlying principle is very simple, indeed. Anyhow I'm still impressed that all this really works as advertized on real data ;-) Currently I'm (hopefully) running the last test-cycles for cleaning polygonal land cover at large scale in GRASS. Next step will be to verify wether v.drape yields a result which is suitable for our needs, thus by filling airport holes (via poly2ogr and some vertex elevation magic) and roads into the base land cover, just few steps remain until the stuff could be written into your favourite scenery format. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-commitlogs] TerraGear / Custom
Hi Martin, I saw the experimental polygons on the mapserver. It's good to see clipping the road against the landclass works so well. I had played with v.buffer before, and was going to use it as a baseline to try to retain texture coordinates in GRASS in the same way I am for ogr-decode / construct. So the single road poly would still be used for clipping, but when triangulating, I would still have individual road polys and column data for the texture parameters. Have you tried to triangulate the landclass in GRASS yet? I was wondering how well that works compared to triangleJRS. I ran a full xdist=2, ydist=2 fgfs-construct last night with my original idea (turns out the time consumed was caused by all the converting of point data to use clipper - reverting to GPC brings the speed back up to the original fgfs-construct). To keep triangleJRS from crashing, I'm issuing the -X flag (suppress exact arithmetic). The author says this isn't recommended, and may cause artifacts, I'll have to inspect it. http://www.cs.cmu.edu/~quake/triangle.exact.html I want to finish my fgfs-construct rework before looking into GRASS modules again, but I was wondering if we have documentation / sourcecode on how the OSM data was imported / converted to shapefiles on the mapserver. I was hoping to add a couple columns from the original XML (number of lanes / z-order). On Mon, Dec 19, 2011 at 7:45 AM, Martin Spott martin.sp...@mgras.netwrote: Hi Peter, what you're describing sounds familiar. Ralf and I had been observing at least two characteristic types of failures: 1.) An airfield hole (or a road) cutting a landcover polygon into two parts of which the (much) smaller one was left without centroid after clipping. 2.) A centroid sitting in a very thin edge of a polygon which resulted from clipping at small angles, in a so-called sliver whereas the sliver was later removed (cleaned) from the polygon without relocating the centroid. For the long-term I'm in favour of doing all this polygon-processing in GRASS because GRASS takes care of the topological consistency - at least as long as you don't force it not to do so. In preparation of a talk last month I did a few pictures from experiments (in PostGIS and GRASS) by creating a buffer around all the road lines - my experimental OSM line feature layer on the MapServer: http://mapserver.flightgear.org/map/?lon=6.5045lat=51.23036zoom=15layers=0BTTFTFF This turns all the various road lines into one single polygon layer, ready for clipping against the land cover: http://foxtrot.mgras.net/bitmap/FGFS/EDLN-OpenLayers-RoadCover.png which I'm then cutting out of the landcover. http://foxtrot.mgras.net/bitmap/FGFS/EDLN-OpenLayers-RoadCutout.png Images had been rendered via MapServer right from the PostGIS DB and delivered by OpenLayers. The underlying principle is very simple, indeed. Anyhow I'm still impressed that all this really works as advertized on real data ;-) Currently I'm (hopefully) running the last test-cycles for cleaning polygonal land cover at large scale in GRASS. Next step will be to verify wether v.drape yields a result which is suitable for our needs, thus by filling airport holes (via poly2ogr and some vertex elevation magic) and roads into the base land cover, just few steps remain until the stuff could be written into your favourite scenery format. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-commitlogs] TerraGear / Custom
Hi Peter,
Peter Sadrozinski wrote:
Have you tried to triangulate the landclass in GRASS yet? I was wondering
how well that works compared to triangleJRS.
I have to admit that I never did that myself.
At one of our meetings maybe more than two years ago Ralf presented to
me what later ended up as v.contri GRASS module in terragear-cs.
It is supposed to be an adaption of exactly the same triangulation as
in fgfs-construct. He was able to prove successful triangulation of
a slightly complex airfield layout (something like EDDK), thus we may
assume that it's functional at least in general, but I think he never
threw large maps at it.
http://www.cs.cmu.edu/~quake/triangle.exact.html
from a certain perspective, this looks like opening yet another
can of worms ;-)
I want to finish my fgfs-construct rework before looking into GRASS modules
again, but I was wondering if we have documentation / sourcecode on how the
OSM data was imported / converted to shapefiles on the mapserver.
I've been using osm2pgsql for years for importing The Planet Dump
into PostGIS and so far I'm quite satisfied. After the bare import I'm
using a custom script to separate the various road types into distinct
tables/layers, something like:
landcover= SELECT osm_id, access, admin_level, z_order, way_area, wkb_geometry
landcover- INTO osm_motorway
landcover- FROM planet_osm_line
landcover- WHERE highway LIKE 'motorway%'
landcover- AND ST_GeometryType(wkb_geometry) LIKE 'ST_LineString';
That way I don't have to query the entire planet_osm_line if the user
selects a large scale which doesn't include all the residential roads.
I'd certainly extend this to SELECT * [...] if required ;-)
Well, and for the Scenery building I'm just using this script - see
the bottom for ${ROAD_TYPE} = OSM:
http://mapserver.flightgear.org/git/gitweb.pl?p=terragear-cs;a=blob;f=src/Prep/OGRDecode/process.sh
No Shapefiles at work here.
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
--
Learn Windows Azure Live! Tuesday, Dec 13, 2011
Microsoft is holding a special Learn Windows Azure training event for
developers. It will provide a great way to learn Windows Azure and what it
provides. You can attend the event by watching it streamed LIVE online.
Learn more at http://p.sf.net/sfu/ms-windowsazure
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] New Minneapolis Scenery
Hello everyone, I've released a new version of Minneapolis scenery: http://www.stattosoftware.com/flightgear/minneapolis.zip I cannot make this scenery load in version 2.4, probably because it hopefully fixes the nasty 'swirlies' problem. If anyone gets this scenery to work, and it actually compiled successfully, please let me know. Cheers John -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Minneapolis Scenery
Hi John, This is my area of the world so I thought I'd jump in and comment -- took off from KANE and once I got airborne, I could really see the difference from the default scenery. There were some odd concrete areas around the airport that looked like they should have probably been swamp or pond or something, but away from the airport I didn't notice any more of those. I instantly recognized Hwy 10 to the south of the airport and 35W to the east. I was disappointed that these were the only roads included -- a few of the smaller (but still major) roads would be a nice addition. You have all the cloverleaf's and on/off ramps from the major freeways, but then they don't go anywhere. You have the lake that is near my house so I was able to fly right over the lake and then spot about where my house would be -- and you had the swampy area behind my neighborhood so that's all pretty cool. I noticed there were more churches than just about anything else in terms of random objects. I wasn't sure, but if these are Lutheran churches, then it's probably about the right density for around here. :-) All in all, pretty cool -- I can fly all over the area and figure out exactly where I'm at. Next maybe I'll overfly my RC club field and waggle my wings at those land lubber pilot wannabe's with their toy airplanes. :-) Curt. On Mon, Dec 19, 2011 at 4:44 PM, J. Holden stattosoftw...@yahoo.com wrote: Hello everyone, I've released a new version of Minneapolis scenery: http://www.stattosoftware.com/flightgear/minneapolis.zip I cannot make this scenery load in version 2.4, probably because it hopefully fixes the nasty 'swirlies' problem. If anyone gets this scenery to work, and it actually compiled successfully, please let me know. Cheers John -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
