Different Insertion points in dxf and actual drawing

Steven Langhammer

Hello there,
I've stumbled upon a strange behaviour, which I can't explain to myself.
The attached picture shows a snapshot from BricsCAD. Important for this case are the values of X, Y and Z for the position.
When I look into the ascii dxf file, I find the insert like this:

  0
INSERT
  5
156D
330
1F
100
AcDbEntity
  8
chrom
100
AcDbBlockReference
  2
rohr350_TKY8M02
 10
234.069563931076
 20
135.500022776367
 30
-16.259552404394
 50
180.0
210
0.0
220
1.0
230
6.123233995736766E-17

As you can see the values for Y and Z are exchanged with oneanother and the sign infront of the X is wrong.

There is no UCS at all used in this drawing and no paperspace used only the modelspace. Does anyone have an idea, what might cause this difference?
(This post is mirrored from The Swamp)

Robt Deans

What's your BASE / INSBASE?

Torsten Moses

The entitie' own OCS (object coordinate system) has a Z vector (or called "normal") which is (0,1,0) ... the coordinates in DXF are based on that OCS.
Seems. the INSERT was inserted on a UCS parallel to XZ-plane ?

Daniel Eiszele

Stephen, Google the 'arbitrary axis algorithm'. The 210, 220 and 230 codes will help you do the conversion to ace.

Daniel Eiszele

Sorry, ace = wcs (auto correct)

Steven Langhammer

I Set the Insbase to 0,0,0. The Block's basepoint is 0,0,0 as well.

I read the information out via LISP, I get the insertion point using the "trans" function to get it in WCS.

There is no UCS in the drawing file.

Handleing the Extrusion direction isn't my task, a collegue handles it and he managed it well in other cases. Or do the 210, 220 and 230 codes actually influence the visualisation of the values in Bricscad?

Daniel Eiszele

The insertion point for inserts is stored in ocs coordinates not wcs, so yes you do need to take the extrusion values into account.  This has nothing to do with a ucs. See the following for conversion info. The arbitary axis algorithm is found in the link at the end. http://www.autodesk.com/techpubs/autocad/acadr14/dxf/object_coordinate_systems_40ocs41_al_u05_c.htm Also yes the extrusion values do affect the output in bricscad and autocad.

Steven Langhammer

Like I said, I use LISPs trans function to handle  to handle the the ocs/wcs difference. It works perfectly fine in oter parts of my script. Maybe I do make a misstake with that somehow though.

[code]entPt  (trans(cdr(assoc 10 ent))1 0)[/code]

Torsten Moses

a) to transform from "Entity OCS -> UCS" : (trans (cdr (assoc 10 ent)) ename 1) ;; ename is the -1 entity name
b) to transform from "Entity OCS -> WCS" : (trans (cdr (assoc 10 ent)) ename 0) ;; ename is the -1 entity name

your code (trans ename 1 0) means : from "current UCS -> WCS", which is fine for points retrieved from user input;
your sample only works correctly, as long as the "entity coordinate system" is identical to actual UCS;

So it seems the safest way to use "(trans (cdr (assoc 10 ent)) ename 0)" always for points of entities;
it also works for entities which always have "World" as entity coordinate system.

I hope this helps ?

Steven Langhammer

Thank you Torsten!

As it seems I missunderstoof the trans-function somehwat. I'll re-read the definition again to see where my understanding error was.