Geometry Boost List: [ggl] RE: A few Boost.Geometry questions

Subject: [ggl] RE: A few Boost.Geometry questions
From: Simonson, Lucanus J (lucanus.j.simonson)
Date: 2010-09-27 13:20:45

Bruno Lalande wrote:
>> Clearly I do not understand Boost.Geometry enough to know whether
>> this would work or not. However I see two potential issues:
>> 1. Consider a clipping operation of a multipoint with "hidden"
>> z-values against a polygon. If intersection() constructs the new
>> clipped multipoint by carefully *copying* unclipped points from the
>> input into the output, this could work. If intersection() however
>> constructs *new* output points using the coordinates from the old
>> input point, it will not work. 
> 
> Interesting, and tricky indeed... We need to think about how this
> could be solved, for the time being I unfortunately don't have any
> definitive solution to propose. I feel that the key would be to
> improve the way in which user expresses how he wants points to be
> constructed, maybe with new functions/metafunctions, but I need to
> elaborate that further.
> 
> I'm mostly interested in game programming, and this situation occurs
> quite often in this area as well (although it mostly appears at
> rasterization time, which developers often delegate to the hardware).
> So you're problem is a bit mine, actually :-)

Concept refinement handles cases where 3D points need to be used in 2D algorithms.  For things like properties if your algorithm modifies the geometric content of the argument passed by reference the properties will be preserved.  We could think of the z as a property in this case.  If it constructs new ones in the output the properties won't be transferred to the output.  If it uses the copy constructor to construct the new ones it would.  If you want to support this kind of thing you'll need to test for it since it os easy to overlook.

Regards,
Luke