Landclass BGL creation

[Guest GerrishGray]

Yes, I believe that the apparent 'bugs' in the search behaviours when locating (a) ground texture files, and (:( Autogen .agn pattern files, have been reported to Microsoft, so we can hope that there will be some change in FS2004 - let's just hope that it's for the better and not for the worse, because at least there is a valid 'workaround' at present! It would be a pity if we ended up with a system that reduced the flexibility we presently have!What we need is a file search system that allows the use of substitute ground textures and .agn files in local ..texture folders without the need to move the default location of the ground textures to the main fstexture folder and copy all the default .agn files to the local folder.What we want is systems that work in the same way as the location of 'ordinary' texture files for 3D objects ... shouldn't be too much to ask, one hopes :-)Kind RegardsGerrish

[Guest gorchi]

First of all, I must thank Gerrish and Rhumba for advices. Today I have tried to couple two landclass raw files together, thankfully with success. This is the inf file used:

{Destination}LOD=5NorthLat=47.8125SouthLat=45WestLong=11.25EastLong=18.75DestDir=.DestBaseFileName=lc {Source}Type=MultiSourceNumberOfSources	= 2 {Source1}Type=ClassU8SourceDir=.SourceFile=landclass.rawLat=47.8125Lon=11.25NumOfCellsPerLine=257NumOfLines=257CellXdimensionDeg=0.0146484375CellYdimensionDeg=0.010986328125  {Source2}Type=ClassU8SourceDir=.SourceFile=landclass2.rawLat=47.8125Lon=15NumOfCellsPerLine=257NumOfLines=257CellXdimensionDeg=0.0146484375CellYdimensionDeg=0.010986328125

This is actually code that works for me. Now the problems I found. At first I tried to couple two raw files, each with size 256x256 so there was a little different inf file before in SourceX part:

NumOfCellsPerLine=256NumOfLines=256CellXdimensionDeg=0.0147058CellYdimensionDeg=0.0110293

At the joint of two raw files (they are on together horizontally), there was a straight line of water with width of 2 LOD8 quadrants. Probably also on the top or bottom, but I didn't checked...Next I enlarged raw bitmaps to 257x257 with adding a vertical line at the right and at the bottom, landclass code is 254. It worked except everything was moved one line up and left. So due to this I moved the new line from the bottom of raw bitmaps to top and from right to left side so now it works perfectly, no problems on any side. I also have around a loooot of space with landclass value 254 because one such bitmap covers part of Austria, part of Italy on left side or part of Hungary on right side and of course Croatia on the south side.I also tried to join Waterclass this way but (old) resample refused doing it so since two different classes are not allowed.By the way, I tried above LC.INF file also with new resample. It worked without any problem, the only thing which is interesting that bgl produced with old resample (and TMFCompress, TMF2BGL) is 6454 bytes long, with new resample (straight bgl) only 6358 bytes. Looking in Flight simulator I have not noticed any difference...I hope this will help someone also.Best regards to all!Goran BrumenFS Slovenija teamhttp://slovenia.avsim.net

[rhumbaflappy 113]

Hi Goran.It might have been easier to just join the 2 RAW files in a paint program, and use them as a single source.The new cell dimensions are figured as:( TotalSpanInDegrees / ( NumberOfImagePixels - 1 ) )We don't need to be tied to 257 x 257 for a source image. The number of 257 is chosen because it is one more vertex than the 256 x 256 ground tiles that are to be defined in a single LOD5.CellYdimensionDeg = (2.8125 / ( 257 - 1 )) = 0.010986328125CellXdimensionDeg = (3.75 / ( 257 - 1 )) = 0.0146484375The ideal image size for 2 longitudinally joined LOD5's is 513 x 257. CellYdimensionDeg = (2.8125 / ( 257 - 1 )) = 0.010986328125CellXdimensionDeg = (7.5000 / ( 513 - 1 )) = 0.0146484375But even so, we are still not tied to this... that image size is just optimal. What if the image size is 722 x 308 for the adjoining LOD5's?CellYdimensionDeg = (2.8125 / ( 308 - 1 )) = 0.0091612377850162866449511400651466CellXdimensionDeg = (7.5000 / ( 722 - 1 )) = 0.010402219140083217753120665742025The only problem with that is resample will now control the end result, and we don't know what resample will come up with... but it works.A multiple of 256, then add 1 extra vertex to the image pixel size for both Lat and Long, will cure the problem of controlling what resample will create for landclass and waterclass. If the entire border of this image... say 513 x 257... is value #254, then the entire landclass will blend seamlessly with the underlying landclass at the edges. Otherwise, you'll get a sharp edge where the new and the old meet. Paintshop Pro allows you to make a 511 x 255 image, then give it a one pixel border... very handy.; DelavanLC.inf; 513x257 source{Destination}DestDir = "."DestBaseFileName = "513x257"UseSourceDimensions = 1{Source}Type = ClassU8SourceDir ="."SourceFile = "513x257.raw"Lon = -90Lat = 45NumOfCellsPerLine = 513NumOfLines = 257; Typical spanCellXdimensionDeg=0.0146484375CellYdimensionDeg=0.010986328125If the size of the image is not exactly a multiple of 256 ( + 1 vertex ), you can still compute the cell dimension degrees and get a good landclass... but with less control.I tried the NEW & OLD resample with an odd spanned image source... say 722 x 308 covering 7.621 x 3.146 degrees... but although it fills the required overlapping LOD5's, it fills them with water ( value 255 {Why not 244!!!!} ). So specifying the Destination bounds is necessary in thay case.Dick

[rhumbaflappy 113]

Hi Goran ( and all ).I actually have found a way to take an 'odd' degree span with an 'odd' image size, and create a seamless blended landclass. Your use of a multisource gave me the idea:; 722x308.inf; 722x308 source with odd degree span{Source}Type = MultiSourceNumberOfSources = 2{Source1}Type = ClassU8SourceDir ="."SourceFile = "722x308.raw"Lon = -90.466Lat = 45.845NumOfCellsPerLine = 722NumOfLines = 308CellXdimensionDeg = 0.010540802213001383125864453665284CellYdimensionDeg = 0.010181229773462783171521035598706; CellXdimensionDeg = (7.621 / ( 722 + 1 )); CellYdimensionDeg = (3.146 / ( 308 + 1 )){Source2}Type = ClassU8SourceDir ="."SourceFile = "transparent.raw"Lon = -180.0000Lat = 90.0000NumOfCellsPerLine = 100NumOfLines = 100CellXdimensionDeg = 3.636363636363636363636363636CellYdimensionDeg = 1.818181818181818181818181818{Destination}DestDir = "."DestBaseFileName = "722x308"UseSourceDimensions = 1I didn't try to use destination bounds, but I could have, as long as those bounds were exact multiples of LOD5 areas.Source1 is the 'odd' data. 722 x 308 image source, spanning 7.621 longitude and 3.146 latitude, with the NW corner at N45.845 by W90.466. It has NO transparent border pixels.( pretty odd, huh? ) :)Source2 is the entire earth with a 100 x 100 source image... this image is filled with value #254 ( transparency ).This produces a valid landclass BGL. The landclass blends seamlessly with the default landclass.I believe many 'odd' sources could be used in one INF file, as long as the last is the transparent world. Note the formula for the Cell DimensionDeg... it adds a vertex, rather than subtracting one! If I didn't do this, I would get an LOD13 border of value #255 to the south and east of the data.The second pic shows the vertex blending of Source1 to the underlying default landclass.Dickhttp://forums.avsim.com/user_files/4293.jpghttp://forums.avsim.com/user_files/4294.jpg

[Guest gorchi]

Hi Rhumba!Thanks for saying hello to me, I saw it in the morning when I was flying oround the world :-hah Well anyway interesting what You are saying. Of course I didn't forget Your idea of one image for all but it sounds more cleaner to draw in only necessary images. I tried it in one image but the effect wasn't so pleasing; I don't remember though what was wrong. So I forced multi source inf file and it works nice.And 256pix width/height of image just sounds logically and I must admit, using Your cellgrid is even easier to put some landclass at some point. What I found really interesting when drawing landclass is that center of each value is just at crossing of 4 LOD8 quadrants. I also found that some landclass values have more influence to others, let's say forests (22, 21, 56) do have more influence on some lanclass values, i.e. 115, 116, 111... Anyway I was wondering why should I use for one LOD5 quadrant image bigger than 257x257 pix if one landclass covers only approx 1.2 x 1.2 km2 area? Only to blend it smoothly? In Slovenia it doesn't seem to be useful, whole Slovenia could be covered in one LOD5 quadrant and I still would have enough pixels on each side with LC value 254. But since border with two adjacent LOD5 quadrants goues right through the middle of Slovenia, I need 2 images...Still it is very interesting idea, having one image of LC and one full of LC value 254 covering whole world. Really weird idea but as long as it works, it is useful! ;)Thanks for all help!Best regards,Goran BrumenFS Slovenija 2002 teamhttp://slovenia.avsim.net

[rhumbaflappy 113]

Hi Goran.Cellgrid dramatically shows that the assignment of landclass ( and CUSTOM ) is on the vertex, rather than the cell ( groundtile ). This also explains why water and CUSTOM, niether of which blend to other groundtiles, will dominate all four cells which touch the assigned vertex... and why 4 is the minumum number of CUSTOM textures that can be asigned with landclass. Likewise, assign 1 water vertex, and it will cover 4 groundtiles.The above example is strange at first glance, until you see that we are not restricted to designing landclass for LOD5 areas.. or need the data in any pre-formated image size ( like 257 x 257 ). We also can use multiple image sources that need not be adjoining. Resample will do it's best to weave it all together.The above example's BGL, although it technically covers the entire earth, is only 141kb, because of the compression of the TMF before it is made into a BGL. The size could have been further reduced by the use of Destination Bounds.The use of this technique could solve many design problems with landclass ( or waterclass ). And their edges will always blend into the default.. instead of betraying a sharp border edge.Dick

[Guest GerrishGray]

Hi guysI usually leave these discussions about creating landclass files to you guys such as Dick and Christian who have spent so much time studying it and know infinitely more than me. But I notice that Goran has said"I also found that some landclass values have more influence to others, let's say forests (22, 21, 56) do have more influence on some lanclass values, i.e. 115, 116, 111..."and that reminds me about the *m1#.bmp textures that accompany some, but not all, of the ground texture sets. These files are plain 256-colour bitmaps with a very unusual grey-scale palette. They are nominally 2048x32 pixels, but are actually made up of eight 256x32 strips. It seems that they probably control the blending of adjoining ground textures between one cell and the next, and the existence of eight strips suggests that they are being applied to either the external, or more probably the internal, boundaries of a cluster of four cells. Dick, as you and Christian are the experts here, perhaps you could experiment with some test versions of the *m1#.bmp textures with recognisable patterns and see if you can determine exactly how they do work? This could be useful information for those working with landclass data and/or building replacement ground texture sets.CheersGerrish

[Guest gorchi]

Hi Gerrish!Interesting opinion, must say. Do You, Rhumba and Christian think that in these grayscale images could also be hidden lookups? I just can't buy it, that MS used brown rocks here. Okay they could be found in some areas but not in Alps! Guys from Austria, Italy, Switzerland and France should have same problems and if changing one of such image (or even better delivering it with own scenery) could brown rocks turn into gray, it would mean one huge step in realistic scenery appearance.Best regards,Goran BrumenFS Slovenija 2002 teamhttp://slovenia.avsim.net

[Guest GerrishGray]

Hi GoranThe problem about the rock colours is actually quite easy to fix using landclass scenery. If you have local landclass scenery and install it in a local ..scenery and ..texture folder pair following the instructions I have given earlier for making this work correctly, then you can put a replacement of the offending 001b*.bmp and 067b*.bmp textures into the local texture folder (e.g. you could use the grey region F versions, renamed for use with region :(.CheersGerrish

[rhumbaflappy 113]

Hi Gerrish.I haven't experimented with the ground texture blending masks. I think I tried once to add masks to other ground textures, without success... but who knows ( that may have been with CFS2 ). I may look a bit into these masks, again. I wonder if their location is hard-coded, or if we can mask locally? That might add some fun to landclass. :)The aspect of transparency made me wonder if they are 8-bit with alpha... but the Imagetool shows them to be 8-bit with no alpha. That means they are probably applied as an 8-bit alpha channel at runtime. So can we apply other alpha masks at runtime? *:-*I also see they are not simply 2-color masks, but contain pallette of grey tones ( but are not specifically greyscaled ).Perhaps manipulating the mask sections, one at a time can yield some information... I would assume the darker the grey, the greater the transparency ( maybe ).==================Rock areas could also be added as VTP1 or VTP2 polys. A wavy or variegated edge could be used... and it could blend in pretty well. I don't know how many areas Goran is thinking of changing... so it could be a bit of work.Otherwise, a customized local landclass texture replacement would be the way to go, as you suggested.Dick