Re: [Flightgear-devel] Aircraft rating now visible in fgrun

2011-11-12 Thread Frederic Bouvier
 See : http://frbouvi.free.fr/flightsim/fgrun-rating-system.png

And what about this one ?
http://frbouvi.free.fr/flightsim/fgrun-rating-system-star-en.png

-Fred

--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Aircraft rating now visible in fgrun

2011-11-12 Thread Alexis Bory
Le 12/11/2011 11:05, Frederic Bouvier a écrit :
 See : http://frbouvi.free.fr/flightsim/fgrun-rating-system.png
 And what about this one ?
 http://frbouvi.free.fr/flightsim/fgrun-rating-system-star-en.png

 -Fred

Hi Fred,

Stars are funnier, but from my point of view, the size of the rating 
block and text looks a bit too big.

Alexis



 --
 RSA(R) Conference 2012
 Save $700 by Nov 18
 Register now
 http://p.sf.net/sfu/rsa-sfdev2dev1
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel



--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


[Flightgear-devel] Building Simgear with OSG 3.0.0

2011-11-12 Thread Chris Marr
Hi guys,

trying to build the latest GIT version of FG, when cmake'ing simgear it
complains that OSG 2.9.7 is installed, even though I've just downloaded
and compiled OSG 3.0.1

can someone provide some pointers as to how to fix this? Or is there's
quick fix in the cmake system I can do?

Ta,
Chris



--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Building Simgear with OSG 3.0.0

2011-11-12 Thread ThorstenB
Am 12.11.2011 11:03, schrieb Chris Marr:
 trying to build the latest GIT version of FG, when cmake'ing simgear it
 complains that OSG 2.9.7 is installed, even though I've just downloaded
 and compiled OSG 3.0.1

 can someone provide some pointers as to how to fix this? Or is there's
 quick fix in the cmake system I can do?

Indeed, =OSG3.0.0 is required now. Make sure you also install 
OSG3.0.1 after compiling it. Obviously cmake still finds your 2.9.7 OSG 
installation, so either remove the old OSG installation, or provide the 
path to your OSG3.0.1 _installation_ folder to cmake directly, i.e. 
using environment variables as described here:
http://wiki.flightgear.org/Building_using_CMake

cheers,
Thorsten

--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


[Flightgear-devel] Fixing fgfs-construct crashes

2011-11-12 Thread Maxime Guillaud
James Turner zakal...@mac.com wrote:
 
 Onwards with fixing the fgfs-construct crashes!

I have had pretty good luck building complex scenery with a modified version of
fgfs-construct. Here is what I did:

Following advice by Peter Sadrozinski here on the list, I started from the code
in papillon's terragear repo where GPC is replaced by clipper. I then applied a 
few
patches, reducing various epsilon constants in the code which I think were 
too loose and
caused inconsistencies in the clipper. You can find my code here (in the branch
custom_scenery_clean):
https://gitorious.org/~maximeguillaud/papillon81/maxime-terragear-cs/commits/custom_scenery_clean

More specifically, the patches relevant to fgfs-construct are in commits
81a78602e09b67edd58b2cedacf09079239b0177 and 
8601f66cf7cf00ffda38f57cee77ae991c42dab8.
The second one uses the constant SG_EPSILON defined in Simgear. I reduced the
value of this constant in simgear/constants.h: 
#define SG_EPSILON (DBL_EPSILON*10)
(Note that I am using a different installation of Simgear for terragear and for 
fgfs, so
I do not know if this change would have consequences on fgfs).

With the above settings, I was able to process large amounts of scenery without 
any crash.
So far I have tried a band covering Europe between 12 and 14 degrees East, i.e. 
going
through Sicily, Italy, the Austrian Alps, the Czech Republic and Germany, 
Sweden and
Norway, up to 69 degrees North. My scenery includes detailed terrain (fitted 
with 15m
accuracy), the CORINE land cover, and OSM rail and roads up to the secondary 
network. The
latest update in the BTG format seem to have fixed the swirlies.

You can see a few screenshots here: http://www.mguillaud.net/fg/scenery-gallery/

The only problem that prevents me from calling it final and generating custom 
scenery for
all of Europe can be seen in the last screenshot:
http://www.mguillaud.net/fg/scenery-gallery/fgfs-screen-008.png
Sometimes, one polygon will have the correct shape but the material is wrong, 
and it
appears all gray. This seems to occur only around roads. Any advice on this is
appreciated. I had a chat with Martin Spott (hi Martin !) a few days ago and he 
mentioned
that the bug is known, and proceeded to explain it to me, however I have not 
been able to
relate his explanation to the code in fgfs-construct. I can provide a minimal 
set of
files (3 roads) that trigger this problem, in case anyone can help with the 
debugging.

Maxime

--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Fixing fgfs-construct crashes

2011-11-12 Thread Curtis Olson
Hi Maxime,

Final material assignment is done when the data is triangulated.  (All the
points connected into triangles.)  The algorithm needs a set of points, and
it also needs a set of edges (boundaries) that show the division between
material shapes.  Finally for each material type, it needs a point inside
each unique area.

The algorithm starts at each given point and finds the triangle that
encloses it assigns it the material type of that point.  Then works it's
way to all the neighbor triangles and assigns them the same type.  It keeps
going until it hits an edge (which we provide) or it runs out of triangles.
 Then it continues on to the next point and the next and the next.

So this all sounds good (I think) except we now have to compute a point
inside each material region.  Easy, right?  Well, except that all the
published algorithms can tell you if a random point is inside a polygon or
not, but they don't tell you how to manufacture a point that is guaranteed
to be inside a polygon.  With very complex convex shapes, possibility of
holes, and all kinds of extremely tiny numbers (or points that are
extremely close to each other) this becomes a bit more of a challenge.

We have an approach with some heuristics to try to find a good point inside
a polygon, but it sounds like this is failing.  Also I haven't had my
fingers in the code for quite some time and there have been some
substantial changes.

So what you want to do is identify the mistaken areas and determine the
point we generate inside those areas.  Then try to figure out what's wrong
with the picture?  Is the point in the area?  Is it too close to an edge?
 Did we miss an edge such that the classification algorithm loses contain
and spills out into a neighboring region.

The answer here is to get down and dirty and look at the intermediate
results ... it's painstaking, drudgery work, but someone needs to dig in to
each specific case and figure out exactly why it's breaking, and then
either fix the problem directly, or back up to an earlier stage in the
pipeline and try to catch/avoid/fix the situation before it causes trouble.

There are direct bugs, and then there are difficult situations with the
data that arise.

Best regards,

Curt.



On Sat, Nov 12, 2011 at 7:59 AM, Maxime Guillaud m...@mguillaud.net wrote:

 James Turner zakal...@mac.com wrote:
 
  Onwards with fixing the fgfs-construct crashes!

 I have had pretty good luck building complex scenery with a modified
 version of
 fgfs-construct. Here is what I did:

 Following advice by Peter Sadrozinski here on the list, I started from the
 code
 in papillon's terragear repo where GPC is replaced by clipper. I then
 applied a few
 patches, reducing various epsilon constants in the code which I think
 were too loose and
 caused inconsistencies in the clipper. You can find my code here (in the
 branch
 custom_scenery_clean):

 https://gitorious.org/~maximeguillaud/papillon81/maxime-terragear-cs/commits/custom_scenery_clean

 More specifically, the patches relevant to fgfs-construct are in commits
 81a78602e09b67edd58b2cedacf09079239b0177 and
 8601f66cf7cf00ffda38f57cee77ae991c42dab8.
 The second one uses the constant SG_EPSILON defined in Simgear. I
 reduced the
 value of this constant in simgear/constants.h:
 #define SG_EPSILON (DBL_EPSILON*10)
 (Note that I am using a different installation of Simgear for terragear
 and for fgfs, so
 I do not know if this change would have consequences on fgfs).

 With the above settings, I was able to process large amounts of scenery
 without any crash.
 So far I have tried a band covering Europe between 12 and 14 degrees East,
 i.e. going
 through Sicily, Italy, the Austrian Alps, the Czech Republic and Germany,
 Sweden and
 Norway, up to 69 degrees North. My scenery includes detailed terrain
 (fitted with 15m
 accuracy), the CORINE land cover, and OSM rail and roads up to the
 secondary network. The
 latest update in the BTG format seem to have fixed the swirlies.

 You can see a few screenshots here:
 http://www.mguillaud.net/fg/scenery-gallery/

 The only problem that prevents me from calling it final and generating
 custom scenery for
 all of Europe can be seen in the last screenshot:
 http://www.mguillaud.net/fg/scenery-gallery/fgfs-screen-008.png
 Sometimes, one polygon will have the correct shape but the material is
 wrong, and it
 appears all gray. This seems to occur only around roads. Any advice on
 this is
 appreciated. I had a chat with Martin Spott (hi Martin !) a few days ago
 and he mentioned
 that the bug is known, and proceeded to explain it to me, however I have
 not been able to
 relate his explanation to the code in fgfs-construct. I can provide a
 minimal set of
 files (3 roads) that trigger this problem, in case anyone can help with
 the debugging.

 Maxime


 --
 RSA(R) Conference 2012
 Save $700 by Nov 18
 Register now
 

Re: [Flightgear-devel] Fixing fgfs-construct crashes

2011-11-12 Thread James Turner

On 12 Nov 2011, at 13:59, Maxime Guillaud wrote:

 I have had pretty good luck building complex scenery with a modified version 
 of
 fgfs-construct. Here is what I did:
 
 snip

Okay, this all sounds like good news indeed. Martin, Chris, Peter - I think the 
steps need to be as follows - get a branch of terragear with the clipper 
changes, and probably the epsilon changes Maxime describes (because I've always 
worried, they were only needed due to GPC problems).

Then we can all test on our favourite datasets, and see if there's any 
regressions, and hopefully a big improvement in not crashing!

(I'm also glad to hear the BTG changes have really fixed the swirlies)

 You can see a few screenshots here: 
 http://www.mguillaud.net/fg/scenery-gallery/

Looks very good to me - especially when it's combined with some of the shader / 
materials work that is coming!

 The only problem that prevents me from calling it final and generating custom 
 scenery for
 all of Europe can be seen in the last screenshot:
 http://www.mguillaud.net/fg/scenery-gallery/fgfs-screen-008.png

Personally, I'd could live with the issue to get the world scenery rebuilt, but 
certainly to have the code on an official branch for testing, and investigation 
of this bug makes sense, I think.

James


--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Aircraft rating now visible in fgrun

2011-11-12 Thread HB-GRAL
Am 12.11.11 11:05, schrieb Frederic Bouvier:
 See : http://frbouvi.free.fr/flightsim/fgrun-rating-system.png

 And what about this one ?
 http://frbouvi.free.fr/flightsim/fgrun-rating-system-star-en.png

 -Fred

 --
 RSA(R) Conference 2012
 Save $700 by Nov 18
 Register now
 http://p.sf.net/sfu/rsa-sfdev2dev1
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Hi Fred

Looking to the bars and the stars I think the stars are probably too 
easy. The rating system introduced looks much more sophisticated.

Cheers, Yves

--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Aircraft rating now visible in fgrun

2011-11-12 Thread Frederic Bouvier
Hi Yves,

 Am 12.11.11 11:05, schrieb Frederic Bouvier:
  See : http://frbouvi.free.fr/flightsim/fgrun-rating-system.png
 
  And what about this one ?
  http://frbouvi.free.fr/flightsim/fgrun-rating-system-star-en.png
 
 Hi Fred
 
 Looking to the bars and the stars I think the stars are probably too
 easy. The rating system introduced looks much more sophisticated.

too easy ? I am not sure to understand what you mean

Regards,
-Fred

--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Fixpoints navaids

2011-11-12 Thread HB-GRAL
Am 10.11.11 12:14, schrieb HB-GRAL:


 Assuming the fix table should contain VFR waypoints mainly, another
 question might be if the fix table can be filtered (only for the map)
 into waypoints containing only VPXYZ-Point-Naming and others
 containing numbers ? Is this a bad idea (for the map) ?


Please tell me if this a bad idea. I just added a filter to the fix data 
on the map: only 5 letters without numbers is shown (as a waypoint) -- 
map.fgx.ch, activating fix layer

Thanks, Yves

--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Aircraft rating now visible in fgrun

2011-11-12 Thread HB-GRAL
Am 12.11.11 19:35, schrieb Frederic Bouvier:
 Hi Yves,

 Am 12.11.11 11:05, schrieb Frederic Bouvier:
 See : http://frbouvi.free.fr/flightsim/fgrun-rating-system.png

 And what about this one ?
 http://frbouvi.free.fr/flightsim/fgrun-rating-system-star-en.png

 Hi Fred

 Looking to the bars and the stars I think the stars are probably too
 easy. The rating system introduced looks much more sophisticated.

 too easy ? I am not sure to understand what you mean


Fred, I meant it is too easy because the stars simplify the system to 
much, but I realize that the rating system is written down very 
sophisitcated, but indeed have 5 levels only ... so it is no difference 
for you probably. I was looking to the stars and thought, wow, we have 
100 % cockpits etc.

Cheers, Yves

--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] [Flightgear-commitlogs] FlightGear branch, next,

2011-11-12 Thread Martin Spott
Flightgear-commitlogs wrote:

 commit 0905b4f36781c057b0c17b5af2c9ccfd72cf0fcd
 Author: Durk Talsma
 Date:   Sat Nov 12 18:40:23 2011 +0100
 
Fixing an age old bug. AIAircraft arriving on an airport never
 received a proper gateId, causing them to taxi to the end of the
 world and beyond.

Is this the one which was causing the 'rabbits' at EHLE ?

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Aircraft rating now visible in fgrun

2011-11-12 Thread Frederic Bouvier
 Am 12.11.11 19:35, schrieb Frederic Bouvier:
  Hi Yves,
 
  Am 12.11.11 11:05, schrieb Frederic Bouvier:
  See : http://frbouvi.free.fr/flightsim/fgrun-rating-system.png
 
  And what about this one ?
  http://frbouvi.free.fr/flightsim/fgrun-rating-system-star-en.png
 
  Hi Fred
 
  Looking to the bars and the stars I think the stars are probably
  too
  easy. The rating system introduced looks much more sophisticated.
 
  too easy ? I am not sure to understand what you mean
 
 
 Fred, I meant it is too easy because the stars simplify the system
 to much, but I realize that the rating system is written down very
 sophisitcated, but indeed have 5 levels only ... so it is no
 difference for you probably. I was looking to the stars and thought, 
 wow, we have 100 % cockpits etc.

The rating system is not my invention. It is just an implementation 
of what was discussed on the forum :
http://www.flightgear.org/forums/viewtopic.php?f=4t=12193
and described here :
http://wiki.flightgear.org/Formalizing_Aircraft_Status

Regards,
-Fred

--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Fixing fgfs-construct crashes

2011-11-12 Thread Peter Sadrozinski
With this minimal data set, do you see bad node print messages during
construct?

found a bad node = xxx

When a node touches a line segment on the same contour, the bad node is
removed, as odd/even clipper algorithms blow up when this occurs.
I would experiment with removing the code that removes the node.  You'll be
trading one error for another, but it may help track this down.

Take a look at reduce_contour_degeneracy() in poly_support.cxx

If this is the cause, then we'll have to figure out a different way to
handle touching segments.  As Curt said, pushing nodes around may not be
any better than removing the offending node all together.

Pete

On Sat, Nov 12, 2011 at 8:59 AM, Maxime Guillaud m...@mguillaud.net wrote:

 James Turner zakal...@mac.com wrote:
 
  Onwards with fixing the fgfs-construct crashes!

 I have had pretty good luck building complex scenery with a modified
 version of
 fgfs-construct. Here is what I did:

 Following advice by Peter Sadrozinski here on the list, I started from the
 code
 in papillon's terragear repo where GPC is replaced by clipper. I then
 applied a few
 patches, reducing various epsilon constants in the code which I think
 were too loose and
 caused inconsistencies in the clipper. You can find my code here (in the
 branch
 custom_scenery_clean):

 https://gitorious.org/~maximeguillaud/papillon81/maxime-terragear-cs/commits/custom_scenery_clean

 More specifically, the patches relevant to fgfs-construct are in commits
 81a78602e09b67edd58b2cedacf09079239b0177 and
 8601f66cf7cf00ffda38f57cee77ae991c42dab8.
 The second one uses the constant SG_EPSILON defined in Simgear. I
 reduced the
 value of this constant in simgear/constants.h:
 #define SG_EPSILON (DBL_EPSILON*10)
 (Note that I am using a different installation of Simgear for terragear
 and for fgfs, so
 I do not know if this change would have consequences on fgfs).

 With the above settings, I was able to process large amounts of scenery
 without any crash.
 So far I have tried a band covering Europe between 12 and 14 degrees East,
 i.e. going
 through Sicily, Italy, the Austrian Alps, the Czech Republic and Germany,
 Sweden and
 Norway, up to 69 degrees North. My scenery includes detailed terrain
 (fitted with 15m
 accuracy), the CORINE land cover, and OSM rail and roads up to the
 secondary network. The
 latest update in the BTG format seem to have fixed the swirlies.

 You can see a few screenshots here:
 http://www.mguillaud.net/fg/scenery-gallery/

 The only problem that prevents me from calling it final and generating
 custom scenery for
 all of Europe can be seen in the last screenshot:
 http://www.mguillaud.net/fg/scenery-gallery/fgfs-screen-008.png
 Sometimes, one polygon will have the correct shape but the material is
 wrong, and it
 appears all gray. This seems to occur only around roads. Any advice on
 this is
 appreciated. I had a chat with Martin Spott (hi Martin !) a few days ago
 and he mentioned
 that the bug is known, and proceeded to explain it to me, however I have
 not been able to
 relate his explanation to the code in fgfs-construct. I can provide a
 minimal set of
 files (3 roads) that trigger this problem, in case anyone can help with
 the debugging.

 Maxime


 --
 RSA(R) Conference 2012
 Save $700 by Nov 18
 Register now
 http://p.sf.net/sfu/rsa-sfdev2dev1
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel

--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] [Flightgear-commitlogs] FlightGear branch, next,

2011-11-12 Thread Durk Talsma
 
 Is this the one which was causing the 'rabbits' at EHLE ?
 

Nope, this one was just causing aircraft that landed at an airport without a 
ground network to taxi to the end of the world (or better the beginning: 
lat/lon 0.00; 0.00). What you're referring to is -I assume- the incrorrect 
ground offset in the cessna. That isn't really a bug in the true sense of the 
word. Just inaccurate data.

Cheers,
Durk


--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Fixing fgfs-construct crashes

2011-11-12 Thread Martin Spott
Hi Maxime and others,

Maxime Guillaud wrote:

 You can find my code here [...]

I'm just starting to recover from a couple of _really_ tight days
(including a nice PostgreSQL conference PGConf.DE where I gave a talk
about our geodata collection and in-database processing), therefore I'm
not yet ready to provide comprehensive responses.  Anyhow there's one
point I'd like to emphasize:

I know it's really cool to maintain private source repositories  ;-)
   but for increasing the overall success of building FlightGear
scenery I'd think it would be really beneficial to keep the various
development efforts in close relation and sync.  Thus I'd invite
everyone who's serious about improving the TerraGear toolchain to
create a branch in the main repository in order to develop their
specific features/changes there - not only but also because this would
simplify tracking of the various changes.

The former terragear-cs main repository at MapServer was already open
to (almost) everybody who asked and now that it's moved over to
Gitorious there's really no more excuse not to create branches inside
the main repo  :-)

Best regards,
Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Aircraft rating now visible in fgrun

2011-11-12 Thread HB-GRAL
Am 12.11.11 20:00, schrieb Frederic Bouvier:
 Am 12.11.11 19:35, schrieb Frederic Bouvier:
 Hi Yves,

 Am 12.11.11 11:05, schrieb Frederic Bouvier:
 See : http://frbouvi.free.fr/flightsim/fgrun-rating-system.png

 And what about this one ?
 http://frbouvi.free.fr/flightsim/fgrun-rating-system-star-en.png

 Hi Fred

 Looking to the bars and the stars I think the stars are probably
 too
 easy. The rating system introduced looks much more sophisticated.

 too easy ? I am not sure to understand what you mean


 Fred, I meant it is too easy because the stars simplify the system
 to much, but I realize that the rating system is written down very
 sophisitcated, but indeed have 5 levels only ... so it is no
 difference for you probably. I was looking to the stars and thought,
 wow, we have 100 % cockpits etc.

 The rating system is not my invention. It is just an implementation
 of what was discussed on the forum :
 http://www.flightgear.org/forums/viewtopic.php?f=4t=12193
 and described here :
 http://wiki.flightgear.org/Formalizing_Aircraft_Status


I know it is not your invention. What I mean is that bars and stars say 
nothing. Who gave the stars, what does it really mean? No info. The wiki 
page says a lot about the rating, and I don’t know if this is really is 
reflected now. It isn’t any fundamental critism, just some feedback.

Cheers, Yves

--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


[Flightgear-devel] KSFO default scenery

2011-11-12 Thread HB-GRAL
Hi Scenery

I just noticed that this small scenery bugs at KSFO never have been 
fixed since many years now (or did I miss something?). When you show me 
how I can help to fix this, I will really send a merge request, and I 
guess this is not critical !  But should be solved once ;-)

osgDB ac3d reader: could not parse texture coords while reading object 
Mesh1 Component_1_1 M setting to (0,0)
osgDB ac3d reader: could not parse texture coords while reading object 
Mesh2 Component_1_2 M setting to (0,0)
osgDB ac3d reader: could not parse texture coords while reading object 
Mesh3 Component_1_3 M setting to (0,0)
osgDB ac3d reader: could not parse texture coords while reading object 
Mesh4 Component_1_4 M setting to (0,0)
osgDB ac3d reader: could not parse texture coords while reading object 
Mesh5 Component_1_5 M setting to (0,0)
osgDB ac3d reader: could not parse texture coords while reading object 
Mesh6 Component_1_6 M setting to (0,0)
osgDB ac3d reader: could not parse texture coords while reading object 
Mesh7 Component_1_7 M setting to (0,0)

Cheers, Yves


--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Aircraft rating now visible in fgrun

2011-11-12 Thread Stuart Buchanan
On Sat, Nov 12, 2011 at 10:05 AM, Frederic Bouvier wrote:
 See : http://frbouvi.free.fr/flightsim/fgrun-rating-system.png

 And what about this one ?
 http://frbouvi.free.fr/flightsim/fgrun-rating-system-star-en.png

Of the two, I prefer the stars. Great work.

Out of interest, what are you planning to display if the aircraft
is not rated? Not Rated?

-Stuart

--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Aircraft rating now visible in fgrun

2011-11-12 Thread Curtis Olson
So now it would be interesting if fgrun could be used by end users to rate
the aircraft in the different categories and then fgrun would pull the
ratings from some server that tracks all this. :-)

Curt.


On Sat, Nov 12, 2011 at 5:02 PM, Stuart Buchanan wrote:

 On Sat, Nov 12, 2011 at 10:05 AM, Frederic Bouvier wrote:
  See : http://frbouvi.free.fr/flightsim/fgrun-rating-system.png
 
  And what about this one ?
  http://frbouvi.free.fr/flightsim/fgrun-rating-system-star-en.png

 Of the two, I prefer the stars. Great work.

 Out of interest, what are you planning to display if the aircraft
 is not rated? Not Rated?

 -Stuart


 --
 RSA(R) Conference 2012
 Save $700 by Nov 18
 Register now
 http://p.sf.net/sfu/rsa-sfdev2dev1
 ___
 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
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Aircraft rating now visible in fgrun

2011-11-12 Thread HB-GRAL
Am 13.11.11 00:12, schrieb Curtis Olson:
 So now it would be interesting if fgrun could be used by end users to rate
 the aircraft in the different categories and then fgrun would pull the
 ratings from some server that tracks all this. :-)

 Curt.


Oh yes, I will immediately set up a new Webby-2.0 Free Independent 
Aircraft Rating Page then :-)

Cheers, Yves

--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Aircraft rating now visible in fgrun

2011-11-12 Thread George Patterson
On 13 November 2011 10:12, Curtis Olson curtol...@gmail.com wrote:
 So now it would be interesting if fgrun could be used by end users to rate
 the aircraft in the different categories and then fgrun would pull the
 ratings from some server that tracks all this. :-)
 Curt.


But be careful what you wish for.

Accepting user ratings would too open to abuse from competing products
and KidSFO pilots thumbing an aircraft up for the lolz.

I would be surprised if the ratings for the different aircraft ended
up being consistent, should rating be accepted from the greater user
base.

Sorry Curt, you have lost me on the merit of this idea, especially
considering the effort required. One person, one vote etc.

Regards


George

--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Fixing fgfs-construct crashes

2011-11-12 Thread Peter Sadrozinski
Hi Martin,

I've been reluctant to move to the official repository mostly because of
very little understanding of GIT.
I'm a bit more confident, now, so I don't see it as a big problem.

I think most of the work we are doing (alternate clipping library, 850
format) should be considered experimental, however.  I'm pretty sure we
want to keep the main branch
concentrated on fixing problems with detailed landclass.

We seem to be breaking terragear pretty good as of late :)

Maxime: I have an experiment for you to try - could you take the UFO under
those grey sections of scenery, and look up at them?  I think the normals
have swapped.
Chris mentioned this happening with the skirt around the airport, and I
hadn't seen it until a recent update.  Looks like something broke recently.

Pete



On Sat, Nov 12, 2011 at 2:38 PM, Martin Spott martin.sp...@mgras.netwrote:

 Hi Maxime and others,

 Maxime Guillaud wrote:

  You can find my code here [...]

 I'm just starting to recover from a couple of _really_ tight days
 (including a nice PostgreSQL conference PGConf.DE where I gave a talk
 about our geodata collection and in-database processing), therefore I'm
 not yet ready to provide comprehensive responses.  Anyhow there's one
 point I'd like to emphasize:

 I know it's really cool to maintain private source repositories  ;-)
    but for increasing the overall success of building FlightGear
 scenery I'd think it would be really beneficial to keep the various
 development efforts in close relation and sync.  Thus I'd invite
 everyone who's serious about improving the TerraGear toolchain to
 create a branch in the main repository in order to develop their
 specific features/changes there - not only but also because this would
 simplify tracking of the various changes.

 The former terragear-cs main repository at MapServer was already open
 to (almost) everybody who asked and now that it's moved over to
 Gitorious there's really no more excuse not to create branches inside
 the main repo  :-)

 Best regards,
Martin.
 --
  Unix _IS_ user friendly - it's just selective about who its friends are !
 --


 --
 RSA(R) Conference 2012
 Save $700 by Nov 18
 Register now
 http://p.sf.net/sfu/rsa-sfdev2dev1
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel

--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Fixing fgfs-construct crashes

2011-11-12 Thread Peter Sadrozinski
I have verified that the problem lies in using clipper.
Using the same simple data with GPC works.  It appears clipper can
sometimes produce clockwise winded polys.

I'm working on a fix now.

Pete

On Sat, Nov 12, 2011 at 7:59 PM, Peter Sadrozinski
psadrozin...@gmail.comwrote:

 Hi Martin,

 I've been reluctant to move to the official repository mostly because of
 very little understanding of GIT.
 I'm a bit more confident, now, so I don't see it as a big problem.

 I think most of the work we are doing (alternate clipping library, 850
 format) should be considered experimental, however.  I'm pretty sure we
 want to keep the main branch
 concentrated on fixing problems with detailed landclass.

 We seem to be breaking terragear pretty good as of late :)

 Maxime: I have an experiment for you to try - could you take the UFO under
 those grey sections of scenery, and look up at them?  I think the normals
 have swapped.
 Chris mentioned this happening with the skirt around the airport, and I
 hadn't seen it until a recent update.  Looks like something broke recently.

 Pete




 On Sat, Nov 12, 2011 at 2:38 PM, Martin Spott martin.sp...@mgras.netwrote:

 Hi Maxime and others,

 Maxime Guillaud wrote:

  You can find my code here [...]

 I'm just starting to recover from a couple of _really_ tight days
 (including a nice PostgreSQL conference PGConf.DE where I gave a talk
 about our geodata collection and in-database processing), therefore I'm
 not yet ready to provide comprehensive responses.  Anyhow there's one
 point I'd like to emphasize:

 I know it's really cool to maintain private source repositories  ;-)
    but for increasing the overall success of building FlightGear
 scenery I'd think it would be really beneficial to keep the various
 development efforts in close relation and sync.  Thus I'd invite
 everyone who's serious about improving the TerraGear toolchain to
 create a branch in the main repository in order to develop their
 specific features/changes there - not only but also because this would
 simplify tracking of the various changes.

 The former terragear-cs main repository at MapServer was already open
 to (almost) everybody who asked and now that it's moved over to
 Gitorious there's really no more excuse not to create branches inside
 the main repo  :-)

 Best regards,
Martin.
 --
  Unix _IS_ user friendly - it's just selective about who its friends are !
 --


 --
 RSA(R) Conference 2012
 Save $700 by Nov 18
 Register now
 http://p.sf.net/sfu/rsa-sfdev2dev1
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel



--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel