Orbiter-Forum [Project] Orbiter texture tree tools (OT3)
 Register Blogs Orbinauts List Social Groups FAQ Projects Mark Forums Read

#1
 Face Beta Tester
Orbiter texture tree tools (OT3)
by Face 09-03-2016, 07:39 PM

The Orbiter texture-tree tools project - or OT3 for short - is inspired by the release of Orbiter 2016, discussions about texture-tree manipulation during the RC-phase and an early addon request.

The idea is to extent Orbiter's /Utils/ toolset with useful programs to inspect and/or manipulate the new texture and elevation file formats. These programs should eventually be released as open-source software.

My idea is to create small programs that can be joined together to create a full-featured work-environment, similar to the Unix mindset:
• archive tree manager (treeman) as CLI tool, making it possible to selectively manage texture-tree archives and/or caches
• visual selection tool (treevis) as GUI tool, allowing users to visualize the various aspects of the new formats (textures, elevations, tree population, etc.), navigate through the tree(s), and select tiles for further processing
• elevation converter for 2D solutions (ele2png), creating compositions of texture and height-map in order to seamlessly edit both aspects in a graphics program, then converts it back to tile formats
• elevation converter for 3D solutions (ele23DS), creating terrain meshes from selected tiles to be edited in 3D programs, then converts meshes back to tiles
For the first point in the list above, there is already some progress to show: treeman . Extract the archive together with the included Microsoft texconv.exe tool (it is MIT licensed, don't worry ) into /Utils/ folder.

From the usage text:
Code:
treeman: Orbiter texture tree managing tool
Lists, extracts, or updates the files of a packed planet texture layer directory tree.

Usage: treeman <Planet-tree-root> <Layer> [<Actions> | <Options> | <Configs>]

<Planet-tree-root>:
Path to planet textures, e.g.
c:\Orbiter\Textures\Earth

<Layer>:
Surf       surface layer tiles
Cloud      cloud tiles
Elev       elevation tiles
Elev_mod   elevation modification tiles

<Actions>:
-l         (default) lists files included in the archive
-s         prints a summary
-e         extracts files into planet tree root

-i[res]    integrates files in the planet tree root into low-level tiles
[res] is an optional single digit specifying the minimum tile resolution,
with 2^res meaning 0=1x1, 1=2x2, 3=4x4, 4=8x8, etc. - default is 0=1x1
note: file list (-F) is mandatory, only full pathes will be checked

-b <path\to\base\file> <path\to\textures>
converts old style base surface tiles into planet tree root

-t <path\to\tex\file>
converts old style texture archives (*.tex) into planet tree root

<Options>:
-T <path>  tree archive file - default is <Layer>.tree in <Planet-tree-root>\Archive
-I <rgx>   file filter include regular expression - default is include all files
-X <rgx>   file filter exclude regular expression - default is exclude no files
-F <path>  file list - if defined, this list defines the base file set for actions
if no path is given, standard input is read until EOF
entries in the list are newline separated, can use '\' or '/' as
separator, and don't need to be full length (e.g. /04/000010 is valid)
padding whitespace and empty lines will be removed
-n         dry run - all file writing actions will be skipped
-v         increase verbosity level (-vvv supported)
-w         run stop-watch for timing information
-y         acknowledge all questions positively
-y0        acknowledge all questions negatively

<Configs>:
--texconv <path>  path to texconv.exe DDS conversion tool - if not present,
DDS files in the wrong format will be skipped - defaults to
'texconv.exe', which will start the bundled version.
As of now, you can use this to:
• list the files in a *.tree archive,
• extract files by specifying regular expressions and/or file lists,
• print a summary on the contents of the archive (also use -v option to get more details),
• import old-style *.tex files into the cache (currently only up to old level 5),
• import old-style base tiles into the cache,
• integrate high-res tiles into lower levels to have seamless experience (only non-elevation tiles for now)
Planned is:
• print difference between archive and cache as status list,
• update files from cache into archive selectively,
• merge archives,
• import full-scale old-style textures,
• support integration of elevation tiles
If you want to try out base conversion, you can get the best results by converting Surf and Mask layer, as well as integrate the tiles involved back to 1x1 pixels like so:
1. treeman ..\Textures\Earth Surf -b <path_to_base_config> <path_to_textures_dir> -y > surf.txt
3. treeman ..\Textures\Earth Surf -i -F surf.txt
Point 1 converts the base config texture tiles to the surface layer of Earth, overwriting every file that might be there already (-y) and pipes the list of files it produces to a file "surf.txt".
Point 2 does the same to the water-mask layer, piping to the file "mask.txt".
Point 3 takes the files from surf.txt and integrates them back into the texture tree (-i). Point 4 does the same for the water-mask files.

So far I've tried that with Edwards, Vandenberg, Ascension and CSSC successfully. The results are certainly not perfect, but you can get a pretty good starting point for further development with it.

A last note: if you use old base configuration files in Orbiter 2016 with converted tiles by treeman, you might have to remove the SURFACE_TILES section from the base config in order to see the converted textures. In addition, you should have the "Try cache first, then archive" setting in the "Visualisation parameters->Planet rendering options" dialog set, which should be there by default.
 Thanked by:

 09-07-2016, 12:50 PM #2 fort Orbinaut Face hello, I'll be brief ..There is something that i don't really understand. treeman Quote: ...integrates files in the planet tree root into low-level tiles With the exception of KSC, at level 19 to its central portion, and for few other places - five or six - at L16 (zone containing Baikonur eg for high resolution), all other surfaces with high-resolution start from L11 to reach L13. If in one of these areas, at level 13 for example, I create a scenery at level 16, 17, etc ( and the intermediate tiles ... L14, L15 ), does the tileedit code that I began to discover, or the one of treeman that I do not know yet, allows you to spread/propagate the information from the* .elv L13 to .elv of higher level, 14, 15 ... usefull ( usefull or not ? ) for newly created tiles ? And how, if it's the case ? By subdivision and replication/creation of the *.elv of L13 for higher levels and/or *.elv in the elv_mod folder ? Or, and for example, does the level 13 *.elv will only be necessary to create ( support ) relief for the new upper levels ( indeed without a great precision at those higher levels ) ? I could experiment with treeman or tileedit but if i could have an answer already for a first approach ( approche ). thank you and good day. Last edited by fort; 09-07-2016 at 03:41 PM.
 Thanked by:
 09-07-2016, 03:47 PM #3 Face Beta Tester Quote: Originally Posted by fort  If in one of these areas, at level 13 for example, I create a scenery at level 16, 17, etc ( and the intermediate tiles ... L14, L15 ), does the tileedit code that I began to discover, or the one of treeman that I do not know yet, allows you to spread/propagate the information contained in the* .elv L13 to .elv of higher level, 14, 15 ... necessary for newly created tiles in 3D ? And how ? By subdivision and replication/creation of the *.elv of L13 for higher levels and/or *.elv in the elv_mod folder ? Well, I can't speak for the tileedit code, of course. treeman in fact works in both directions, but only the high- to low-level direction is exposed directly to the user yet. treeman uses both directions, because while converting alpha-blended base textures, it needs a texture it can blend on. Often this tile is not present, because base textures are mostly higher level. Therefore, treeman extracts the highest available tile in the tree-path, takes the appropriate pixel-range from it, and blows this smaller tile up via cubic interpolation scaling. The result is blended over with the base tile to be converted. So this is the direction you talked about, if I understood you correctly. The inverse direction, which is exposed to the user via "-i" action takes a high-level tile, shrinks it into smaller tiles (again via cubic interpolation scaling), and integrates those tiles into the lower levels, so you have a smooth LOD transition while e.g. approaching WIA. Quote: Originally Posted by fort  Or, and for example, does the level 13 *.elv will only be necessary to create ( support ) relief for the new upper levels ( indeed without a great precision at those higher levels ) ? If I understand this right, your question is if it is necessary to provide elevation data at the same level as texture data, even if you only need the low-level terrain resolution. IMHO, the answer to this is no. For example: I've converted Vandenberg textures at resolutions 14/15/16 and integrated them back to level 6. Although the highest resolution of available elevation data in the release distribution at this location (probably 12) is lower than 14, I see the (coarse) terrain nicely overlayed with the high-res texture. Currently treeman does not support elevation tiles on import and integration. This is planned, but it is a bit tricky because of the padding data involved. I hope this helps, Face
 Thanked by:
 09-07-2016, 06:38 PM #4 fort Orbinaut Hello, I'm not completely a newby in that matter even if i've never released anything of that sort - sceneries - for orbiter and i understand the whole part of your explanations. But i'm not very comfortable with the english language and some things, that question of alpha blending, for example, that i've read in another topic , from you, escape a little to my understanding. I think that it's evident and in the same time i'm not sure to really visualize all that articulation. I have to reread calmly your answer first and in it's entirety. good day. Edit: Quote: Originally Posted by Face  If I understand this right, your question is if it is necessary to provide elevation data at the same level as texture data, even if you only need the low-level terrain resolution. IMHO, the answer to this is no. OK. I have just made à try on KSC with that. Right. If i delete the elv from, by example, the L14 to the end ( L17 ), those in the elv folder, and the other one, for the same levels, in the elv_mod folder, the tiles are there in Orbiter with values for elevation at the max levels remaining in Orbiter and in that case level 13. I have to understand the first part. Last edited by fort; 09-07-2016 at 07:12 PM.
 Thanked by:
 09-07-2016, 07:13 PM #5 Face Beta Tester Quote: Originally Posted by fort  I'm not completely a newby in that matter even if i've never released anything of that sort - sceneries - for orbiter and i understand the whole part of your explanations. But i'm not very comfortable with the english language and some things, that question of alpha blending, for example, that i've read in another topic , from you, escape a little to my understanding. I think that it's evident and in the same time i'm not sure to really visualize all that articulation. I see. With alpha blending, I mean that old-style base texture tiles often come with an alpha channel, meaning that the texture contained transparency information. E.g. coast lines were often outlined with transparency, so the water was not overwritten by the tile, just the land part. Orbiter 2010 then overlayed the coarse planet texture with the fine base texture tile, letting the coarse water part shine through. Of course that wasn't restricted to only coast lines, it was often done to gradually blend-in surrounding coarse land area into the finer base texture, too. 2016 changed that a bit. Now the texture is not containing transparency anymore (or better: doesn't support overlaying). So in order to convert base textures to new-style planet texture tiles, I had to do something with the alpha channel. I chose to let treeman do the overlaying in the import process, just as Orbiter 2010 did it in the past on the fly. This overlaying process, if done in a certain way, is called alpha blending. It takes every pixel of the underlying picture, multiplies its color values with the inverse alpha channel value for that pixel, then adds the pixel of the overlayed picture, multiplied by the alpha channel value for that pixel, which results in the value for the appropriate color for the pixel in the finished picture. This perhaps complicated sounding process gets pretty simple if you visualize the alpha channel values as either 1 or 0, like with the DXT1 format. It means that for each pixel, the system just decides if it takes the value from the underlying or the overlayed picture. Things get even a bit more confusing, if you realize that Elev_mod is almost like a DXT1 alpha channel format for elevation data.
 Thanked by:
 09-07-2016, 08:27 PM #6 fort Orbinaut Quote: Originally Posted by Face  I see. With alpha chanel... Yes i think that i understand better. You, as you say, where talking about the alpha chanel coming sometime with surf tiles. Yes in the 2016 edition, the alpha comes in the mask with nightlights, but the surftiles are in 32 bits when i extract the bmp from the dds. I think that is due to the processus of creation of the tiles and that that blank alpha was necessary for that. I don't know. Or something else. Or ... Quote: Originally Posted by Face  Things get even a bit more confusing, if you realize that Elev_mod is almost like a DXT1 alpha channel format for elevation data. Yes, i read that in another topic. I've used the old Terragen a long time ago only two or three times to create a mesh if i remember...not sure. Not sure if it was Terragen. Anyway those conversion from a 2d grayscale to a 3D object, of vectors...i don't know what it is. I suppose like the data as they are in a mesh. There a DXT1. Well. It's a direct conversion ? Quote: Originally Posted by Face  The inverse direction, ... LOD transition while e.g. approaching WIA. Oui. Last thing: i don't know if treeman in the gui version will show, for the surf, the number of the tiles and their coordinates values, but it will be maybe usefull, and in tileedit also but it's not your work, to show, for a tile, in the same time, the coordinates values as they was implemented in the 2010 version and before. I mean for example Earth_1_W0347_N0105. Taking account of the difference of one level between the 2010 and 2016 version of orbiter if i'm not wrong (?). And on the old 2010 basis of 256 px by cell ( if i'm not wrong ) ? That makes a lot of thing to consider at the same time but maybe simpler that i think. Good day and thank you again. Last edited by fort; 09-07-2016 at 09:13 PM.
 Thanked by:
 09-07-2016, 08:55 PM #7 jacquesmomo Addon Developer Quote: Originally Posted by fort  Last thing: i don't know if treeman in the gui version will show, for the surf, the number of the tiles and their coordinates values, but it will be maybe usefull, and in tileedit also but it's not your work, to show, for a tile, in the same time, the coordinates values as they was implemented in the 2010 version and before. I mean for example Earth_1_W0347_N0105. Yes, this would be a good idea ...
 09-08-2016, 05:34 AM #8 Face Beta Tester Quote: Originally Posted by fort  Yes in the 2016 edition, the alpha comes in the mask with nightlights, but the surftiles are in 32 bits when i extract the bmp from the dds. I think that is due to the processus of creation of the tiles and that that blank alpha was necessary for that. If you convert DXT1/3/5 with alpha channels to BMP, it will sure get lost, because BMP does not support alpha channels. For this reason, I use PNG internally, which supports alpha channels. Quote: Originally Posted by fort  Yes, i read that in another topic. I've used the old Terragen a long time ago only two or three times to create a mesh if i remember...not sure. Not sure if it was Terragen. Anyway those conversion from a 2d grayscale to a 3D object, of vectors...i don't know what it is. I suppose like the data as they are in a mesh. There a DXT1. Well. It's a direct conversion ? I think you mean tessellation. It's where you take the plane and subdivide it into more and more triangles, using the texture data to offset the triangle points in height. The result would be a 3D terrain mesh of the 2D height-map. Quote: Originally Posted by fort  Last thing: i don't know if treeman in the gui version will show, for the surf, the number of the tiles and their coordinates values, but it will be maybe usefull, and in tileedit also but it's not your work, to show, for a tile, in the same time, the coordinates values as they was implemented in the 2010 version and before. I mean for example Earth_1_W0347_N0105. I didn't think about the GUI component of OT3 (treevis) that much yet, but I'll keep that in mind. The coordinate transformation between lat/lon/resolution, old-style level-bands and new-style level-bands is not that complicated, treeman is doing that already to convert old-style base textures to tiles.
 Thanked by:
 09-10-2016, 04:04 PM #9 fort Orbinaut Hello, I made a point of some aspects in relation to the textures of the device used in 2010p1 version with regards for surftiles coming as addon - i mean, out of *tex files - (noted Earth_0_n xxxx_e xxxx for example), with respect to the new system, with level folders and sub dds files (or * .tree files in the archive folder), of the 2016 release. I redid a general picture, surely too detailed of equivalence between 2010p1 and surftiles for 2010p1 version and equivalence between 2010p1 and 2016. [URL=http://ww A surftile eg Earth_0_n0012_e0032, so of level 0, corresponds to an overall level of 12 in 2010p1. The number of cells in latitude and longitude, at the level 11 of the 2016 version is equivalent to the number of cells at level 12 of the version 2010p1. But those of the version 2016, starting from the level 3, included, contain 512 pixels, while those of the 2010p1 release contain only 256. Suppose, to take a simple example, I created a scene with a unique surftile for 2010p1, at level 0, a cell containing 256px x 256px. How is reinstated this image/dds in the tree of the 2016 release ( how treeman do it ) ? A resize is certainly necessary (?).Does Orbiter itself do it ? And does the tile is reintegrated at L-1, level 10 here, for example or the opposite, L12 ( for angular equivalence ) ? I have not really pushed my reflexion on that last question. good day Edit: First question answered (Is a resize necessary ?): Orbiter, resize it. And the answer for the second is i think: the tile is reintegrated at level 12. Edit2: I redid the table of equivalences in a more comprehensible presentation ( i hope ). Edit3 (02/10): modified some comments in the table. Edit4 (12/11): added comments in the table. Last edited by fort; 11-12-2016 at 08:39 AM.
 Thanked by:
 09-14-2016, 08:26 AM #10 fort Orbinaut Hello I want to see how treeman works trying with a simple surf tile. I put it in a base.cfg but i wanted first try to " integrate a high-res tiles into lower levels..." not particulary included in a base. I must be wrong somewhere: My command line: E:\ESSAI>treeman e:\ESSAI\Textures\Earth Surf -i -b e:\ESSAI\Config\Earth\Base\Orlando.cfg e:\ESSAI\Textures2\Earth_4_W1852_N649.dds Result: E:\ESSAI>treeman e:\ESSAI\Textures\Earth Surf -i -b e:\ESSAI\Config\Earth\Base\Orlando.cfg e:\ESSAI\Textures2\Earth_4_W1852_N649.dds /16/001398/002244.dds error: unable to open file e:\ESSAI\Textures2\Earth_4_W1852_N649.dds\Earth_4_ w1852_n0649.dds, error 3 BASE-V2.0 Name = Orlando Location = -81.383160 28.535231 Size = 1000 ObjectSize = 100 MAPOBJECTSTOSPHERE = TRUE BEGIN_NAVBEACON END_NAVBEACON BEGIN_OBJECTLIST END_OBJECTLIST BEGIN_SURFTILELIST 4 -1852 649 1 END_SURFTILELIST Do i need -i or is it -b or an error with the path or the syntax ( do i need the <...> ) or does the dds must be in the Textures folder and not in the Textures2, or something else ? Except the last thing: Textures versus Textures2 ... i tried different things/scriptings without success. Sometimes with an error2 sometimes like here with an error3. I must reread your instructions for sure. good day Last edited by fort; 09-14-2016 at 10:13 AM.
 09-14-2016, 10:32 AM #11 Face Beta Tester Quote: Originally Posted by fort  I want to see how treeman works trying with a simple surf tile. I put it in a base.cfg but i wanted first try to " integrate a high-res tiles into lower levels..." not particulary included in a base. I must be wrong somewhere: My command line: E:\ESSAI>treeman e:\ESSAI\Textures\Earth Surf -i -b e:\ESSAI\Config\Earth\Base\Orlando.cfg e:\ESSAI\Textures2\Earth_4_W1852_N649.dds For conversion AND integration, you would have to do two calls. First the base conversion call, piping files into a text file: Code: E:\ESSAI>treeman e:\ESSAI\Textures\Earth Surf -b e:\ESSAI\Config\Earth\Base\Orlando.cfg e:\ESSAI\Textures2 -y > surf.txt Note how there's no '-i', but a '-y'. The former is missing because you can't do two action at once currently, the last action will always win. The later is because the system might ask for user input, if the file to be converted is already present, so this option quietly acknowledges it. Second, the integration call, using the text file as input list to integrate the tile(s) upwards: Code: E:\ESSAI>treeman e:\ESSAI\Textures\Earth Surf -i -F surf.txt
 Thanked by:
 09-14-2016, 10:54 AM #12 fort Orbinaut Hello and thank you for your answer, With the first command line: treeman e:\ESSAI\Textures\Earth Surf -b e:\ESSAI\Config\Earth\Base\Orlando.cfg e:\ESSAI\Textures2 -y > surf.txt i obtain a surf.txt file containing: /16/001398/002244.dds error: unable to open file e:\ESSAI\Textures2\Earth_4_w1852_n0649.dds, error 2 At first my Earth_4_w1852_n649.dds was 512x 512 px ( for my convenience unicolor, red ) without mip and dxt5. After my failures during my first trys i've converted it ( dxtbmp ) to dxt1 and resized it to 256 x 256. I tried also with Earth_4_w1852_n649.dds in Textures and in Textures2. Something else: The first command line is supposed to create a dds ? With the new denomination ( 002244.dds ) ? The second command line is supposed to integrate the dds and it's low level in the surf.tree or in the simple/basic cache ? There is certainly something that i don't understand. good day. Edit 1: first error from me: my dds was named Earth_4_w1852_n649.dds . If i rename it Earth_4_w1852_n0649.dds There is a change but the surf.txt now is: /16/001398/002244.dds error 193: can't execute '"texconv.exe" "e:\ESSAI\Textures2\Earth_4_w1852_n0649.dds" -w 512 -h 512 -m 1 -f BC1_UNORM -o "e:\ESSAI\Textures\Earth\Surf\16\001398" -nologo' please check paths Treeman and texconv.exe are actually at the root of Orbiter - named ESSAI - but without anything else in it than config and textures folder. Edit:texconv.exe is not a 32 bits application valide ! Last edited by fort; 09-14-2016 at 11:41 AM.
 09-14-2016, 11:33 AM #13 Face Beta Tester Quote: Originally Posted by fort  Suppose, to take a simple example, I created a scene with a unique surftile for 2010p1, at level 0, a cell containing 256px x 256px. How is reinstated this image/dds in the tree of the 2016 release ( how treeman do it ) ? A resize is certainly necessary (?).Does Orbiter itself do it ? And does the tile is reintegrated at L-1, level 10 here, for example or the opposite, L12 ( for angular equivalence ) ? If you have an entry for a surftile in a base configuration, treeman will calculate the appropriate 2010P1 name and find it in the given texture path. It will then resize/recode the tile to the appropriate layer's format (Surf 512x512 DXT1 no alpha, Mask 512x512 DXT1 1-bit alpha). Resizing/Recoding is done via Microsoft's texconv.exe tool. The resulting file will be placed in the tree by means of Martin's publicized formulas.
 09-14-2016, 11:49 AM #14 fort Orbinaut Hello Face, I've added comments to my previous post. At the end: texconv.exe is not a win 32 bits application valid... But anyway... 1) On a 64 bits OS treeman resize my dds with the right new name and put it in the right cache folder. Not in the archive/surf.tree. I'm i right on that ? Do i have to create by myself all the previous levels as for the highest ( for example for a level 16, the levels 15, then 14, then 13 ) or does treeman do it ? I think that i have the answer but... thank you. Last edited by fort; 09-14-2016 at 11:53 AM.
 09-14-2016, 12:04 PM #15 Face Beta Tester Quote: Originally Posted by fort  The first command line is supposed to create a dds ? With the new denomination ( 002244.dds ) ? The second command line is supposed to integrate the dds and it's low level in the surf.tree or in the simple/basic cache ? The first command line takes a base configuration file and import all listed tiles into the file system cache. The second command takes a file list - which should be file system cache paths - and for each of them it integrates the tile into low-level tiles taken from the *.tree archive, and saves them in the file system cache, not the surf.tree file. ATM, treeman does not change the tree files. Quote: Originally Posted by fort  first error from me: my dds was named Earth_4_w1852_n649.dds . If i rename it Earth_4_w1852_n0649.dds Interesting. If Orbiter2010P1 supported this non-zero-filled format, treeman should of course support it, too. Did you try that naming scheme in 2010P1? Quote: Originally Posted by fort  There is a change but the surf.txt now is: /16/001398/002244.dds error 193: can't execute '"texconv.exe" "e:\ESSAI\Textures2\Earth_4_w1852_n0649.dds" -w 512 -h 512 -m 1 -f BC1_UNORM -o "e:\ESSAI\Textures\Earth\Surf\16\001398" -nologo' please check paths Treeman and texconv.exe are actually at the root of Orbiter - named ESSAI - but without anything else in it than config and textures folder. Error 193 is this: Quote: Originally Posted by MSDN  ERROR_BAD_EXE_FORMAT 193 (0xC1) %1 is not a valid Win32 application. However, according to the PE header texconv.exe is a 32-Bit tool. Perhaps there is some path issue, try to explicitly set the texconv path by means of adding the configuration "--texconv " to your calls. ---------- Post added at 14:04 ---------- Previous post was at 13:54 ---------- Quote: Originally Posted by fort  I've added comments to my previous post. At the end: texconv.exe is not a win 32 bits application valid... I've also tried it on a 32-bit machine now, and indeed the texconv.exe is not working there, although the signature is 32-bit. I will dig for a 32-bit build. Quote: Originally Posted by fort  On a 64 bits OS treeman resize my dds with the right new name and put it in the right cache folder. Not in the archive/surf.tree. I'm i right on that ? Exactly. It puts it in the file system cache, not in the tree archive. Quote: Originally Posted by fort  Do i have to create by myself all the previous levels as for the highest ( for example for a level 16, the levels 15, then 14, then 13 ) or does treeman do it ? If you have level 16, treeman can integrate them back to 15,14,13,etc. for you with the -i option.

 Orbiter-Forum

 Posting Rules BB code is On Smilies are On [IMG] code is On HTML code is Off You may not post new threads You may not post replies You may not post attachments You may not edit your posts
 Forum Jump User Control Panel Private Messages Subscriptions Who's Online Search Forums Forums Home Orbiter-Forum.com     Announcements     Meets & Greets Orbiter Space Flight Simulator     Orbiter Web Forum         OFMM         Orbiter Forum Space Station         Simpit Forum     General Questions & Help     MFD Questions & Help     Hardware & Software Help     Tutorials & Challenges     Orbiter SDK     Orbiter Visualization Project     Orbiter Beta » Orbiter Project Orbiter Addons     OrbitHangar Addons & Comments     Addons     Addon Development     Addon Requests     Addon Support & Bugs         Addon Developer Forums             Project Apollo - NASSP     Orbiter Lua Scripting Far Side of the Moon     Spaceflight News     Math & Physics     Astronomy & the Night Sky     Backyard Rocketry     Brighton Lounge     International Forum

All times are GMT. The time now is 11:29 AM.