Clipping polygons by polygons can be done efficiently, but the algorithms that I have seen (sweep-line algorithms) have to cope with precision limitations, which makes them significantly more complex and hard to debug.

I completely agree with this :
“(Realistically a better implementation is probably to have polygonal exclusion zones with an AABB saved around them as an early-exit test.)”
Shapes in shapefiles all come with their bbox precomputed, there must be a similar reason.

Two remarks though :
1) I was skeptical too initially about implementing the w-n algo for one-one checks, but if you put actual numbers in front of your data (Ntrees*Nexcl*Nnodes) and divide by common flops you’ll probably end-up in the order of the second [implemented and tested in a nearby setting].
2) Initially your forest information is a polygon. It would make a lot of sense to clip it first with the exclusions zones. Clipping an arbitrary pol by another one is more complex as you know but there is an efficient algorithm since the work of Vatti. Actually as far as I can see it (your description was a bit sketchy) your rasterizing process is half-way towards Vatti (raster colons or lines corresponding to the scanbeams), but you clip with 4 half-planes rather than polygons.

Any way, chatting is easy but in the end this is your code and your choice given your time, and it already works quite well 😉

thanks for the open discussion. such a polygon (hull around the airport points) maybe be even created automatically – and not by the designer. I think a very simplified hull would be sufficient. See: https://en.wikipedia.org/wiki/Convex_hull

Yep – I am familiar with this algorithm:

http://dev.x-plane.com/cgit/cgit.cgi/xptools.git/tree/src/Utils/CompGeomDefs2.h#n1676

Here’s an example of why it’s not as easy as you think it is:

We go to rasterize a forest. The forest code works by rasterizing an arbitrary polygon with holes _restricted_ to within an axis aligned bounding box. This AABB restriction is important for ensuring that the cost of forest rasterization doesn’t become amplified by the subdivision of the final output mesh into “buckets” for scenery paging and scrolling.

So you want to go exclude with a polygon. Okay – you’ve now made each tree test “N” times more expensive where N is the number of sides of the exclusion zone.

By comparison, with the box rasterizer, we simply _skip rasterizing entire scanline segments_ when a box excludes it.

In other words, AABB exclusion zones exclude many trees with a single very cheap test; polygons exclude a single tree with a significantly more expensive test.

There is no question that with if the user inputs a large number of AABBs (to try to simulate a complex shape) then the shear number of AABBs makes things expensive. But it is also true that users will be able to make arbitrarily complex polygons – WED makes it cheap to really make a complicated exclusion zone.

One other note: a number of DSF shapes -are not points-, so the point-in-winding test doesn’t do us a lot of good – it’s only useful for objects (where it is reasonably cheap) and trees (where it’s cheap by the tree but since there are a huge number of trees, it’s not cheap compared to what we do now).

There is another option: convex polygon exclusion zones. In a convex polygon test, you test whether the entity is on the left side of your polygon edges – if you are inside -every- edge, you are inside. On paper it’s O(N) just like the winding rule, and it’s more restricted, but it has one really nice feature: if you are outside of ANY edge, you are outside the polygon and you can -stop the check early-.

For something like a DSF where exclusion zones are small and most stuff is outside the polygon, the early exit is a pretty nice win. In the case of an airport being excluded from a DSF, most of the trees are outside the airport, and on average half of them will be outside the first segment of the polygon’s contour, letting us skip a lot of checking a lot of the time.

(Realistically a better implementation is probably to have polygonal exclusion zones with an AABB saved around them as an early-exit test.)

I just discovered reading the comments above that exclusion zones
need to be rectangles because of the claimed difficulty to deal with
polygonal exclusions.

The point in polygon algorithm in its winding number version
works for multiply connected polygons and is linear (with a small
constant) in the number of boundary points. It is roughly ten lines
of code (here is a C++ implementation http://geomalgorithms.com/a03-_inclusion.html).

Is there a reason why including it in the X-Plane code wouldn’t
be straightforward ?

Found that it was not the refresh rate. The crash occurs when I have DSR enabled in the Nvidia control panel. My guess is that X-Plane then tries to load a DSR resolution which overloads the gpu’s ram.

PS: Interesting observation: This does not happen if I set my monitor’s refresh rate to 60Hz. I normally have it at 30Hz.

I find this tool useful “Remove duplicate Global or Prefab airports V1.1 ”
http://forums.x-plane.org/index.php?app=downloads&showfile=27785

Ah – if W2XP contains an “autogen airport” that -is- an airport, but is -not- as good as what’s on the gateway, then I agree that it is not wrong. (If W2XP contains “city” autogen on the airport, that is what I would consider wrong, because _reality_ is the standard we are trying to match, so putting a house where there is an airport means your source data is broken.)