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 we really
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 reside in
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 really
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 MByte).
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. This
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
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
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
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
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
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
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
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
17 matches
Mail list logo
