[Bug?] Having trouble making VERY small rotations to a long thin component

I’m helping Scott Baker (@NewThinking2) with his large and complex RiverArch model.

Part of what I’m trying to do is to make very small angular changes to very long (ca 250’) walls, to align the ends to stub walls which are all on two parallel vertical planes. The distance between the stub walls varies by a few feet between lowest and highest wall in a set of walls which are otherwise identical.

I’ll then fill in the gaps with another stub wall.

Here’s a simplified version. I’ve just extracted one wall and two stub ends from the tenth floor of the building.

There are about 100 walls to do altogether, in about four or five sets of walls, so it’s very frustrating that SU doesn’t appear to do it accurately.

For this example floor of this building the Protractor tool shows the angle to be .053°, but I can’t get the Rotate tool to do such a small rotation, and Angular Dimension 2 tool reports the angle as zero, even though it uses the precision setting for its display…

Here’s the SKP file
Example.skp (685.5 KB)

I simply can’t get the ends to align - I pick the rotate tool, fix the rotation axis to blue and on the endpoint of the long wall, pick an edge (or face) on it, get an inference on the on the corner end of the stub wall like this:

Then I click, and the long wall appears to rotate. But its end is NOT on the line between the origin of rotation and the stub wall endpoint. It’s snapping back to its original direction.

I’ve tried changing the Angular precision to maximum, and turning off angle snapping, to no avail.

Rotate simply snaps back to the original edge line, even if I do a two-stage rotation in two large steps - away, and back to target.

The actual displacement of the end is about 10" so it isn’t a problem of small absolute sizes of things.

Any suggestions for how to do this? Please, someone try it on your machine to see if it is something odd about mine.

The really annoying thing is that it SOMETIMES works, but I can’t see why it sometimes does and sometimes doesn’t. So some walls in my initial batch of about 20 work, and some don’t.

A bit of further experiment - starting the rotation, then typing in an angle of .053 doesn’t work. But .060 does, and .058 doesn’t.

Why not?

With the rotation set at .060, you can see the difference:

If SU offers angular precision setting to four decimals, and can easily measure it with the protractor to three places, why won’t it respect inputs to only three decimals, and in effect round to two?

did you try over rotating say 40.058 and then rotating back 40…

helps eliminate ‘small’ changes…



I tried that manually - large movement away, then trying to move back to endpoint inference, which didn’t work.

Will try your suggestion. I want 0.053 degrees, if I can get it. I used .058 to explore the boundary betwen the smallest that works (0.6) and the largest that doesn’t (0.058 - didn’t try 0.59)


Tried rotating in desired direction 10.053° then a separate rotation back of 10°.

Back to original position. Even with separate invocations of the Rotate tool. And without the edge line I drew to clarify what I’m trying to do.

Stumped, at the moment, and heading for bed.

Gave it one more try before bed.

After a cold restart of the computer, and doing noting before opening Example.skp, I get partial success.

Doing it directly still doesn’t work. Indeed, I can’t rotate the wall at all in a counterclockwise direction (viewed from above - moving near end to the right), until I rotate it the other way, then swing back right past a ‘sticky point’ in the original position.

But click then on the inference, and it still snaps back to original edge.

But this time if I follow your suggestion, and make an over-large movement to the right, I CAN them move back to the inference point.

Seems like a form of bug to me. Doesn’t do ‘what it says on the tin’.

That’s in the sample file with only one wall. Will try tomorrow if it works, after a cold reboot, in a submodel with about 20 walls and a few other components.

I’ve just found an old thread about small angle rotations:

It seems I’m just out of luck.

Still seems like a bug to me. I do understand there need to be tolerance limits, but this seems set just too coarsely. As I said earlier, offering apparent precision to four decimals of degrees, then getting stuck at only slightly better than two (0.057° or thereabouts as a minimum rotation) really is making life very difficult at this point.

I’ve only just twigged - .057° is 1/1000 of a radian.

SU works in radians internally.

I wonder if this is hard coded into the rotate tool, but maybe smaller rotations could be made using a Ruby Geom::Transformation.rotation?

Will experiment tomorrow.

I hope so, otherwise I can’t see how to align the walls exactly.

Just jumping in here. For the sake of project progress - which is coming up on its 1-year anniversary next month (for me anyway) - we could live with a 100th of an inch or even 100th of an inch discrepancy. There are other more serious alignment issues with this non-right-angle join anyway, such as a shrinking middle wall and growing triangular inter-spliced end-wall joins that make exact window placement relative to internal walls and external terraces virtually impossible to maintain in a consistent relative position. If we can live with that, we can certainly live with being off by 100th of an inch. We can move on…

I am often wanting a rotation around an arbitrary axis, so wrote a script for this purpose, it may be what you need…

require 'sketchup.rb'

class RotateBy

	@ax = 0.0
	@ay = 1.0
	@az = 0.0
	@angle = 0.0
  def RotateBy::validateEntity
		if sel == nil
			return false
		return true
	def RotateBy::RotateByNow()
		prompts = ["axis X:","axis Y:","axis Z:","Angle:"]
		values = [@ax,@ay,@az,@angle]
		results = inputbox prompts, values, "Rotate around axis"
		return if not results 
		@ax = results[0]
		@ay = results[1]
		@az = results[2]
		@angle = results[3]
		vc = Geom::Vector3d.new @ax,@ay,@az
		selection = Sketchup.active_model.selection
		box = selection[0].bounds
		selection.each { |e|
			box = box.add e.bounds
		angle = @angle * Math::PI / 180.0		
		transform = Geom::Transformation.rotation box.center,vc,angle
		Sketchup.active_model.start_operation "Rotate by",true ,false ,false

		# refresh the display
end # Class RotateBy


Why are all the door components and window components somewhat “leaning back” in the wall example? Is this poor modeling or is there a higher reason?

Why does the wall component have its local axes aligned to nothing logical? Currently they are slightly off according to the system’s axes. It seems that rotating the wall to target gets them even closer to system’s axes and may be the root of your rotation issue. Is it that both axes sets come within angle tolerance so the rotation operation skips snapping to target but in stead snaps local axis (red) to system’s axis (red)?

When I changed the wall component’s axes according to the system’s axes directions I had no problem rotating the wall around its rotation origin to target without angle input.

Try with other component axes that do not get close to system’s axes at the end of the rotation (target).

1 Like

The issue does appear to be related to coarse settings; those of the user, not SU’s.

Coarse precision settings tend to increase the likelihood of modeling errors.
Coarse precision settings also mask modeling errors when they occur.

The long wall in question is wracked out of square. Its east end being higher than the west end.
Consequently, it’s tilted away from parallel with the ground plane.
Thus askew, there’s little wonder why rotating about World Z might not work as expected.

Example_Off-Axis.skp (674.8 KB)

Probably poor modelling - will fix.

Their axes parallel the main model axes - these walls are at an angle. They are set this way to allow a custom script to array copies up the arch on a curved edge.

However, once arrayed, I can reset the axes, and that as you say may fix the rotation issue.

Thanks for that suggestion - I’ll try it later today (on phone now, not at computer).

I have angle precision set to four decimal places and angle snapping off, so it seems more likely that @Wo3Dan’s suggestion of a powerful ‘snap to world red axis’ is the cause of my woes!

But certainly a point to note in future.

I too had (dislay!) precision set to max, plus decimal and millimeters, my favorite settings for investigating these issues.
The rotation issue (neglecting the target) persisted, snapping to something else. That’s why I suspect that it is the nearby world axes rather than the units settings. Changing the component axes made the difference, the target was focused on.
With value input @john_drivenupthewall’s suggestion certainly helps with very small angles, but again without “snapping to axes” interfering.

I’m very happy to says, @Wo3Dan, that after changing the axes so the origin is at the far end, and the red component axis it along the wall long edge, the small rotations now work as expected and snap easily to the ‘target’ corner, and stay there!.


This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.