Coordinate of the centre of a circle

[wimal]

I am comfused PLEASE HELP

(setq r(cdr(assoc 40 ent)) )

; radious fo circle

How can get the center coordinate of this circle

[hmsilva]

(setq c (cdr(assoc 10 ent)))

[wimal]

Thanks you are correct.But when I move ucs some where and reload this code the value is not correct.

[hmsilva]

take a look in "trans" function...

(setq c (cdr(assoc 10 ent)));; wcs point
(trans c 2 1);; ucs point

Henrique

[wimal]

Thanks , Your code is grate.

[hmsilva]

You're welcome, Wimal

Glad I could help

 

Henrique

[Lee Mac]

take a look in "trans" function...

(trans c 2 1);; ucs point

 

The trans argument 2 indicates the input is expressed in DCS (Display Coordinate System), however, coordinates for most planar objects (circles included) are expressed in the OCS of the entity; I would hence suggest:

 

(trans (cdr (assoc 10 ent)) (cdr (assoc 210 ent)) 0)

Assuming the variable ent is assigned the DXF data for the circle, the above will return the coordinates of the circle center w.r.t. WCS; the 0 may be changed to 1 if the output is required w.r.t. the active UCS.

[hmsilva]

Lee Mac wrote:

 

"The trans argument 2 indicates the input is expressed in DCS (Display Coordinate System), however, coordinates for most planar objects (circles included) are expressed in the OCS of the entity"

 

Completely correct, my mistake, and my apologies if I confused someone...

 

Henrique

[Lee Mac]

No worries Henrique

[fixo]

I would hence suggest:QUOTE]

Thought, same as

 (trans (cdr (assoc 10 ent)) ent 0)

Or I missed something?

[hmsilva]

maybe

(trans (cdr (assoc 10 ent)) (cdr (assoc -1 ent)) 0)

 

Henrique

[Lee Mac]

I would hence suggest:

Thought, same as

 (trans (cdr (assoc 10 ent)) ent 0)

Or I missed something?

 

As Henrique has suggested, the equivalent using an entity name argument would be:

(trans (cdr (assoc 10 ent)) (cdr (assoc -1 ent)) 0)

Assuming that the variable ent points to a DXF data list (confusing, I know - but I was simply following the variables supplied by the OP).

 

For a Circle, these methods are equivalent since the Circle coordinates are defined in the OCS, however, observe that when using an entity name as the trans output argument for entities such as the Ellipse or MText entity, coordinates will be returned in WCS (even though these are planar entities) whereas, when using the extrusion vector (DXF Group 210) for these entities, the points will be returned w.r.t. an OCS calculated for that entity (using the Arbitrary Axis Algorithm).

 

To demonstrate, draw an Ellipse in a plane other than the WCS plane and run the following code:

(defun c:test ( / dxf sel )
   (if (setq sel (ssget "_+.:E:S" '((0 . "ELLIPSE"))))
       (progn
           (setq dxf (entget (ssname sel 0)))
           (princ "\nCenter in WCS: ")
           (princ (cdr (assoc 10 dxf)))
           (princ "\nReturn of (trans <WCS-Center> 0 <ellipse-entity>): ")
           (princ (trans (cdr (assoc 10 dxf)) 0 (cdr (assoc -1 dxf))))
           (princ "\nReturn of (trans <WCS-Center> 0 <extrusion-vector>): ")
           (princ (trans (cdr (assoc 10 dxf)) 0 (cdr (assoc 210 dxf))))
       )
   )
   (princ)
)

Note the difference in the return from using the entity name argument and the extrusion vector argument.

 

Just something to keep in mind.

[hmsilva]

Lee Mac wrote:

"...

Note the difference in the return from using the entity name argument and the extrusion vector argument.

Just something to keep in mind."

 

It really is...

Thank you!

 

Henrique

[fixo]

Try this out in any ucs then

(princ (trans (cdr (assoc 10 dxf)) (ssname sel 0) 0 ))

same result on my end

[hmsilva]

Hi fixo,

what Lee Mac is demonstrating, is, when the OCS is not parallel with WCS (need to rotate the z axis), using the entity name instead of the extrusion vector, the result is incorrect...

Tested in multiple UCS, and I only detect the error using a UCS non parallel to the WCS.

From now on, I will use the DXF Group 210 for coordinate systems transformations (if I don't forget, I'm getting too old).

 

Cheers my friend

Henrique

[fixo]

Thanks Henrique , I knew that

I tested as well with rotated Z axis and X axis, same result

Cheers

[Lee Mac]

Thank you!

 

You're welcome Henrique!

 

Try this out in any ucs then

(princ (trans (cdr (assoc 10 dxf)) (ssname sel 0) 0 ))

same result on my end

 

Yes, since an Ellipse is already defined relative to WCS, the trans function is not altering the supplied coordinates in any way since the expression is equivalent to:

(trans (cdr (assoc 10 dxf)) 0 0)

However, my point was that when transforming coordinates from UCS/WCS to the OCS of a planar entity, the result will be different if an entity name is used in place of an extrusion vector for entities such as Ellipses or MText (since these planar entities are exceptions and are defined wrt WCS rather than OCS).

 

what Lee Mac is demonstrating, is, when the OCS is not parallel with WCS (need to rotate the z axis), using the entity name instead of the extrusion vector, the result is incorrect...

Tested in multiple UCS, and I only detect the error using a UCS non parallel to the WCS.

From now on, I will use the DXF Group 210 for coordinate systems transformations (if I don't forget, I'm getting too old).

 

You are correct Henrique, however, please note that this difference is only applicable to entities such as Ellipses & MText which, although planar, are defined relative to WCS rather than the OCS as with other planar entities - there may be other exceptions, but these two entities spring to mind.

 

As noted:

 

For a Circle, these methods are equivalent since the Circle coordinates are defined in the OCS, however, observe that when using an entity name as the trans output argument for entities such as the Ellipse or MText entity, coordinates will be returned in WCS (even though these are planar entities) whereas, when using the extrusion vector (DXF Group 210) for these entities, the points will be returned w.r.t. an OCS calculated for that entity (using the Arbitrary Axis Algorithm).

 

I hope my explanations are clear!

[pBe]

Great explanation yet again LM

[Lee Mac]

Great explanation yet again LM

 

Many thanks pBe; the point I raised was rather subtle, but I've been caught out in the past by using an entity name in place of an extrusion vector when working with these planar entities which are exceptions to the use of the OCS.

[hmsilva]

Lee Mac wrote:

"...

I hope my explanations are clear!"

 

Your explanations, as always, are clear.

 

Thank you!

Henrique