Graphics intersection

[MaxV]

Hello,
how is possible to show just the intersection area between two graphics?

If would use images instead of graphics, should I use the ink property? Which modes?

[dunbarx]

Hi.

One thought is to test each point of each graphic in turn, and see if it intersects the other. By identifying those two sets of points, you could reconstruct the two "halves" into one new shape. This would be as accurate as the number of points in each grc, the more the better, since it is unlikely that the intersection of the perimeters would actually fall on actual points. There would be an undefined portion of each graphic in those two locations.

So now you should be able to create a temporary list of point that lie between each of the "actual" points, knowing which are just within and which are just without, as these will straddle the perimeter intersection of the other grc. Do it finely enough and you will be getting near to the pixel level. Then if you run the above test, you will get very close to the intersections. The interior points do not matter. Now you can add those intersection points to the "actual" points, delete the temporary points, and you are good to go.

This is something that CAD programs do without even thinking about it.

Hermann? What do you think?

Craig

[bn]

Hi Max,

how is possible to show just the intersection area between two graphics?

that is quite tricky and by experimenting I found a way to show just the intersecting area of two graphics.

The intersection is just black.

It involves changing the backgroundColor and foregroundColor of the graphics and grouping them. You might want to save the properties of your graphics before changing them.

I made a little stack that shows what I did.

intersection.png (16.27 KiB) Viewed 5720 times

There might by other ways that I did not find.

Kind regards
Bernd

[[-hh]]

Hi all, three notes.

First. Bernd's method is tricky and could be even expanded to "in-out" rules because it's generally not easily definable what's "inside"/"outside".

Second (@Craig). Your method is necesary if there is no "fill" so one has to find the intersection of two (possibly open polygons) from their points only. There is an own math application field ("subdivision theory") that handles this. Most is too much complicated for LC, from my point of view.

Third. There is a LC built in function that could easily be used, if it would work.
For example for the starting example of MaxV one could build a smaller rect that encloses the intersection (max of lefts, max of tops, min of rights, min of bottoms).
Then, if p1 and p2 are the two graphic names, check for each point (i,j) of this smaller rect
if within(grc p1, (i,j)) AND within(grc p2, (i,j)) is true
and then set alpha and color of these points. This is very fast, but sadly
= the last version that works "close" to correct, but NOT correct is LC 6.6.5
= LC 6.7-7.0 are EXTREMELY wrong, mostly more than 50% of wrong decisions !!

Result (dark) with LC 6.6.5

within2.jpg (16.95 KiB) Viewed 5666 times

Result (dark) with LC 6.7.1 rc1 / 7.0.1 rc1

within2_7.jpg (17.24 KiB) Viewed 5666 times

The attached stack is used as for the bug report (#13974). Moreover, as soon as the bug is resolved, you could use it as an alternative solution to the original problem.

[bn]

Hi,

here is a little cheat. Since Hermann discovered that "within" is "without" I had a take on intersect.

I use a picture of size 3 by 3 pixel. Then I set the alphaData of only one pixel, the middle one, to 255, i.e. fully opaque. Effectively giving me only one pixel that fulfills the condition for "opaque pixels" of the intersect function.

Then I move the image with Hermann's code along the small rect and test for intersect "opaque pixels" of the image against both polygons.

Kind regards

Bernd

[[-hh]]

Clever idea. This could be also more than a cheat: an alternative one could use to avoid "clicked I on border?"-problems.

Next is what I originally intended to have further on here: To have a fast algorithm to create a polygon with a (close to) minimal list of points from that image.

I saw once in an archive a luminous highlite: An approach by you were you converted an image to a graphic shape by finding edges. This is also applicable here, isn't it? This could be a good starting point for finding a (close to) minimal set of points ...

[MaxV]

What about working on image displayed?
Here is my idea:
########CODE#######
on graphIntersection graph1, graph2
group graphic graph1 and graphic graph2
set the name of the last group to "tempg"
set the showborder of group "tempg" to false
set the lockloc of group "tempg" to true
set the visible of graphic graph2to false
import snapshot from group "tempg"
set the name of the last image to "temp1"
set the visible of graphic graph2to true
set the visible of graphic graph1to false
import snapshot from group "tempg"
set the name of the last image to "temp2"
set the visible of graphic graph1to true
put the alphadata of image "temp1" into aImage1
put the alphadata of image "temp2" into aImage2
put the length of aImage1 into numpix
repeat with i=1 to numpix
if (charTonum(char i of aImage1) is not 0) and (chartoNum(char i of aImage2) is not 0) then
put numtoChar(255) after tResult
else
put numtoChar(0) after tResult
end if
end repeat
set the alphadata of image "temp1" to tResult
delete image "temp2"
ungroup group "tempg"
end graphIntersection
#####END OF CODE#####

This code is for graphic, but it should work also for overlapping images, just modify the first row of code.
This is the result, on the left 2 graphics, on the right just the intersection:

[[-hh]]

This is exactly Bernd's first approach who already solved there your original question of which inks to use for a more general kind of shapes.

You simply "scripted" his combinations of inks to apply for the special snapshots you additionally made.

The setting of a special ink combination is always scriptable by using alphadata, but the engine does it 'directly' 100 times faster than a script. Is it that what you where asking for with your first post? Then I understood something wrong, sorry.

[MaxV]

I just look at the posted images, so I didn't realize that he worked with ink.
Good work Bernd