Jump to content
  • 0

Rotated rectangles


BG

Question

24 answers to this question

Recommended Posts

  • 0

BG,

A Rectangle object is defined by two points, upper left & lower right. The other two points are implied from the first two. This is achieved because the implied points fall on the orthogonal X-Y grid, so the left corner points and the right corner points have the same X values respectively. As well, the top corner points and the bottom corner points have the same Y values respectively. Rectangle drawing primitives, that only require two points to define the shape, are supplied in all OS program interfaces and draw to the screen very quickly.

The same shape can be drawn as a Polygon, but to do so would require storing all four points individually, thus taking twice the data space for storage and drawing to the screen somewhat slower. Therefore, the Rectangle is more efficiently stored and drawn than a similarly shaped Polygon.

Rotate the rectangle, and now all four points have different X & Y values, so a Polygon data structure must now be used, hence the Rectangle is transformed into a Polygon. Rotating it back does not perform the magic you would wish for, returning it to a Rectangle object. Its rectangleness is forever lost (unless you Undo the rotation).

What you desire could be done if a Rectangle object also stored a rotation parameter, but that would require more data storage, and ultimately, slower redraw times. If you need to be able to edit rotated rectangles as you describe, you can program a RotRect object as a PIO, but that would undoubtedly add another layer of complexity to your drawing that you probably don't want.

HTH,

Raymond

Link to comment
  • 0

The rectangle should have its rotation angle as an *optional* third parameter. Rectangles without rotation angle are treated as before. There is absolutely no additional storage capacity needed and only infinitesimal calculation time.

It is expected behaviour that an rotated object does not change its type and there is no excuse for loosing rectangleness forever.

This is also true for constrained and unconstrained dimension. These should be the same object type with a checkbox in the object info palette for the constraint.

Link to comment
  • 0

Raymond is correct about the definiiton of a vector rectangle, Not to be confused with the geometrical definition of a rectangle.

If you draw a rectangle and rotate it 90, 180 or 270 degrees, it's still a rectangle.

It gets converted to a polygon because now, a 4 sided object with line segment lengths and magnitude are defined for the object.

Link to comment
  • 0

Thomas is right (almost), as well. It would be theoretically possible to define a rectangle using two vectors, one to represent its diagonal, the other to represent its rotation from the orthogonal orientation. This would obviously double the memory required to store a rectangle, but probably not as much as is required to store the rotated rectangle as a polygon.

Link to comment
  • 0

The point is:

In the past, when storage capacity and calculation power was limited it made sense for the user to adapt to the way the computer defines objects. (A rectangle is something defined by two vectors and it has always vertical and horizontal lines.)

Nowadays we should expect the computer to treat objects as we expect them to behave. (A rectangle is defined by four ortogonal lines, and it does not matter how it is rotated.)

Again there is no reasonable argument for an object to loose its "rectangleness" when it is rotated, aside form issues of backward compatibility.

Link to comment
  • 0

There are two sides of the problem:

1.) User Interface

2.) Vectorscript

How can we improve user experience without breaking most vectorscripts?

Rectangles are a subset of polgons. Thus rectangles should accept all modification tools and procedures polygons do accept. If needed they are converted to polygons without further notice. (No dialog box telling you cant do that to a rectangle.)

Some polygons are rectangles. If a polygon is rectangular (rotated or not) it should silently revert itself to a rectangle and accept user input (stretching and resizing) just like any other rectangle.

Link to comment
  • 0

Thomas, AutoCAD treats rectangles in its core code as you describe. As I understand it, VW's code is different, and rectangles are a separate class and therefore do not inherit polygon behaviors. Since it's easy enough to convert a rectangle to a polygon in VW, getting polygon behavior is reasonably convenient. What I think you are neglecting is the fact that, compared to AutoCAD, VW's rectangles are much easier to use -to resize and create. This ease of use flows directly from the different way in which VW has organized their basic class concepts, and asking them to change it to make rectangles a subset of polygons might not be logical.

To add a rotation attribute to the rectangle's definition might be feasible and useful, but it may cause lots of problems when it comes to converting old files to the new system.

[ 04-16-2003, 01:38 PM: Message edited by: P Retondo ]

Link to comment
  • 0

-- AutoCAD treats rectangles in its core code

-- as you describe. As I understand it, VW's

-- code is different, and rectangles are a

-- separate class and therefore do not inherit

-- polygon behaviors.

True, I know that.

-- Since it's easy enough to convert a rectangle

-- to a polygon in VW, getting polygon behavior

-- is reasonably convenient.

True more or less. Rectangle -> Polygon is easy, but Polygon -> Rectangle is not so easy.

What I suggest is automatic conversion in both directions . Just in the moment when conversion is needed. No questions asked, no dialog boxes shown, no pulldown menus involved, no scripts broken.

-- What I think you are neglecting is the fact

-- that, compared to AutoCAD, VW's rectangles

-- are much easier to use -to resize and

-- create.

The opposite is true. I am *stressing* the fact that compared to AutoCAD, VW's rectangles are much easier to use -to resize and create.

What I am suggesting is, that rotated rectangles could be as easily created and resized as conventional VW-style rectangles.

-- This ease of use flows directly from the

-- different way in which VW has organized

-- their basic class concepts

True, but has nothing to do with rectangles and polygons.

-- and asking them to change it to make

-- rectangles a subset of polygons might not

-- be logical.

Not true, at least in my opinion. I am talking about geometry here. All rectangles are polygons, some polygons are rectangles. The ideal program should know about this fact and act accordingly (Neither Autocad nor VW do it properly.). This behaviour should actually be more logical.

-- To add a rotation attribute to the rectangle's

-- definition might be feasible and useful, but it

-- may cause lots of problems when it comes

-- to converting old files to the new system.

Not true. The rotation attribute should be optional. All rectangles without this attribute would not change at all. (Neither storage, nor code, behavior, object creation or modification, user interface, etc...) We should not expect any difficulty converting old files.

When saving a new file in an old format all new rectangles with rotation attribute would be converted to polygons, so we should not see any difficulties either.

Link to comment
  • 0

quote:

Originally posted by Thomas Wagensommerer:

... The ideal program should....

The key question here, which none of us can answer, is whether the terrific speed and efficiency of VectorWorks Rectangles would be diminished by giving all the capabilities of Polygons to Rectangles and vice versa.

If it would, then the disparity should remain, even though it's not ideal.

The ideal program would also operate at infinite speed. That will never happen, and we must accept the less-than-ideal, and decide which shortcoming is more critical. The Rectangle/Polygon disparity is not very difficult to work with, whereas the increasing sluggishness of the program and the prevalence of bugs is a considerable problem.

Link to comment
  • 0

There is absolutely no additional computing power needed for screen redraw, since internal storage is not changed.

Only if you select a polygon the computer would need 0.001 sec to calculate if this polygon is actually a rotated rectangle.

If the computer recocnizes it as rotated rectangle it would give you height, width and rotation angle in the object info box instead of polygon and vertex info. With the selection tool active you would get selection handles specific to rectangles, not the bounding box you get now, which is useless for rotated rectangles. If you drag, orthogonality is not destroyed.

If you choose the reshape polygon tool you would still get polygon and vertex info in the object palette. If you drag, you can move individual vertices, orthogonality is destroyed.

Its as simple as that.

[ 04-18-2003, 04:56 AM: Message edited by: Thomas Wagensommerer ]

Link to comment
  • 0

a blank file with a rectangle 1.5" x1" is 17k.

A blank file with a polygon 1.5"x1" in the shape of a rectangle is 56k.

There is a substancial difference in the way these objects are drawn, treated and redrawn.

Link to comment
  • 0

Thomas, you have obviously given this a lot of thought. But consider this question alone: resizing rectangles in the OIP is a powerful tool, and I gather that those who want rectangles to remain rectangles when rotated want to be able to use the OIP to resize a rotated rectangle. In the OIP is an array of 9 radio buttons that determine which point on a resized object remains fixed. How would the program determine the user's intent in clicking one of those choices when the rectangle is rotated? When does the lower right corner cease to be the lower right corner as the object is rotated beyond 45 degrees towards 90 degrees? These questions might be answered and a solution implemented, but imagine the increased complexity in programming required of NNA and in knowledge required of the user. I can imagine the rectangle becoming a kind of symbol that has to be "entered" to edit it in normalized orthogonal space.

Re: whether a rectangle is a kind of polygon, true in the geometric sense, but not true from the programming point of view (or so I surmise, since I haven't seen VW source code or any summary of their class structure).

[ 04-17-2003, 01:15 PM: Message edited by: P Retondo ]

Link to comment
  • 0

Katie, thank you for your research. If I need a rotated rectangle *now*, I draw a polygon. It is absolutely true this polygon takes somewhat more storage space than a rectangle.

After the user interface is improved, the same polygon in the shape of a rotated rectangle will still use the same storage space as before, but it behaves nicer towards the user. As I said before, internal storage is not changed in any way, only the user interface is improved. There is no difference in the way these objects are drawn and redrawn, but yes, they are treated differently.

P Retondo, obviously the array of 9 radio buttons in the object info palette should be aligned to the rotated rectangle. Yes, there is a considerable effort in programming required. No, I cannot imagine the rectangle becoming a kind of symbol that has to be "entered?. I dont think there is additional knowledge required by the user. Quite on the contrary, the current behaviour of rotated rectangles is counter-intuitive and not expected by the ?non-expert? user.

Perhaps one of the VW-gurus can comment from the programming point of view?

[ 04-18-2003, 04:56 AM: Message edited by: Thomas Wagensommerer ]

Link to comment
  • 0

Prodded by this discussion, I finally confronted the problem of re-sizing rotated-rectangle Polygons, and I found that there's already a pretty good way to do it! It works in all versions of VectorWorks.

By setting "Grid Angle" to align with the rotated-rectangle Polygon, and selecting the "2D-Reshape" tool, you can grab the center of any side of the rotated rectangle and drag-stretch it (just as you would drag-stretch a non-rotated Rectangle with the "Select" tool, including entering the desired new length or height in the "Data Display Bar" if you wish. Actually, it's a little quicker in this case to enter the new dimension, so that you can enter a zero for the other dimension rather than trying to stretch exactly in the direction intended). This method only works for re-sizing length OR height, one at a time -- not both at once as you can when drag-stretching a corner of a Rectangle with the "Select" tool.

It's not as quick as using the "Select" tool to drag-stretch a non-rotated Rectangle, but it compares favorably with the method referred to in this thread, of using the "Object Info" palette to re-size a Rectangle; assuming that, like any sensible computer user, you've figured out that the left hand is the appropriate hand for the mouse, leaving the right hand free to operate the numeric keypad, which selects coordinate boxes on the "Data Display Bar" and fills them with values, and also free to select Tools via the letter keys and to issue Commands and Command sequences via the function keys, which in turn presupposes that you use a keyboard macro utility to map each of the 24 function keys on your Focus 8200 keyboard to a Command or sequence. The general discussion in this thread assumes that you work with rotated objects often enough to justify dedicating a function key to a Command sequence that opens the "Set Grid" dialogue box, sets "Grid Angle" to "Next Mouse Drag", and closes the dialogue box, so that you need only one keystroke and one short click-drag to align the Grid with the rotated rectangle and other objects parallel to it, and the same keystroke and click-drag to return to normal orientation when done editing the skewed area. The Grid-Angle-and-stretch method is a little quicker if you normally keep the OI palette roller-shaded up and out of the way. The Object-Info-Palette method is a little quicker if you normally keep the OI palette opened and cluttering up the screen (which slows down your whole operation enough to offset any speed advantage in this one operation).

Link to comment
  • 0

It's not hard to find a keyboard with the keypad on the left, but remember that you would have to train your left hand to touch-type the keypad, just as you had to train your right hand. Left-mousing requires no training; it feels awkward, but only for the first few days.

Mousing isn't like writing. It takes no more dexterity than erasing a chalkboard. If you think about it, it's the same motion, and the same hand position. As far as age is concerned: a friend of mine switched to left-mousing at age 60 and had no problem with it.

Link to comment
  • 0

on the left / right handed mouse issue

it's really just a matter of set up

mouse on right hand

keyboard placed so natural position of the left hand is resting on the u&i keys. this way the left hand can roam for key picking and command combo's.

and is still comfortable for typing.

Link to comment
  • 0

But with the right hand on the mouse, it's constantly moving back and forth between the mouse and keyboard. Half the user's time is spent moving the right hand between devices.

With the left hand on the mouse, it never leaves the mouse except for typing text (which is done much less often than drawing operations). We type data (numbers) all the time while drawing, and that can be done much faster on the numeric keypad -- and only with the right hand -- at the same time that the left hand is moving the mouse. It's the old draftsman's joke become reality: you can draw with both hands!

I didn't understand what you meant by "the u&i keys".

Link to comment
  • 0

oops i think it comes down to if your a left hand or right hand person.

i'm left handed so i have the mouse in my right hand, keyboard left, and tend to have the keyboard placed well left of the centre of the screen, so that with my arm fully relaxed my wrist sits on edge of desk, and index finger rests on the u key (which is good seeing that is that is the main tool mode toogle key you use).

but if i was right handed i'd have a very different set- up [smile]

Link to comment
  • 0

Rotating the grid is actually very easy, especially with the macro described above. And even without macros it's usually well worth the effort, because it's rare to work on just one object at the other angle. Usually there are several objects at that angle, and the time saved in drawing and editing with the grid rotated is well worth the time it takes to pull down, click, Enter, and drag-click.

I still don't understand what you mean by "u&i keys". And "holding down the shift key to use the midpoint resize handles". Is that a Mac only feature? Nothing happens when I hold down the shift key in Select mode.

Link to comment
  • 0

I have just noticed that "square tubing" when rotated is still "square tubing" and fully editable in the OIP.

Obviously the code can't be that difficult to write - I imagine there would be more code required for the rotated tubing object than a simple rectangle.

BG

Link to comment
  • 0

with regard to the subtopic - left/right mouse keypad etc.

For what it is worth -

I am right handed. I use a Kensington trackball with 2 keys + an Ortek USB ergonmic keyboard with a built-in keypad on the right side.

To solve this problem, I have added a USB keypad and positioned it to the left of the keyboard.

However, the greatest asist to my efficiency is the use of a trackball rather than a mouse.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Answer this question...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...