Holes in surface shapes

[NathanKronenfeld]

Last summer, when we first were able to draw shapes with holes using SurfacePolylines, overriding the draw interior call to actually fill it (albeit poorly).

When upgrading to the latest WorldWind in January, we moved to using SurfacePolyline/SurfacePolygon instead, and found we'd lost this ability.

I've managed to get it back by making a copy of SurfacePolyline (which I've called SurfacePolySet), removing the override to drawInterior that makes it do nothing, and by changing the input location format from

Iterable<? extends LatLon>

to

Iterable<? extends Iterable<? extends LatLon>>

I think nothing else was needed - the internal createGeometry was already set up correctly to take the new types, and the changes in logic were pretty simple.

Is this a good way to support holes in surface geometry, or is there a problem with it I'm missing? Is there a better way?


Thanks,

-Nathan Kronenfeld

[dcollins]

Hi Nathan,

In order to correctly answer your question, we'll need to know more about what you're doing. Would you please answer three follow up questions:

1. What type of geometry do you need to represent with surface shapes?
2. What was the original motivation for using SurfacePolylines?
3. What is the motivation for extending SurfacePolylines/SurfacePolyline to fill their interior, instead of using SurfacePolygons/SurfacePolygon directly?

Thanks,
Dave

[NathanKronenfeld]

Holes in surface shapes

...

1. What type of geometry do you need to represent with surface shapes?

I'm not sure what you're asking, but I'll try to answer as best I can.

We are representing terrain-draped decorated surface lines and figures, drawn and configured by users to have arbitrary fill and outline characteristics.

1. What was the original motivation for using SurfacePolylines?

Originally, back last summer, I chose to use SurfacePolylines because it was significantly faster than SurfacePolyline or SurfacePolygon. Because of this, I hadn't noticed I was only getting holes properly represented because I was using the polyline set.

1. What is the motivation for extending SurfacePolylines/SurfacePolyline to fill their interior, instead of using SurfacePolygons/SurfacePolygon directly?

Because our perimeter line isn't always closed, and I assumed polygons were necessarily closed. I guess I should probably check that. However, I don't think it really matters which I use, as long as I take out the explicit disabling of fills in the polyline code when I copy it.

As best I can tell, neither polygons nor polylines have a way of inputing their points so that one can represent holes in the fill. They would draw holes just fine if one could tell them where to put them (well, polygon would; polyline only if the disabling of fills were removed), it's just the way they store locations that prevents it.

Thanks,
-Nathan

[dcollins]

Nathan, Thanks for the explanation.

We recently added support for interior holes to SurfacePolygon. See SurfacePolygon.addInnerBoundary. Given that, does SurfacePolygon now meet your requirement for holes in the fill?

Additionally, you mentioned that your perimeter lines aren't always closed. Do you display any fill in this case? If so, could you post a screen shot?

Thanks,
Dave

[NathanKronenfeld]

Holes in surface shapes

That will take me a little time to check - we're currently locked into build 726, so I have to do some integration work to be sure.

In the mean time, here's a screen shot of what I mean:

[dcollins]

Nathan, If I understand this correctly, you need a SurfacePolygon with two features:
1. Optional holes in the filled interior.
2. Optionally open perimeter.

Is that correct? If so, you can achieve both needs by using SurfacePolygon as follows:
1. Call SurfacePolygon.addInnerBoundary to specify one or more holes in the filled interior.
2. Extend SurfacePolygon and override generateIntermediateLocations. Your subclass' implementation should delegate to the superclass implementation, but pass a value of false for the parameter "makeClosedPath".

Note: you'll need a World Wind build from 9/29/2010 or later.

Thanks,
Dave

[NathanKronenfeld]

That is plenty early enough for us - we're using a January build.

Unfortunately, it presumes that there is only one outer boundary, and that we know which of the set of boundaries it is. In our case, we are handed the geometry by an external library. Sometimes what it returns is a set of outer boundaries, sometimes it's an outer boundary and some inner boundaries, which may or may not be nested.

Looking at the code, this looks very similar to what I am doing, except that it tries to maintain the getLocations and setLocations methods as is. However, as the former is used for determining extents, when I try using SurfacePolygon, I find it only draws my graphic in some of the necessary tiles whenever I have multiple outer boundaries.

[tmuic]

I implemented something similar for Extruded Polygon,

I made a sub class of Extruded Polygon and rewrote tesselator for cap using outer and inner vertices
http://glprogramming.com/red/chapter11.html