There is a way to steal the direction a polyline is in accordance with the block, whether it is on the right, left, front or back and how many are in that direction.
and return a list like this ' ((2 "front") (0 "back") (2 "right") (1 "left"))
if someone helps me i will be very happy,
Thank you very much in advance!
I'm not sure how to approach that, but clarify something:
According to the count, the red-circled diagonal line is apparently counted as going to the front, and the other diagonal one to the right. But the red-circled one is closer in angle to the right than to the front. What criteria determine what constitutes "front"-ward as opposed to "right"-ward?
Thanks for the answer.
You're right, it was very confusing even for me.
it is not necessary to be very precise, the important thing is to indicate the direction and quantity.
so the understanding is better are basically these senses
return '((1 "N") (2 "E") (1 "NE") (1 "O"))
Different approach to the problem
(defun c:indira ( / deg_to_rad pt p1 p2 anglist dirlist ss i ret)
(defun deg_to_rad (deg)(* pi (/ deg 180.0)))
(setq pt (getpoint "\nSelect centerpoint >"))
(setq anglist (mapcar 'deg_to_rad '(45 135 225 315 45)))
(setq dirlist '("N" "O" "S" "E"))
(setq i 0)
(foreach dir dirlist
(setq p1 (polar pt (nth i anglist) 5))
(setq p2 (polar pt (nth (+ i 1) anglist) 5))
(setq ss(ssget "F" (list p1 p2)))
(if ss (setq n (sslength ss)) (setq n 0))
(setq ret (cons (list n dir) ret))
(setq i (+ i 1))
)
(reverse ret)
)
(defun c:indira ( / deg_to_rad pt p1 p2 anglist dirlist ss i ret)
(defun deg_to_rad (deg)(* pi (/ deg 180.0)))
(setq pt (getpoint "\nSelect centerpoint >"))
(setq anglist (mapcar 'deg_to_rad '(22.5 67.5 112.5 157.5 202.5 247.5 292.5 337.5 22.5)))
(setq dirlist '("NE" "N" "NO" "O" "SO" "S" "SE" "E"))
(setq i 0)
(foreach dir dirlist
(setq p1 (polar pt (nth i anglist) 5))
(setq p2 (polar pt (nth (+ i 1) anglist) 5))
(setq ss(ssget "F" (list p1 p2)))
(if ss (setq n (sslength ss)) (setq n 0))
(setq ret (cons (list n dir) ret))
(setq i (+ i 1))
)
(reverse ret)
)
Miljenko Hatlak
@adaptacad wrote:
.... to indicate the direction and quantity.
so the understanding is better are basically these senses
return '((1 "N") (2 "E") (1 "NE") (1 "O"))....
But that should be determining angles not in relation to absolute compass directions, but as directions relative to the rotation of the Block, if I understand the image in Message 1 correctly.
I see a problem with the nature of the Polylines. The long horizontal above is one Polyline all the way across [though at least it has a vertex in the middle], so the same Polyline extends in more than one direction from the Block, and that is in its drawn direction on one side but in the opposite direction on the other side. Likewise for the two diagonals, which are a single Polyline. In other situations in the sample drawing, there are L-shaped 2-segment ones, and some that extend in only one direction with a single segment. It would be difficult to find an approach that can account for all those possibilities, and would be much easier if all of them were separate ones, with none continuing through at the middle. I think @doaiena 's suggestion assumes they are separate, since it looks at each Polyline only once, not one segment at a time. That can give only one result per Polyline, but you are looking for two results from many of your Polylines.
But even if they were all separate pieces, that approach could, I think, give opposite-direction results in some cases if any are drawn in the inward direction, depending on the specific position of their inward end relative to the reference point or the Block. If the nearest point of one drawn inward is at the downstream end, there will be no next parameter value, so the angle measurement will fail. If the nearest point on it isn't at the very end, whether User-selected or based on the Block's insertion point, then the rounded-down parameter will be at the outward end, and the angle will be measured in the opposite direction from the one intended. This would be the case, for example, in the upper non-orthogonal situation if its lower-right Polyline were drawn from the outside in, instead of the way it is, and if the reference point is the Block insertion point. @doaiena's suggestion asks the User for the reference point, but it would make sense to me to have that taken from the Block, since the Block needs to be selected anyway, if the angle determinations are to be relative to its rotation angle.
Also, are they always Polylines, or might they sometimes be Lines, or something else?
You can do what ever you like. Just define what you would like.
Miljenko Hatlak
@adaptacad wrote:
....(setq anglist (mapcar 'deg_to_rad '(22.5 67.5 112.5 157.5 202.5 247.5 292.5 337.5 22.5)))(setq dirlist '("NE" "N" "NO" "O" "SO" "S" "SE" "E"))....(setq p1 (polar pt (nth i anglist) 5))(setq p2 (polar pt (nth (+ i 1) anglist) 5))(setq ss (ssget "F" (list p1 p2)))....
I'm wondering [without trying it].... If a Line or Polyline or whatever lies exactly on one of those break-point directions, such as 22.5°, won't it be touched by the Fence selection for two of the octants, and therefore be counted twice? Maybe you would want it counted for both octants, but if not, some criteria would be needed for which of them to include it in.
[Also, I don't know the typical circumstances, but that 5 for the distance from the center in setting p1 & p2 requires that all objects to be found must come at least to within 5 drawing units of the center at their inner end, and extend at least to 5 drawing units away at their outer end. Would that always be the case?]
@adaptacad wrote:
@Kent1Cooper I don't understand what you mean, can you give me an example ?? ....
When I do this:
yellow-to-green should be the Fence for the NorthEast octant, and it should find both the 22.5° and 67.5° lines. And green-to-cyan should be the Fence for the North octant, and it should find both the 67.5° and 112.5° lines. Using the indira command on them returns this:
((0 "NE") (1 "N") (1 "NO") (0 "O") (0 "SO") (0 "S") (0 "SE") (1 "E"))
It's seeing all three lines, only once each, but note that two of them [N, NO] are being counted in the octant that is counterclockwise from the line's direction, but one [E] is being counted in the octant that is clockwise from the line's direction.
I assume the fact that none of them is being counted in two adjacent octants is a rounding issue in the degrees-to-radians calculations, and the Fence endpoints are not always precisely on the octant break directions, but these lines are. I tried it on this:
with all of the octant-dividing directions, and this was returned:
((0 "NE") (2 "N") (0 "NO") (2 "O") (0 "SO") (2 "S") (1 "SE") (1 "E"))
Some octants are not "given" any lines, some are given 1, and some 2. It may not be that some of those lines are being counted twice in two adjacent octants, because two of the Fences in the selections touch them [which is what I suspected might happen in my previous Reply], but at least some Fences are seeing the lines at both ends of them, and some are not seeing the line at either end.
I tried a different approach to the angle calculations:
(setq anglist '(1 3 5 7 9 11 13 15 1))
....
(setq p1 (polar pt (* pi (/ (nth i anglist) 8.0)) 5))
(setq p2 (polar pt (* pi (/ (nth (+ i 1) anglist) 8.0)) 5))
and got this result [different varieties of the same problem]:
((1 "NE") (0 "N") (1 "NO") (1 "O") (2 "SO") (0 "S") (2 "SE") (1 "E"))
