The task is to create the visibility of hatches overlapping each other. For example, we have two hatches: first add the first hatch, then add the second hatch so that the objects of the first hatch become islands for the second hatch. If we add a third hatch, it will look like it is located under the two previous hatches
Along the lines of my assumed approach at your Topic in the AutoCAD Forum [this is the better place for it], in very simplest terms, this seems to do what you want:
(defun C:HHB (/ hatch pieces); = Hatch with Hatch Boundaries
(setq hatch (car (entsel "\nSelect Hatch to use as Hatch bounaries: ")))
(command
"_.copy" hatch "" "0,0" "@"
"_.explode" "_last"
)
(setq pieces (ssget "_P"))
(initdia)
(command-s "_.hatch"); allow completion of command, then:
(command "_.erase" pieces "")
)
It worked for me with the HEX pattern inside a Circle, putting GRAVEL in around the hexagonal islands:
But bear in mind that it could be affected by the details of the pattern definition, if the pieces resulting from Exploding it don't meet precisely, which could become more of an issue if far from the origin.
It doesn't do various things it could, like verify that you picked a Hatch object, and if you would usually use it with only a limited choice of patterns [many don't make closed shapes and wouldn't work as boundaries], check whether it's one of those. And the usual other stuff -- Undo begin/end wrapping, Layer control if you want, *error* handling if appropriate, command-echo suppression, etc.
@edushka228 wrote:
Why doesn't it work with custom hatches?
Not enough information.
Do you mean a custom Hatch as the islands part, or as the filling-around-them part? If the islands, I suspect the pattern definition is not precise enough for the islands produced to be closed shapes, but there are little gaps at corners, etc. If that's the case, you may be able to help the situation by ensuring the Hatch origin is within or very close to it, because any "drift" of line positions, from imprecision in the definition, increases with distance from the origin.
And what do you mean by "doesn't ... work"? Your infill bleeds inside the islands? [See my suspicion above.] It doesn't get rid of the pieces from the Exploded pattern? Something else?
@edushka228 wrote:
If you manually apply the explode method to custom hatches, everything works. Is there any way to improve the code?
Since it doesn't suppress command-echoing, check the command-line history after you use it unsuccessfully, where you may find some indication of what's going wrong.
EDIT: I've now tried it on several other patterns for the islands part, both some that come with AutoCAD and some custom ones, and it has worked as expected. [Acad2020 here -- I can try it on 2024 elsewhere, later.]
My final task is to write a script that will select all hatches in the figure and for each area painted with multiple hatches, apply the overlay script you implemented in the code above. I will define the order of overlaying later, for now it can be done randomly.
For example, we have areas with multiple hatches (picture on the left). We just run the script and we get the result as in the picture on the right
@edushka228 wrote:
.... I will define the order of overlaying later, for now it can be done randomly. ....
I don't think it can be done randomly. Would it not be critical that the Hatch pattern that makes closed shapes must be done first, and only after that, the one that does not?
Yes, something like that, except that after the first Hatch, it should be possible to use (entlast) for the selection of the Hatch to Copy/Explode/etc., not requiring the User to pick it. Also, a specific sequence of patterns could be built in, with their appropriate scales and rotations, if there are typical combinations.
But I think it would still always be necessary to ask the User to pick in the open area they want to Hatch in, at each step. I don't see how finding the right place to pick in could be automated, i.e. how to guarantee that a calculated point is outside the closed-shape portions of all Hatches drawn so far. [Maybe it could be done with a very specific series of patterns and careful control of the origin points and scales and rotations of each.]
Nor do I think it could be done by automated object selection only, at least not after the second Hatch, because I expect once you get more than one pattern of closed shapes drawn around each other, some shapes from newer ones will partially overlap or could even enclose those from earlier ones, and there will likely be ambiguities about what constitutes an "island."
At the least [and applicable whether by point pick or object selection], you would need to ensure the Style for islands is "Outer," not "Normal." This is the kind of thing that could happen under "Normal" Style, if the yellow SQUARE pattern was first, the red HEX pattern second, and the green DASH pattern last:
Note the bit of DASH pattern inside the yellow square in the middle, and inside the partial red hexagon at lower left, which I suspect you would not want.
Maybe that would never happen in the sequence(s) of patterns you would use, if they get successively smaller so that nothing newer can ever fully enclose something earlier.
I don't know - but I am guessing... With 2 my last codes, I think OP meight achive what's supposed to be... I've added error handler and set necessary system variables - for "Outer" - it's HPISLANDDETECTION - should be set to 1... So first step if he needs 3 hatches like in your picture - Kent's attachment is to use my HHB.lsp and create wipeouts for ex. triangles over hexagons... I've coded 2 times copy hatches so that originals stays in place... Then OP should use HHB-new.lsp - my last posted code and pick point on empty space between those 2 hatches - that's Kent's green hatch... As island detection is set to "Outer" it shoud do well, avoiding to fill inner hatchings...
But if OP has more than 3 to do, OP should apply my HHB.lsp more times and only at the end HHB-new.lsp... I've described procedure... But it's all semi automatic - so no full automatisation - that's over my head and I think that OP should agree with me, as HATCH origin point meight be 0,0 , but it could be anywhere and I think that there is no help for this kind of situations...
