Topic: Akward rotations with blocks in blocks and 3d-faces

[S.Langhammer]

Hey, some new error poked up lately.
Für some reason a lot of 3d faces showed up just wrong. The attached file "original" shows, what the object is supposed to look like. "imported" shows,what it looks like after my script red it out.

I might be wrong, but I suspect the way I read out inserts to be the cause. I might be wrong.

Code - Auto/Visual Lisp: [Select]

1. (defun getInsData( ent / entName entRot entNorm entPt test Blk blkPt)   ;;;Inserts
2.         (setq entNorm   (cdr(assoc 210 ent))                    ;;; extrusion vector
3.                   entPt         (trans(cdr(assoc 10 ent))1 0)   ;;; insertion point
4.         )
5.         ;;; handle anonymous blocks
6.         (if (=(substr(setq entName(cdr(assoc 2 ent)))1 1)"*")(progn
7.                 ;;; simplify if possible
8.                 (setq test 0)
9.                 (while  (< test 5)
10.                         (if(= T(contentCheck(Blk_ENameLstNstd entName)))
11.                                 (simplify blkN)
12.                         )
13.                         (setq test (1+ test))
14.                 )
15.                 (fileWrite (strcat "BLOCK," entName))
16.                 ;;; 0 . Entity type
17.                 ;;; 1 . Block name
18.                 (getinfo (Blk_ENameLstNstd entName))
19.                 (fileWrite (strcat "End of " entName))
20.         ))
21.         (setq blk (entget(tblobjname "BLOCK" entName))
22.                   blkPt(cdr(assoc 10 blk))
23.         )
24.         (if (= T (contentCheck(Blk_ENameLstNstd entName)))
25.                 (fileWrite(strcat "INSERT,"     ;;; 0 . Entity type
26.                 (cdr(assoc 8 ent))","   ;;; 1 . Layer
27.                 entName ","     ;;; 2 . Block name
28.                 (rtos(-(car entPt)(car blkPt))2)","     ;;; 3 . X
29.                 (rtos(-(cadr entPt)(cadr blkPt))2)","   ;;; 4 . Y
30.                 (rtos(-(caddr entPt)(caddr blkPt))2)"," ;;; 5 . Z
31.                 (rtos(cdr(assoc 41 ent))2)","   ;;; 6 . scale X
32.                 (rtos(cdr(assoc 42 ent))2)","   ;;; 7 . scale Y
33.                 (rtos(cdr(assoc 43 ent)) 2)","  ;;; 8 . scale Z
34.                 (if(setq entRot(cdr(assoc 50 ent)))(vl-string-right-trim "r"(angtos entRot 3))"0")","   ;;;; 9 . rotation
35.                 (rtos(car entNorm)2)","         ;;; 10 . extrusion X
36.                 (rtos(cadr entNorm)2)","        ;;; 11 . extrusion Y
37.                 (rtos(caddr entNorm)2)))        ;;; 12 . extrusion Z
38.         )
39.         (princ)
40. )
41.  

I read out the blocks almost exactly the same way I read out the anonymous blocks, that I handle via getInsData. The basic difference is, that I ignore anonymous blocks at first.
I already handle angbase and angdir. Is there any other possible way to influence the rotation of inserts or rotation in general? Anything I could have possibly forgot or didn't know yet? Is there any other rotation that might have an influence? Am I just badly wrong about something in the function?

Edit: Once I explode all blocks, I get a perfect result, so it can't be the face's fault.

[David Bethel]

Just as a guess, all points in a 3DFACE are WCS.  Is there a (trans) some where that could be affecting the BLOCK ?  Also 3DFACEs do not have a group 210 value.

[S.Langhammer]

Before I read anything I do this: (command "_.ucs" "w")
As I understand it, that sets the WCS current, and there's no trans in use.
When I explode all blocks, the drawing looks perfectly fine.

I just looked into the DXF and got this example:

  0
INSERT
  5
D2
330
1F
100
AcDbEntity
  8
0
100
AcDbBlockReference
  2
griff_m_nummer_TKY8M0
 10
-271.569702148438
 20
-51.9595222473145
 30
43.200080871582
 50
180.0

And in the formated file I print out it looks like this:

INSERT,0,griff_m_nummer_TKY8M0,-271.5697,-51.9595,43.2001,1,1,1,3.1416,0,0,1

It's formated like this: "ent type, Layer ,Block name, insert X, insert Y, insert Z, scale X, scale Y, scale Z, rotation in rads,  extrusion X, extrusion Y, extrusion Z
3.1416*57.2957795 = ~180°

Doesn't look error-esque to me... Yet well scrambled inserts...