WCS2OCS

[John Uhden]

WCS2OCS.LSP has been posted in

 

[Devin]

It appears at first glance to be a much different approach in method. But it seemed, without getting too deep into it, to use the same math methods?
Is that correct?

Devin

 

[Joe Burke]

Thanks, John.

One question, in your comments:

;; Function to transform a point from either:
;; the MCS of an entity selected by (nentsel), or
;; the OCS of an entity selected by (nentselp)

I thought MCS and OCS are the same thing. That MCS is the previous term for OCS. Or am I missing something here?

Joe Burke

 

[John Uhden]

It's exactly the same except for the way of passing arguments. I basically just skipped all Larry's (nth) functions and got to the point, plus a few other shortcuts.

 

[John Uhden]

BTW, Devin (you naughty boy for responding in CF!) I want the function names to be kept as is because...

1. We don't want to run into the "whose function is that anyway?" scenario.
2. We actually might understand each other when referring to them and the problems that may arise in using them.
3. Just because.

 

[Joe Burke]

John,

No big deal as long as the group agrees the two acronyms are functionally the same.

I plugged your revised stuff into my AngleBetween function. Works fine. If you recall, that was the function which prompted my thread a few months ago about WCS to OCS.

I had to change a couple intances where I had renamed your @PTrans function to @OCS2WCS. I'm sorry about posting the renamed version recently. I understand why I shouldn't have done that. I'm back in line now. I guess you know renaming just seemed symmetrical.

Thanks again
Joe Burke

 

[John Uhden]

You're fine, Joe. But, come to think of it, your renaming of the @PTrans function probably subliminally reinforced my opinion about renaming. Who knows what matrix will be thrown at the function? It just transforms whatever you feed it, thus the generic name.

Of course I still have this annoying problem with the fact that the (xentselx) functions return the pick point without any meaningful Z value. I've complained about this before. Suppose you want to pick a segment of a 3DPolyline (nested or not). An (osnap pt "_quick,_near") might find a point on another nearby object. A (vlax-curve-getclosestpointto) might find a different segment because the distance is affected by the Z values. But I guess that should be in a different thread.

 

[Devin]

I take it you're not supposed to respond in CF's?

Devin

 

[John Uhden]

Very good, Devin! Just watch out; 'cause after 3 responses there, Anne will send a diseased moose to leave unmentionables in your mukluks. :]