Well - yes - I am rather disappointed
Especially because i looked again, but cannot find any of my suggested
improvements in the latest getstart, in regards to structuring,
referencing, and looks. In addition I did not really see an answer to
Curtis question, that started that all - I get that
If you regularly pull+build 'next', please try a cmake based build, and
report any issues you encounter - CMake should work 'out of the box' on Mac
(Makefiles or XCode), Linux (32- and 64- bit) and Windows (VisualStudio 2008
and 2010 - mingw and cygwin may need some fixes).
Hi James,
Hi Durk,
- Mail original -
If you regularly pull+build 'next', please try a cmake based build,
and report any issues you encounter - CMake should work 'out of
the box' on Mac (Makefiles or XCode), Linux (32- and 64- bit) and
Windows (VisualStudio 2008 and 2010 - mingw and
hi Fred,
On 10 Sep 2011, at 10:28, Frederic Bouvier wrote:
Hi Durk,
FindOpenSceneGraph.cmake is in the Cmake distribution, in the share
directory. You certainly need to tell Cmake where the installed OSG is.
Regards,
-Fred
Thanks; looking at /usr/share/cmake/Modules, I see that I
- Mail original -
hi Fred,
On 10 Sep 2011, at 10:28, Frederic Bouvier wrote:
Hi Durk,
FindOpenSceneGraph.cmake is in the Cmake distribution, in the share
directory. You certainly need to tell Cmake where the installed
OSG is.
Regards,
-Fred
Thanks; looking
Hi Durk,
On Saturday, September 10, 2011 10:28:22 Frederic Bouvier wrote:
FindOpenSceneGraph.cmake is in the Cmake distribution, in the share
directory. You certainly need to tell Cmake where the installed OSG is.
Correct, this should be cmake provided.
So, cmake does not find its own files.
Hi,
On Saturday, September 10, 2011 10:46:03 Durk Talsma wrote:
Thanks; looking at /usr/share/cmake/Modules, I see that I have a
Findosg.cmake file, as well as several Findosg*.cmake files, but no
FindOpenSceneGraph.cmake. FWIW, this is one an opensuse 10.0, running
cmake version 2.6 - patch
Am Sat, 10 Sep 2011 10:18:27 +0200
schrieb Jörg Emmerich j-emmer...@online.de:
Well - yes - I am rather disappointed
That is not surprising!
Technically seen, it is correct that Latex is the most flexible format,
from which you can derive most other types, but that doesn't lessen the
nice
James Turner wrote:
If you regularly pull+build 'next', please try a cmake based build, and
report any issues you encounter - CMake should work 'out of the box' on
Mac (Makefiles or XCode), Linux (32- and 64- bit) and Windows
(VisualStudio 2008 and 2010 - mingw and cygwin may need some
Am 09.09.11 22:56, schrieb Frederic Bouvier:
I hope you all remember that there is already a 8.50 parser inside fg and
code to display airports in the MFD (with Bezier curves).
Regards,
-Fred
Does this parser handle both types, 8.10 and 8.50 format ? As I
understand 8.50 is only
On Fri, Sep 9, 2011 at 2:49 PM, HB-GRAL wrote:
Hi Curt
Thank you very much taking time for this.
Now this is very interesting, a curved surface with a natural looking
slope and correct hills. Can you point me to an example for this ? I
guess my current examples like KSFO and EHAM etc. do
Curtis Olson wrote:
I won't say this is perfect in all areas ... some areas have stray data
points or noise in the terrain data that confuses things. There's always
a chance of a mismatch between airport location terrain location so that
we
are trying to put the airport on not quite the
I just noticed when I pushed out the latest developer snapshot build that
our setup.exe size has grown from about 410 Mb to 500+ Mb. I think (?) this
may be the new dds textures? I'm not making a judgement, or calling for a
particular action here, but it might be worth thinking/discussing if
On Sat, 10 Sep 2011, Curtis Olson wrote:
I just noticed when I pushed out the latest developer snapshot build that
our setup.exe size has grown from about 410 Mb to 500+ Mb. I think (?) this
may be the new dds textures? I'm not making a judgement, or calling for a
particular action here,
Am 10.09.11 14:47, schrieb Christian Schmitt:
Curtis Olson wrote:
I won't say this is perfect in all areas ... some areas have stray data
points or noise in the terrain data that confuses things. There's always
a chance of a mismatch between airport location terrain location so that
we
are
Hi all,
If you are looking for airports with extreme runway slope for testing,
may I suggest Lukla, Nepal (VNLK). If that one comes out looking right,
I'd say you've got the code sorted :)
Cheers,
Vik
On 09/10/2011 02:47 PM, Christian Schmitt wrote:
Curtis Olson wrote:
I won't say this is
On Sat, Sep 3, 2011 at 8:15 AM, Thorsten Renk wrote:
1) placement in flat layer instead of curved
OK. I'll get the fix for this committed as soon as I get the
chance.
2) clouds don't obscure some objects (newly discovered)
This may be a problem related to the rendering order of objects
with
Am 10.09.11 21:56, schrieb Viktor Radnai:
Hi all,
If you are looking for airports with extreme runway slope for testing,
may I suggest Lukla, Nepal (VNLK). If that one comes out looking right,
I'd say you've got the code sorted :)
Cheers,
Vik
Lukla is just boring ;-) Other suggestions ?
I was also directed to the ogr2ogr converter. The problem I had with both
parsers so far, is the final output is too high level. I need the
individual nodes and control points so I can create other useful structures.
My initial parser keeps all of the information from the original file.
For
Hi all
Unfortunately I just run into another problem with my map.
This is what I see on my currently generated map using 8.10 taxiway data
and 8.50 runway data (this is no reference and a crude mixup of course,
I apologize in adnvance):
http://maptest.fgx.ch/screens/mapping.png
But now, I
I don't know the specific answer in this case, but it does illustrate one of
the surpreme challenges in mixing different gis databases ... you end up
with information from different sources, adhering to different standards,
appropriate for different scales, using different datums, different
21 matches
Mail list logo
