Norman Vine wrote:
Alex Romosan writes:
Norman Vine [EMAIL PROTECTED] writes:
Doesn't SGPath.apapend just do the right thing here ?
i.e. there shouldn't be a need to do the
! #ifdef _MSC_VER
! tmp.append( ;);
! #else
! tmp.append( :);
!
Alex Romosan wrote:
Norman Vine [EMAIL PROTECTED] writes:
Doesn't SGPath.apapend just do the right thing here ?
i.e. there shouldn't be a need to do the
! #ifdef _MSC_VER
! tmp.append( ;);
! #else
! tmp.append( :);
! #endif
kludge in the patch below
if append() doesn't
Frederic Bouvier [EMAIL PROTECTED] writes:
Norman Vine wrote:
Alex Romosan writes:
Norman Vine [EMAIL PROTECTED] writes:
Doesn't SGPath.apapend just do the right thing here ?
i.e. there shouldn't be a need to do the
! #ifdef _MSC_VER
! tmp.append( ;);
Alex Romosan wrote:
sorry, i meant sgSearchPathSep (as you correctly point out). the more
i look at the code in sg_path.cxx, the more confused i get. what
exactly is it being fixed by SGPath::fix()?
It changes all occurences of '\' into '/' because MS runtime is able
to cope with '/' and
Alex Romosan wrote:
sorry, i meant sgSearchPathSep (as you correctly point out). the more
i look at the code in sg_path.cxx, the more confused i get. what
exactly is it being fixed by SGPath::fix()?
It fixes the case when someone does append(/tmp/mydirectory/whatever);
It then replaces every '/'
Norman Vine wrote:
Modified Files:
FGTileLoader.cxx
Log Message:
Windows uses ';' instead of ':' as a path separator.
Index: FGTileLoader.cxx
===
RCS file:
Norman Vine wrote:
aside
Splitting the database into partitions is potentially a good thing
from a management perspective but my guess is that the 'tile loader'
should inherit some smarts about which path to use based on file
extension name rather then have it have to search multiple paths
Frederic Bouvier wrote:
I am surprised --prop:/sim/rendering/bump-mapping=false don't work for
you. I am also able to turn it on and off with the property browser
during flight.
Someone should put this into the rendering options dialog before we
forget. It's
really easy, try it. :)
Andy
I have noticed that if I open and close the autopilot setting dialog repeatedly, the
grey panel behind the widgets gets a little smaller each time, eventually disappearing.
Is anyone else seeing this?
Richard Bytheway
Richard Bytheway wrote:
I have noticed that if I open and close the autopilot setting dialog repeatedly, the grey panel behind the widgets gets a little smaller each time, eventually disappearing.
There was a similar bug with the layout code that got fixed a few weeks
back. Are you
on current
* Andy Ross -- Monday 07 June 2004 16:31:
Someone should put this into the rendering options dialog before we
forget. It's really easy, try it. :)
Do I win the coffee machine?
m. :-)
Index: rendering.xml
===
RCS file:
Current CVS as of last night (UK time).
Richard
-Original Message-
From: Andy Ross
Sent: 07 June 2004 3:51 pm
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] New dialogs
Richard Bytheway wrote:
I have noticed that if I open and close the autopilot
This is a warning to all the mirror operators. I'm beginning to copy
the v0.9.5 scenery over to ftp.flightgear.org. This is about 12Gb of
new data that will be showing today (or however long it takes to copy.)
It will show up under .../pub/fgfs/Scenery-0.9.5
Regards,
Curt.
--
Curtis Olson
Curtis L. Olson wrote:
This is a warning to all the mirror operators. I'm beginning to copy
the v0.9.5 scenery over to ftp.flightgear.org. This is about 12Gb of
new data that will be showing today (or however long it takes to copy.)
Thanks alot for the notice. Would you mind waiting until
I want to get a good idea of what the appropriate way to make scenery objects is
from the perspective of detail vs performance and general usability. If anyone
can answer any of these questions or provide learned opinions, please do:
It looks to me like once FG finds a directory for a tile
Um... Durk, I lost the prototype aircraft to quicksand at KLGB. =(
It was perfectly fine in the beginning...
http://www.cs.yorku.ca/~cs233144/fgfs-screen-028.jpg
...then it starts sinking...
http://www.cs.yorku.ca/~cs233144/fgfs-screen-029.jpg
...and nothing is left.
Josh Babcock wrote:
What would be good poly counts and texture sizes for low and high LOD
models of individual objects? Same for autogen objects?
Most of the time, buildings on the screen use up only a tiny number of
pixels. I often do buildings with 5 quads and a 64x64 texture, but even
that
David Megginson wrote:
Josh Babcock wrote:
What would be good poly counts and texture sizes for low and high LOD
models of individual objects? Same for autogen objects?
Most of the time, buildings on the screen use up only a tiny number of
pixels. I often do buildings with 5 quads and a 64x64
Roy Vegard Ovesen wrote:
I've also thought about using a textured needle instead of an object
colored one. The textured one might look a lot better with variable
alpha creating an anti-alias effect, but I'm concerned about
performance.
Alpha blending is almost free on modern hardware, so I
I've just find this out. Check out the Models/3ds folder in your home
directory. There is a mesh of KingAir in there.
Regards,
Ampere
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
It isn't the model. I used a texture from another aircraft and that texture
showed up too bright as well.
I have tried everything that I can think of, and the model is still showing up
too bright in FlightGear. I am sure there is a way to set it, because the
other 3ds files in the Models/3ds
On Mon, 07 Jun 2004 16:41:21 -0400
David Megginson [EMAIL PROTECTED] wrote:
Most of the time, buildings on the screen use up only a tiny number of
pixels. I often do buildings with 5 quads and a 64x64 texture, but even
that much texture is too much sometimes.
A city with a lot of simple
Chris Metzler wrote:
Is there the ability to give a distance-dependancy to the textures
used on a model? Or, alternately, to have the specific model/texture
set used be distance-dependent? I'm aware that one can apply
distance-dependent effects to the xml file, but I haven't yet found
any docs
On June 7, 2004 09:56 pm, Curtis L. Olson wrote:
Mipmapping does this for you automatically. The system stores several
versions of the texture at reduced resolution. If the original texture
is 256x256, then the system will also build a 128x128 version, 64x64,
32x32, 16x16, etc. Then the
Ampere K. Hardraade wrote:
On June 7, 2004 09:56 pm, Curtis L. Olson wrote:
Mipmapping does this for you automatically. The system stores several
versions of the texture at reduced resolution. If the original texture
is 256x256, then the system will also build a 128x128 version, 64x64,
32x32,
Curtis L. Olson wrote:
Ampere K. Hardraade wrote:
On June 7, 2004 09:56 pm, Curtis L. Olson wrote:
Mipmapping does this for you automatically. The system stores several
versions of the texture at reduced resolution. If the original texture
is 256x256, then the system will also build a 128x128
26 matches
Mail list logo
