Jump to content

Find exact insertion point


ripuz

Recommended Posts

Hi!

 

Does anyone know how to find the exact insertion point of a block with autolisp?

And with "exact" I mean with all decimals.

 

If a block is inserted with snap and then moved 0.0000001 to the left. Is it then possible to find that block with autolisp?

 

Thanks in advance

/ Thomas

Link to comment
Share on other sites

contrary to what other people think, when you retrieve the insertion point of a block , it WILL give you the exact coordinate. You may not "see" it, but i tell you now. IT IS.

 

Try inserting a block at 0,0 coordinates. and move that block 0.0000001 then use

 (Cdr (assoc 10 (entget (Car (entsel)))))

You will get something like (1.0e-007 0.0 0.0)

Link to comment
Share on other sites

The code below will allow you to see the available number of decimals:

(if (setq itemBlock (ssget ":S" '((0 . "INSERT"))))
(progn
 (setq pointIns (cdr (assoc 10 (entget (ssname itemBlock 0)))))
 (prompt (strcat "\Insertion point:"
                 "\n   X = " (rtos (car   pointIns) 2 18)
                 "\n   Y = " (rtos (cadr  pointIns) 2 18)
                 "\n   Z = " (rtos (caddr pointIns) 2 18)))
)
)

Link to comment
Share on other sites

@pBe: While the example shows correctly, I think it might be unclear about rounding off errors. If the insertion point is somewhere away from 0,0,0 and also ever so slightly off a full number (integer) then you might find that the display of the insertion point omits the decimals (this is due to the LUPREC setting).

 

@ripuz: Even if you set the precision as high as possible, it might still not display all the decimals. The returned value (as pBe's shown) is still the "exact" point though, it might just be difficult to display to absolute accuracy. All calculations on such point uses the double precision floating point value returned with entget, not the value you see on the command line in the list command. It's not "perfect" accuracy, but it's as good as it gets, since acad itself only uses double precision floating points internally. There are some small errors (called floating point errors), which might crop up - but they're generally to 16 decimal digits or less. http://en.wikipedia.org/wiki/Floating_point

Link to comment
Share on other sites

contrary to what other people think, when you retrieve the insertion point of a block , it WILL give you the exact coordinate. You may not "see" it, but i tell you now. IT IS.

 

Try inserting a block at 0,0 coordinates. and move that block 0.0000001 then use

 (Cdr (assoc 10 (entget (Car (entsel)))))

You will get something like (1.0e-007 0.0 0.0)

 

Okey, I see... I did as you said and i got the same answer as you but only when x are close to zero.

If the block is located at 99.999999, 100 the answer will be (100.0 100.0 0.0).

 

I got your point though... That the coordinates is the right coordinates, it´s just not displayed exactly.

And to show it:

(rtos (Cadr (assoc 10 (entget (Car (entsel))))) 2 

 

Thanks for you quick reply pBe!

Link to comment
Share on other sites

@pBe: While the example shows correctly, I think it might be unclear about rounding off errors. If the insertion point is somewhere away from 0,0,0 and also ever so slightly off a full number (integer) then you might find that the display of the insertion point omits the decimals (this is due to the LUPREC setting).

 

@ripuz: Even if you set the precision as high as possible, it might still not display all the decimals. The returned value (as pBe's shown) is still the "exact" point though, it might just be difficult to display to absolute accuracy. All calculations on such point uses the double precision floating point value returned with entget, not the value you see on the command line in the list command. It's not "perfect" accuracy, but it's as good as it gets, since acad itself only uses double precision floating points internally. There are some small errors (called floating point errors), which might crop up - but they're generally to 16 decimal digits or less. http://en.wikipedia.org/wiki/Floating_point

 

Thanks irneb, now I´ll understand.

Link to comment
Share on other sites

Also keep in mind that the precision is inverse proportional with the "size" of the number:

(rtos 12.345678901234567 2 18)
[color=magenta];Return> "12.34567890123457"[/color]

(rtos 1234567.8901234567 2 18)
[color=magenta];Return> "1234567.890123457"[/color]

(rtos 12345678901234.567 2 18)
[color=magenta];Return> "12345678901234.57"[/color]

Link to comment
Share on other sites

Yes, the ~16 digits means 16 in total. Not 16 after the decimal point. So as Mircea's shown the rounding / floating point error becomes worse the further you are away from 0,0,0. For this reason I prefer drawing as close as possible to 0,0,0 and using UCS's for stuff like coordinate references.

Link to comment
Share on other sites

I got your point though... That the coordinates is the right coordinates, it´s just not displayed exactly.

Thanks for you quick reply pBe!

 

Good for you

 

@Msasu/Irné

All bases covered :thumbsup:

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...