P3D v2 Seeking exact size of LOD - else duplicate agn files!

[Clutch Cargo]

First, just want to say thx for all the great "simmer heads" out there who have provided great feedback to me and community. It helps tremendsouly! So with that let me dive into my latest query.

Issue short-n-sweet:

Autogen files (XXX.agn) I compile sometimes overlap others that are in adjoining areas along their borders. Which in turn wipes out what was previously created along those borders.

So the issue, I thought, appears to be obvious on how to solve. Make sure the areas I work on are an exact match to the size of the typical autogen tile, from what I understand in the P3D (FSX) SDK is about 1.19m/pp.

Now to the nitty gritty. Here is what I have tried:

1. Each area I am working on is a LOD10.
2. I crop some ground photoreal images to match the LOD10 extents.
3. I get the LOD10 extents LAT/LON from the app LOD Extents Calculator
4. So using that size as my "canvas" I create autogen - no issues there.
5. Create 50-60 agn files
6. Move on to the next LOD10 and repeat
7. This time when I create the new agn files the are usually 6-8 that are duplicate files from the previous LOD10 area.
8. After digging in deeper using SBuilderX and zooming in as close as I can, the LOD10 seems to be about 1 maybe 2 pixels off from an exact match. Depending on size it can be one pixel over or one pixel under the LOD10 grid markings. My thought is that one pixel off from the true edge is causing the creation of duplicate agn. files?

But how can I make it exact? Is the LOD Extents calculator not precise to begin with?
Should I multiply the number of 1.19m/pp tiles that fit into an LOD 10? (Not sure how to do that as math and me are not friends, ha!)

Any thoughts, ideas on what to try would be most appreciated.

 

[GHD]

If your photo-textures are in the same folder, it doesn't matter, you can't get duplicate names in the associated texture folder.

 

[rhumbaflappy]

Why not simply discard the offending overlapping AGN files? I also don't understand why you are 'cropping' images. Resample can give precise sizing at the QMID bounds.

Dick

 

[rhumbaflappy]

Here's what I mean:

I turn on the QMID 12 grid in SBuilderX314 and Zoom in as far as I can while still keeping the grin fully onscreen (actually one click more to zoom level 13). I then use File|Add Map|From Background. I can then click the level 16 tile selection to get a good LOD10/QMID12 image.

Here's the INF SBuilderX makes:

[Source]
   Type = BMP
   Layer = Imagery
   SourceDir = "."
   SourceFile = "L16X62144X62231Y50160Y50215.BMP"
   Variation = All
   NullValue = 255,255,255
   SamplingMethod = Gaussian
   ulyMap =  38.8568201347437
   ulxMap = -9.31640625
   xDim =  1.07288360595698E-05
   yDim =  8.36175146955958E-06

[Destination]
   DestDir = "."
   DestBaseFileName = "Photo01"
   DestFileType = BGL
   LOD = Auto
   UseSourceDimensions = 1
   CompressionQuality = 85

I change this to:

[Source]
   Type = BMP
   Layer = Imagery
   SourceDir = "."
   SourceFile = "L16X62144X62231Y50160Y50215.BMP"
   Variation = All
   NullValue = 255,255,255
   SamplingMethod = Gaussian
   ulyMap =  38.8568201347437
   ulxMap = -9.31640625
   xDim =  1.07288360595698E-05
   yDim =  8.36175146955958E-06

[Destination]
   DestDir = "."
   DestBaseFileName = "MyPhoto01"
   DestFileType = BGL
   LOD = Auto
   UseSourceDimensions = 0
   BoundingCell = 12,1457,582
   CompressionQuality = 85

You can get the bounding cell info from LEC or from TMFViewer ( viewing SBuilder's BGL ). If using LEC's info, remember and LOD10 is a QMID 12... also LEC will give 0580, but the INF needs 580.

The above inf needs to get drag'n'dropped on to resample ( which you can copy to the SBuilderX314 Tools\Work folder ), and you'll get a bgl perfectly clipped to the QMIS12 bounds.

Now make sure you don't annotate the scenery over the image edges, and there shouldn't be any overlapping AGN files. If there are, then you have a problem with the annotation, not with the bgl.

Dick

Dick

 

[JRobinson]

That's a neat trick Dick, I didn't know you could do that. However if the end goal is a photoreal that precisely matches an autogen cell in the annotator you'd need to use i.e. BoundingCell = 15,11664,4663 because autogen tiles end at QMID15/LOD13 boundaries rather than QMID12/LOD10.

http://www.cat-tamer.com/flightsim/atchmnts/a_photoreal.zip

Jim

 

[rhumbaflappy]

The QMID bounds are nested like the Russian dolls. QMID 12 is exactly 16 x 16 QMID 15's. I think the OP just wanted to break up his project by exact autogen bounds, but not necessarily just one QMID15. I might be wrong.

There is also a SplitFileLOD = 13 in the Destination, that should split the entire mess into LOD13 chunks, and that will give single autogen-friendly images to work with in the Annotator.

[Source]
   Type = BMP
   Layer = Imagery
   SourceDir = "."
   SourceFile = "L16X62144X62231Y50160Y50215.BMP"
   Variation = All
   NullValue = 255,255,255
   SamplingMethod = Gaussian
   ulyMap =  38.8568201347437
   ulxMap = -9.31640625
   xDim =  1.07288360595698E-05
   yDim =  8.36175146955958E-06

[Destination]
   DestDir = "."
   DestBaseFileName = "MyPhoto01"
   DestFileType = BGL
   LOD = Auto
   UseSourceDimensions = 0
   BoundingCell = 12,1457,582
   SplitFileLOD = 13
   CompressionQuality = 85

And if you have a very large area, you could use MultiSource to combine several sources.

Dick

 

[Clutch Cargo]

Thx for the quick response guys. Let me try to follow-up with your input:

George

“If your photo-textures are in the same folder, it doesn't matter, you can't get duplicate names in the associated texture folder.”

I’m not sure I follow what you are saying. Can you elaborate?



Dick –

“Why not simply discard the offending overlapping AGN files? I also don't understand why you are 'cropping' images. Resample can give precise sizing at the QMID bounds.”

The cropping of images give me a workable size to concentrate on. LOD 10 are huge files to manipulate when you add HD photorea', vector lines, autogen, night lighting, etc. This gives me a the largest manageble size with my PC power. So, my thinking is if I keep everything within the exact borders of the LOD10 I will have no overlapping of work or duplicate files created (talking about the autogen stuff here).

True, that is one “work-around” I may have to use . The issue becomes time and labor. I mentioned I might get 6-8 duplicate files but that is just along one border. And there are three other borders to one area. Now the number increases to 24-32 files I would need to address and decide which holds the most or best autogen. And this will occur 100’s of times. So not the best option for me but still an option if all else fails.

On your second part I think I see what you mean – sounds like I can get more accurate if I apply your method. Which I will look into when I get home from work.




Jim –

“However if the end goal is a photoreal that precisely matches an autogen cell in the annotator you'd need to use i.e. BoundingCell = 15,11664,4663 because autogen tiles end at QMID15/LOD13 boundaries rather than QMID12/LOD10.”

Sounds like you are saying using the measurements of a QMID 15/13 rather than my 12/10 as that would give a more precise measurement? Since a LOD 10 holds eight LOD 13 tiles I would need to calculate the extents by multiply the eight tiles (or adding?). Here’s where my math skills may screw me up with so many digits, ha! And does the math change if I move to different latitudes? Arrrgh!



And to your third reply, Dick –

“The QMID bounds are nested like the Russian dolls. QMID 12 is exactly 16 x 16 QMID 15's. I think the OP just wanted to break up his project by exact autogen bounds, but not necessarily just one QMID15. I might be wrong.

There is also a SplitFileLOD = 13 in the Destination, that should split the entire mess into LOD13 chunks, and that will give single autogen-friendly images to work with in the Annotator.”

Yes, I believe you got a handle of what I am trying to achieve. The resampling of the ground photoscenery is not the issue. I see that resample can “slice” it up correctly. It is slicing up the autogen (and even vectors) to match up. It gives me a workable size to work with without over stressing my PC.

Have to look at the thread more when I get home. Plan to hit this again tonight.


Lot's of stuff to try here,

Clutch

 

[GHD]

Thx for the quick response guys. Let me try to follow-up with your input:

George

“If your photo-textures are in the same folder, it doesn't matter, you can't get duplicate names in the associated texture folder.”

I’m not sure I follow what you are saying. Can you elaborate?

Annotator creates agn files in the texture folder associated with the scenery folder containing the photo-texture bgls.

If you annotate over the edge of a particular photo-tile, an agn file will be created. If you then open the adjacent photo-tile, that particular agn contents will be visible in Annotator. If you add other objects, they will be included in the existing agn file.

One cannot have two files with the same name in any particular folder.

 

[Clutch Cargo]

Gotcha George, thx. FYI, I am not using Annotator to create my autogen but I know the same rule applies. You did just give me an idea, however.

 

[GaryGB]

FYI: AFAIK, *an.agn files are always LOD-13 (aka "QMID-15") in size; the quad tile they are linked to, and their dimensions "on the ground" (thus their actual "shape") ...will vary with each tile location on the FS 'curved Earth' spheroid 3D world model that they are mapped to.


Each custom *an.agn file bears a unique "alternate" numeric series name related to the unique "alternate" numeric series name and coordinates of custom photo-real land class 'textures' they 'annotate'...by which such files respectively are referenced internally within the FS "file system".



The FS default *an.agn files bear the original more commonly known numeric series names and coordinates of land class 'textures' they 'annotate', as used in the default / "stock" land class supplied "out-of-the-box" ...which have not been substituted by 3rd party add-ons.


BTW: The FS default land class textures were reportedly originally derived from photo-real imagery by ACES.

http://forum.avsim.net/topic/279367-agn-auto-naming/



These distinct names for the world same area can be seen in an appropriate FS utility as one moves over default or custom land class texture tiles in a FS flight.

If one places a "autogen-annotated" add-on tile of custom land class textures over an area of the FS world, (subject to certain SDK methods which may involve use of blend masks and/or concurrent use of un-compiled .xml autogen annotation files for the same tile area), they will pre-empt display of the underlying default land class and associated default *an.agn files.

Thus, if one first notes the numeric file name for the default land class scenery, then flies over the exact same area using a custom land class photo-real scenery add-on, one will instead see the alternate series numeric file name used ...in place of the default series numeric file name.


As George alludes to, there can only be one copy of a file with a (default or custom) specific name and matching file extension ...in FS 'system' folders, and in folder layers set "active" in FS Scenery Library.



Also, IMHO, some info previously posted by George might offer additional insights on this topic:

http://www.fsdeveloper.com/forum/threads/fsx-annotator-and-tile-numbers.4272/

Annotator still uses the same tile numbers as FS9 but photo-real scenery files each contain 64x64 tiles. I have a program to identify the scenery file for the Horizon Generation-X scenery using FSUIPC. I guess it should work for other areas assuming they use the same naming (numbering) convention.

George

http://www.fsdeveloper.com/forum/threads/fsx-annotator-and-tile-numbers.4272/

The agn tile size in FSX is exactly the same as in FS9. The difference is that the textures are contained in bgl files and not bmps. Each bgl contains 16x16 agn tiles:






I just convert the lat/long to a QMID15 reference:



George

I'm wondering if George might be willing to once again share the original images of his "worked examples" for this helpful info ?



Also, to illustrate where / when one transitions between neighboring LOD-13 *an.agn file coverage areas (aka "tiles") using custom annotations during a live flight within FS, George's "IdentifyTile" utility might help:

http://www.fsdeveloper.com/forum/th...-files-based-on-bgl-files.429425/#post-671247



PS: You may also wish to review this excellent tutorial:

"Using the Autogen Annotator" by Luis Feliz-Tirado:

http://library.avsim.net/esearch.php?CatID=fsxsd&DLID=140537

using_the_autogen_annotator_264833.zip
License: Freeware
Added: 21st November 2009, 16:18:51
Downloads: 3266
Author: Luis Feliz-Tirado


Hope this helps !

GaryGB