LandClass...I'm stumped.

[akriesman 0]

I have been playing with redoing the DFW LandClass for some time now. I had been having problems, so I took it down to the smallest, simplest example. No matter what I do, I get a generic looking terrain. and not the expected city textures.For my test, I put all the same landclass values in the binary input file (256 rows x 256 columns filled with a decimal 101 value). When I fill the value with 101 (city texture), I get a moon like landscape. When I fill the value with 106 (suburb), I get a similar landscape in another shade. This is really crazy. I have read the SDK, and have a good understanding of the process. I even tried LandClass assistant, but achieved the same results.I am wondering if the RESAMPLE.EXE that I am using is causing problems. It is the version from 6/28/02 that came with the Terrain SDK.Any advice would be welcome. Here are some screenshots and other information. Remember, the RAW input file is 65536 bytes, all filled with the value 101. First, the INF file (brackets removed)....DestinationLOD=5NorthLat=33.75SouthLat=30.9375WestLong=-97.5EastLong=-93.75DestDir=.DestBaseFileName=TESTSourceType=ClassU8SourceDir=.SourceFile=new.rawLat=33.75Lon=-97.5NumOfCellsPerLine=256NumOfLines=256CellXdimensionDeg=0.0147058CellYdimensionDeg=0.0110293Here are the values from the LOD 5 calculatorAnd, hear is a screenshot showing the problem (area around the airport should be city texture 101, but it is not).Thanks guys! I must be missing something rediculously simple.Allen

[Guest christian]

Make sure that you DON'T have a texture folder...Cheers, Christian

[rhumbaflappy 113]

Hi Allen.I think Christian is right. You should not have a twin 'texture' folder to the 'scenery' folder, if you are using the default textures.When I have a scenery project, I'll make a project folder... say 'Custom Workshop'. Inside that folder I'll have a folder named 'scenery', and another folder called 'texture'...BUT a normal landclass project should not have a local 'texture' folder.The project "Custom Workshop' is added to FS2002, and activated, through the Scenery Library.Oddly, if your landclass has Custom textures ( defined by #252 or #253 ), you must have a twin 'texture' folder containing the properly named custom textures!For a laugh, try this INF file:{Destination}DestDir = "."DestBaseFileName = "TEST"UseSourceDimensions = 1{Source}Type = ClassU8SourceDir ="."SourceFile = "new.raw"Lon = -97.5Lat = 33.75NumOfCellsPerLine = 256NumOfLines = 256CellXdimensionDeg = 0.014705882352941176470588235294118CellYdimensionDeg = 0.011029411764705882352941176470588( Substitute square brackets for '{' and '}' )Let us know if it works... and if not maybe I can look into it deeper.

[akriesman 0]

Thanks guys for the advice. I did indeed have a texture folder.Now that you mention it, I remember reading about this somewhere. Boy does it cause some strange effects. I must have wasted 3 hours on the problem. Although, I also don't ask for directions, until I have been driving in circles for 3 hours either :) My wife can verify this to her dismay.On a side note, I wrote a program that takes detailed land classification images (TIFF files) from the USGS, and converts the TIF files into RAW files containing the translated land classes (NLCD to FS LC).I was planning on having this very detailed landclass scenery generated, from my 13,500 x 10,127 pixel image files (NLCD data). I knew that I had to generate an LOD 5 area of 3.75 degrees x 2.81. What I did not know, was that an LOD 5 region only samples points every 1.2km. So basically, my very large and detailed image, is no better than a 256x256 image.I don't see how you guys found this stuff out prior to the year-late SDK's. I tip my hat to you.Cheers,Allen

[akriesman 0]

Rhumba...CellXdimensionDeg = 0.014705882352941176470588235294118CellYdimensionDeg = 0.011029411764705882352941176470588Thanks for the laugh :)Allen

[rhumbaflappy 113]

Hi Allen.It's not a joke. These are the numbers that pass a 256x256 source through Resample without altering the data!CellXdimensionDeg = 0.014705882352941176470588235294118CellYdimensionDeg = 0.011029411764705882352941176470588Try the SDK's numbers with the old Resample...and look at the uncompressed TMF file with a hex editor. You can't retrieve your data from the TMF 100%, because resample has resampled!Try it with the above numbers, and the data can be retrieved 100%. No resampling... so those have to be the correct numbers for landclass! And, in fact, they are.The FS2000 SDK was not accurate, and that has led us to many problems over the past couple of years. The new SDK info on Landclass repeats this error.Dick

[Guest luissa]

>CellXdimensionDeg = 0.014705882352941176470588235294118 >CellYdimensionDeg = 0.011029411764705882352941176470588 >CellXdimensionDeg = 0.014705882352941176470588235294118 >CellYdimensionDeg = 0.011029411764705882352941176470588 Hi,I think that if you use these numbers to describe the spacing between source samples, you get a wrong sampled file. With the shown numbers the raw file should be 255 x 255 which is not very practical to specify 256 x 256 classes in a LOD5 quadrant. The ressampler will only use the "top-left" 255 x 255 values of your 256 x 256 source values. Nevertheless it will create, using some interpolation, 256 x 256 destination values from the 255 x 255 usable source values.If you have a 256 x 256 source file you should use:CellXdimensionDeg = 0.0146484375CellYdimensionDeg = 0.010986328125Thinking of CellXdimensionDeg as the spacing in longitude degrees between source samples and of CellYdimensionDeg as the spacing in latitude degrees between source samples, we get:CellXdimensionDeg = 3.75 / 256 = 0.0146484375CellYdimensionDeg = 2.8125 / 256 = 0.010986328125Following are 2 pictures derived from TMFViewer. In the first shot I used the numbers that I am convinced of and I get the same image as the raw data. Using the other numbers I got the second picture.May be I am wrong! I am sorry if that is the case!Regards, Luis

[rhumbaflappy 113]

Hi Luis.Look at an uncompressed TMF with a hex editor. My numbers will yield a retirevable dataset of exactly 256x256 ( 65,536 bytes ). Place a value of #254 at 0,0 and at 255,255... so you can eaasily find the start and end of the data within the TMF. Make all other data as you wish. You can extract the data, put it right in a good paint program, and it's identical to the original 256x256 source. I needed to find this number, as I wanted to create Photoreal BGLs with landclass and value #253 ( #252 for seasons ). I was getting corrupted scenery with the usual numbers... so I guessed the usual was wrong. It was.The 'usual' numbers won't retrieve the same data... the data has been corrupted by Resample.Dick

[akriesman 0]

I tried those numbers, and RESAMPLE aborted itself. I thought the joke was that the RESAMPLE app would not handle numbers of this precision without being in exponential form. I will them again though (must have had a typo).DFW looks a whole LOT better now. Thanks for the help.Allen

[rhumbaflappy 113]

Hi Luis, Christian, and all.Now I'm the one that's confused!I could not repeat my own experiment! :-lol The most confusing part of it is this:Using a 257x257 source....{Destination}DestDir = "."DestBaseFileName = "HomeCustomLC257"UseSourceDimensions = 1{Source}Type = ClassU8SourceDir ="."SourceFile = "Home257.raw"Lon = -90Lat = 45NumOfCellsPerLine = 257NumOfLines = 257; 256 spanCellXdimensionDeg=0.0146484375CellYdimensionDeg=0.010986328125.... this now produces a 100% retreivable 257x257 source...just as Christian Stock has been saying for months!!:-eek Apparently I was able to fool myself by retrieving the first 65536 bytes of the data from the bgl... and never checked to see if resample had padded my source data with extra bytes. It had. My way produces the same size uncompressed BGL as Christian's idea... but his data is sound. Oddly, we still must have the dimensions based on one less than the actual number!Also, the SDK's rounded off numbers are still wrong.So Luis, you're right about the dimension numbers. And Christian, you're right about the source size ( 257x257 ). And after I set things aright in the TerraBuilder forum, I'll have a big helping of crow.:-lol Dick

[Guest luissa]

Hi Dick,Here are some disperse ideas about the MS resampler. I think that 2 possibilities exist for the sampling as in the enclosed image (8 squares "represent" 256).In both cases the distance between the produced cells is:LOD_Edge / 256Christhian says that each LOD quadrant in a TMF file consists of 257 x 257 cells or samples. You confirmed this by using an HexEditor and looking to a TMF file.The above claim suggests that "sampling" is taken exactly at "LOD latitudes and longitudes" as in the first half of the image.Many problems arise:1) in the case of Terrain (mesh) resampling - we do not know if triangles are made with the all 257 x 257 points or, say, the north row and the east column are discarded, the elevations being taken from the adjacent LOD quadrants!2) in the case of LandClasses and PhotoTiles - here we do not know which of the 4 corner numbers (LandClass indeces) are used to represent the square !!!I have been able to overcome these problems with some sort of trial and error. In some cases I use SampleIsCentered = 1 and, in others, I add or subtract 1/2 of ( LOD_Edge / 256 ) to the source boundaries.However it would be very useful to completly understand how sampling is taken. Also I would like to understand and relate: 1) what values the TMF file stores (257 x257) 2) what values TMFViewer shows (256 x 256) and 3) what values FS uses when running.One good experiment could be to make a raw data file of say (1024 + ?) x (1024 + ?) values. We could start by filling the file with the same value, say 0. Then we could place 1s in a grid of 4 x 4 like this:000000000000000 ...000000000000000 ...001000100010001 ...000000000000000 ...000000000000000 ... 001000100010001 ...Using: CellXdimensionDeg = 3.75 / 1024 CellYdimensionDeg = 2.8125 / 1024it would be interesting to write the INF that just "pick up the ones".The second and third pictures refer to my previous message in this thread. By some reason I could not upload them.Regards, Luis

[Guest luissa]

Hi,Let me add one more comment on the CellXdimensionDeg CellYdimensionDeg issue.These values simply depend on the spacing of the samples in the raw source data. They should not be derived from the size (span) of the data. For example say that I have a 1 degree DTED2 cell. These cells span a square of one degree by one degree and elevations are defined at 1 second intervals. Therefore each DTED2 cell has 3601 x 3601 elevations in it. The Source section of the INF will be:[source]...Lat = 33Lon = -18NumOfCellsPerLine = 3601NumOfLines = 3601CellXdimensionDeg = 0.0002777777777CellYdimensionDeg = 0.0002777777777 whereCellXdimensionDeg = 1 / 3600 <<< eg 1 second!CellYdimensionDeg = 1 / 3600 <<< eg 1 second!Say that I "crop" the upper left corner of this 1 degree cell so that I end up with 1801 x 1801 data points spaning N33 up to N32.5 and W18 up to W17.5. For this new data file the INF would be:[source]...Lat = 33Lon = -18NumOfCellsPerLine = 1801NumOfLines = 1801CellXdimensionDeg = 0.0002777777777CellYdimensionDeg = 0.0002777777777 Of course that I do not use UseSourceDimensions in the Destination section. I prefer to precisely specify the boundaries of the LODs quadrants that I am interested in.Regards, Luis

[rhumbaflappy 113]

Hi Luis, and all.What I've been doing for the last few hours completely backs what Christian Stock had noted quite a while ago.The Landclass BGL is a grid of 257x257.Further, the grid is verticies... not cells!I had wondered why I could never create a photoreal BGL that had just one texture. My attempts were always uncontroled. The tile I wanted was displayed... but often surrounded by blanks, where additional custom textures had to go.I wondered why I could never get one tile. Now I know why. If the grid is verticies, then the singular vertex I chose with my sourcefile, must have textures to the NW, NE, SE, and SW.A problem proving this would have been the 'blending', done by the terrain engine with default textures.Now that I can find the names of CUSTOM textures, and add them to a landclass BGL by using value #253, I can see the verticies must be surrounded by textures.If I place a #253 at 0,0 ( NW corner ) in a 257X257 source, the only texture showing should be the SW, as the other textures are outside the LOD5 enclosureSimilarly, I should be able to show apprpriately named texture in each corner of the LOD5 enclosure.Finally, the center is actually the central vertex, and 4 tiles must surround a single vertex chosen as value #253, and this proves to be true.Here's the INF I used with the 257x257 source:{Destination}DestDir = "."DestBaseFileName = "HomeCustomLC257"; SampleIsCentered=1UseSourceDimensions = 1{Source}Type = ClassU8SourceDir ="."SourceFile = "Home257.raw"Lon = -90Lat = 45NumOfCellsPerLine = 257NumOfLines = 257; 256 spanCellXdimensionDeg=0.0146484375CellYdimensionDeg=0.010986328125Dick

[rhumbaflappy 113]

One last example.A sand deseert default texture on the center vertex ( 128, 128 ) of a 257x257 source, shows the blending in of the 4 surrounding textures.So we may think of each tile as the blending of the values of the 4 enclosing verticies... 256x256 ground tiles defined by 257x267 verticies.Dick

[Guest christian]

dick and luis,luis, I have been doing all these experiments you suggested months ago, and also used a hexeditor, exactly like dick has now. If you're still not convinced, why don't you try it yourself with an hexeditor?dick, I tried your inf yesterday, and was really confused why you got 256. I see, you found the path to wisdom and eternal life now :-lolCheers, Christian