Re: [Flightgear-devel] reminder: entering feature freeze now

[Anders Gidenstam]

On Tue, 25 Jun 2013, Stuart Buchanan wrote:

> Having thought about this a bit more I'm going to propose we do 2.12.0 now and
> "pre-announce" 3.0 as the Feb 2014 release to give us just a little more time
> to prepare and make the 3.0 as polished as possible.  After all, it'll
> be the third
> major release in 15 years :) .

Sounds like a plan. I prefer this option.

Cheers,

Anders
-- 
---
Anders Gidenstam
WWW: http://gitorious.org/anders-hangar
  http://www.gidenstam.org/FlightGear/

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Improved Scenery Data Question

[John Holden]

JJ:

The mirror would be great, but the scenery isn't finished - it's just the 
underlying scenery data.

Plus, because it's 'better' scenery, the question of how do we distribute the 
scenery once it is generated becomes an issue.

I know Martin's working on a potential solution, so I'll be patient.


Cheers
John




 From: default 
To: John Holden ; FlightGear developers 
discussions  
Sent: Monday, June 24, 2013 3:12 AM
Subject: Re: [Flightgear-devel] Improved Scenery Data Question
 

Hi John:


I'm wondering if anyone has any suggestions on getting this data into the 
system so users can start flying over it.


I maintain a mirror for flightgear.  (ftp://ftp.kingmont.com and 
http://kingmont.com)

You might try contacting Curtis and see how you would go about putting some of 
your stuff up on that site!  You would be welcome to use it as far as I'm 
concerned  (I don't fool with it except to pay the bill! ).

jj--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Positioning Aircraft: accuracy

[Adam Dershowitz]

A few years ago, I helped squash a bug that occurred when reading in data with 
generic IO (I think that my patch was included in the code).  At the time, it 
was reading in just a float.  So, when using it to read in position, the 
doubles for lat/long were being cut (rounded or truncated?) and it meant that 
during playback of flight the aircraft would jump around a little bit (on the 
order of meters), even when there was actually smooth position data in the 
input file.  The look was like a bad frame rate, because it would jump from 
position to position.
So, I concur that it sounds a lot like just a float is being used for initial 
position, when a double is necessary.


-- Adam


From: Curtis Olson mailto:curtol...@flightgear.org>>
Reply-To: FlightGear developers discussions 
mailto:flightgear-devel@lists.sourceforge.net>>
Date: Tuesday, June 25, 2013 12:05 PM
To: FlightGear developers discussions 
mailto:flightgear-devel@lists.sourceforge.net>>
Subject: Re: [Flightgear-devel] Positioning Aircraft: accuracy

It really smells like a double -> float conversion somewhere in the pipeline 
(more than a geocentric / geodetic conversion or something like that).

Curt.


On Tue, Jun 25, 2013 at 2:01 PM, D-NXKT 
mailto:d_n...@yahoo.de>> wrote:
> How far off is the aircraft placement - how much is the "jump"? Is it
> many hundreds of meters, or on the order a meter or two, or just
> centimeters?
>
> Jon


Several meters!

Or more precise:

first: lat= 47.306263  lon= 11.379070
"jump" to: lat= 47.3062060567  lon= 11.3790703145
   ^
Difference = 6.34 meters (20.80 ft)

Best regards
D-NXKT


--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
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
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] reminder: entering feature freeze now

[Curtis Olson]

On Tue, Jun 25, 2013 at 4:48 PM, Stuart Buchanan  wrote:

> Having thought about this a bit more I'm going to propose we do 2.12.0 now
> and
>  "pre-announce" 3.0 as the Feb 2014 release to give us just a little more
> time
> to prepare and make the 3.0 as polished as possible.  After all, it'll
> be the third
> major release in 15 years :) .
>
> We currently have about 3 weeks before the release branches are cut,
> and we'll have
> some 7 weeks for bug hunting.  For a 2.12.0 release, that's business as
> usual,
> but I can imagine that many aircraft developers in particular would
> want to perform
> some extra TLC before a major release.  Externally, 3.0 is going to be
> considered
> a bigger deal than 2.12.0.
>
> Declaring that the Feb 2014 release will be 3.0 now will give everyone
> plenty of
> notice, and might encourage efforts to fix bugs in the next 6 months.  I'm
> aware
> that my FG development time is more limited these days, and given activity
> on
> this list I suspect I'm not alone, so this time might be quite useful.
>
> Whatever way we go, I suggest that we zero-pad the minor release digit
> after 3.0.0
> so we have 3.02, 3.04 etc. to reduce confusion if we reach double digits.
>

Hi Stuart, before you wrote your message, I was going to write that my
preference is to cut over to 3.0.0 for this release. :-)

That said, we probably created and endured most of the potential confusion
when we went with 2.10.x so continuing on with 2.12.x probably doesn't make
things any worse for ourselves at this point.

In retrospect, I can see how this has the ability to create confusion ...
many computer systems sort file names in ascii order, many people don't
seem to pay careful attention to where the decimal points are placed, etc.

Once we clear past the 2.10, 2.12, etc. series, I'd like to go back to
keeping things single digits in the major and minor version numbers and
when we run out of a single digits bump up the major number (so 3.8.x ->
4.0.x).  Number are numbers, but this one confused a lot more people than I
expected it would or should so maybe it's good to be sensitive to that
after we clear the 2.x series of versions.

So to summarize, I would have voted for 3.0.x as my personal preference,
but numbers are numbers and 2.12 works just as well for me.

This email probably took me 5 minutes to write, so I've said what I wanted
to say and I'm done worrying about it now, whatever the final consensus is.
:-)

Curt.
-- 
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org - http://gallinazo.flightgear.org
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] reminder: entering feature freeze now

[Stuart Buchanan]

On Mon, Jun 24, 2013 at 10:41 PM, Torsten Dreyer wrote:
> Collecting the arguments from this discusson, I can see good points for
> a 3.0.0 release. Most convincing was Stuarts comparison against 2.0.0
> and the progress we made since that version.
>
> My suggestion is, we dare to call the 2013 summer edition FlightGear
> 3.0.0 and we bump the version number later this week.
>
> I'll leave that discussion open for a few days and hope we can agree on
> the new number.

Having thought about this a bit more I'm going to propose we do 2.12.0 now and
"pre-announce" 3.0 as the Feb 2014 release to give us just a little more time
to prepare and make the 3.0 as polished as possible.  After all, it'll
be the third
major release in 15 years :) .

We currently have about 3 weeks before the release branches are cut,
and we'll have
some 7 weeks for bug hunting.  For a 2.12.0 release, that's business as usual,
but I can imagine that many aircraft developers in particular would
want to perform
some extra TLC before a major release.  Externally, 3.0 is going to be
considered
a bigger deal than 2.12.0.

Declaring that the Feb 2014 release will be 3.0 now will give everyone plenty of
notice, and might encourage efforts to fix bugs in the next 6 months.  I'm aware
that my FG development time is more limited these days, and given activity on
this list I suspect I'm not alone, so this time might be quite useful.

Whatever way we go, I suggest that we zero-pad the minor release digit
after 3.0.0
so we have 3.02, 3.04 etc. to reduce confusion if we reach double digits.

-Stuart

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Positioning Aircraft: accuracy

[Curtis Olson]

It really smells like a double -> float conversion somewhere in the
pipeline (more than a geocentric / geodetic conversion or something like
that).

Curt.


On Tue, Jun 25, 2013 at 2:01 PM, D-NXKT  wrote:

> > How far off is the aircraft placement - how much is the "jump"? Is it
> > many hundreds of meters, or on the order a meter or two, or just
> > centimeters?
> >
> > Jon
>
>
> Several meters!
>
> Or more precise:
>
> first: lat= 47.306263  lon= 11.379070
> "jump" to: lat= 47.3062060567  lon= 11.3790703145
>^
> Difference = 6.34 meters (20.80 ft)
>
> Best regards
> D-NXKT
>
>
>
> --
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> ___
> 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
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Positioning Aircraft: accuracy

[D-NXKT]

> How far off is the aircraft placement - how much is the "jump"? Is it
> many hundreds of meters, or on the order a meter or two, or just  
> centimeters?
> 
> Jon


Several meters!

Or more precise:

first: lat= 47.306263  lon= 11.379070
"jump" to: lat= 47.3062060567  lon= 11.3790703145
   ^
Difference = 6.34 meters (20.80 ft)

Best regards
D-NXKT


--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Grain texture for models - a demo

[Gijs de Rooy]

Hi Thorsten

> I can also give you the extra lines for the Citation Bravo with hires stains

That would be appreciated. Emilian already reminded me of the normalmap 
feature, so it'd be interesting to compare the two and see which one I prefer. 

But don't hurry; better not send it to me before Friday the 5th, so I don't 
waste 
my precious study time ;-)

Cheers,
Gijs
  --
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] SimGear build fails

[Thomas Geymayer]

Hi Torsten,

2013/6/25 Torsten Dreyer :
> I'm failing to build SimGear on 64bit linux:
> EffectGeode.cxx:83:136: error: no matching function for call to
> ‘osg::Geometry::setVertexAttribArray(int&, osg::Geometry::ArrayData)’
>
> OSG is stable 3.0.1 from svn (same with OSG trunk)
> SimGear is git next from today

seems you are using a too new version of OSG. The latest version of
OSG working for me is 3.1.7. setVertexAttribArray has been deprecated
and removed within OSG >= 3.1.8.
Btw. OSG trunk == 3.1.8

Tom

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] SimGear build fails

[Torsten Dreyer]

Hi,

I'm failing to build SimGear on 64bit linux:
EffectGeode.cxx:83:136: error: no matching function for call to 
‘osg::Geometry::setVertexAttribArray(int&, osg::Geometry::ArrayData)’

OSG is stable 3.0.1 from svn (same with OSG trunk)
SimGear is git next from today

Yes, I rm-rf'ed previous artefacts and started from scratch.

Thanks,
Torsten


--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] reminder: entering feature freeze now

[Renk Thorsten]

Hi Stuart,

> Ah yes.  I remember you mentioning this before, me saying I'd add it
> to my TODO list, and then failing to do so.  Sorry.  I've now added it
> to my wiki TODO list so I don't forget again.  Are you thinking about
> the sprinkling of lights that we put over the terrain, the VASI/PAPI
> lights, or the approach lights.  Or all three?  :)

I think none of the lights are ever processed by any shader code, so they would 
all get some default non-shader fogging and never fog correctly. It might be as 
trivial as just running them through model-default.eff, but I can also write a 
dedicated shader for lights as they won't need any ambient of diffuse light 
computations. It might also be much cheaper to simply fade them to transparent 
and use the fog color from whatever is behind rather than to comnpute the 
actual fog color (which is moderately expensive). This strategy seems to be 
working well for heavily fogged clouds.

Certainly all the runway lighting sticks out worst, because it make the runway 
outline visible through very dense fogging, which sort of defeats the point of 
dense fog obscuring the runway. I could probably live with VASI being seen from 
a larger distance, I guess they're pretty powerful lights, and fog fading of a 
light source must be a function of the light intensity (and direction - and 
aerosol size... and...) in reality.

> I don't think it's a major hold-up, but it would be nice to get it  
> resolved.

I'll be travelling next week - hotel rooms have often been the location for 
major code development, so I'll try to get the wake shader done then. If we 
agree that this doesn't constitute a novel feature and can be added despite the 
feature freeze.

* Thorsten
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Terrasync.exe on Jenkins

[Nigel Mackay]

Terrasync.exe is not in the Jenkins 64-bit build. Isn't this an error? 
Haven't checked the 32-bit build.

Seems to me that if you start off with FG using on;y Git it needs to be 
there.

Nigel


--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Grain texture for models - a demo

[Renk Thorsten]

> Interesting! Any way we can see this example "live"? I'd love to  
> experiment with it in the 744's cockpit, but that'll have to wait till  
> after next weeks exams...

I'll be happy to let you have the files - but the Vinson can't go to GIT 
because it doesn't really work due to the uv-mapping, and even if I get it to 
the point where it does (I'd have to see if I can get the ac3d license 
transferred to my new computer, just copying the directory isn't enough...) 
it's not my model and I have no business modifying it.

If it's just about studying from a working example, I can also give you the 
extra lines for the Citation Bravo with hires stains, that's perhaps more 
instructive as it combines grain with other effects. Just let me know what you 
need.

* Thorsten

 
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Grain texture for models - a demo

[Gijs de Rooy]

Interesting! Any way we can see this example "live"? I'd love to experiment 
with it in the 744's cockpit, but that'll have to wait till after next weeks 
exams...

> If you want to do the same detail level using conventional texturing, you 
> need a texture resolution of 25600x6400 (I'm guessing no GPU can even process 
> this).

You could split the deck to create a square texture of 12800x12800, which is 
something my (laptop!) GPU can handle. I've been experimenting with 16384x16384 
textures lately and didn't run into trouble, apart from a 32bits build running 
out of memory when adding a second texture. But that's a little overdone for 
something as "small" as a carrier deck :-)

Cheers,
Gijs

> From: thorsten.i.r...@jyu.fi
> To: flightgear-devel@lists.sourceforge.net
> Date: Tue, 25 Jun 2013 09:13:47 +
> Subject: [Flightgear-devel] Grain texture for models - a demo
> 
> 
> Since the idea hasn't really caught with modelers yet, I've tried to get a 
> more practical demo of the virtue of a grain texture and tried to put a grain 
> effect on the Vinson flightdeck (I've always felt that the homogeneous grey 
> color doesn't justice to the details of the model otherwise).
> 
> Here's a comparison
> 
> http://users.jyu.fi/~trenk/pics/vinson_with_grain.jpg
> 
> http://users.jyu.fi/~trenk/pics/vinson_without_grain.jpg
> 
> In my personal view, this makes a hell of a difference. I'm not getting any 
> visible framerate difference, and the GPU memory has to hold just a single 
> 512x512 texture more. If you want to do the same detail level using 
> conventional texturing, you need a texture resolution of 25600x6400 (I'm 
> guessing no GPU can even process this).
> 
> There's (unfortunately) a catch - the screenshots are taken on the landing 
> strip where the uv-mapping is very homogeneous, but to my surprise I 
> discovered that the rest of the flightdeck has a rather inhomogeneous 
> uv-mapping, i.e. to make the Vinson really make use of the grain effect, the 
> uv-mapping of the Flightdeck would have to be redone.
> 
> Vinson crew - anyone interested? I'm happy to send the effect definition and 
> the grain texture. 
> 
> We can use this whenever a model has a large crufely textured surface and 
> just should get some hint of metal surface (or any other structure - we can 
> do concrete or wood just as well) - it's tremendous texture resolution for 
> cheap. But I'm a coder, not a modeler, for me things like changing the 
> uv-mapping take unreasonably long, so I would really hope to get folks from 
> modeling interested.
> 
> * Thorsten
> --
> This SF.net email is sponsored by Windows:
> 
> Build for Windows Store.
> 
> http://p.sf.net/sfu/windows-dev2dev
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
  --
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Grain texture for models - a demo

[Renk Thorsten]

> I looked at this possibility already. The carrier deck is made up of a
> number of odd-shaped areas, for historical reasons. I don't think that a
> complete rebuild of the flight deck is worth it for this very nice  
> eye-candy
> (just too much work). Alexis might think differently.

Do you really think it has to be rebuilt? My impression was that you just need 
to map the odd-shaped area to a grey base texture without distortion (now it's 
mapped to a distorted grey patch) using the same magnification as for the main 
strip. All the shader effect wants is the same ratio of physical size to 
texture coordinates all over the deck, it doesn't care about odd shapes 
otherwise.

* Thorsten
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Grain texture for models - a demo

[Vivian Meazza]

Thorsten wrote

> Sent: 25 June 2013 10:14
> To: FlightGear developers discussions
> Subject: [Flightgear-devel] Grain texture for models - a demo
> 
> 
> Since the idea hasn't really caught with modelers yet, I've tried to get a
more
> practical demo of the virtue of a grain texture and tried to put a grain
effect
> on the Vinson flightdeck (I've always felt that the homogeneous grey color
> doesn't justice to the details of the model otherwise).
> 
> Here's a comparison
> 
> http://users.jyu.fi/~trenk/pics/vinson_with_grain.jpg
> 
> http://users.jyu.fi/~trenk/pics/vinson_without_grain.jpg
> 
> In my personal view, this makes a hell of a difference. I'm not getting
any
> visible framerate difference, and the GPU memory has to hold just a single
> 512x512 texture more. If you want to do the same detail level using
> conventional texturing, you need a texture resolution of 25600x6400 (I'm
> guessing no GPU can even process this).
> 
> There's (unfortunately) a catch - the screenshots are taken on the landing
> strip where the uv-mapping is very homogeneous, but to my surprise I
> discovered that the rest of the flightdeck has a rather inhomogeneous uv-
> mapping, i.e. to make the Vinson really make use of the grain effect, the
uv-
> mapping of the Flightdeck would have to be redone.
> 
> Vinson crew - anyone interested? I'm happy to send the effect definition
and
> the grain texture.
> 
> We can use this whenever a model has a large crufely textured surface and
> just should get some hint of metal surface (or any other structure - we
can
> do concrete or wood just as well) - it's tremendous texture resolution for
> cheap. But I'm a coder, not a modeler, for me things like changing the uv-
> mapping take unreasonably long, so I would really hope to get folks from
> modeling interested.
> 

I looked at this possibility already. The carrier deck is made up of a
number of odd-shaped areas, for historical reasons. I don't think that a
complete rebuild of the flight deck is worth it for this very nice eye-candy
(just too much work). Alexis might think differently.

Vivian


--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Grain texture for models - a demo

[Renk Thorsten]

Since the idea hasn't really caught with modelers yet, I've tried to get a more 
practical demo of the virtue of a grain texture and tried to put a grain effect 
on the Vinson flightdeck (I've always felt that the homogeneous grey color 
doesn't justice to the details of the model otherwise).

Here's a comparison

http://users.jyu.fi/~trenk/pics/vinson_with_grain.jpg

http://users.jyu.fi/~trenk/pics/vinson_without_grain.jpg

In my personal view, this makes a hell of a difference. I'm not getting any 
visible framerate difference, and the GPU memory has to hold just a single 
512x512 texture more. If you want to do the same detail level using 
conventional texturing, you need a texture resolution of 25600x6400 (I'm 
guessing no GPU can even process this).

There's (unfortunately) a catch - the screenshots are taken on the landing 
strip where the uv-mapping is very homogeneous, but to my surprise I discovered 
that the rest of the flightdeck has a rather inhomogeneous uv-mapping, i.e. to 
make the Vinson really make use of the grain effect, the uv-mapping of the 
Flightdeck would have to be redone.

Vinson crew - anyone interested? I'm happy to send the effect definition and 
the grain texture. 

We can use this whenever a model has a large crufely textured surface and just 
should get some hint of metal surface (or any other structure - we can do 
concrete or wood just as well) - it's tremendous texture resolution for cheap. 
But I'm a coder, not a modeler, for me things like changing the uv-mapping take 
unreasonably long, so I would really hope to get folks from modeling interested.

* Thorsten
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel