I’d like to report a bug that appears once in a while when copying a component with the rotate tool: some components are not perfectly positioned on the rotation path. See picture:
As you can see, the seats in the red-shaded area are weirdly positioned.
The bug appears a while after completing the rotated array. At first, everything looks fine, then after while of working on other parts of the model the issue comes up without a known trigger.
I’d be happy to have this solved, because it completely messes up my work atm
The best way of getting this bug (if it really exists) resolved is to share the file with the SketchUp team. Out of curiousity to me and others here, could you also share the file here?
Please include the steps involving the copy/rotate operation(s) in a short explanation if possible.
They seem to be that way too in the corresponding area of the big block of seats to the left of your highlight, as well.
Which ‘column’ of seats was the original? It may not be in view - perhaps out of sight to the left? Or were there several radial columns of seats in the original for the copy?
They seem to be that way too in the corresponding area of the big block of seats to the left of your highlight, as well.
That’s because the entire block of seats is a component, so the error is in all blocks.
Which ‘column’ of seats was the original? It may not be in view - perhaps out of sight to the left? Or were there several radial columns of seats in the original for the copy?
Not 100 % sure what you mean, but there was not one ‘column’ of seats I rotated, but for each row of seats a new rotation & copy procedure was done. That is also why the bug appears only in some rows, while others are fine. In fact, most of the affected row is also fine with just that single seat stepping out of line.
Unfortunately I cannot share this particular file for legal reasons, and when I tried to reproduce the bug in a new file, it did not show up. As I said before, it only happens once in a while unfortunately without a known trigger.
As for the explanation of the procedure of the copy/rotate operation:
I manually insert the first and last seat in a row and find the the pivot point by creating two guide lines through the middle axis of said seats. Pivot point is the intersection of those two guide lines
Then I delete the last row in the seat and copy/rotate the first seat to the exact position of the deleted seat.
After that I use the /x comand to find the maximum number of seats I can squeeze into that row by trial and error.
Does anyone know how SU ‘knows’ the position of copyrotated elements? Does it ‘remember’ where the pivot point was and recreates the operation every time the area is rendered within SU? Or is each element given proper coordinates and an orientation after copy/rotation? If it’s the latter, there might be the source of the problem perhaps?
During the copy/rotate operation you can change /x as long as you wish to other values or even to *x values and back. The center of rotation stays the same for each input you give.
This ends by ending the operation, say through selecting some other tool.
Your description (1,2 and 3) seems clear except you probably swapt ‘2. Then I delete the last seat in the row … … …’.
The pivot point ( center) has no meaning afterwards for re-rendering. Each group or component has its own insertion point and orientation. The copy/rotate has done its job.
I haven’t heared of the ‘bug’ you see. Without a file and its steps it’s hard to tell what is wrong.
There’s something else going on in this file. The uploaded file has its model wrapped in a toplevel group “not close” to the systems origin. Even that may be okay here. But then the component’s axes “jump” to other locations, sometimes also far from the systems origin at illogical places for these component. Enable viewing the ‘Axes’ and open the ‘Outliner’ and click through the different groups in the top levels.
(cross posting )
I copied one seats component#151 to another location where I couldn’t see the seats unless I zoom in. The seats just disappear again from the view once I zoom out. I think your model may be suffering from having geometry too far from local (and maybe system’s) origins.
I’ll have a closer look later.
Given:
The floor tiers are concentric arcs.
Thus, all the floor tier arc centers are coincident.
Given:
The arc of each row of seating is desired to be concentric with the arc of its floor tier.
Thus, the arc center of each row of seating must be coincident with the arc center of the tiers.
Therein lies not a “bug”, but your modeling error.
The intersection of the guides does not coincide with the arc center of the tiers.
The premise of accurate Move, Rotation and Arrays is to begin the operation inferring to a meaningful point and then take that point to a meaningful destination.
In this instance, the point of rotation of each array of seats is off target >5m
The guides used to array the seating still have no relationship to the arc center of the tiers.
Hi George, I do agree. And also about one and only one center for all the elements.
But the fact remains that some seats near the end of a row seem to be out of (arc)-“line” with the others.
My guess was/is that this does happen due to incorrect rotation. But OP stated that the issue occurs after a while where seat positions (location and orientation) were correct at first. So the mystery still remains to be solved. Is it the weird illogical locations of the component’s local; origins.
I’m far from convinced that there is a bug involved.
I know that the arc center of tiers is different to the pivot point I chose. That is on purpose and not at all a modelling error. I could use the arc center but if I did this the distance from the first seat to the stairway is different in every row and that looks hideous.
Furthermore, in the second file I sent all but one seat are positioned as intended and the one that isn’t was originally in the correct position as well. So the position of the pivot point is most certainly not the issue here.
Persistence in claiming a bug is “modeling error” causes irritation.
Of course the result in the video is what it should look like actually. The bug appears (if it all) at a later point in time and like I said I am unware of the “trigger event” that does it.
What do you mean by that exactly? The seat component was created at a random point somewhere in the model before I moved it to the place I needed it … is this known to cause any issues within SU?!
Not necessarily. But enable displaying the axes and click through various levels of groups and components to see that some have their geometry far from the local origins. Is there a specific reason for doing so?
To make things easier (as an example) you could redraw the component’s axes for the seat, one axis running from the seat’s center along the center line.
)
