Aerosoft official retail partner for Microsoft Flight Simulator !! 
Click here for more information

Jump to content

Oscar Pilote

  • Content Count

  • Joined

  • Last visited

Community Reputation

5 Neutral

About Oscar Pilote

  • Rank
    Flight Student - Groundwork

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. One remark : you can freely change the parameters inside blurX.scm to suit your preferences for the transition. I have uploaded an example blurX.scm.inland (you have to rename it to blurX.scm if you want it to be used) I prefer it over the original one when using the use_masks_for _inland option (it makes the transtion smooth but keeps some of the orthophoto also in the middle of the rivers (so do not use if if there is real sea or spoiled orthophotos!)). I use it with masks_width=2. If you wish to experiment the important line in the blurX script is : (gimp-levels drawable 0 0 255 2 140 235) it means that (after the bluring) the grey levels 0 to 255 (full black to full white) will be sent to the range 140 235 (mid grey to almost white) [like the "levels" tool in gimp or I guess photoshop] Initially black = water and white = sea, and the blur yields some smooth grey transition. With the above setting the full black (i.e. "far" from the riverbank) is turned grey, and therefore there will be a mix of orthophoto and x-plane water. If you decrease the 140 closer towards 0 you will have more x-plane water in the middle of the rivers. You can think what are the effects of changing the two blue numbers (don't change the red ones) on the result, and choose your prefered option (thanks for the texture dir bug Armin, I have just made the change in the dropbox) 0
  2. When you experience a problem with a TMS server you can check the "check TMS response" (right of "skip convert"). It can be put on on the fly, and also stopped on the fly, it will keep reasking small tiles until they are indeed advertised as jpegs (can lead to a dead loop if the server really hgas nothing to deliver). On the other hand, when a server has issues, it is wise to wait untill it recovers ;-)
  3. I have uploaded my home version on the dropbox (for windows users I found some cuda aware nvcompress, but I barely tested it on one tile, yet it seemed to be fine with10min for the whole tile). The windows nvcompress is included in Utils/nvcompress/ dir (just copy the dir at the same place). You should update and Ortho4XP.cfg (and Carnet_d_addresses if you wish). Small new features in this version, in addition to the dds fix include : - possibility to use a different provider for sea textures (I am using that to build tiles for updating zonephoto France) - possibility to clean up unused dds and ter files when you redo a tile - if you have STRM in addition to viewfinderpanorama DEM files, it will use the former to fill the viewfinderpanorama gaps (when there are) instead of filling with the mean altitude of the tile (this fixes the strange plateaus that could be seen on certain tiles with no_data not filled manually). The SRTM should be in the same resolution 3" or 1" as the hgt one (and with their default gdex filename). I have had few time for X-Plane lately so just back up your working version just in case... Gruss
  4. Sorry I should have put the updated version online for a while, but I had other changes in mind so I postponed it. I will put it this evening or more probably tomorrow evening. It uses nvcompress for the jpeg to dds conversion if no color correction is aked. Otherwise is first uses imagemagick convert jpeg to png for the color correction followed by nvcompress for png to dds. I will ask imagemagick developper to include the dxt1a version for the next release if they can. Xgrinder unfortunately is 3 times slower than nvcompress with the -fast switch, at least on Linux. On Windows I found a good version with cuda support (different than the one of maydayc but probably the same code). On Mac I could not test since I don't have easy access to a Mac machine.
  5. I do not understand where those squares come from, here is an example with the original dds on the left and the way it is rendered in X-Plane on the right, it shows that the problem is not in the dds (I checked in lower mipmaps and no problem either, it really puzzles me). I will ask Ben Supnik about a possible cause in the rendering engine...
  6. @ffm_750 brew update brew install p7zip @WilKur große Probleme! (typical bad dds compression when almost flat color) Strange to see it there and so strong (is your X-Plane rendering option "texture res" far from "extreme" ?). Can you give the lat/lon of the place for testing here ?
  7. Entschuldigung... es ein Fehler war.
  8. Hallo, Im Handbuch, Kapitel 7.1 (sorry I go on in english) : elevation files always contain some form of "noise", and are therefore not appropriate to reproduce flat runways. For that reason the triangles corresponding to airports are FORCED to be flat at the mean altitude of all the boundary points of the airport. For that, Ortho4XP needs to know where is the boundary of the airport, and it relies on Openstreetmap (not on apt.dat) : there must be a closed "way" or a "rel" tagged "aeroway"="aerodrome" corresponding to your airport in Openstreetmap. Sometimes (it really depends on the country) there is only a "node" with the "aeroway"="aerodrome" code in OSM, in that case you should encode it in OSM yourself (it may take a bit of time the first time but then with a bit of use it takes 2 min using JOSM), wait a couple of minutes for the OSM server to update, push "purge OSM data" and redo Step 1. You'll then get a perfectly flat airport. (if you hesitate on how to do it check how it is done for an airport that has it)
  9. 1) Sie können auswählen : contrast_adjust, saturation_adjust, brightness adjust in der Konfigurationdatei 2) Die letzte Version ist bereits in der Dropbox hier Sehr schöne Ihre Bilder Markus ;-) Gruß Os(k)ar
  • Create New...