shifting centerpoint on angle

Ok, this got a little more complex. I'm getting the angle of a room to drop in the ceiling grid now, like this:

(setq ang (angtos (getangle "\nPick two points to set angle. ") 0 4))

then I drop in the ceiling grid, and then I get the centerpoint of the room like this:

(setq obj (vlax-ename->vla-object region))
(setq center (vlax-get obj 'centroid))

So, my variables are "center" for the centerpoint and "ang" for the angle of the room. Now, I shift the grid vertically or horizontally, but right now I have it set up to just shift the grid straight up or straight over by taking the "center" variable and doing addition to it, but what if I want to incorporate an angle onto that? Here's what I have for shifting the centerpoint:

(setq shift-v (getreal (strcat "\nEnter distance to shift grid vertically <" defshift-v ">: ")))
(if (not shift-v)(setq shift-v (atoi defshift-v)))
(setq center (mapcar '+ center (list 0 shift-v)))
(command "hatchsetorigin" "last" "" center)

What I'm looking to do is take the center and add shift-v onto it at a certain angle (which would be my variable "ang") Anyone know how to do this?

 

Use (polar... With that you get a new point per your old point.
ie.
(setq tmpPt (polar center (DTR 0) 1))
This will move your point form your center point 1 unit in the 0 direction (angle).

Hope that helps.
Tim

 

As we discussd before, polar would be the way to do this.

Just to confirm, are you talking about only shifting the grid along its own axes? For instance, if the grid angle is set at ang for the room, would the shift be always parallel or perpendicular to ang?

 

Yes, the grid would only be shifted parallel or perpendicular to ang.

 

I got the horizontal shift on an angle to work. This is what I did:

(setq center (polar center (angtof ang) shift-h))

But, I'm not getting my vertical shift to work. For that I need to take ang (which is a string right now) and add 90 to it, then turn it back into floating point with angtof. So, this is what I have for vertical shifting:

(setq ang-v (+ (atoi ang) 90))
(setq center (polar center (angtof ang-v) shift-v))

Should I just add the floating point equivalent of 90 to ang?

 

How are you getting your angle? You should be getting it as a "real" number, so then when you add the 90 degrees to it it will be fine. If you are getting it in radians then add the 90 degrees like (setq ang-v (+ ang (DTR 90))) DTR = degrees to radian function. Then you can just plug that into the polar command because it wants radians.

Tim

 

Perfect! My angle was put into a degrees format right away, like this:

(setq ang (angtos (getangle "\nPick two points to set angle. ") 0 4))

So, I had to switch ang back into radians. I put in:

(setq ang-v (+ (angtof ang) (DTR 90)))
(setq center (polar center ang-v shift-v))

and it works perfect!

Thanks a lot Tim and Tom!

 

You're welcome. Glad it works.

Tim

 

What vertical app are you running? Hatchsetorigin isn't a native Acad 2004
command.

Also, you seem to be assuming the existence of a region, possibly created
earlier within your program? I've been wondering about the pros and cons of
using a region's centroid as the origin of a ceiling grid.

In two cases it would be ideal. The most common situation would be a
rectangular room, where the centroid would be the same as the midpoint of
the room's diagonal. Last time I did a (very simple) ceiling-related
routine, long before vlisp, I simply prompted for picking opposite corners
of the room, and got the center point that way. In the majority of
situations this was fine. The centroid business would select the same point
in a more sophisticated way, but I wonder how your interface works -- is it
faster or easier than just picking two points?

The other case would be a wildly irregular or rounded or angular room, in
which the midpoint can't be so easily defined. This is where the centroid
would give you a darn good place to start, when followed up with the
centerpoint-shifting loop.

However, I wonder about another case, which I think is the next most common
behind a plain rectangular room -- namely, a room that's chiefly a simple
rectangle, but has one or more small places where the perimeter jogs in or
out, for instance at a door alcove. In that case, I would lay out the grid
centered on the primary rectangle, with little or no regard for how it
happened to fall in the minor "jog" space. It seems to me that in this case
you wouldn't want to use the true geometric centroid of the total area,
because the minor irregularity in the perimeter would pull the centroid
slightly away from the center of the predominant rectangle. Does that make
sense? I wonder if your larger routine will provide a way to work around
this. I'd hate to have to sit there and fiddle with the grid-shifting loop
just to get the center nudged over a tiny smidgen to the place I would have
wanted it to start from the get-go.

 

To answer all the questions:

Hatchsetorigin could be a base AutoCAD 2005 command, but I am using ADT2005. Which I wouldn't know why they would add it in for architecture only, so my guess is that it is a AutoCAD 2005 native command. It's on the right-click menu as 'Set Origin' when having a hatch hightlighted.

I have the centroid of the room calculated automatically, because the person has two options: Select object or Pick point. If they select a pline it is converted to a region first, then the centroid is pulled from the region. If they pick a point it creates a region and then pulls the centroid.

Which, you are 100% correct about. It gets the center perfectly for a rectangular room. A very oddly shaped room you are going to have to shift around the grid anyway. But, a room with just a corner missing out of it will put the centroid at a point slightly off considering the person will usually want the center of the overall rectangle overlooking the missing corner that it has.

I have no clue on how to account for that, unless the centroid was derived from the middle of the longest distance in the x-axis and the middle of the longest distance in the y-axis, which wouldn't work out well for rooms on angles either. I guess the best work around I have is when repositioning, I have two options, one to shift the grid and the other to pick a point. They can do pick point and track from the midpoints to get the center easily enough if they wanted to.

 

Yup, if I unload ADT, hatchsetorigin still runs, so it must be new to 2005.