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
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,
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
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 ab
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 s
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
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
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
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 t
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 m
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.
http://www.cs.yorku.ca/~cs2331
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 set,
"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 un
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
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 auto
* 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: /var/
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
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
This
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
_
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
Norman Vine wrote:
>
> > Modified Files:
> > FGTileLoader.cxx
> > Log Message:
> > Windows uses ';' instead of ':' as a path separator.
> >
> > Index: FGTileLoader.cxx
> > ===
> > RCS file: /var/cvs/FlightGear-0.9/FlightGear/sr
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 '/'
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 u
"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
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() d
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
>
26 matches
Mail list logo