OCC2618

Dear Francois Lauzon,

This bug has been registered as OCC2618.
We'll inform you about changes in its status.

Yours faithfully
Bugmaster

Igor Nazarov's picture

Dear Francois,

It is not a bug.
It is default behavior of Open CASCDE visualization.
You can change the center of rotation by means of Rotate method:

Rotate ( me : mutable ; Ax,Ay,Az : PlaneAngle ;
X,Y,Z : Coordinate ;
Start : Boolean = Standard_True )
---Level: Public
---Purpose: Rotates the eye about the coordinate system of
-- reference of the screen
-- for which the origin is Gravity point {X,Y,Z},
-- with a relative angular value in RADIANS with respect to
-- the initial position expressed by Start = Standard_True
raises BadValue from Viewer;
-- If the eye, the view point, or the high point are
-- aligned or confused.

Yours faithfully
Bugmaster

Francois Lauzon's picture

Hi Bugmaster,
you're telling me it is the default behavior of StartRotation... maybe I didn't explain it correctly, here is a more detailled explanation:

void V3d_View::StartRotation(const Standard_Integer X,
const Standard_Integer Y,
const Quantity_Ratio zRotationThreshold) {

sx = X; sy = Y;
Standard_Real x,y;
Size(x,y);
rx = Standard_Real(Convert(x));
ry = Standard_Real(Convert(y));
Gravity(gx,gy,gz);
Rotate(0.,0.,0.,gx,gy,gz,Standard_True);
#ifdef IMP250900
zRotation = Standard_False;
if( zRotationThreshold > 0. ) {
Standard_Real dx = Abs(sx - rx/2.);
Standard_Real dy = Abs(sy - ry/2.);
// if( dx > rx/3. || dy > ry/3. ) zRotation = Standard_True;
Standard_Real dd = zRotationThreshold * (rx + ry)/2.;
if( dx > dd || dy > dd ) zRotation = Standard_True;
}
#endif

}

In the following code, even if I set a center of rotation myself, it is reset by the StartRotation method. It is fine if Gravity return de center of the displayed objects, but the way the center of the displayed objects is computed lead to incorrect result in some case. It could append that Gravity return 0,0,0, imagine you are looking at a 3d model that is dx=300mm, dy=300mm and dz=300mm but is located around 4000, 4000, 9000 in space, so if you see the whole model, the gravity is computed ok and then the rotation is done by a center point near 4000, 4000, 9000, but if you zoom the model, you could end up with a gravity computation of 0,0,0 and THIS become the center of rotation, so you just have to move the mouse a little and you lost your model into space. What I did has a temporary fix since I don't know much about the internal of V3d_View is the following:

void V3d_View::StartRotation(const Standard_Integer X,
const Standard_Integer Y,
const Quantity_Ratio zRotationThreshold) {

sx = X; sy = Y;
Standard_Real x,y;
Size(x,y);
rx = Standard_Real(Convert(x));
ry = Standard_Real(Convert(y));
Standard_Real ggx,ggy,ggz;
Gravity(ggx,ggy,ggz);
if (Abs(ggx)+Abs(ggy)+Abs(ggz)>Precision::Confusion()) {
gx=ggx; gy=ggy; gz=ggz;
}
Rotate(0.,0.,0.,gx,gy,gz,Standard_True);
#ifdef IMP250900
zRotation = Standard_False;
if( zRotationThreshold > 0. ) {
Standard_Real dx = Abs(sx - rx/2.);
Standard_Real dy = Abs(sy - ry/2.);
// if( dx > rx/3. || dy > ry/3. ) zRotation = Standard_True;
Standard_Real dd = zRotationThreshold * (rx + ry)/2.;
if( dx > dd || dy > dd ) zRotation = Standard_True;
}
#endif

}

I keep the last gravity if the one computed is near 0,0,0, and this is more of a desirable behavior. I have include a small avi file that show the current behavior (currentBehavior.avi) and the one with the fix (fixBehavior.avi) and the brep file you could use to see the problem (model.brep).

Thanks,
Francois.