Mesh LOD and NW Boundary

[Guest Stormshadow]

Evening all,I'm still not convinced about the mesh procedure albeit getting the mesh correctly positioned in FS....and the parameter which is I've yet to digest well is the north west coordinate.So in the info file we have to supply a level of detail which in my view determines the distance between sample points. The higher the LOD the higher the resolution. Fine.Why then is the NW coordinate the actual NW coordinate of an LODXX cell/area? Should it not be the NW in FS which represents the NW coordinate of your mesh DEM, or rather the start of the DEM data (top-left most point)? I hope you understand what I'm trying to suggest :)Storm

[Guest Stormshadow]

See what I cannot yet understand, and I wish some1 could be crystal clear on this, is the difference between LOD as resolution (the distance between sample points if you may), and and LOD cell, or rather when we speak about the "NW coordinate of your LOD boundary" - LOD calculator does that, finds the NW coordinate of say LOD12 - Shouldn't LOD be just a resolution parameter??Another question:If you set LOD = AUTO right,how can you caluclate the NW coordinate of your freakin LOD boundary when you don't even know what the LOD is!!!??Storm

[Guest sgreenwood]

Hi Storm,I'm sure this is not crystal clear, but it may help to adjust your perspective. Your situation is quite unusual in the amount of detail you have to attend to, assuming you are still working with the same single quadrant block of data. Normally we start with simpler tasks so we can absorb the more general principles involved in a forgiving environment, then move on to more challenging tasks requiring a better understanding of the details, but building on a sound conceptual model. Your project requires that you accomplish all of this in one step and that is not easy, so don't be too discouraged!>Why then is the NW coordinate the actual NW coordinate of an LODXX cell/area? This is not required and is generally not the case. (Your situation is an exception!)>Should it not be the NW in FS which represents the NW coordinate of your mesh>DEM, or rather the start of the DEM data (top-left most point)?Consider the more general case first.The NW values in the Destination section of your inf file are used to position your data in the FS world. You can use these coordinates to position a set of elevation points anywhere, although we normally want to place them in the same location as the one they represent in the real world.Resample interprets these values as the coordinates of the NW elevation post in the DEM dataset you are processing. (Your source data.)In effect, it uses this value as a starting point for creating an entirely new set of elevation posts with the spacing defined by your LOD, aligned with the LOD quadrant grid for that LOD. It then discards all the new data points that are not part of a full LOD quadrant. So the NW corner of your mesh will lie at the NW corner of the nearest full LOD quadrant created by Resample, not (usually) at the NW location specified in the inf file.The LOD value you choose determines the grid size and the locations of data points in that grid and hence the NW corner of the final mesh. This approach allows people to begin constructing mesh without any real understanding of LOD quadrants and none of the messy calculations you are doing. Resample handles all the details and they just get a little less coverage than they expect, and probably never notice it.And is allows us to construct mesh from the same (large set of) source data using several LOD levels, although the coverage will vary with LOD.But considerable care is necessary when you are using only enough data points to cover exactly one quadrant at one LOD. Then you must be certain that the NW corner of your source data (specified in the inf) lies exactly on the NW corner of the LOD quadrant where it is to be rendered in the sim. You have no wiggle room here at all. Spacing must also be exact. This is further complicated by the issue of precision in the number of decimal places used in the Resample calculations, as you have seen. (Fortunately, coordinates stored in the finished bgl file header seem to have at least one more decimal place than Resample displays in the DOS window.)>Shouldn't LOD be just a resolution parameter??It is, but it also determines precisely where the points will be positioned in the mesh.>If you set LOD = AUTO right, how can you caluclate the NW coordinate>of your freakin LOD boundary when you don't even know what the LOD >is!!!??You are getting close! You can't, and normally you don't need to. Most mesh is constructed without ever worrying about the calculations you are dealing with because the source data covers a much larger area and the relatively small amout trimmed off the borders by Resample are not important.LOD coverage does become more important when you are trying to create multiple mesh files which completely cover larger areas. This is often the next step along the learning curve for beginners. I often see large gaps in the coverage of mesh created without taking this into account. A final check with TmfViewer can help prevent these gaps.Steve

[Guest Stormshadow]

Phew Steve! You made my head spin!!Cheers for the explanation! Sorry if I bored you out m8, I'm simply one of those lads who prefers understanding 90% of things together with experimenting rather than doing it blindfolded. >> My situation is an exception? In what way am I exceptional :) ?>> Ok Steve, let's take if from here (if I've sickened you out ignore me :)) )The following is taken from the FS2002 SDK[Destination]LOD = AutoDestBaseFileName = "rainier"UseSourceDimensions = 1[source]Type = ElevS16LSBSourceDir = "x:dem"SourceFile = "dem_100m_mtrainier.dat"Lat = 46.99916666667Lon = -121.9466666667NumOfCellsPerLine = 457NumOfLines = 375CellXdimensionDeg = 0.0008333333333333CellYdimensionDeg = 0.0008333333333332ScaleinMeters = 1.0Question: give me a straightforward answer: how did the author get to the Lat and Lon coordinates? Do these represent the NW coordinate of some LOD cell or just author selected values?CellX... and CellY... should be calculated in accordance with the LOD one is using together with the no. of rows and columns of the raw data image, am I correct? If yes, again, if LOD is unknown, how were these values computed?CheersStorm

[Guest sgreenwood]

>> My situation is an exception? In what way am I exceptional :) ?I am assuming you are still working with the small block of data covering a single LOD quadrant. Most of us start by downloading a large block of data for a large area and don't have to worry about these details in the beginning. The detail required for your mesh is more typical of the level familiar to scenery designers than for us mesh folks.>> Ok Steve, let's take if from here (if I've sickened you out ignore me :)) )OK :)>Question: give me a straightforward answer: how did the author get to the >Lat and Lon coordinates? Do these represent the NW coordinate of some LOD >cell or just author selected values?I don't know. But usually when we download source data, it comes with "metadata" files that describe the data in some detail, including the coordinates of at least one corner of the area covered by the data. That is probably where they got their numbers as well.(There is some confusion here regarding USGS seamless data and the way some software handles the metadata. I'm working on a description of the issue and how it affects MicroDem and Manifold users - coming soon.)I assume you've created your data manually, and so you get to specify where it is in the world, in the inf file.>CellX... and CellY... should be calculated in accordance with the LOD >one is using together with the no. of rows and columns of the raw data>image, am I correct? If yes, again, if LOD is unknown, how were these >values computed?In the general case, they have nothing to do with LOD and the final data. They provide a description of the source data for Resample.Normally, they are calculated by dividing the dimensions (in degrees) of the area covered by 1 less than the number of data points involved. (rows-1 and cols-1, since we are calculating the space BETWEEN the data points)In your case, the area covered is the width/height of one LOD quadrant. Resample uses the NW corner and the cell spacing to determine where the source data points are. This is used to allocate proper weights to the source data elevation values when interpolating to calculate the new values on the LOD grid.Steve

[Guest Stormshadow]

Steve, bare with me - no dem data is available for this minute but fabulous Island so I have to go about it manually using grey images.I've abondoned using 1 LOD13 quadrant/area as I never got bgls compiled, anyones guess why. I reverted to LOD11 and I get fairly decent mesh.Basically what I do is create LOD11 sectors - Take a top-down view of one particular LOD11 area or sector, and superimpose terrain contour data onto this using coastlines as guidelines. I get my grey mpa, convert it to .dem using the nice little tool Grises50 (thumbs up to the author), and compile my info file assigning the NW coordinate calculated through LOD Calculator to the NW parametr in the inf file. Thats the process in a nut shell.Am I correct saying that since I'm using LOD11 resolution, I should get my elevation posts at 19m or so from each other? My grey-level maps are highly detailed - using 5m separation - but I still get tent like mesh and I don't think the mesh is being rendered to the resolution I'm stipulating. (I've given aswell on setting the terrain parameter to 20 or 21 as it too gives me many tent like features). I don't get the 5m and at times 10m contour elevations.That's why I re-started my investigation in the info file. I thought I could leave LOD = 11 together with the NW coordinate as they are and simply change the X and Y values, using the separation of an LOD13 rather than LOD11. Didn't work.Storm

[Guest sgreenwood]

>Steve, bare with me - no dem data is available for this minute but >fabulous Island so I have to go about it manually using grey images.I understand. I have a couple of islands I'd like to model as well and may have to resort to this approach. But I have not tried it yet so bear with me as well.>I've abondoned using 1 LOD13 quadrant/area as I never got bgls compiled,>anyones guess why. I reverted to LOD11 and I get fairly decent mesh.It should work, but the sim can't render that much detail anyway, so 11 is a better choice.It sound like the problem is not the coordinates, if the mesh works and is showing up where you expect it to be.>Am I correct saying that since I'm using LOD11 resolution, I should get>my elevation posts at 19m or so from each other? Yes.>My grey-level maps are highly detailed - using 5m separation - but I still >get tent like mesh and I don't think the mesh is being rendered to the resolution >I'm stipulating. I'm afraid you may be. Resample works with 1m elevation resolution and source data is available in 1m, 1ft and even some at 1cm resolution! While constructing 10m mesh for the almost flat coastal area of New Jersey, I had to deal with adjacent source data quadrants that differed in elevation along the boundary between them. A difference as small as 2m created a small "cliff" extending for miles that was obvious from thousands of feet AGL. On the ground it looked terrible, so I had to spread the transition over a wider area so it was not so obvious. If your elevations are in increments of 5m then you will get very rough terrain, and a higher TMVL value will just emphasize it. I suspect the only way to eliminate the blocky appearance is to use much closer intervals (a lot of work, if you have the information necessary).An alternative is to use a much lower LOD, which will have the reverse effect of using the higher TMVL values. This might be worth trying.This is probably the explanation for the blocky appearance of the photoreal terrain for Spain (ESCENARIO DE LA RIOJA.ZIP), when viewed with higher TMVL values. It looks great with the default value though. You might want to see if you can determine what LOD he used. His readme.txt file does not provide details regarding construction, but:"If you have any question, please tell it to me:Julio Estefan

[Guest Stormshadow]

Cheers Steve,Err, so basically I have to get hold of contour maps which are at 1m resolution - jeez that's gona be tough. The ones I have at the moment show contours separated by 2.5m but I can't use this as Grises50 supports integer values not real (decimal). That's why I'm using a resolution of 5m which is the next best alternative.By the way I tried using a lower LOD - I kept LOD=11, same NW coordinates, but used the Lad Deg Boun and Lon Deg Boun for LOD's smaller than 11 in the formulas for CellXdimensionDeg and CellYdimensionDeg. I got a bgl but the result is that the whole area is pancake flat at some elevation level.Storm