Re: Intersection Points

Thanks for the quick reply, Peter. I'll reply inline:

Peter Sorotokin wrote:
|
| At 03:19 PM 3/14/2004 -0500, Doug Schepers wrote:
|
| >Hi-
| >
| >In reading the newest draft of the 1.2 Spec, I noticed that intersections
| >are required in several sections, such as "10.1.2 Alpha compositing" and
| >various Vector Effects, such as veJoin, veUnion, veIntersect, and
veExclude.
| >These look really great.
| >
| >Since the math is being done in the viewer anyway,
|
| It is done for paths, not arbitrary element

Converting arbitrary elements to paths is trivial; I wrote a set of
functions to do that in a couple of hours. The viewer could make a temporary
conversion for the sake of the intersection check (it's only two elements,
after all).

| >  I think that the results
| >of this functionality should be exposed in the interface. It would be
great
| >to have access to the vector math functions, since it could help with
some
| >of the heavy-duty math that's hard to do in JavaScript, but that's
probably
| >a bit much to ask.
| >
| >In addition to getIntersectionList and getEnclosureList, which only
return
| >the intersecting elements, I would very much like to get the points of
| >intersection as a list of SVGPoints. Something like:
| >
| >getIntersectionPoints(element, referenceElement)
| >This method returns a dom::SVGPointList.
|
| But intersection is a shape, not a list of points. Vector effects work
with
| shapes described by contours, not contours themselves as you seem to
| propose. Try to spec out such a method fully (take into account things
like
| transforms, visibility, text elements, use element, clipping, masking,
| filter effects, etc)  and you'll see that it is a fairly non-trivial thing
| to do.

Sorry, yes, to clarify, I mean the intersections points of the contours of
the respective shapes.

Kevin Lindsey has made a very good implementation of this on his site:
   http://www.kevlindev.com/geometry/2D/intersections/index.htm
Even in JavaScript, he is getting pretty darn good performance... in C/C++,
it should be much faster. He notes that his code is not perfect yet, but it
would be a great starting point. Inkscape also seems to be doing this in
their drawing app.

I'll think more about the various issues you bring up, and write a more
rigorous reply. But for now, I would say that I, for one, would be satisfied
if only the points of intersections of the contours (that is, without
strokes) of the basic shapes (rect, circle, ellipse, line, polyline,
polygon, and path) were provided. Transforms should not be a problem...
simply apply them to the relevant temporary shape (from above). The <use>
element could be handled in a similar way, by creating a temporary path
version of the referenced shape, offset by the x and y values of the <use>
(I do this in my simple drawing app in JavaScript); then again, <use> could
be exluded easily if it poses a problem (anyone wanting to apply the
functionality to <use> could do it as I described manually in their JS). I
understand how text is also problematic (though I'd be surprised to find
that individual characters would not be represented in the viewer as path
descriptions), and would not object to text being excluded from this
functionality.

I feel strongly that having some degree of this functionality is better than
having none at all, and I think that this is something that would be easy to
do in a simple form. These are things that Flash has in its toolkit, and I'd
like to see them in SVG. The utility that this would have for SVG would be
very worthwhile.

Regards-
-Doug

| Peter
|
| >  The element parameter is of type
| >SVGElement.  The referenceElement parameter is of type SVGElement.
| >
| >Use cases:
| >     Math apps - this would help with many visual tutorials and similar
| >math-related apps.
| >     CAD - precision intersections of machinery and walls.
| >     GIS - intersections of street, rivers, and other map features.
| >
| >Again, since a conformant viewer already needs to have this
functionality, I
| >think that there would be very little additional cost in exposing the
| >results in the interface. I think that this is something that could
easily
| >be done in SVG1.2.
| >
| >Regards-
| >-Doug
|

Received on Monday, 15 March 2004 02:23:58 UTC