Sign in to follow this  
rhumbaflappy

Landclass BGL creation

Recommended Posts

Hi,I think we allready discussed this matter few months ago but I can't find the post. Anyway, I have the following situation. I have three landclass.raw files to cover whole Slovenia and I would like to combinte them into one inf file so I will get oe BGL for lanclass. How this inf file should look? I also assume, since waterclass is similar to landclass, that I can also include waterclass data also in the same bgl (and same inf). Are there any special things that I should be aware of?Thank You for answers in advance.Best regards,Goran BrumenFS Slovenija 2002 teamhttp://slovenia.avsim.net

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

Hi Goran.Have you tried to use tmfmerge.exe to merge the tmfs before you use tmf2bgl.exe?I think that would work.Also, you could combine the RAW files to one source. Then, create the TMF from that in one INF.[source]Type = ClassU8SourceDir ="."SourceFile = "goge2_0ll.raw"Lon = -179.99999999Lat = 89.99999999NumOfCellsPerLine = 43200NumOfLines = 21600CellXdimensionDeg=0.0083335262390333109562721359290724CellYdimensionDeg=0.0083337191536645215056252604287236[Destination]DestDir = "."DestBaseFileName = "World"UseSourceDimensions = 0NorthLat = 89.99999999SouthLat = -89.99999999EastLong = 179.99999999WestLong = -179.99999999The above INF creates a new WorldLC.tmf from a source of 43200x21600 !It works. Note I made the destination a tiny bit less than the actual world dimensions. That allowed the wrapping of the tmf around the world. The exact dimensions left a line of water near the international dateline ( W180* ).If this causes a problem with a single RAW file, then the solution might be to enlarge the dimensions a bit, rather than shrink them ( you're not wrapping around the globe in this case ).Dick

Share this post


Link to post
Share on other sites

Hi Rhumba!Thanks for reply! I went so deep in VTP coding for my roads and lakes that I completely forgot how to use resample and TMFxxxx utilities :D. Anyway thank You for remembering me on TMFMERGE. So You mean that it would be best to create separate TMF, named let's say FSSloLC1.tmf, FSSloLC2.tmf and FSSloLC3.tmf, combine them together with TMFmerge and convert this LC with TMF2BGL to FSSloLC.bgl?Yesterday, when I was searching for suitable LC code for displaying rocks (texture 056b2xxx.bmp and btw I haven't found it ;( ) I also found the what I hope it will also work in one SDK. it goes something like this:

(source)UseMultipleSources=1NumberOfSources=3(source1)...(source2)...(source3)...(destination)...

Do You think I can use this approach? Thanks again,Goran BrumenFS Slovenija 2002 teamhttp://slovenia.avsim.net

Share this post


Link to post
Share on other sites

Hi Goran.It might work. I seem to recall a problem with a multisource inf and landclass. The best way would be to try it. :)I suspect you may need to actually combine the RAW files. This RAW source would need to be rectangular, and equal to or larger than the bounds of the destination.You may need to add a "dummy" RAW block to square off the source... that would be filled with value #254:XOXXwhere "O" is the dummy. In fact you could make it:OOOOOXOOOXXOOOOOand that would guarantee the compilation! The source can be much larger than the destination extracted from it. The surrounding dummy value blocks may help the blending-in of the new landclass without the sharp "cutoff" we sometimes see with addon landclass.I think #130 is rock, but I don't know if it "blends" like normal landclass.Dick

Share this post


Link to post
Share on other sites

Hi Rhumba!Thanks for Your answer; You mean that original RAW file should be resized to 257x257 so that one coloumn added on the right and one row added on the bottom would be for joining? If it is so, no problem, thanks for advice.Regarding rocks; I think also #130 are rocks, but the main problem is, that I want texture 056B2xxx to appear (gray rocks) but instead of it I got 056F2xxx which has some unnatural reddish stones. All the pictures of our mountains have these gray rocks and I am quite surprised, that they are not available. I spent 4-5 hours searching valid landclass value and at the end came up to use red rocks :(. And I have full house of nice pictures of our mountains with beautiful (light) grey stones...Thanks again and best regards,Goran BrumenFS Slovenija 2002 teamhttp://slovenia.avsim.net

Share this post


Link to post
Share on other sites

Hi Goran.What I actually meant was that each "X" would be a 256x256 or 257x257 source... and each "O" would be a dummy ( transparent ) source, also 256 or 257 in span. Then join the source RAW files by cut'n'paste in a paint program to have a larger, all-inclusive source for your project's landclass. Then the INF file would need to declare the right bounds for the source and desination... and it would give you a single landclass BGL that would encompass all your area, and blend-in to the default at it's edges, due to the transparency. We actually should have been doing this from the start with our small landclasses. By surrounding our data with LOD5 blocks of null data ( #254 ), and expanding our destination bounds to include those null blocks, we get a natural blending with the default landclass, instead of the sharply cutoff texture at the edge of the landclass.===========================The best way to source a single LOD5 area landclass, is to make a 769x769 null ( value #254 ) RAW file, then paste our 256x256 data to the center of that file. Why 769? ( 256 * 3 ) + 1 = 769That's one more vertex than the number of cells enclosed. For the best control, the source should always be the number of cells + 1.Place the source bounds at the NW corner. Make the destination bounds as equal to all the 9 LOD5 areas encompassed.The end result should be a file that encompasses 9 LOD5 areas, with all transparent except the central LOD5 ( that has your data ). And that landclass should blend into the default perfectly at the edges.=================This would also allow non-adjoining LOD5 data to be in a single BGL:00000000000X000X000000XXXXX00000X00X00000000000000That represents 50 LOD5 areas, with 9 areas of actual data. The rest of the data is populated by #254. The optimal size would be 2561x1281 ( with 256 cells per LOD5 area, +1 each way for the enclosing vertex ). The entire area should be sourced and destined. The resulting BGL should have all 50 areas landclassed. Only the 9 with valid data will appear. With tmfcompress, this BGL will be smaller than 9 separate BGLs, and the landclas edges will blend-in to the default as well.==========Try #133 ( lava ) or #138 ( black sand beach ) for rock values, and see if those are better.Dick

Share this post


Link to post
Share on other sites

Hi Rhumba!Thank You for this great answer. If there will be any problems, then I will try this enormous texture, but for now I will try with INF file with multiple sources.But what still bothers me is the texture. I tried around 30 different LandClass values to get those gray stones but I can't persuade FS to use them. Do You (or anybody else) have any idea, how to push FS to use grey stones textures instead of brown ones. It is simply unnatural here in Slovenia; it looks like we are in Grand Canyon not in the Alps world. :-( Is there any possibility to add some textures to LC lookup table or to tell FS use those textures? Afterall those textures are allready there... :-zhelp :-zhelpBest regards,Goran BrumenFS Slovenija 2002 teamhttp://slovenia.avsim.net

Share this post


Link to post
Share on other sites

Maybe you can use the approach we use for our Dutch landclass? We just use the default numbering, but have made our own textures for the fields. So in the texture subfolder we have new textures with the default names and those are used.(Of course there are no mountains in the Netherlands, so we didn't have that stone problem :D).Arno


Member Netherlands 2000 Scenery Team[link:home.wanadoo.nl/arno.gerretsen]Arno's FlightSim World for scenery design hints, tips and other tricks...

Share this post


Link to post
Share on other sites

Hi Arno and Goran.I think if you use a local texture set, the local set must contain all the textures used in the small landclass BGL, or else there will be default textures not displayed. The work-around for that was to copy all textures from the '...scenedbworldtexture' folder to the main "Scenery" folder ( not a well recieved idea ).This isn't a large problem if your landclass contains a dozen texture assignments, but it still has some problems. If you wish to distribute the scenery, MS might frown on packaging their textures with your scenery.An alternative?2 landclass BGLS, one in a separate project folder without a texture subfolder, and the second in a normal project folder with a texture subfolder. First, the landclass for the general area using the default textures. It must be in a scenery folder without a twin texture folder, like normal landclass. The textures are then found normally in the default '...scenedbworldtexture' folder.Second, a landclass bgl that can be placed with the VTP or object scenery ( that does have a twin texture folder ). This landclass is all value #254, except for the rock texture that is placed. These textures must have the same name as a default texture, as Arno indicated, so the lookup table will be able to place them. Then placed the renamed textures into the local twin texture folder.You'll need to watch the datastream for the landclasses. The default landclass scenery folder will need to be displayed first ( lower ) in the Scenery Library order, so your customised rock landclass will next override them. This, in effect, layers the landclasses you create.I think this should work, though I have not tested it.Dick

Share this post


Link to post
Share on other sites

Yes, I guess you are right. Our landclass scenery only uses a few textures (6 different types of fields, to indicate the different look in the different parts of the country). All other things like towns, etc are placed with VTP polygons, so we use a very limited amount of textures with our landclass (and all textures are made by us).Arno


Member Netherlands 2000 Scenery Team[link:home.wanadoo.nl/arno.gerretsen]Arno's FlightSim World for scenery design hints, tips and other tricks...

Share this post


Link to post
Share on other sites

Hi Rhumba and Arno!Thanks for this nice idea! Maybe it would be worth trying making two LandClass files. The installer (which must be used due to hugness of scenery) will simply copy those needed default textures to my texture folder under correct name of course. I think if I copy those textures it won't be illegal to Microsoft?Best regards,Goran BrumenFS Slovenija 2002 teamhttp://slovenia.avsim.net

Share this post


Link to post
Share on other sites

Hi Goran.As long as you're not distributing their textures, MS shouldn't have a problem with it... after all, the end user is supplying the actual textures from their own copy of FS2002. Good solution, I think.I still haven't tested this "layering" of landclass BGLs, so I would appreciuate if you keep us informed if you use that approach to using customized textures.Remember, the landclass BGL that uses the default textures needs to be in a separate project folder, with a "scenery" sub-folder, and no twin "texture" sub-folder. That's usual for landclass, and it forces the sim to use the default textures for that landclass BGL.Dick

Share this post


Link to post
Share on other sites

Hi Rhumba!Thank You for Your opinion. I will gladly post You discoveries based on this theme, no problem.Thank You and Arno again!Best regards,Goran BrumenFS Slovenija 2002 teamhttp://slovenia.avsim.net

Share this post


Link to post
Share on other sites

Hi guysThe simple solution to problems with ground textures and landclass scenery is to copy (or move - more efficient and perfectly safe - I have checked it out thoroughly) all ground textures files from fs2002scenedbworldtexture to fs2002texture, as mentioned earlier. One can then have landclass BGL's in their own ..scenery & ..texture folder pairs, with any replacement textures in the ..texture folder, with no problems at all. The other step that is necessary is to also copy ALL Autogen .agn files from fs2002scenedbworldtexture to the new ..texture folder (copies are required in every ..texture folder accompanying a ''scenery[/b] folder with a landclass BGL in it - unless you leave the ..texture folder out altogether).Everything then works like a charm. Why on earth the reference to "not well received", Dick, I just don't understand. This technique works and there are NO side effects etc. - so what's the problem?CheersGerrish

Share this post


Link to post
Share on other sites

Hi Gerrish.Perhaps that was just my mistaken impression. The method you describe is right, and can easily be accomplished by a batch file to either copy the textures and autogen. Scenery designers could include the copying batch file with their scenery. Unless harddrive space is at a premium, there would be no need to remove the original contents of the "scenedbworldtexture" folder... in fact they could be left as a storage of the original textures and autogen.It's one of my wishes for FS2004, that this could all be fixed... especially autogen location. ( And the vertical flipping needed for VTP texturing, and the secret of default VTP lines.... ). :-lol Dick

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this