Re: [Flightgear-devel] Re: Fw: FlightGear/src/SceneryFGTileLoader.cxx, 1.7, 1.8
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( :);
! #endif
kludge in the patch below
if append() doesn't do the right thing I suggest we would be
better off fixing append() rather then kludging every instance
of it use.
we should use sgDirPathSep instead. it's defined in
simgear/misc/sg_path.cxx, but it should be moved to the header file
instead so it can be used elsewhere.
Agreed but
append() should/will just do this automagically :-)
// append another piece to the existing path
void SGPath::append( const string p ) {
if ( path.size() == 0 ) {
path = p;
} else {
if ( p[0] != sgDirPathSep ) {
path += sgDirPathSep;
}
path += p;
}
fix();
}
sgDirPathSep is ':' for macintosh, or '/' for other systems. It is the
character that is between a parent and a child folder in a path, not
the one between 2 valid path. It that file, it is called sgSearchPathSep
and is used only in sgPathSplit, not in SGPath::append( const string ).
Maybe we need a SGPathList object for that matter.
-Fred
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Fw: FlightGear/src/Scenery FGTileLoader.cxx, 1.7, 1.8
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 do the right thing I suggest we would be better off fixing append() rather then kludging every instance of it use. we should use sgDirPathSep instead. it's defined in simgear/misc/sg_path.cxx, but it should be moved to the header file instead so it can be used elsewhere. Ah, good catch! I have been searching for that but couldn't find one. And I wanted to get something usable in there and look for a better solution later on. I'll take a look and make the necessary changes. Thanks. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Fw: FlightGear/src/SceneryFGTileLoader.cxx, 1.7, 1.8
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( ;);
! #else
! tmp.append( :);
! #endif
kludge in the patch below
if append() doesn't do the right thing I suggest we would be
better off fixing append() rather then kludging every instance
of it use.
we should use sgDirPathSep instead. it's defined in
simgear/misc/sg_path.cxx, but it should be moved to the header file
instead so it can be used elsewhere.
Agreed but
append() should/will just do this automagically :-)
// append another piece to the existing path
void SGPath::append( const string p ) {
if ( path.size() == 0 ) {
path = p;
} else {
if ( p[0] != sgDirPathSep ) {
path += sgDirPathSep;
}
path += p;
}
fix();
}
sgDirPathSep is ':' for macintosh, or '/' for other systems. It is the
character that is between a parent and a child folder in a path, not
the one between 2 valid path. It that file, it is called sgSearchPathSep
and is used only in sgPathSplit, not in SGPath::append( const string ).
Maybe we need a SGPathList object for that matter.
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()?
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Fw: FlightGear/src/SceneryFGTileLoader.cxx, 1.7, 1.8
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 unix use '\' for something else. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Fw: FlightGear/src/SceneryFGTileLoader.cxx, 1.7, 1.8
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 '/' with the appropriate OS specific separator. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Fw: FlightGear/src/Scenery FGTileLoader.cxx, 1.7, 1.8
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/src/Scenery/FGTileLoader.cxx,v retrieving revision 1.7 retrieving revision 1.8 diff -C2 -r1.7 -r1.8 *** a/FGTileLoader.cxx 6 Jun 2004 19:15:04 - 1.7 --- b/FGTileLoader.cxx 6 Jun 2004 19:34:31 - 1.8 *** *** 99,103 SGPath tmp; tmp.set( globals-get_fg_root() ); ! tmp.append( Scenery/Terrain: ); tmp.append(globals-get_fg_root() ); tmp.append( Scenery/Objects ); --- 99,108 SGPath tmp; tmp.set( globals-get_fg_root() ); ! tmp.append( Scenery/Terrain ); ! #ifdef _MSC_VER ! tmp.append( ;); ! #else ! tmp.append( :); ! #endif tmp.append(globals-get_fg_root() ); tmp.append( Scenery/Objects ); Doesn't SGPath.apapend just do the right thing here ? ack ... has other's have pointed out append() doesn't do the right thing. 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 if 'stutter' is still an issue. /aside in any case the above should be ! #if defined(WIN32) !defined(__CYGWIN__) ! tmp.append( ;); ! #else ! tmp.append( :); ! #endif So that MingW works Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Fw: FlightGear/src/Scenery FGTileLoader.cxx, 1.7, 1.8
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 if 'stutter' is still an issue. /aside Unfortunately that won't work because on both cases the extension leading to the appropriate scenery is .stg. What might be an option is keeping an open directory cache in memory somewhere. That would require just a few entries but could possibly give a good performance increase (although probably unnoticeable in framerate). in any case the above should be ! #if defined(WIN32) !defined(__CYGWIN__) ! tmp.append( ;); ! #else ! tmp.append( :); ! #endif Ok, this is fixed. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: bump map clouds
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 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] New dialogs
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 e-mail has been scanned for Bede Scientific Instruments for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New dialogs
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 CVS? Maybe I should re-investigate. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: bump map clouds
* 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/cvs/FlightGear-0.9/data/gui/dialogs/rendering.xml,v retrieving revision 1.3 diff -u -p -r1.3 rendering.xml --- a/rendering.xml 12 May 2004 15:37:17 - 1.3 +++ b/rendering.xml 7 Jun 2004 14:51:13 - @@ -36,6 +36,12 @@ labelSpecular reflections on objects/label property/sim/rendering/specular-highlight/property /checkbox + +checkbox + halignleft/halign + labelBump mapped clouds/label + property/sim/rendering/bump-mapping/property +/checkbox /group group ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] New dialogs
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 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 CVS? Maybe I should re-investigate. Andy This e-mail has been scanned for Bede Scientific Instruments for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] v0.9.5 scenery
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 Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] v0.9.5 scenery
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 wednesday before you announce general availability ? Last time I visited 'my' server I forgot to bring the new disk that I planned to mount into the box, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Questions about scenery objects
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, it never looks for any more data for that area (eg w078n40). Is it possible for me to create a dev directory containing just objects to be placed and a .stg file to place them and not override any pre-existing .stg files for that area? I want to develop an area without interfering with any of the default towers in the new data set. If not, I can rig up a Makefile that will merge my data with whatever it finds and put that into the production directory for my scenery, separate from the base scenery directory. How do I animate an object based on the LOD distances defined in the preferences.xml file? If this is not possible, is there a way to make LOD select animations work differently based on user prefs or how powerful the computer that is running fgfs is? What would good high and low LOD distances be based on object size? I would like to have as much detail as possible without killing performance, but this is dependent on the user's machine. What would be good poly counts and texture sizes for low and high LOD models of individual objects? Same for autogen objects? I know that those last two groups really depend a lot on the machine running fgfs, but I would still like to get a good idea of what makes sense beforehand so that if I make a set of models for a city they will be consistent. Josh ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Intermittent message on the console
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/~cs233144/fgfs-screen-030.jpg Regards, Ampere ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Questions about scenery objects
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 much texture is too much sometimes. A city with a lot of simple buildings will look much more realistic than a city with only a few highly-detailed buildings. I don't think there's any consumer hardware out there yet that could handle, say 300,000 or more buildings for a big city, so the same point applies no matter what you're running. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Questions about scenery objects
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 texture, but even that much texture is too much sometimes. A city with a lot of simple buildings will look much more realistic than a city with only a few highly-detailed buildings. I don't think there's any consumer hardware out there yet that could handle, say 300,000 or more buildings for a big city, so the same point applies no matter what you're running. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel Hmm, well, I think I'll concentrate on landmarks first anyway, for VFR. Looking at the Models/Buildings directory though I can see that I would have to add lots of little 5 poly buildings. It also occurs to me that there should be a shared texture directory for the Models directory. Lots of call for stuff like light-concrete.rgb or red-brick.rgb or dark-grey-shingle.rgb. There's already some pretty generic sounding texture files in there. Sharing will save disk space as well as texture memory. Also, when one populates an area with purposely placed buildings, how do they turn off autogen for that area? Is this something that can be done without editing a .btg file? Is FG smart enough to not place autogen objects next to defined ones? Josh ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] King Air cockpit progress (and question)
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 wouldn't expect there to be any performance difference. So long as you have a sane/natural order to draw your objects in, alpha is definitely the way to go. Then again, on really modern hardware you can use FSAA to get antialiasing for polygon edges anyway... Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] King Air cockpit progress (and question)
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
Re: [Flightgear-devel] Intermittent message on the console
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 folder don't have this kind of problem. Regards, Ampere On June 6, 2004 10:30 pm, Ampere K. Hardraade wrote: The format of the model is 3ds. Could this have anything to do with the textures themselve? Regards, Ampere On June 6, 2004 08:56 pm, David Megginson wrote: Ampere K. Hardraade wrote: The model isn't made in AC. What format do you use for loading into FlightGear? All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Questions about scenery objects
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 buildings will look much more realistic than a city with only a few highly-detailed buildings. I don't think there's any consumer hardware out there yet that could handle, say 300,000 or more buildings for a big city, so the same point applies no matter what you're running. 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 about how that works (none in data/Docs, for instance). If possible, then I might think that one could use a very very small texture (little more than color) tiled over the face of an object at large distances, then switch to something more detailed once closer. -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear pgp6iDGaQ4qmx.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Questions about scenery objects
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 about how that works (none in data/Docs, for instance). If possible, then I might think that one could use a very very small texture (little more than color) tiled over the face of an object at large distances, then switch to something more detailed once closer. 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 driver selects the texture resolution that best matches the screen resolution of each polygon it renders. There are cases where this doesn't work as well as you'd like (nearly edge on polygons get a much lower res texture than you'd hope for) but there are often work arounds such as anisotropic texture filtering (which is probably a driver option for most cards/drivers.) Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Questions about scenery objects
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 driver selects the texture resolution that best matches the screen resolution of each polygon it renders. This is great news. There are cases where this doesn't work as well as you'd like (nearly edge on polygons get a much lower res texture than you'd hope for) but there are often work arounds such as anisotropic texture filtering (which is probably a driver option for most cards/drivers.) Curt. Would you mind explaining what anisotropic texture means? Thanks, Ampere ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Questions about scenery objects
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, 16x16, etc. Then the driver selects the texture resolution that best matches the screen resolution of each polygon it renders. This is great news. There are cases where this doesn't work as well as you'd like (nearly edge on polygons get a much lower res texture than you'd hope for) but there are often work arounds such as anisotropic texture filtering (which is probably a driver option for most cards/drivers.) Curt. Would you mind explaining what anisotropic texture means? Hold on, I'm right in the middle of ripping off all my toe nails and dipping my feet in paint thinner. This is a slightly complicated thing to explain and I don't have the energy to really go into detail. I don't claim to be an expert here so my explanation is probably half fantasy and half my own imagination, but here is how I understand it at a conceptual level. Imagine some triangle (part of the scene) that when drawn on your screen consumes about 4 pixels across and 4 pixels high. The opengl system will pick the best square texture that fits the smaller of the two axes so it will probably pick the 4x4 pixel texture. This is a perfect match for the onscreen size of the triangle and gives you great visual results and minimizes any sort of texture aliasing. (Remember the horrible pixel swimming of MSFS 5.x and other early 3d video games? This is what mipmapping fixes.) Now imagine some triangle (part of the scene) that when drawn on your screen consumes about 40 pixels across and 4 pixels high. The opengl system will pick the best square texture that fits the smaller of the two axes so it will probably again pick the 4x4 pixel texture. But, this means that 4 pixels of your texture get stretched across 40 pixels of your screen which makes the result look really blurry. I doubt this is how anisotropic texture filtering is specifically implimented in the driver, but conceptually, anisotropic texture filtering makes additional versions of your texture that are wide and short as well as tall and narrow. This way it can often find a much better match for most/many situations. Now observe that when you view a runway it is almost always as you take off or land or taxi. This means it is almost always nearly edge on. These runway triangles end up being drawn short and wide on your screen which makes the runway texture blur out really quickly. Try turning on anisotropic texture filtering in your driver (under linux/nvidia there is an environment variable to set.) You will find that your runway textures look *much* sharper and nicer ... you can probably now pick out the markings at the opposite end where as before they were probably a big blurry mess. Here's a link, but it angles towards the technical side of it: http://www.opengl.org/resources/tutorials/sig99/advanced99/notes/node67.html Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Questions about scenery objects
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 version, 64x64, 32x32, 16x16, etc. Then the driver selects the texture resolution that best matches the screen resolution of each polygon it renders. This is great news. There are cases where this doesn't work as well as you'd like (nearly edge on polygons get a much lower res texture than you'd hope for) but there are often work arounds such as anisotropic texture filtering (which is probably a driver option for most cards/drivers.) Curt. Would you mind explaining what anisotropic texture means? Hold on, I'm right in the middle of ripping off all my toe nails and dipping my feet in paint thinner. This is a slightly complicated thing to explain and I don't have the energy to really go into detail. I don't claim to be an expert here so my explanation is probably half fantasy and half my own imagination, but here is how I understand it at a conceptual level. Imagine some triangle (part of the scene) that when drawn on your screen consumes about 4 pixels across and 4 pixels high. The opengl system will pick the best square texture that fits the smaller of the two axes so it will probably pick the 4x4 pixel texture. This is a perfect match for the onscreen size of the triangle and gives you great visual results and minimizes any sort of texture aliasing. (Remember the horrible pixel swimming of MSFS 5.x and other early 3d video games? This is what mipmapping fixes.) Now imagine some triangle (part of the scene) that when drawn on your screen consumes about 40 pixels across and 4 pixels high. The opengl system will pick the best square texture that fits the smaller of the two axes so it will probably again pick the 4x4 pixel texture. But, this means that 4 pixels of your texture get stretched across 40 pixels of your screen which makes the result look really blurry. I doubt this is how anisotropic texture filtering is specifically implimented in the driver, but conceptually, anisotropic texture filtering makes additional versions of your texture that are wide and short as well as tall and narrow. This way it can often find a much better match for most/many situations. Now observe that when you view a runway it is almost always as you take off or land or taxi. This means it is almost always nearly edge on. These runway triangles end up being drawn short and wide on your screen which makes the runway texture blur out really quickly. Try turning on anisotropic texture filtering in your driver (under linux/nvidia there is an environment variable to set.) You will find that your runway textures look *much* sharper and nicer ... you can probably now pick out the markings at the opposite end where as before they were probably a big blurry mess. Here's a link, but it angles towards the technical side of it: http://www.opengl.org/resources/tutorials/sig99/advanced99/notes/node67.html Regards, Curt. Here's another: http://www.extremetech.com/article2/0,1558,1152380,00.asp Josh ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
