Tim Moore wrote:
If you are going to enable random objects, I recommend using OSG 2.3 or
later. Otherwise,
set the environment variable OSG_DATABASE_PAGER_DRAWABLE=VertexArrays
Installing OSG 2.3.1 did indeed do the trick but it's still slower at
startup than I was used to. I think I'll
LeeE wrote:
Yup - I downloaded lots of SRTM data to play with in GRASS and
above/below +/- 60 lat it isn't there.
There doesn't seem to be any alternative source of suitable data
either so I don't see how FG can cover the poles.
FG can cover the poles - and has been doing so for years -,
Hi!
Frederic Bouvier wrote:
Selon Curtis Olson :
My gut feeling is that once you get up (or down) into the latittudes where
the tiles get significantly skinny, the resolution of the available data
drops of significantly. We really don't have a per-tile triangle budget
anyway. The only
Hello,
I was afaik, and i just built the last FG-OSG , unfortunately i get a crash
during loading:
fgfs --aircraft=c172p
Error: Not able to create requested visual.
Erreur de segmentation
What the matter ?
I do use the last OSG 2.2 stable.
Happy new year.
--
Gérard
On Jan 8, 2008 1:22 AM, Frederic Bouvier wrote:
I was thinking about the parameter we pass to Terra to simplify the
initial
grid. IIRC, this parameter is always the same, leaving all *.arr.gz files
with
the same number of vertices.
Yes, that's a good point, and something definitely to
Hi!
Curtis Olson wrote:
On Jan 8, 2008 1:22 AM, Frederic Bouvier wrote:
I was thinking about the parameter we pass to Terra to simplify the
initial grid. IIRC, this parameter is always the same, leaving all
*.arr.gz files with the same number of vertices.
Yes, that's a good point, and
Ralf Gerlich wrote:
Currently we have tile borders that are representable as polygon - more
strictly as rectangles - which makes clipping easy. The new tile borders
could not be well-approximated using polygons. We could try creating
clipping polygons that approximate the borders down to an
Frederic Bouvier wrote:
Selon Ralf Gerlich :
The alternative would be to scale the number of vertices passed to
TerraFit by cos(lat)...
I was thinking of this solution : regular lon/lat tile scheme but variable
number of resulting vertices per tile.
That's what I meant ;-)
On mar 8 janvier 2008, Tim Moore wrote:
gerard robin wrote:
| On mar 8 janvier 2008, Tim Moore wrote:
| gerard robin wrote:
| | Hello,
| |
| | I was afaik, and i just built the last FG-OSG , unfortunately i get a
| | crash during loading:
| | fgfs --aircraft=c172p
| | Error: Not able to
On mar 8 janvier 2008, Tim Moore wrote:
gerard robin wrote:
| Hello,
|
| I was afaik, and i just built the last FG-OSG , unfortunately i get a
| crash during loading:
| fgfs --aircraft=c172p
| Error: Not able to create requested visual.
| Erreur de segmentation
|
| What the matter ?
|
Selon Ralf Gerlich :
The alternative would be to scale the number of vertices passed to
TerraFit by cos(lat)...
I was thinking of this solution : regular lon/lat tile scheme but variable
number of resulting vertices per tile.
-Fred
--
Frédéric Bouvier
http://frfoto.free.fr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
gerard robin wrote:
| On mar 8 janvier 2008, Tim Moore wrote:
| gerard robin wrote:
| | Hello,
| |
| | I was afaik, and i just built the last FG-OSG , unfortunately i get a
| | crash during loading:
| | fgfs --aircraft=c172p
| | Error: Not able to
On Tue, 8 Jan 2008 11:13:56 -0600
Curtis Olson wrote:
One possibility ... if you have a --native-fdm= option, it is blindly
grabbing data from 1 - MAX_TANKS (which is currently 4). So that could
be creating the nodes if they don't exist so it can fill the data into
the structure.
No
On Jan 7, 2008 9:05 PM, LeeE [EMAIL PROTECTED] wrote:
More information is helpful useful - thanks.
Yeah - script based routines for things like fuel handling doesn't
seem right but Nasal, because of the timer functions, is
effectively real-time - it's just a question of resolution - for
I just posted an update to the Super Stallion at:
http://jrbabcock.home.comcast.net/~jrbabcock/flightgear/ch53e/ch53e-rollup.20080108.tgz
I don't know who is doing cvs commits now, I would appreciate if someone
could do this one for me. The file contains a unified diff and many new
files
On Jan 7, 2008, at 7:15 PM, LeeE wrote:
On Monday 07 January 2008 22:28, Curtis Olson wrote:
On Jan 7, 2008 3:51 PM, Frederic Bouvier wrote:
If we keep the same triangle budget for every tile, we will
have sparse data and
features at the equator and much more than what is really
needed at
Hello list,
this is sort-of a n00b question so please be patient; I've been using OSG for
years but only just started with FG...
I'm using OSG SVN trunk on MacOS X and it works fine for my other projects, so
I'm pretty sure this is not an issue with the OSG installation.
However when attempting
Hello,
I am working on a live CD for FlightGear 1.0 - I have a working beta
based on Puppy Linux. It has graphics card detection and configuration
for nVidia, ATI, and some Intel. I have managed to squeeze this into a
300 meg iso. Your comments and criticism is welcome.
The download can be
On Wed, 2008-01-09 at 15:28 +1100, Ulrich Hertlein wrote:
Hello list,
this is sort-of a n00b question so please be patient; I've been using OSG for
years but only just started with FG...
(snip)
After some digging it appears that for some reason 'APIENTRY' is not
#defined properly and is
19 matches
Mail list logo
