« previous next »
Pages: [1] |   Go Down

Author Topic: MLeader rotation  (Read 3271 times)

0 Members and 1 Guest are viewing this topic.

sinc

  • Guest
MLeader rotation
« on: July 04, 2008, 07:24:38 PM »
Anyone know how to create an MLeader that is oriented to the current DView TWist, ideally without creating a UCS?
Logged

MickD

  • King Gator
  • Posts: 3637
  • (x-in)->[process]->(y-out) ... simples!
Re: MLeader rotation
« Reply #1 on: July 04, 2008, 07:35:33 PM »
unless you can extract the ucs from the view directly I'd say you'll have to build it from the view direction vectors etc.
As you probably already know, you have to create the ent then transform it with a matrix which can be built by hand using your own vectors to construct pseudo UCS transformation or grab a UCS and build it from that, not much help I know.
cheers.
Logged
"Programming is really just the mundane aspect of expressing a solution to a problem."
- John Carmack

"Short cuts make long delays,' argued Pippin.”
- J.R.R. Tolkien

sinc

  • Guest
Re: MLeader rotation
« Reply #2 on: July 04, 2008, 07:50:33 PM »
How do I transform an MLeader?  I'm looking at that SetPlane() method, and wondering if that's the ticket...
Logged

sinc

  • Guest
Re: MLeader rotation
« Reply #3 on: July 04, 2008, 07:52:21 PM »
...or I see a transformBy method in the ObjectARX docs...  Do I need to PInvoke that to do it from C#.NET?


- edit -

D'oh!  Never mind!  I see TransformBy in the .NET API, too.  I suppose that's the thing to look at?
Logged

MickD

  • King Gator
  • Posts: 3637
  • (x-in)->[process]->(y-out) ... simples!
Re: MLeader rotation
« Reply #4 on: July 04, 2008, 08:02:23 PM »
yep, every 'entity' has a transformby(), they have to so it can be located in space as you need, whether you code in the plane (which gives the ent it's normal) or create it at the origin in WCS, sooner or later it has to be transformed.

In your case, if you can get a plane and an 'x' direction of it (twist may have something there) or at least 2 vectors of the view you can then build your matrix and pass that to transformby and you're done.
Logged
"Programming is really just the mundane aspect of expressing a solution to a problem."
- John Carmack

"Short cuts make long delays,' argued Pippin.”
- J.R.R. Tolkien

sinc

  • Guest
Re: MLeader rotation
« Reply #5 on: July 04, 2008, 08:21:09 PM »
Yep, seems to work just fine.  Thanks!
Logged

sinc

  • Guest
Re: MLeader rotation
« Reply #6 on: July 05, 2008, 12:54:25 PM »
Spoke too soon.

The TransformBy() works loosely, but there seem to be a number of issues created when applying this function to an MLeader...

There appear to be weird quirks in how this method is applied.  Since an MLeader location is based on the TextLocaition, as well as the vertices of the leaders, there are potentially a lot of points needed in order to specify the location of an MLeader.  In my tests, it does not appear that all the points rotate together when TransformBy() is called...

The most-insidious issue seems to be that at some DView TWist angles, the text is created upside-down.  I've tried changing the rotation of the MTEXT before adding it to the leader, but with lackluster results.

This MLeader API sure seems difficult to work with...
Logged

sinc

  • Guest
Re: MLeader rotation
« Reply #7 on: July 05, 2008, 01:51:56 PM »
OK, I think I have tentatively found that I can fix the upside-down text by changing the MLeader.TextAngleType to TextAngleType.InsertAngle - at least, I *think* that's working without unintended side-effects.  I've been here before, though, where I thought I had it figured out, only to discover some other weird effect in certain conditions...

This MLeader thing seems to be incredibly sensitive to the order of operations.  If methods must be called in some specific order to get them to work, then it would be really, really nice to have that information in the documentation.  The "trial and error" method of development is no fun.
Logged

sinc

  • Guest
Re: MLeader rotation
« Reply #8 on: July 05, 2008, 02:08:49 PM »
Sure enough, that seems to have fixed the upside-down text for everything except for when 90° <= DView TWist < 135°.  When DView TWist is in that one half-quadrant, I still get upside-down text.
Logged

sinc

  • Guest
Re: MLeader rotation
« Reply #9 on: July 05, 2008, 02:51:06 PM »
Ah hah!

Brain-dead error, I think.  I had an error in my transformation matrix creation.

I think I have that part working (I hope...).  Now to see if I can figure out why the leaders always come out the left side...

Logged

MickD

  • King Gator
  • Posts: 3637
  • (x-in)->[process]->(y-out) ... simples!
Re: MLeader rotation
« Reply #10 on: July 05, 2008, 07:22:44 PM »
sounds like you're having fun!
Logged
"Programming is really just the mundane aspect of expressing a solution to a problem."
- John Carmack

"Short cuts make long delays,' argued Pippin.”
- J.R.R. Tolkien

sinc

  • Guest
Re: MLeader rotation
« Reply #11 on: July 06, 2008, 09:36:58 AM »
Not really - I'd rather have good documentation, so I didn't have to do so much trial-and-error.  This is a VERY slow way to do development.

Finally discovered that many necessary functions are not exposed to the managed API for MLeaders.  Going through the ObjectARX documentation reveals some key methods - like Scale() and SetScale() - that are missing from the managed API.  I created PInvoke wrappers for those, and am now able to do some things I needed to do and couldn't.

But I still can't figure out how to get leaders to come out the right side.  No matter what I do, they always come out the left.

For example, taking the code from Kean's blog and running it on C3D 2009 with no changes, I get an image like the one attached, and not one like in Kean's screen shot.  I get this even if I use one of Autodesks default templates, such as the NCS Base, and use the Standard MLeader style found in that template.  But it looks like, for Kean, the leaders automatically came out the correct side.

Any idea why? 
Logged
Pages: [1] |   Go Up
« previous next »