> The "Models" folder for example, since that's not maintained there -
> it's just a copy of what is maintained in the scenery database
> and we shouldn't modify it directly in fgdata.
Um... not true. Cloud textures and models currently reside in
/Models/Weather/ and as far as I know are modified
On Sun, 16 Oct 2011, ThorstenB wrote:
> Am 16.10.2011 23:30, schrieb Curtis Olson:
>
>> One question: if we have our own local branches of the fgdata repository
>> for our own experimentation, will it be straightforward to hang these
>> off the new repository?
>
> Simple answer: no. :-(
>
> Since
On 17.10.2011 09:11, thorsten.i.r...@jyu.fi wrote:
>> The "Models" folder for example, since that's not maintained there -
>> it's just a copy of what is maintained in the scenery database
>> and we shouldn't modify it directly in fgdata.
>
> Um... not true. Cloud textures and models currently res
> Yes, true, we noticed that already. Hence we'll have to leave it as it
> is right now. A bit unfortunate, this would have really shrunk the
> archive significantly. But we may still be able to do that one day...
It's a finite task to move the Weather/ folder elsewhere (i.e. out of
Models/) and d
ThorstenB,
ThorstenB wrote:
> Yes, true, we noticed that already. Hence we'll have to leave it as it
> is right now. A bit unfortunate, this would have really shrunk the
> archive significantly. But we may still be able to do that one day...
The two biggest chunks in Models/ are Weather/ (110
>> Um... not true. Cloud textures and models currently reside in
>> /Models/Weather/ and as far as I know are modified within fgdata, but are
>> not in the scenery database.
>
> Yes, true, we noticed that already. Hence we'll have to leave it as it
> is right now. A bit unfortunate, this would have
>> Yes, true, we noticed that already. Hence we'll have to leave it as it
>> is right now. A bit unfortunate, this would have really shrunk the
>> archive significantly. But we may still be able to do that one day...
>
> The two biggest chunks in Models/ are Weather/ (110 MByte) and
> Geometry/ (35
Hi.
> Here is a random thought: what if the polygon data was painted onto a raster
> texture (of some "sufficient" resolution) in correct bottom up order, rather
> than being clipped. Then at the end of the process we figure out how to
> extract the resulting polygons from the raster image. Thi
HB-GRAL wrote:
> There is so many "software" to do exactly this task. I could not imagine
> that our scenery is THAT important for this developement.
At least our Scenery led to significant improvements in the way GRASS7
deals with vector data ;-)
Cheers,
Martin.
--
Unix _IS_ user fr
It's been a month since I announced the intention, to switch all the main FG
platforms to use CMake, and to deprecate and remove the other build systems
from Git. There's been many small improvements in the Cmake files since then,
which I hope have eased some people's concerns about the switch.
Hi James,
One thing that stresses me out is large scale technology changes with no
documentation or howto's to back them up. This change might be fine for
people who are cmake experts. And I know anyone can start from scratch and
read the cmake manual from cover to cover. But that takes time an
Am 17.10.2011 19:10, schrieb James Turner:
> It's been a month since I announced the intention, to switch all the main FG
> platforms to use CMake, and to deprecate and remove the other build systems
> from Git. There's been many small improvements in the Cmake files since then,
> which I hope
FYI,
http://www.barco.com/en/product/2337/video
http://boingboing.net/2011/10/12/new-immersive-360-degree-flight-simulator-for-fighter-jet-pilots-unveiled.html
--
Roberto Waltman.
--
All the data continuously generate
FYI,
http://www.barco.com/en/product/2337/video
http://boingboing.net/2011/10/12/new-immersive-360-degree-flight-simulator-for-fighter-jet-pilots-unveiled.html
--
Roberto Waltman.
--
All the data continuously generat
While investigating a reported compilation error, I had a look in the
SGMath headers. I noticed some of them don't properly include their
dependencies (for example, SGMisc is missing SGCMath, SGGeodesy is
missing SGVec3 and SGGeod, etc.).
I am wondering if they are supposed to be available for sta
I can't provide specifics yet, but I have a feeling our old friends,
random segfaults and "glibc detected" memory corruption, are back with
a vengeance.
Anybody else noticed it?
--
Csaba/Jester
--
All the data continuous
On Mon, Oct 17, 2011 at 7:01 PM, Csaba Halász wrote:
> While investigating a reported compilation error, I had a look in the
> SGMath headers. I noticed some of them don't properly include their
> dependencies (for example, SGMisc is missing SGCMath, SGGeodesy is
> missing SGVec3 and SGGeod, etc.)
Hi,
On Tuesday, October 18, 2011 02:01:33 Csaba Halász wrote:
> While investigating a reported compilation error, I had a look in the
> SGMath headers. I noticed some of them don't properly include their
> dependencies (for example, SGMisc is missing SGCMath, SGGeodesy is
> missing SGVec3 and SGG
18 matches
Mail list logo
