CellShow

[rhumbaflappy 113]

Hi all.I'm working on a tool to help us with a TDF visual reference to the LOD13 Areas within an LOD8 Cell. It will allow us to quickly make a reference grid BGL to place in a project folder. Ideally, we'll need to give a correct Latitude and Longitude, and the program will build a BGLC code text file, to drag'n'drop on BGLC... We'll see.I can do it manually, quite easily.It will help with screenshots used for reference, and help with the placement of Landclass, waterclass, polys, lines, LWMs....Dick

[rhumbaflappy 113]

Hi All.It wasn't that hard to do it in BGLC!Here's the only coding you'll need:include Cell_Grid.incCellDefine 192, 127That's it... save as '192_127_Grid.txt' and Drag'n'Drop onto the bglc icon. Simple.It requires a project folder, with a 'scenery' sub-folder and a 'texture' sub-folder.I'll enclose 'LOD8define.bmp' in the texture sub-folder... a single 87KB bitmap for the lines and numbers.In the Project folder, I'll enclose 'TDFHeaders.inc', 'TDFMacros.inc', 'Cell_grid.inc', and a sample code ( like the above ) to make BGLs.BGLC.exe is required to be placed in the project folder with the code and the INC files. Add the Project folder ( 'CellGrids' ) to the Scenery Library, and activate. ( When adding or deleting BGLS to this folder, take a second and delete it's 'Scenery.dat' file, to ensure the scenery loads properly... standard practice ).I'll enclose my 'TDFCalc2' and 'LandCalc' tools.I should be able to upload it tomorrow.2 pics...a dusty takeoff from a VTP1 Layer 9 skinny poly over water!Approaching a new Cell... note the Green line marking the Cell borders. 2 separate BGLs. Lines and numbers cling to the mesh.Dick

[Guest Simpit]

You read my mind!I was wondering whether this was possible, but I was thinking of a graphical representation within a separate program, not from within FS itself! Of course that program would have had to read the bgls, etc...This is going to be really neat!Derek

[rhumbaflappy 113]

Hi Derek.We're just scratching the surface of what we can, and cannot do.Here's a pic of something I thought not possible... an autogen sprouting up through a VTP Method1 polygon! The autogen is built by the default ground tile.Dick

[LuisFelizTirado 33]

Fabulous, Dick! And extremely useful. Will we be able to get the entire identifying number of the grid, or just the last digits?Best regards.Luis

[rhumbaflappy 113]

Hi Luis.TDFCalc2, included with the package, will give all the necessary locational information for a given Latitude, Longitude.But, I've found a visual reference, within the sim, of great value, for visualization, verification, screenshots...So a very small TXT file can be created, simply giving the Cell ( LOD8 ) coordinates, and compiled by BGLC to produce the reference grid within the sim. The Grid covers the LOD8 Cell, and marks exactly the LOD13 Area bounds ( and gives the LOD13 Area co-ords).A topdown screenshot of any of the LOD13 Area squares can be selected in a paint program, pasted as a new picture, resized to 256x256. It then gives you, within a paint program, the coords needed to place LWM and VTP polygons, exactly within an LOD13 Area.Here's a topdown Screenshot, and a resized 256x256 Lod13 Area, ready for analysis and rework.Dick

[rhumbaflappy 113]

CellGrid.zip is uploaded to the AVSIM Library.

[Guest]

Hi DickUsing your CellGrid files I compiled the bgl and took this screenshot (see attached jpg image) of an area near Anchorage,AK. Within the center 4 LOD13 areas that you see here I'm wanting to create a lake area onto hand painted textures and from what I understand so far each LOD13 will require a 256x256 bitmap image.Although I haven't been successful to this point to accomplish this it's looking to me to be a lost cause because my images will be a square but FS is going to stretch&squeez each image out of perportion. Am I correct in assuming this? And if so, is the reason because of the 4.8 meter per pixel squares are also out of perportion?Thanks for any helpKen

[rhumbaflappy 113]

Hi Ken.As you approach the poles, the width ( Longitude ) of the LOD13 areas becomes skinnier, while the height ( Latitude ) remains the same. That's why there is this distortion. The 'Sample Size in Meters' is about 4.8 x 4.8 at the equator only.If you were to create a photoreal texture for this area, resample would also "skinny it up".A VTP polygon would also "skinny it up".So if you want to display your textures as a CUSTOM or VTP polygon, the result is an automatic sizing to the LOD13 area. If your custom textures are derived from an aerial photo, those photos are usually presized to some sort of latitude/longitude set ( 1* x 1*... or whatever ). So your photo should have already been stretched out of it's actual shape by the government technician's resizing of the original photo ( to make it square, when longitude isn't at those latitudes ). You should just be stretching it back to it's actual shape!To place lakes on the LOD13 Areas, take a screenshot, and make a bmp. Copy the rectangular LOD13 area, and paste as a new image. Resize this new image to 256x256, and you now can get the x, y coordinates you want, for LWM water. ( A trick is to paint a blue area for the lake right on the screenshot bitmap... then you'll have the exact shape of the LWM polys when you resize the LOD13 Area to 256x256 ).Dick

[Guest]

Thanks for the excellent and quick response Dick. I caused my own confusion by thinking I'd have to mathamaticly create the out of perportion lake area in the first place but your explaination made it much simpler than that. Thanks awesomely!!!I do have one other question though. Will my source images need to be 257x257 pixels?Thanks again bro!!!Ken

[rhumbaflappy 113]

Hi Ken.I'm not sure what you mean by source images.Aerial photos for use with Microsoft's Resample, can be any size, as Resample creates custom textures that are 256x256, with the resizing controlled by the INF file.Aerial photos you wish to resize and slice youself follow the same idea... but your resultant slices must be resized to 256x256, to display as a CUSTOM LandClass texture, or as a VTP polygon ( fan ) source BMP... not exactly sure about VTP1 polys, but why not assume the standard as a 256x256 BMP?All LWMs use a 256x256 grid ( 0-255, inclusive ).All VTP1s reside in the same 256x256 grid. All VTP2s reside anywhere in an LOD8 Cell, but their exclusion property ( if used ) seems to confine itself to the LOD13 Areas it uses... so it is somewhat tied to a 256x256 grid system.------------------------------------------------------The 257x257 grid is what the "destination" of Resample.exe becomes with CUSTOM and LandClass, and seems to refer to the verticies... not the size of resultant bitmaps ( slices ), which are created as 256x256. If you use the size of 257x257 in the "source" of a LandClass INF file ( with the traditional size in CellDegDimensions ) the resultant TMF will leave your 257x257 array unresampled... passing it through as you designed it... ( if it's 256x256 it will resample it!).------------------------------------------------------Even though the array of Landclass or CUSTOM verticies is 257x257, the visual display is a grid of 256x256 LOD13 Areas... same as LWMs and VTPs.------------------------------------------------------An LOD5 Landclass ( and CUSTOM ) Group has 256x256 LOD13 Areas that FS2002 will build as groundtiles at run-time, as derived from the BGL info which defined the class of the verticies. Water texture assignment does not blend ( and is best avoided... use LWMs ).CUSTOM assignments do not blend, but also override other blending... so one vertex asigned as CUSTOM will influence the 4 groundtiles it touches... and force all four to use CUSTOM textures.Edges of the LandClass BGL do not blend with the underlying Landclass... so use #254 transparent along the edges of your 257x257 LOD5 LandClass source to force blending!------------------------------------------------------An LOD8 cell has 32x32 ( 1024 ) LOD13 Areas for use with LWMs or VTPs...and also has 32x32 LandClass runtime-generated, blended groundtiles...and also has spots for 32x32 CUSTOM textures ( made from Resample.exe... or made by you... unblended ).And Each LOD13 Area has 256x256 points ( which are actually tiny cells, 4.8 meters square at the equator ). Which is why your Bitmaps will utimately need to be 256x256. Those 'tiny cells' are totally defined and encompassed by an array of 257x257 verticies. Just as one cell has 4 unique corners, and a 2x2 cluster of cells have 9 corners ( because some are shared ), just as a cluster of 4x4 ( 16 total cells ) are defined by 25 corners ( 5x5 verticies )... and so on until 256x256 cells share 257x257 distinct corners ( verticies ).Dick

[Guest]

Super thanks again Dick. 256 squares sources is what they will be. It'll take some time for me to work this out because of other priorities but I'll certainly let you know how it goes.Have an excellent weekend!!Ken

[rhumbaflappy 113]

Hi Ken.Thanks... you have a good one, too.The complexity of what the terrain engine is doing is amazing.The world has 6144 LOD5 Groups ( 96x64 )... defined by land and water classes.The world has 393216 LOD8 Cells ( 768x512 )... that may contain TDF data... LWM masks, and flattens, or VTP2 polys/lines ( VTP1 isn't native to the FS2002 BGLs, but we can make it ).The world has 402,653,184 LOD13 Areas... separate groundtiles, watertiles, LWM or VTP1 Areas.The world has 26,388,279,066,624 LOD17 Points... each 4.8 meters span squared ( equartorial span ). ( We can define any one of these points! )And ( I think ) each point can be one of 16,777,216 colors, and have attributes of either land or water....So to have the world already in memory... or on a harddrive... you'd need about 110,000,000,000,000 byte of memory ( 110,000 gigabytes ? ).This is why MS decided to build the groundtiles at run-time.Dick

[Guest vlada stoje]

Hi Dick,the size of the LOD13 pixel is about 6.4 x 4.8 m on the equator. On the latitude "lat" the pixel size iscos(lat)*6.4 x 4.8 m. So the optimum isotropic grid with squares is on the parallel 41.4 (=arccos(90/120), where is maybe the majority of airports and also there lives the majority of the fs pilots

[rhumbaflappy 113]

Hi Vlada.Good to hear from you!I just assumed the TDF Point size was 4.8m squared at the equator... never tried to measure it.Lets see...the FS2000 scenery SDK states the earth is 40075000 meters at the equator. 768 LOD8s times 32 ( to derive the LOD13s ) times 256 ( Points ) equals 6291456 Points in each longitudinal circumference of the earth.40075000 / 6291456 = 6.3697497049967447916666666666667 ( about 6.37 )meters span longitudinally ( at the equator ).You're right!Latitude?40007000 meters circumference divided by 2 ( we ony want pole to pole... not all the way around ) = 20003500 meters pole to pole. 512 LOD8s times 32 ( to get LOD13s ) times 256 ( Points ) equals 4194304 Points pole to pole.20003500 / 4194304 = 4.76920604705810546875 ( about 4.77 ) meters span latitudinally ( everywhere ).-------------------------------The point I made to Ken, was that it seems many sources of aerial imagery have already been 'squared' or 'rectangularized' in order to display a certain size in degrees ( or minutes ), not as actual meters. That makes the picture look good, but actually distorted, as the world ( and FS2002 ) is not square. FS will rebuild the proper shape when it displays ( at least as 'proper' as we can expect ), so we don't need to worry how a square slice from Resample gets 'skinny' as it approaches the poles. That square slice from resample is in fractions of degrees... not meters or feet. We do have problems with the Data images. I think Misho Katulic had some problems recently with aligning some scenery. My guess was that the image needed 2-way sizing to known coordinates ( both latitudinally and longitudinally ). Then if the area is small, and the data not too distorted, the alignment will be OK... never perfect, but usable. I think Misho may have been doing Crater Lake, and the image displayed off by 100 meters one way and 200 meters the other. Was it the image, or mesh, or the sim? Probably all three! ;)Which reminds me of discussions of the location and height of default runways in FS2002. Are they accurate? Probably not... but usable... and etched in stone for mesh and scenery designers.Dick