On Sun, 28 Nov 2004 20:34:51 -0600 "Curtis L. Olson" <[EMAIL PROTECTED]> wrote: > > I can think of 4 approaches to defining taxiways and lines.
[ snip ]
> 2. Draw the taxi lines as separate polygons over the top of the taxiways
>
> and runways.
[ snip ]
> But this scheme would burn a
> lot of polygons and it would require some complex preprocessing of the
> line polygons to clip them against all the underlying triangles. That
> would be no small task ... (writing the code to do that.)
>
> 3. Cut the lines right into the geometry ... i.e. cut holes for the
> lines.
[ snip ]
> . . .we'd still be burning a fairly high
> number of polygons.
So while #2 and #3 hold the most promise in the near term, the fact
is that they require a lot of polygons. If I remember correctly,
the issue with using vmap1 data (rather than vmap0) to improve the
accuracy of roads/railroads/land use contours/etc. is also polygon
count, right?
What I'm wondering is how well known the constraints here are? Presumably
some time in the past, someone created a scenery tile that had tons and
tons of polygons and their framerate went into the dirt. Was it really
old hardware? How high was the visible poly count, and how bad did their
framerate get hit? That kind of thing. IOW, do we know that fgfs
framerates are basically polygon-count-limited at this point? Maybe this
is just a fool's hope on my part, but perhaps we worry about this more
than we need to? Maybe everything will be fine.
-c
P.S. Maybe even vmap1 would work. Or has someone tried it recently,
and the results were awful?
--
Chris Metzler [EMAIL PROTECTED]
(remove "snip-me." to email)
"As a child I understood how to give; I have forgotten this grace since I
have become civilized." - Chief Luther Standing Bear
pgpFO9PkXPhMC.pgp
Description: PGP signature
_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
