@tt_su said:

That disappearing group (visually) sure looks like a bug. I'll file a bug internally (SU-29499).
Meanwhile, the workaround is to specify scaling in X Y and Z explicitly.

Ok, Thom. It is a small bug but it took me a long time to be assured it was not my code fault and try another way to do it.

@tig said:

What I was trying to explain is that doing all three scaling at -1 is the same as scaling -1,1,1 the rotating about the Y axis 180 degrees.

Scaling and rotation are linked...

Orig = Geom;;Point3d.new(0,0,0)
Point3d(0, 0, 0)
y_axis = Geom;;Vector3d.new(0,1,0)
Vector3d(0, 1, 0)
Geom;;Transformation.scaling(-1,1,1).to_a
[-1.0, 0.0, 0.0, 0.0,  # formated manually for easy viewing
 0.0, 1.0, 0.0, 0.0,
 0.0, 0.0, 1.0, 0.0,
 0.0, 0.0, 0.0, 1.0]
Geom;;Transformation.scaling(-1,-1,-1).to_a
[-1.0, 0.0, 0.0, 0.0,
 0.0, -1.0, 0.0, 0.0,
 0.0, 0.0, -1.0, 0.0,
 0.0, 0.0, 0.0, 1.0]
Geom;;Transformation.rotation(Orig,y_axis,Math;;PI).to_a
[-1.0, 0.0, -1.22464679914735e-016, 0.0,
 0.0, 1.0, 0.0, 0.0,
 1.22464679914735e-016, 0.0, -1.0, 0.0,
 0.0, 0.0, 0.0, 1.0]

So, they are all different! But, yes, the transformations
[pre:lswzgknb]Geom::Transformation.scaling(-1,+1,-1)
Geom::Transformation.rotation(Orig,y_axis,Math::PI)[/pre:lswzgknb]are equal (within a certain precision).

@arqpadao said:

Marcos, um dos modelos achei o bloco pronto de um fabricante, confesso que foi um "achado", outro foi de um arquivo 3ds - [highlight=#bfff40:2walp8hz]o que da trabalho geralmente é limpar o excesso de triângulos[/highlight:2walp8hz]. Outro modelei usando o arco e depois o folow me.

Acho que esse plugin pode ajudar:
http://sketchucation.com/forums/viewtopic.php?t=22920

@unknownuser said:

The two forms of the transformation matrix are equivalent. So there should be no difference when you apply the transformations to an object. Nothing to do with SU.

Do you mean that Geom::Transformation.scaling(-1) and Geom::Transformation.scaling(-1,-1,-1)
are equivalent? I agree they should. I applied them to non grouped entities and got the expected results. But try applying them to a group or component instance. You will get surprisingly different results at least in SU 8.

@tig said:

So to recap: scaling in three steps by -1, just in x, then just y, then just z [steps 1/2b/3b], is the equivalent result to just scaling -1 about the x-axis in one step [step 1] [the subsequent second and third scalings for y and z effectively cancel out each others 'handing' ?]!

Since a combined transformation of -1,-1,-1 effectively does these steps, then you could have used -1,1,1 [with a rotation] instead and got the same result ?

I do not understand your conclusion. Your drawings/examples seem to contradict it. The scaling by (-1,-1,-1) (steps 1/2a/3b) is handed but different from the scaling of step 1. Scaling (-1,-1,-1) is an uniform scaling but (-1,1,1) is not.

In 3D coordinate system, scaling may be represented by a 3x3 diagonal matrix. However, SU uses the uniform coordinate system (a 4D coordinate system) where geometrical operations are represented by a 4x4 matrix and points by 4 coordinates. The main purpose of this system is to unify parallel and perspective projections or, more properly, unify affine and projective transformations. Except by the 4x4 transformation matrices, we cannot access the forth coordinate of points in SU but it is there inside the code. When we code point.to_a, SU divides the first 3 coordinates of point by the fourth coordinate before presenting them. This is a projection from 4D in 3D.

"Usually" the 4th coordinate of points equals to one. But, if it is something else (except zero!), all first 3 coordinates will be divided by something different from one in the 3D projections. So, to produce a uniform scaling of points we can either change the first 3 coordinates or just change its 4th coordinate. When we create a scaling with Geom::Transformation.scaling and just one argument, SU adopts the later method, that is, change just the 4th coordinate. You can see it by printing the transformation matrix.

I think that the incorrect presentation of groups and components transformed by negative uniform scaling is not a bug in the transformations themselves but in the way SU handle the viewing of points with a negative values in their 4th component. I could not observe any positive uniform scaling bug.

According to the SU API, a ConstructionLine object has the following geometrical properties:
direction, position, start and end.
The start and end of infinite ConstructionLine objects are nil. Semi-infinite ConstructionLine objects have either a non nil end or a non nil start. Finite ConstructionLine objects have non nil start and end.

These 4 properties are not independent and some odd results may surprise us.

ent = Sketchup.active_model.entities
#<Sketchup;;Entities;0xa02542c>
p = Geom;;Point3d.new(0,0,0)
Point3d(0, 0, 0)
dir = Geom;;Vector3d.new(1,1,0)
Vector3d(1, 1, 0)
ent.add_cline(p,dir)
#<Sketchup;;ConstructionLine;0xa024f90>
cl = ent.add_cline(p,dir)
#<Sketchup;;ConstructionLine;0xa024e64>
cl.end = Geom;;Point3d.new(100,100,0)
Point3d(100, 100, 0)
cl.start = Geom;;Point3d.new(0,0,0)
Point3d(0, 0, 0)
cl.end = Geom;;Point3d.new(200,0,0)
Point3d(200, 0, 0)
cl.end
Point3d(100, 100, 0)
cl.end = Geom;;Point3d.new(300,0,0)
Point3d(300, 0, 0)
cl.end
Point3d(150, 150, 0)

It seems to me that the end method projects the input Point3d in the line before setting it. The same behaviour is observed for the start method.

If the input point of either the end method or the start method is not in the line of the construction line, we should change the line direction too.

cl.direction = Geom;;Vector3d.new(1,0,0)
Vector3d(1, 0, 0)
cl.end = Geom;;Point3d.new(300,0,0)
Point3d(300, 0, 0)
cl.end
Point3d(300, 0, 0)

Select a component or group and try this:

selected = Sketchup.active_model.selection[0]
selected.transform! Geom;;Transformation.scaling(-1)

Where is your group?
If you open the Outliner window, you will see that the group is there and may be open for edit.

If you check the group transformation, you will get:

selected.transformation = Geom;;Transformation.scaling(-1)
selected.transformation.to_a
[1.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, -1.0]

To make your group reappear, do:

selected.transform! Geom;;Transformation.scaling(-1)
selected.transformation.to_a
[1.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 1.0]

And after that try:

selected.transform! Geom;;Transformation.scaling(-1,-1,-1)
selected.transformation.to_a
[-1.0, 0.0, 0.0, 0.0, 0.0, -1.0, 0.0, 0.0, 0.0, 0.0, -1.0, 0.0, 0.0, 0.0, 0.0, 1.0]

According to the API, there would be no difference between
Geom::Transformation.scaling(a,a,a) and
Geom::Transformation.scaling(a)
But this is not true for negative scales.

There is not essentially wrong with a non unitary last element in the transformation matrix. For instance:

selected.transform! Geom;;Transformation.scaling(2)
selected.transformation.to_a
[-1.0, 0.0, 0.0, 0.0, 0.0, -1.0, 0.0, 0.0, 0.0, 0.0, -1.0, 0.0, 0.0, 0.0, 0.0, 0.5]

works great.

Is this a bug? Is it restricted to SU 8?

Dan, you are right and I think I found the bug source inside my own code.

I deleted the tool method codes leaving just the codes of activate, onMouseMove and draw. The bug remained active. So I stripped those codes to a minimum and then deleted one statement at a time. And I found an improper view.invalidate inside the draw code...

I am ashamed of this so basic mistake. I cannot remember why and when I put that line but it was there and caused the bug. I suppose that view.invalidate will, at some instance, call draw, right?

Thank you very much for your help.

Sorry, Dan, but no success. I removed all other tools from the plugin folder and disabled all the native SU tools. The odd behavior remains.

Thank you, Dan, for your help.

Yes, I am using SU 8. And the tool do not use the ALT key, only CTRL , TAB and ESC.

With the tool active, I have access to all main menus (File, Edit, View, etc). But no submenu (like Edit/Unhide) open neither do the Preference modal dialog nor the Help/About. After trying to open the Preferences dialog, all main menu itens turn gray and the icons do not respond; the only ways I found to regain control of SU is either pressing the ALT key, the ESC key or a keyboard shortcut of another tool. After pressing the ALT key and closing the dialog, the tool resumes normally.