Just had an interesting discussion on a Facebook Sketchup Group…
One person indicated that they had a lot of problems with the rectangle tool not producing 90 degree rectangles,
" I get myself in trouble using the rectangle tool all.the.time. Before using the color by axis or without using guide lines. When using the rectangle tool not all the lines will necessarily be parallel even if at right corner in one plane. I know there is a better way to describe it in geometric terms but unless you are snapping to a parallel line in the same plane, you are going to have some issues. "
I was rather surprised at this , maybe my workflow avoids the problem they say they encounter…
I have asked for a more detailed example… even with Snap to length on surely the rectangle is still a rectangle… ie opposite lines are parallel and corners 90 degrees?
Here’s an example.
I started with a square and deleted one edge, then used the move tool to move the endpoint of the bottom edge .0001m to the left.
So as you see when I draw a square using the rectangle tool and the inference I get a tilde in the angle.
This is why once you get an error it continues through your model.
If I change the units to mm you can see that it isn’t a square.
Hmmm that explains why I don’t usually encounter a problem with my workflow, I create a raw rectangle, group it and then copy, rotate and scale it to create my object geometry… but hell, the tool should be renamed the “Sometimes Rectangle Tool”
Not really, you have to force it to make a mistake. I personally have never had an issue with it but have seen and repaired many models that are suffering from this sort of thing. Basically a good workflow with length snapping off won’t produce problems.
If Trimble had clearly advised users that the rectangle tool sometimes does not create rectangles then ok! But the fact that the rectangle tool in some circumstances may not be a rectangle is clearly negligent of the software and causes us all lost time and effort… it should not be distorting a rectangle…regardless of what it snaps too! You and I by chance or design have workflows that bypass the issue; thousands and thousands have not… and are not even aware of the issue… (including me until today!)… and I keep myself pretty well SU informed…
Is this issue stemming from the decision at the outset to use “inches” as the base unit ? I guess not, just bad code
There is also an issue if the open group/component has been sheared/skewed. Many SU tools assume the drawing axes are perpendicular, but in rare cases they are not.
@jean_lemire_1 was 100% right. The dashed line has nothing to do with “square” or “golden section” !
The dashed line in this case is a warning that an extra edge will be needed to obtain a segmented surface.
Both the possible cursor indications: “From Point Square” and “From Point Golden Section” are false and misleading. The cursor information in these cases should be left out completely or “From Point (no rectangle)”. The manual about the rectangle tool should mention the dashed line as being a warning. SketchUp’s code isnotbuggy in creating geometry. The text on screen should be taken care of.
I would say he was 90% right , since normally the dashed line indicating the “square” or “golden section” and there is nothing else mentioned in the manual. You pointed that right (and I agree):
You are absolutely right. In my opinion this is also a kind of bug (wrong cursor indication.)
I do not agree. The rectangle tool is buggy, because in some cases it is creating four edges out of plane and thees will not format a rectangle.
The rectangle tool should create a rectangle - or nothing - in any case. Don’t you think?
@dezmo, I must admit, a rectangle tool should only create rectangles. The code must ignore that last “out of alignment” (pilot error-) endpoint inference and stick to three used endpoints to create the fourth corner endpoint in plane. Thus forming a rectangle and its face.
So not even a dashed line option should be presented.
I think the issue is not with the rectangle tool per-se, but with a quirk in SketchUp’s merging of nearby vertices during the cleanup step after new geometry is added. In every case when merging SketchUp must make a choice about which vertex to keep and which to eliminate. I have noticed that it tends to favor the pre-existing one, even when it is at an irregular location and even when an inference lock suggests you really meant the new edge to be exactly on axis. In other words, I think the rectangle tool drew a true rectangle and cleanup warped it!
In the attached image, I drew an edge exactly 5.0" along the green axis from the origin. I then moved a copy of it in the red direction exactly 5.0". Next I moved the end point of the copy back 0.0005" in the green direction - intentionally below SketchUp’s nearby vertex tolerance for merging. Then I drew another edge from the end of the original edge with inference lock on the red direction until I saw a snap for the end of the second edge. SketchUp violated the inference lock during cleanup to make the new edge land on the moved vertex of the other edge. You can see from the image that the length of the copied edge is still 4.9995 and the angle of the new edge from the green axis isn’t 90 degres even though the other three corners are!
Edit: The crux of the issue may be that by the time the cleanup operation runs, the context from which SketchUp might know your intent is gone; there is just a database of geometry that needs to be checked for nearby vertices. So SketchUp favors whichever came first, probably based on older ID.
O.k. maybe misunderstood the point you where trying to make. I do move the mouse the intended direction before entering the dimension in the measurements box.
Moving up and typing should get rid of the minus sign, I do misinterpret them sometimes for ~, too.
The colors of the edges would give the most predictable output before clicking the second endpoint, you can lock them with the shift key.
…
, since normally the dashed line indicating the “square” or “golden section” and there is nothing else mentioned in the manual. You pointed that right (and I agree):