Bug in Rectangle tool ( in both desktop and web versions )

[dezmo]

There is a bug in Rectangle tool. I wonder since when we have this case ?..

The Rectangle tool in some cases does not create a face, because one corner is not on a same plane.
The animation is created in web version, but I was able to reproduce in SU 17.2.2555 Make and SU 21.1.279. I guess “all” versions are “infected.”

(The ladybug has been inserted by me into animation, this is not built in feature… )

[jean_lemire_1]

When you begin rotating the rectangle, you notice that a dashed diagonal is shown intermittently.

If you click to complete the rectangle when this diagonal is not shown, the rectangle closes without problem.

If you click when this diagonal is shown, you get no face.

This diagonal indicates that one of the two new endpoints is not coplanar with the other three and that a line will be needed to define two triangles to close that new face. There must be an inference that is having an effect here.

[dezmo]

@jean_lemire_1

This diagonal indicates that one of the two new endpoints is not coplanar

No. The diagonal line is indicates if it is Golden ratio or Square
https://help.sketchup.com/en/sketchup/drawing-basic-shapes#draw-rectangle

SketchUp Training Series: Rectangle tool

The rectangle tool is buggy. Can not handle properly the inference line (From point) and Golden/Square “jump” together.

[Anssi]

Do you have Length Snapping on?

[dezmo]

Definitely NO.
Have you tried what I demonstrated in the animation?

[Box]

Yes, I can reproduce it.

[jean_lemire_1]

You are right. I can reproduce the issue. It is only if I get the dashed line indicating the golden rectangle or a square that this bug happens.

Try with this SU file. I made it with sU 2021 but saved it as SU 2017.

Rectangle bug.skp (99.1 KB)

[colin]

I do see it too. I wonder if the golden ratio ‘square’ is actually a square, and is just off axis.

Whatever the case, as it’s been there perhaps since SketchUp 1, it may not get a high priority.

I did already search for an existing issue, but with the kinds of generic terms you would search for this, a ton of other issues show up.

@trent is away this week, but when he’s back he may know if it’s a known issue.

[dezmo]

Further study:

• Neither side of the created “square” is equal to any other: It is not a Rectangle.
• The vertices A* and B* are at least in place.
• The C* vertex was projected From point C in the right direction but at the wrong distance.
• I have no idea how the D* vertex was created. Only its vertical coordinate is okay.
  

One possible way to do it: (Perhaps it helps for SU developers, but hopefully they know better … )

When we detect the conditions “From point” (C) and “Square”, we know which two coordinates of the cursor are “fixed”, so we can calculate the side length of the square, as well as the AC distance. (Using the corresponding coordinates of the first point (B) and C).
Then, using Pythagorean theorem, we can calculate the distance of offset (CC*) e.g.:
CC* = sqrt(AB^2 - AC^2) = sqrt( 100^2 -61,803399^2 ) = 78,615138

The position of C* can be obtained by offset the point C by the vector. This vector obtained from the position of the “Form point” (C) and the actual cursor, the length of the vector must be set to the previously calculated distance (CC*).

Ruby dev note

The “From point” position is not available in the Ruby API, so Ruby developers need to work harder, but the C-side should have it.

[MikeWayzovski]

Many times, when placing rectangles inside voids of frames etc. and you notice that the sides don’t have a red, green or blue color, I tend to hit an arrow key to constrain it, rather than trusting on the inferencing machine.
Of course, there is no plane in this situation what can be inferenced. Only points.

The inference system might be confused, or is very sensitive in that matter. It involves the points of inferences hoovered over, the angle of the camera, the position of the cursor when dragging the rectangle out, etc. (I always say ‘etc.’ when I can’t think of anything else)
With some patience, I managed to get a ‘blue’ side of the rectangle by moving the cursor back to the opposite corner of the rectangle to be:

Maybe the preference system needs to prioritise certain aspects (eg. ‘always have plumb lines’)

[dezmo]

@MikeWayzovski

get a ‘blue’ side of the rectangle

But it is not a Square, I’m 99,99% sure about it.
Either you get a rectangle with the edge projected From point. OR a Square where the edge is not on a same Blue-Red plane as the From point.
Both are not really possible currently.

Jack, you are talking about inference system or how to create a rectangles… (‘etc.’) , and you are certainly right.

… but the topic is about a fact and prove a bug in Rectangle tool.

We have been living with this bug for a long time. We know how to avoid. But that’s still a bug. Do not you think so?

[MikeWayzovski]

I definitively agree that there is a bug exposed. Anyone can draw edges, but the rectangle should only draw edges that are in one plane and square, otherwise it should be called ‘Four Edge Linetool’

My point was that’s in a normal model with lot’s of geometry in the background (not a simple 1x1x1 cube), it’s much more difficult to get sides to be ‘On one of the Axes’ and since we do not know what order of inferences is prevailing in the program where kind of left in the dark out here.

When I have a blue side and then click, it is a perfect square:

When all sides are black before the second, that might be a clue to the enduser that something is off. Usually, this results in a rectangle in a whole different plane, so again, it is bugged.

If you switch the corners of the rectangle, it seems to draw a square face, though:

[jean_lemire_1]

See another version of my file with dimensions and coordinates that show the problem that Demo showed.

Rectangle bug 2.skp (108.5 KB)