polygons near the poles.
- Fix a bug in the code that would insert dividing nodes in a long seam which
could lead to infinite recursion for lines on the poles.
- Change airport area clipping semantics to reduce cracks in scenery.
favor of newmat11 which is much simpler, and seems to compile well on modern
OS's.) I need to do some further testing of genapts and until then, don't
assume the new mechanism is working perfectly.
situations
- Made the code a bit more robust and able to handle the handful of rare
occasions when the least squares nurbs interpolator fails.
- Add airport surface bases for towers, windsocks, beacons, and vasi/papi
lighting so they never are buried and never float. (I'm considering the
idea of doing this for the approach lighting too ...)
surface. I think I have this working robustly.
A few miscellaneous tweaks to handle latest X-Plane data (with a few new
runway surface codes we hadn't seen before.)
caused missing output (and thus missing scenery features.) This could
also lead to cracks in the scenery because of the nature of the underlying
edge matching system.
polygons. This was to bail us out of the overwhelming memory requirments
when using the default polygon clipping routines on really large polygons.
However, the simplistic polygon partitioner did not handle holes.
Unfortunately, several TG utilities were calling this function with polygons
that did contain holes with potentially mixed results.
I renamed this function tgChopBigSimplePolygon() and created a new
tgChopNormalPolygon() which should be used by most utilities unless you
really know what you are doing.
This has some performance implications, but achieves more correct results.
branch. Kind of an out and back. node[n] == node[n+2] where there is some unique point in between. Our triangulator is usually robust to this, but not in
100% of all cases. So I had some code to catch and eliminate this weirdness.
However, a key piece of code was commented out (?!?) rendering it a no-op.
I fixed this and tile building is more robust now.
There are quite a few difficult cases where an airport is located on top
of a hill, or in a bowl, or has a significant elevation change near by.
I take the average elevation of the area and clamp the outlyers. However
these difficult cases "bias" the average elevation because the airport
surface may include much of the surrounding area.
This change to the code computes the airport elevation *only* based on the
actual airport geometry node and ignores all the surrounding nonsense that
might exist. This doesn't make things perfect, but is a *big* step forward
for airports in areas with significant elevation change nearby.
precision with floats.
- Restructure how the airport surface is sampled just a bit.
- Solving for X,Y given U,V on a nurbs surface is a little bit tricker than
I first thought. If you change one demension of U or V, you can change
both X and Y. We need to solve for each X, Y axis independently, and
then iterate in case moving in the other axis has taken us away from the
solution in the first axis.
- Add a slope constraint on airport surfaces.
Expose a polygon function that will split up long edge lines to keep the
max edge distance below some threshold. This could be used for instance
to reduce long lines in polygon area shapes so they can better follow
the underlying terrain changes.
The patches deal with three separate issues, all rolled up into one
tarball:
Currently, arrayfit always appends .arr.gz onto the name passed on the
command line, meaning that only tile names can be passed. The patch strips
off .arr or .arr.gz if present prior to it's appending, meaning that tile
names or filenames can be passed on the command line.
The interface to the OSGB36 conversion functions is cleaned up a lot. I
can't believe I originally wrote it in such an ugly manner!
A lot of console output (> 5000 lines per tile) is removed from the final
construction process, meaning that the output left can actually be read.
The attached patches significantly quieten the output from genapts, which in it's current form resembles the universe flying by on a bad hair day Remember chaps, console output on Windows is slooowwwwww... Normal service may be resumed using --verbose or -v. I've also added a short help, obtainable with --help or -h. I've also added a couple of extra options, --airport=abcd for just generating a particular airport, and --tile=<[we]xxx[ns]xx> for generating a 1x1 degree tile. We currently have --chunk=<[we]xxx[ns]xx> for generating a 10x10 degree chunk, and I'd like to eventually add --tile as an option to all tools that take --chunk.
This one adds the tile option to
tgvpf.
Erik Hofman:
Some small code changes for IRIX.
It looks like the program gets into an infinite loop while findind
edges for a contour (inserting the same edge over and over until the
program runs out of memory). i am not quite sure i understand the code
but the following patch solved the problem for me:
Before:
- if it's a concrete taxiway over 150 ft wide, assume it's an apron
(confusingly called "tiedown")
After:
- if it's an asphalt or concrete taxiway over 150 ft wide, *or* if
it has no blue taxiway lights, assume it's an apron
markings.
- Fix a couple very small alignment/sizing problems.
- Use a different texture (similar to rest) before aim points on nonprecision
runways. This will potentially make things easier if we want to add
skid marks to the textures.
- Fix a couple bugs (el stupido) in precision marking generation.
Originally I through together a really cheap/ugly hack for estimating
distance between two points, but that really started to stink when throwing
a lot of new situations at it. So now I calculate spherical distances between
two points in meters which is plenty accurate for these purposes. This gives
us much better control over smoothing. For instance we could establish a
maximum 10% grade for all roads if we wanted to.
This could cause tile edges to no longer match up becuase this routine would
adjust node elevations which it shouldn't have. Hopefully this change fixes
the problem.
on the command line with the --terrain= option. You can specify as many as you like. Directories specified on the command line will take precidence over
the default directories and the directories will be searched in the order
specified.
in Robin's data.)
- Code adjusted to work with slightly modified input data format (part of
our move away from metakit.)
- Eliminate some debugging output.
Attached are patches to Terragear to enable it to compile out of the box on
Cygwin (once all the relavent libraries have been compiled). Specifically
they fix a conflict with another version of min/max somewhere on the
system.
but because of the use of default arguments, the compiler wasn't flagging
this as an error. This caused a) much stupidity and b) additional stupidity.
I also found a case where I passed in a length and width extention parameters
but, used the length parameter twice ignoring the width parameter. This
yields much more sensible and expected results when building the grass buffer
zone around a runway.
cover" areas. Rather than artificially cut in polygon areas, just lookup
a land cover type for unassigned triangles. I think this has potential, but
it needs more work to eliminate some odd artifacts.
- Revove --min-angle= option.
- Don't re-fit() triangle array to try to achieve a particular range of
node quantities ... this is all pre-computed with a much smarter, much
more efficient algorithm.
impliment essentially the same thing as "ArrayFit". Requires the terra
program, but the terrafit.py script should take care of the pre/post
processing.
is probably better than guessing at a value and fitting to the guessed value.
For corner points (where we *need* a value to do the fit) use the elevation
of the "closest" euclidean-wise valid point.
Then I needed to modify libArray code so that other portions of the code
could use the pre-computed fit data.
Today I discovered that arrayfit was messed up. That is now fixed.
to a higher res data set, attempting to preserve the most important
features in the original data set. The user can specify a min and max
number of output nodes as well as a maximum error tolerance that should
not be exceeded (between the original and simplified surfaces.)
based on the terrain simplification algorithm in Michael Garlands paper
located here:
http://graphics.cs.uiuc.edu/~garland/software/terra.html
Essentially start with two triangles forming the bounding surface.
Then add the point that has the greatest error. Retriangulate.
Recalcuate errors for each remaining point, add the one with the
greatest error. Lather, rinse, repeat.
format. The big trick was that the polygon clipper is completely 2d. So
I needed to add code to preserve the elevations in the clipped output and
fill in plausible elevations for any new points created as a result of the
clipping.
intermediate mode. The goal then is that these elevations would be
preserved throughout the tile construction process and the surrounding
geometry would fill in without gaps. This has potential applications for
airports and runways of course as well as roads, rivers, streams, railroads,
or any other object where we might want to control the final elevation in
advance.
in .dem format. The .arr format is a much simpler (and a bit less flexible)
specifically for use as an intermediate format when building scenery. Any
number of various raw terrain formats could be translated into the common
.arr format which then greatly simplifies life for the build tiles util.
position.
Terrasync runs as a separate process and accepts the --atlas=port format.
The fgfs output tells the terrasync util where FlightGear is currently flying.
Terrasync will then issue the appropriate commands to rsync the surrounding
areas to your local scenery directory.
As you fly, terrasync will periodically refresh and pull any new scenery tiles
in the vicinity.
This also works if the scenery on the scenery server is update. Rsync will
pull any missing files, or any updated files.
There is a chicken/egg problem when you first start up in a brand new area.
FlightGear is expecting the scenery to be there *now* but it hasn't been
fetched yet. I suppose without making a more complex protocol, the user
will need to be aware of this. The user could restart flightgear after the
initial rsync completes, and then after that everything should be good,
assuming the user has the necessary bandwidth to keep up with flight speeds.
Final notes:
At the moment Alex Perry has a partial rsync server, but I don't know it's
status. I hope to have a full server up and running at some point soon.
Currently the terragear utility just echos the commands it would run to
rsync the data, it doesn't actually run the commands. This is a work in
progress.
- Put a space between arguments and redirection operator: looks nicer
and may be necessary in some circumstances.
- Add missing option "--min-angle" to help text.
equal to the elevation of the highest light.
Approach lighting systems don't rise and fall with the prevailing terrain.
This prevents portions of the approach lighting system from dipping below
ground level in cases where the surrounding terrain is simplified and doesn't
perfectly match the DEM data.
confused by the alphabet soup.
- Forgot to impliment the SALS(F) version of SALS approach configuration.
- Was generating SSALS when the system was requesting SALSF.
it involved creating a 2d runway object of the right size, rotating it and then
trying to back solve for the actual lon/lat. This and a few other problems was
causing problems with subsequent texture coordinate calcs for the runway
surface textures. It also could have contributed to runways/lighting being
slightly misaligned with the ILS's. Then lots of minor cascading changes as a
result.
Well, I found a bug in VpfTile that prevents the function getTileSubdir
to return the correct value.
In that case getTileSubdir was returning the content of a local
variable (subdir) that is destroyed before used outside. Usually,
it generates a segfault with MSVC but here, the returned string
was "". The patch returns the value of the string and tgpvf is
going well so far.
Added --min-area and --max-area options to specify the minimum and
maximum area of a polygon's bounding rectangle in meters square. This
option will make it possible to use different textures for big lakes
and small ponds, or for large cities and smaller towns.
polygons to scenery. It uses the regular XML property format, which
users can create easily in a text editor. See
src/Prep/UserDef/sample.xml for examples.
