Old resample INF for CUSTOM

[rhumbaflappy 113]

Hi all.The old and new resample programs give greatly different results.Regarding CUSTOM ( photoreal ), the new resample's BGL actually behaves better than the old version, placing the textures as expected... but the sliced bitmaps are terrible. And there is the dreaded black borders to deal with. So we need to use the old resample for photoreal. ( I've gone ahead and renamed mine 'oldresample.exe'. )Assuming an LOD13 Area needs a texture of 256x256, it makes sense to fit and trim our source bitmap to a multiple of 256. Andrew McLean noted a year ago that the maximum bitmap size the old resample takes is 2560x2560... I don't know if the newer version has this constraint. By presizing/trimming our master bitmap, we know what we'll be getting as slices. Besides, we already need to color the masters for each season, so they should be correctly sized and trimmed first.I also noted that we must have at least a 2x2 LOD13 Area, so our range for presized-trimmed bitmaps is 512x512 to 2560x2560, covering 2 to 10 LOD13's latitudinally and longitudinally... resulting in anywhere from 4 to 100 slices. I haven't used tmfmerge.exe, but it should join TMFs just fine ( I'm not even sure the joined TMFs need to be adjoining ). Also, a landclass BGL can be made to replace several CUSTOM BGLs, by using the value #254 for transparent, and #252 for seasonal texture use. The area doesn't need to be square, but a rectangle at a multiple of 256.A problem with the old resample, is that it doesn't behave well regarding the BGL. The sliced bitmaps look alright ( not like the blurred mess of the new resample ). But the source bounds need to be slightly larger than the actual area covered, in order to give us a good BGL, and the right number of slices. But, if we make the bounds too large, a good part of our source bitmap will be discarded... and our slices will be 'off' in their accuracy. I've noted that problem with TerraBuilder.Consider this INF, for NiagaraWithSeasons:;[Destination]DestDir = "."DestBaseFileName = "NiagaraWithSeasons"WithSeasons = 1UseSourceDimensions = 1[source]Type = CustomSourceDir = "."SourceFile = "niagara_falls_su.bmp"Lat = 43.099422679227941176470588235294Lon = -79.086957146139705882352941176471; LAT = (43.099365234375 + ( 1 * ( 0.0146484375 / 255 ))) = 43.099422679227941176470588235294; LON = ( -79.0869140625 - ( 1 * ( 0.010986328125 / 255 ))) = -79.086957146139705882352941176471NumOfCellsPerLine = 768NumOfLines = 1024CellXdimensionDeg = 5.7444852941176470588235294117647e-5CellYdimensionDeg = 4.3083639705882352941176470588235e-5; CellXdimensionDeg = (((0.0146484375 / 255 * 256) * 3) / 768) = 5.7444852941176470588235294117647e-5; CellYdimensionDeg = (((0.010986328125 / 255 * 256) * 4) / 1024) = 4.3083639705882352941176470588235e-5; Each LOD13 Area to be displayed is already sized to a 256x256 matrix.What I sneakily do here is to add slightly less than 1 LOD13 Point to the North and West Bounds. The NW corner is now slightly outsized. I then adjust the CelldimensionDegrees to slightly oversize them. I take the LOD13 size, divide by 255 and multiply by 256 to oversize the source for each LOD13 area. I then multiply by the number of LOD13 areas it will span... 3 for X, and 4 for Y.I left the numbers for the Cells and Lines alone, as both resamples need this to be accurate.The result is a perfect 3x4 LOD13 fit and 12 samples produced without distortion by the old resample. The slices look fine, with minimal distortion.If the above formulas seem too hard to digest, Microsoft's calc.exe can digest a parenthetical expression, "()". You can use 'CRTL-c' to copy and 'CRTL-v' to paste in and out of that utility. calc.exe is found in either "windowssystem" or "windowssystem32'.Dick2 pics. First is a topdown showing a well blended fit of the textures to the default landclass ( good job, Microsoft ). Second is the telltale lack of shoreline with the new textures... fits well.Using this method with the old resample seems to put everything 'on the money'.

[LuisFelizTirado 33]

You make some very good points, as usual, Dick.These are issues that, I believe, many of us have wondered about, but not been able to completely understand.What we need is some kind of utility that will completely bypass resample.exe and calculate the proper bounds, create a bgl, slice the image correctly without distorting it, and rename the slices according to the convention.All with a very easy to use interface. Only then, will we start to see a lot of custom scenery.If it could also integrate the VPT methods and even water classes, all the better.Best regards.Luis

[rhumbaflappy 113]

Hi Luis.VTP Method1 can place a slice perfectly. The layer number of 32 can replace the major roads, and overlay everthing else. That still leaves layers 33-63 for adding shorelines, etc..., within the LOD13 Area.You don't want an alpha for the water, as this will be transparent with VTP1's. Instead, you'd need to make an LWM watermask for an water area.If you want to place a customized texture over the LandClass, but under everthing else, use Layers 4-7, and the default shores, roads, water... will show over your texture.The drawback? I don't think an autogen will show over a VTP1, unless the VTP1 uses one of the landclass numbers as a texture.If someone has a small area, it should be possible to recreate a photoreal effect with smaller, oddly shaped VTP1s... as if you cut'n'paste polys cut from landclass textures. Then autogen and seasons will be automatic.Lots of possiblities, but also lots of 'hand coding'. As you say, without the right interface, it won't happen, as too many designers are put off by BGLC.Dick

[Guest luissa]

Dear Dick,You can have bitmaps greater than 2560 x 2560. This is true with the old_resample and I think that it is also true with the new_resample. I am working with bitmaps as large as 7XXX (7 thousand) by 5XXX. The bitmaps are preajusted to the final 5m/pixel resolution and matched to the mesh. Here is an island created from such a bitamp:http://www.ptsim.com/madeira/madeira1a.jpgI have no problem at all in specifying destination regions for mesh, landclass or custom (photo) scenery. I normally use a large bitmap (for the custom scenery) and create several INFs with an identical Source Section. In each INF I declare a unique Destination Zone. This destination Zone can even be a single LOD13. Instead of UseSourceDimensions=1 I enter the 4 borders for my Destination Zone. I explain the algorithm that I use to specify the borders of, say, LOD13(200, -250). I am using these numbers as I have not with me, at the time of writing, the Excel files that I use. I am using the numbers just for the propose of explanation. The specified LOD13 quad is in the 200th row (to the north from the equator) of LOD13 cells and in the 250th column (to the west from Longitude=0). Therefore this particular LOD13 cell has the following borders:NLat = 200 * 90 / ( 2 ^ 13 )SLat = 199 * 90 / ( 2 ^ 13 )WLong = -250 * 120 / ( 2 ^13 )ELong = -249 * 120 / ( 2 ^13 )For proper OLD_RESAMPLE operation I enter the mid coordinates of the adjacent-outer LOD13 instead of the shown values. That is:NLat = 200 * 90 / ( 2 ^ 13 ) + 90 / ( 2 ^ 14 )SLat = 199 * 90 / ( 2 ^ 13 ) - 90 / ( 2 ^ 14 )WLong = -250 * 120 / ( 2 ^13 ) - 120 / ( 2 ^ 14 )ELong = -249 * 120 / ( 2 ^13 ) + 120 / ( 2 ^ 14 )This never fails with the OLD_RESAMPLE. I think that the NEW_RESAMPLE would try to generate data for the adjacent LODs.One final comment on the possibility of generating an INF with a single LOD13 - I do not know if, in this case, the TMF is a valid one. I learned from you that I can generate the CUSTOM scenery BGL as if it was a LANDCLASS scenery BGL. So I am able to produce scatered areas. I simply delete the TMFs that the INFs generate as I do not need them. Kind Regards,Luis

[rhumbaflappy 113]

Hi Luis.The scenery is beautiful!I assumed Andrew's bitmap size information was correct, but maybe it was a limitiation of his computer.I don't know if you are familiar with Misho's latest Terrabuilder. I was disturbed to find that the Niagara bitmap was 'trimmed' by Misho's program, when, in fact, it needed no trimming. The Masters were designed to fit a 3x4 LOD grid perfectly.Some people may be misled by the '4.8 meter' or '5 meter' sizing.All textures will be 256x256 pixels, and all will cover 1 LOD13 Area. Vlada Stoje pointed out to me the longitudinal width of an LOD13 Area Point is actuall 6.4 meters at the equator, and greatly narrower than 4.8 meters near the poles. But they are all 0.0146484375* longitude and 0.010986328125* latitude.If you start with a master that is already sized and trimmed so that each 256x256 multiple represents a multiple of those degree fractions, then the Master doesn't need resizing by resampler... just slicing. If someone were to use a landclass BGL, then the slicing could be done by a paint program, or a dedicated 'slicer' program, and all resampling could be avoided, with resampler used to create the landclass BGL. My TDFCalc program gives the needed Texture names.Ideally, I'd like to see a program that will slice and properly name textures, then produce a BGL, without butchering the sizing or quality of the master bitmaps. ------------------------------Actually, it's called resample... the old resample. :)If the INF is created my way, and the textures are multiples of 256X256, and exactly fill the intended LOD13 Areas, it works really well. No odd pieces of the master left unused. No weird resizing or trimming of bitmaps that were already sized right. It has occured to me that the Master bitmap might better be a multiple of 256x256 + 1 ( an extra row and column for the master... probably to the North and West). An example would be 769x1025... an extra pixel for the old resample to chew on... then use:; CellXdimensionDeg = (0.0146484375 * 3) / 769 ; CellYdimensionDeg = (0.010986328125 * 4) / 1025... where 3 is the longitudinal span of LOD13 Areas, and 4 is the span of latitudinal LOD13 Areas.In a paint program, trim the bitmap to equal an exact LOD13 multiple, then resize to the multiple span, plus an extra pixel.But I'm getting good results right now.----------------------------------As far as using landclass BGLs,if the the number of landclass groundtiles to cover was 512x512 ( 4 LOD5s ), then the LC source would need to be 513x513 ( always 1 more vertex than the enclosed tiles). And the textures needed to be displayed as groundtiles would still be 256x256 and must still span 0.0146484375* longitude by 0.010986328125* latitude. Christian Stock had been researching the landclass structure, but he is pretty much done with it, as he has other non-FS projects going. I don't think I'll get into it anymore than I have. But if someone is willing to spend the time with a hex editor, and uncompresssed landclass TMFs, he might find out the BGLC structures needed to bypass resample.exe entirely. I can take a 257x257 landclass source, and make an uncompresed landclass TMF.. then extract the original data unchanged from the TMF ( no resizing.. so no distortion ), each assignment where I placed it ( on the verticies! ).The scenery is beautiful!Dick

[Guest]

Dick, I see that the source limit error made here has been corrected. That one was researched long ago, why the original statement was made...who knows...simply not true.The continued discussion on the trimming source file to a set number of 256x256 eludes me...what's the point? I never do this, and don't plan to start.What matters to me is that the point of overlap of the lOD13 grid is identified. I WANT overlap, as it relieves me with any obligation to identify the boundary precise to the pixel. A bit of slop at the edges suits me fine, and I can work a bit more quickly.B

[rhumbaflappy 113]

Hi Bob.Everybody has been assuming we should resize to 4.8 meters/pixel, when in fact a pixel should be a span of ( 0.0146484375 / 256 )longitudinally and ( 0.010986328125 / 256 ) latitudinally! The Width is better than 6 meters at the equator and skinnys to 0 at the poles. Height remains the same.So if we resize to maintain exactly a multiple of 256 Pixels for every complete LOD13 Span, then there won't be any resizing of the slices from the master bitmap... so there should be no errors of placement ( unless they are errors from the aerial image's processing ).The INF I used did give an overlap of about 1 pixel all around. The formulas are exact, and the only thing needed to change is the number of LOD13 Areas to grid. If it's 3x4 Areas, then we need a bitmap of 768x1024... 4x4 Areas would get a bitmap of 1024x1024. ( And the formulas for CelldimensionDeg would need the 3 and 4 plugged into the appropriate spots.) We'd need to find the bounds of an aerial image, trim it to an exact multiple of LOD13 Areas, resize it to the correct multiple of 256x256, make copies, color for seasons, and resample the masters. All with no guesswork as to what the final bitmaps will look like. To cheat even further, as the master is already scaled to the proper texture sizing, you could make a collection of 256x256 bitmaps from the default landclass textures, and use those to 'color' your masters. Because everything's already sized correctly, they should blend-in pretty good.No need to worry how things will blend-in or line up. No Mount St. Helen off by 300 meters. It will be 'on the money', if your source aerial is 'on the money'.Otherwise you're at the mercy of resample, and it will stretch, and blur, and misposition.I think this is exactly how Microsoft does their 'photoreals'. They are aerials that are trimmed, resized, and stamped with snippets of textures to build the master over the aerial 'template'.Dick

[Guest luissa]

>The continued discussion on the trimming source file to a >set number of 256x256 eludes me...what's the point? I never >do this, and don't plan to start. Dear Bob,An island is a simple example where we need to trim the source file to the mesh. Otherwise you can have things like water climbing over cliffs. In cases like these I take a "picture of the mesh" with TMFViewer. If the mesh is, say LOD10, then I resize the "picture of the mesh" to LOD13, eg, amplify it 8 times in both directions.On the other hand I resize my master bitmap to 4,8m/pixel. Then, using a paint program and 2 layers, I adjust (this often envolves small distortions) the master bitmap to exactly match the "picture of the mesh".Kind Regards,Luis

[John_Cillis 2,406]

"then the LC source would need to be 513x513 ( always 1 more vertex than the enclosed tiles)."With Landclass Assistant and the .inf file I created for it June, I've had good results with a 256x256 .raw source (which is easier to work with from a programming standpoint). When I calculate the X/Y cell dimensions, I simply divide the factors by 255 (256-1),Internally, I've tweaked Landclass Assistant since June to calculate texture placement with as much accuracy as possible. My next public release will include those tweaks...Based on the results LCA users have had with the new .inf and the .raw files, I'll continue to use the 256x256 format along with the .inf file. I'm also sticking with the older version of resample as the "supported" one.-John

[rhumbaflappy 113]

Hi Luis & Bob.My idea for pre-sizing the master bitmap is similar to Luis'. Instead of trying to match the mesh, I try to trim to the LOD13 bounds, then size it to a multiple of 256x256. That gives me the exact image size that will appear as the CUSTOM texture. In fact, you could then discard resamples slices, and just slice the master yourself ( and name them properly ).Just about all aerial sources give a bounds ( metadata? )... so after stitching together the original images, you should have the data needed to trim to the LOD13 Areas, rather than letting resample do it's usually erratic job.A further thought on resizing to 4.8 meters. It only works N-S direction, as that never changes. The W-E size is a factor of the latitude. It would be more accurate to size to the LOD13 bounds; the pixel trimming positions derived mathematically from the metadata.-----------------------------With some more thinking on VTP1 polys used for ground design:VTP1 deals only with the LOD13 Area. If a trimmed aerial were used as a template, you could paste the polys into the LOD13 Area with landclass values. Instead of coloring the photoreal, you use the VTP1 to color the sim directly. Layer 8 polys act exactly as land. So a 'clean slate' of an LWM watermask 1x1 areafill could give an underlying water, then the layer 8+ VTP1's could 'paint' landclass values as ground. They'd have autogen and seasons automatically, so you'd only have to 'paint' one 'master'. Roads and shorelines could be added if needed ( though the layers might need to be changed ), so effects would also be possible on the psuedo-photoreal.I'm starting to sound like a landscape designer. :)Dick

[Guest]

I can see the points made here, but for folks that are centering their focus on an airport, as I do, then the georeference that counts most is the "scar" on the photo for the runway, and the runway. Thus, I establish my cellxdim, cellydim numbers using the ends of the runway (which have pretty good geographic lat/long positions supplied), and the runway length, again pretty will defined. Doing this, I leave the edges as an overlap so that I'm sure they fill the farthest lod13 grid I desire.I agree that matching the mesh matters, which is more about assuring that the depiction of the alpha channel matches the mesh, but that can be a custom edit rather than something that drives how you size your image slices, right? Perhaps I'm missing something.Dick, I do agree with your logic about image resolution. Msoft put the 4.8m/pixel on their fs2000 sdk, for lod13, and I never questioned it. I'm sure my local is pretty close to 4.8, but surely I'll have the best images if I dermine that value more precisely.Cheers,B

[Guest]

dick the usgs doqq metadata is based off of hash marks that only appear with purchased versions of the images. The actual images are intentionally cropped with a generous overlap. I've found nothing exact about edge georeferencing off of these images, whether from the direct usgs sites or from terraserver. If I try to use my best effort at such a process, invariably my runway doesn't sit right on its "scar". After I started using the process as I wrote above, the runways ALWAYS sit perfectly.B

[Guest]

Hi Luis, I understand...the part that was confusing me was why bother attempting to precisely specifiy the georeference of the edge of the master, it just seems so hard, but I'm beginning to see that Dick has something up his sleeve. As far as the work you are doing, its essentially going to end up being some artistry no matter how you slice it...right? Its about custom edits of the alpha channel to put the water in the right spot, and fill in with the image above..right? At least that's how I do it.Cheers,B

[rhumbaflappy 113]

Hi Bob.The resizing should go well as you do it. It could go even better if you have 3 airfields in the bitmaps to 'triangulate' the sizing, because the runway data is there for us.The only difference I think we have, is that you'd let resample 'trim the fat' off the master image. I'm suggesting a tighter control by trimming to the LOD13 bounds, before resample wreaks havoc with our bitmaps.I think we can all agree with John Cillis... the new resample.exe is bad news for photoreal. I think Christian Stock also found some 'crippling' of features in the newer version, regarding waterclass, seasons, and regions.I wonder if anyone has done mesh with the new resampler, and does the mesh have an equivalent of the 'black borders' of photoreal? And is the BGL bounds header corrected for the western hemisphere?---------------------------As far as the 'sleeve'...We have some problems with CUSTOM bgls. Even if we derive the BGL from a LandClass, there are the textures... hundreds of 'em. And then we try to blend them into the sim so they don't stick out like a sore thumb. And we need to color them... for each season... and nights.VTP1s and VTP2s could be used with no texture overhead, with automatic seasons and autogen. We could use a tool to help with this.Actually, there is something in the works, along these lines. Not by me, but it will be an elegantly simple and effective tool to use when it's ready.Dick