Seed Priority Rules and Guidelines

Seeds on different seed levels (and, often, even on the same seed level) can overlap in scenery design. For example, a level 8 seed can define a large 150km square area as being arid; however, somewhere within this defined area, a level 10 seed can specify a 37.5km square area as desert. In Flight Simulator scenery design, seed level priority dictates which one of the overlapping seeds is visible.

In earlier versions of Flight Simulator, the level of the seed determined projection priority; that is, higher level seeds had higher priority. Higher level, smaller seeds had higher priority because database designers designed areas by laying out large, low-level seeds for large area coverage, and then layered smaller seeds on top of them to more precisely define smaller areas. Flight Simulator version 5.1 and later still use seed level priority as long as the seed status byte is set to < 0f0h, as shown in the table in the topic Defining Seeds. If the status byte is not 0f0h, seed status priority is overridden.

In Flight Simulator version 5.0, if two seeds overlapped and were both at the same seed level, the seed at the highest altitude would be visible. Because altitude is specifiable to the nearest 1/256 meters, this made it possible to upgrade a scenery area by specifying a seed that was 1/256 meters higher than the ground used to be. This altitude priority system also reduced the “last encountered seed at this level wins” effect that made database depiction depend on the order of files encountered on the disk.

Flight Simulator versions 5.1 and later still use seed altitude priority as long as the seed status byte is set to 0f0h, as shown in the table in the topic Defining Seeds. If the status byte is not 0f0h, seed status priority is overridden.

You can set the status byte to override both seed level and altitude priority. You can use the status byte to determine priority as follows:

• If status < 0f0h, use normal altitude and level priority rules.
  
  
• If status > = 0f0h seed is high priority seed. Bits 0–3=priority code; 0=lowest, f=highest.

Even with seed level, altitude, and status byte priority, the system needed more flexibility to handle the large number of scenery design overlaps and upgrades. In Flight Simulator versions FS5.1 and later, scenery design files (BGL files) each have a design level.

Basically, all level, altitude, and status byte rules apply within each design level, but design levels of higher priority take overall precedence over lower design levels. Design levels enable scenery upgrades and detailed scenery areas to completely replace existing scenery with new scenery design areas.

To summarize, the seed priority rules and guidelines for Flight Simulator, version 5.1 and later, are as follows:

• Higher priority design level seeds override any seeds that are from a lower priority design level.
  
  
• For seeds of the same design level:
  • Seed priority system (0FpxxH seeds of higher priority "p"  replace seeds of lower priority "p" regardless of seed level or altitude. For example, seed 0F244h is of higher priority than seed 0F144h, even if seed 0F144h is on a higher level.)
    
    
  • Seed altitude priority (seeds on the same level are replace by seeds on the same level but at a higher altitude.
    
    
  • Seed level (seed levels 8–13) priority (seeds of a higher level override seeds of a lower level).

The following table describes how layers are used for seed prioritization in Flight Simulator, versions 5.1 and later. The descriptions in the table assume that Flight Simulator is run with its default world, the enhanced CD-ROM world, and Las Vegas scenery disk.

Most seeds expand into textures that are digitized ground terrain photographs. It's important that the texture is continuous over adjacent seeds of the same type and that the texture is repeatable. The texture must be locked to the earth reference frame; the seed area is used to compute the borders of the area to fill in, and the texture that fills it is scaled and positioned relative to a fixed coordinate point on the earth. As is the case with sky texture, this coordinate point can't be assigned to a fixed value (lat=0, lon=0, for example) and used throughout the world because texture distortion would occur far from the lock down scale point. For low altitudes, seeds are restricted to fall within level 8 seed bounds and all seeds are locked within these bounds to the lower left point of the level 8 seed. At higher latitudes (where even level 8 seeds get very small), the lock points are assigned at lower left corners of lower level seeds (levels 7, 6, 5, and so on); this prevents hundreds of non-combined level 8 seeds from being created at high latitudes. The earth lock bounds are in the following table.

Note: The first latitude break in all cases is a multiple of level 8 cells per break. As a result, the latitude break crossing is easy to detect because a change in the level 8 latitude is bit 0 for level 8, bit 1 for level 7, bit 2 for level 6, and so on, and indicates that a latitude break has been crossed. The front-end processor, when optimizing seeds, computes a mask of 1 for level 8, 2 for level 7, 4 for level 6, and so on, and, while optimizing, looks for changes in these bits to determine earth lock latitude break crossings. 

To optimize seeds, the seed map optimizer takes a seed map of a given size (for example, 40 x 40 level 13 seeds) and combines adjacent seeds with the same characteristics (type, class, and altitude) into larger seeds to be passed as seed objects to the GET_OBJECT command caller. Different optimization algorithms are used depending on the version of the front-end processor.

For the optimization algorithm, a method is used that creates the largest seeds possible from the remaining uncombined seeds in the seed map. Scanning of seeds begins at the lower left (southwest) corner of the rectangle. Seed rectangles with common characteristics are tested to determine the largest area possible. When the largest area is determined, it is turned into a seed and the "used" map elements are marked as used. The seed scan continues until the next unused element is found; this process repeats until all the seeds are incorporated. Some problems with the process were as follows:

• Mountain seed edges were always synthesized and projected to be 0 altitude. This created long valleys along seed breaks.
  
  
• Seeds break up differently depending on plane location. This caused new valleys to form and others to disappear as the plane moved across the scenery:
  • Large mountain seeds next to small ones, and especially elongated seeds (for example, an 8x1) caused severe prioritization problems for mountain seeds.
    
    
  • Limitations in the projection code caused the random peak points to be at only 3 values instead of 256 random values.
    
    
  • Seeds often overlapped because of nonprecision projection.

The following improvements were made in Flight Simulator, versions 5.1 and later, to correct all these problems:

• A mountain seed combining system (as described later in this topic) was implemented. The mountain seed combining system allows the front-end processor to send the seed projection system information about whether mountain seed edges and corners can be random altitudes. Because random altitudes are the same for any latitude/longitude location, adjacent seeds can have matching, nonzero altitude edges, eliminating valleys between seeds.
  
  
• The front-end processor passes maximum square-sized flat seeds instead of maximum-sized flat seeds to the projection system, eliminating elongated seeds.
  
  
• The front-end processor passes grid size seeds (maximum size 2x2) to the projection system. This greatly reduces prioritization problems. Keeping the mountain seeds small reduces the "cracks" in mountain edges (between seeds).

Improvements to the seed optimizer increased the number of seeds produced in Flight Simulator versions 5.1 and later. This decreased performance. The Image Quality/Speed setting in the Preferences dialog box enables the user to regain performance speed, as shown in the following table.

Even with the optimization algorithm, different seed breaks can occur because of new seeds scrolling into the scanned area and causing a break in the horizontal scan. Breaks have a negative effect on mountain seeds because long, thin valleys are created at the point at which the edge of a seed causes all altitudes to be set to zero. These valleys create a jagged, disjointed visual effect.

The method to smoothly merge mountains at non-zero altitude edges is based on the fact that mountain heights, at any coordinate latitude/longitude location, are identical regardless of the seed that they occur in. The altitude generator just needs information that indicates whether to set an altitude at an edge point to zero because it intersects with a non-mountain seed. The front-end processor determines this and sends BGL seeds that have any combination of their edges specified as either "use computed altitudes for points on this edge" or "make all mesh points on this edge altitude=0." Corner points of the seeds are also considered for zero-altitude conditions because it's possible for the seeds to the north and east to be of the same type, but a diagonal to be of a different type; as a result, a zero-altitude condition at the corner is necessary. An example of how the method works is shown in the following example.

NSEW_code = abcdNSEWa = 0 if ne corner 0 altit
b = 0 if nw corner 0 altit
c = 0 if se corner 0 altit
d = 0 if sw corner 0 altit
N = 0 if north edge 0 altit
S = 0 if south edge 0 altit
E = 0 if east edge 0 altit
W = 0 if west edge 0 altit
SCAN FOR COMBINED SEED
init:
get next available seed
max_x = seed_array_max_side
NS_code = NS code seed
south_row_NS_code = NS_code
row expand until:
max x reached, or
grid end, or
type mismatch, or
NS code mismatch

EW_code = EW code (this row)
size_x = x width (this row)
size_y = 1
max_x = size_x
loop:
move north
if type mismatch, seed done
NS_code = NS code seed
row expand until:
max x reached, or
grid end, or
type mismatch, or
NS code mismatch
if EW_CODE != EW_code (this row), seed done
if max_x != x width (this row), seed done
size_y = size_y + 1
goto loop
seed done:
NS_seed_code = N from NS_code,  S from south_row_NS_code
EW_seed_code= EW_code
NSEW_code = NS_seed_code + EW_seed_code
EXIT

Using the center of seed radsort method is the only way to make sure seed prioritization is 100 percent correct; assuming that all seeds are square, the same size, and orthogonally aligned. However, there are cases where cyclic blocking can make any projection order incorrect.

The BGL system, when requesting seeds as objects, requests a scan level on which to scan for seeds. You can specify levels 8–13. The front-end processor scans all seeds at the specified level or lower to fill the seed map array. The advantage of this system is that at higher latitudes where seeds get smaller, you can specify a lower scan level and reduce the number of seeds necessary in the array for a given scan radius. This also reduces database size requirements because a fewer number of a lower level seeds cover an equal area of a similar number of higher level seeds at the equator with the same resolution.

Multilevel seed scanning was introduced in Flight Simulator, version 5.1. At certain latitude breaks, seed scanning reduces down to lower levels to compensate for seed shrinkage at higher latitudes. The latitude break points must occur:

• Near where the size of the seed has reduced to 50 percent of a level 13 seed at the equator. This causes a size variation of scan areas from 50 percent to 100 percent of size at the equator.
  
  
• On a level 8 seed bound.
  
  
• On an earth-lock bound

The following table details seed scan levels and latitude breaks. (In the following table, v1=1fffc000h /seed width in meters at this latitude.)

Important: Multilevel seed scanning results in a new database design rule; you can't use seeds of a higher level than the scan level at the seed's coordinate latitude.

When seeds are combined by the seed map optimizer, no combined seed can straddle any coordinate latitude break included in the table above; seeds on either side of a latitude break can synthesize at different resolutions, and the resolution of a seed that straddles a latitude break can't be resolved. The seed synthesizer uses combined seed center to determine which synthesis resolution to use. This "no-straddle rule" resolves any possible ambiguities as to which side of the latitude break the seed belongs.