frtps wrote in Sat Jun 12, 2021 3:36 am:A few alternative shaders with overlay mixing parameters adapted to 1024x1024m texture size to remove tiling
Not sure what you mean specifically - but it might be simpler to avoid creating a new shader, and expose more controls as parameters with a default value set to the current value? e.g. if the shader in question doesn't have overlay scale exposed as a control (e.g. <overlay_magnification> parameter), or you are changing an unexposed attribute of the noise function used in mixing. It's also possible to add a new feature gated by a uniform flag that is off by default, if it's not too big of a code change - e.g. if you are porting (?) the detiling code from the agriculture shader.
frtps wrote in Sat Jun 12, 2021 3:36 am:1. Detailed region boundaries based on climate classifications and study of aerial photos
You probably implemented these with lots of boxes? In the long-term a way to handle this type of boundary would be extending the box definitions to polygons an arbitrary number of lat/lon pairs defined clockwise.
In a lot of cases, natural boundaries are generally hard to do with boxes. For example I was looking at a valley floor texture for alps after it was pointed out in the mailing list that there were some landlcass mapping issues in certain countries. I had a look at geology too.
Geology of alps - a rock climbing site that came up in search -
link . Geology affects appearance of vegetation, bare mountain look, mountain meadows, and even the colour of (glacial) rivers/lakes from things like suspended paricles in limestone areas:
So regional definition structure for the alps covering multiple countries might be: 3 xml files for natural terrain with differring mountain & lake appearance - and terrain affected by human activity like alpine valleys, agriculture, towns in different countries can get a separate common alps definition or per-country regional definition.
frtps wrote in Sat Jun 12, 2021 3:36 am: I had been waiting until I had a complete set of textures that I was happy with, but that is going to be several more years at my current pace.
Release early and release often is best from an opensource point of view
. Unfortunately the amount of exposure drops exponentially if even 1 extra step is needed to get scenery - the FGUK photoscenery had only 70 downloads when I looked despite being the only such package for several months, while there are many thousands of downloads of FG per week. And as Thorsten said the standard for inclusion is that it's an improvement with no technical issues like tiling - so the bar is pretty low in regions with placeholder definitions.
frtps wrote in Sat Jun 12, 2021 3:36 am:I'd also be happy to submit textures that are better than default but not yet ideal into FGData but I think churn of textures is a great way to burn up space in git repositories, especially ones that don't use Large File Storage, so I'm trying to avoid that.
Is the binary file churn that serious if there's one or two iterations on 1-2mb textures? Might be something to ask the list..
People are expected to iterate on textures and binary files in the normal course of development - e.g. AI aircraft textures may be replaced by JPGs in future, and there's a steady stream of commits to AI craft in FGData. There appears to be ways of cleaning binary files from git history according to google if it becomes troublesome in future (?) (e.g.
link), but this seems to need fresh clones and would need some careful backing up. Incidentally there's a FGAssets repo being set up for binary files of source data for OSM2City building improvements - that could also be used for regional texturing sources etc. or a similar one created for FGData if there's an unavoidable need (?) to download the whole repo when cloning.
Kind regards