Andy Ross writes: > Jim Wilson wrote: > > When I get some time I'll run further tests and maybe come up with a > > patch to avoid this sort of glitch. It would be helpful if someone > > happened to know why this gap happens in the scenery data sometimes. > > I'm sure Curt can talk in more detail, but my guess is that this is > going to be very hard to avoid* in the general case. Maybe the best > way to do this is to apply some meta-intelligence about the structure > of the data. Rather than finding a purely geometic intersection with > any polygons that may (or may not!) be there, test each tile > individually (with a little guard band around the edge to prevent > misses) and select exactly one intersection. > > [* It's really the same issue as the jitter -- at the scales covered > by the terrain tiles, the floats in the vertex coordinates are only > accurate to within a few millimeters. Even "perfect" math will > result in cracks. The only way to avoid is would be to find all > the duplicated vertices accross tile boundaries and force them to > be precicely equal at load-time, which sounds like a pain to me. > You can't force them to be precicely equal at generation time > because each tile has its own coordinate origin and the "equality" > test needs to happen after they're placed into the same > coordinates.]
Exactly ... Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities [EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
