text in a UCS

can anyone tell me what's happening here?

from World, in UCS rotate the ucs around Y 180, then around Z 345.
type PLAN <enter> CURRENT <enter>

now put a piece of text on the screen, middle justified, somewhere away from
0,0

(setq TXT (entlast))

now, draw a line from:
(cdr (assoc 10 (entget TXT))), or
(cdr (assoc 11 (entget TXT)))

why don't either of these point start a line at one of the alignment points
of the text?

using trans didn't solve it, but you shouldn't need trans as the text was
created in the current ucs right?

thanks for your time,
daron

 

The point that is returned is in the WCS and you need to translate that to you Current UCS. In my test it worked once I did the trans function.

Left justified
(trans (cdr (assoc 10 (entget (entsel)))) 0 1)
Other justifications use assoc code 11

Tim

 

i'm not getting the same thing. when i use trans, the point is even farther
away. did you rotate BOTH Y and Z? it works fine here if i do only one or
the other, but not both.

any suggestions?

thanks,
daron

you Current UCS. In my test it worked once I did the trans function.

 

I only rotated my ucs one way. After doing it both I see that you are correct, and the beginning of the line is not close to the Insertion point of the text.

I'm not really sure how to solve this one, but you might need a matix equation, and I have seen some posted in here.

Sorry I couldn't be more help. Hopefully someone that uses 3d more will chime in and help.
Tim

 

Daron,

Try this. Assuming the TXT symbol represents the ename of a text object entered in
the rotated coordinate system you mentioned.

Start the line command. Paste this to the command line:

(trans (cdr (assoc 10 (entget TXT))) TXT 1)

The line should start at the text insertion point.

HTH
Joe Burke

 

Nice one Joe, and hello. =)

So if I understand it right you are transforming the point from the object coordinate system to the user coordinate system?

If so, I thought the point that was returned by the dxf code was in the world coordinate system. Could you explain a little.

Thanks.
Tim

 

Hi Tim,

I'm on shakey ground here. James Allen would probably provide a more detailed
explanation of how it works.

Yes, transform the point from OCS to UCS, using the ename of the object in question
as the "from" argument.

As I understand it, a UCS rotation about the Z axis alone does not alter the "normal
vector" associated with a new object. But that's not the case after rotating the
coordinate system two ways, as mentioned here.

That's why I thought using the ename of the object as the "from" argument might work.
If it does, and it seems to, it was just a lucky guess.

I guess you could say programming boils down to intuition after you get past the
mechanics. That's not meant to imply I'm past the point. Only that I'm aware of
others who are.

Joe Burke

 

Joe,
are you in the Phoenix area? i would like to buy you a steak dinner!

thanks )
daron

 

Cool. Thanks for the info.

Tim

 

Hi Joe, that sounds right to me. Well, except for the shakey ground bit.
And I know there are others here who know far more about this than I.

Tim, the entity data in this case is reported in OCS coordinates, which for
most 2d work just happens to coincide with the WCS. You can find a good
summary in the topic titled "Object Coordinate Systems (OCS)" in the DXF
reference.

 

James,

I don't have your email address, so I'll post this here.

Wanted to let you know those functions you pointed me to in BlockSwap.lsp fixed the
problem I had with my matrix functions. If you recall, they didn't return the correct
answer when the block passed had a normal other than (0 0 1). So I'm using your
MWE:GetNMatrix function and the others it calls. From that I get a matrix which is
plugged into the matrix multiplication sequence at the end of ObjMatrix and
InverseObjMatrix.

Many thanks.

Joe Burke

 

Daron,

You're welcome.

I'll take a rain check on your offer. I'm in the Honolulu area.

Joe Burke

 

James,

Thanks for the tip. I love understanding why/how things work.

Tim

 

I tried sending this email to your address as shown in the quote back, and
it bounced back. Is the dot railroad supposed to be removed, or something
else? <JamesA~AA~mwengrs~DD~com>

<begin original email>

Hi Joe,

That's great! If you want any explanation of what I posted, I'd be happy to
attempt. While I was gone I did look over the code you posted and it looks
good. The list of blocks part, AFAIK, is the only way to get the correct
matrix if you are picking a nested block or need just parts of the overall
matrix.

I haven't forgotten about the new thread I mentioned starting. I plan to
repost the subs from BlockSwap.lsp in better form. I'm already in the
process of optimizing them (or at least trying to) since I use them pretty
heavily in general, and particularly for copy/highlighting nested items,
hence that ca[d.]r thread I started.

James

<end original email>

 

James,

You can send me private mail by adding an "e" at the obvious place within my name
given the address you see here. BTW, "rr" stands for RoadRunner. Hope that's clear.
I'm really paranoid about my address in newsgroups. Please try to send me mail. I'd
like to have your address as well.

I haven't had time to study the functions in BlockSwap, other than to understand them
well enough to put them to use. I did wonder what might be involved to condense
MWE:GetNMatrix to a single function. As is it calls MWE:ArbAxis and MWE:GetOMatrix.
And those call MWErojUV and MWE:CrossProd. Which I'm sure makes perfect sense
within the scheme of things. But of course I don't have a use for the other four
functions beyond supporting MWE:GetNMatrix.

If I'm sounding ungrateful, I don't mean to. It's really nice to have this last
problem resolved. As you know, your functions and mine are doing similar things.
Though I tend to take a less modular approach. The thing is I have some programs
which depend on these functions working perfectly. It sure was nice to see them
behave as expected after incorporating MWE:GetNMatrix. Given people send me drawings
with blocks that have a normal of (0 0 -1). I have no idea why and only some of the
blocks are that way.

So thanks again.

Joe Burke