Moved Object visualization

[yorik]

I have an old CHM file of version 5.2. The newer documentation generated by doxygen is IMO nearly unusable.

Werner could you somehow share that chm file? Many forum threads talk about it, but I cannot find a valid download link... I have the same opinion about the doxygen OCC stuff

[wmayer]

I hope the upload worked...

[wmayer]

Hmm, it seems to have failed. The file is about 11MB can I upload it somewhere else?

[yorik]

Can you send it to my gmail account? yorik.vanhavre at gmail dot com
I think gmail accounts can take up to 15Mb
I'll upload it on 4shared next, so people can download it from there.
Thanks!

[wmayer]

Hi Andrey,

I have cleaned up with some incorrect usage of the matrix concerning scaling, i.e. the value a44 is now always 1 and not longer used for scaling. I did this because I thought that because gp_Trsf has a single value for scaling and only this one is used. Apperently, this assumption is wrong. Then I fixed a bug in the transformGeometry() method (renamed from transform()). Now it supports a correct scaling, too. However, it still has the problem of changing the geometry type.

So, this means that if you want to do scaling you must use the transformGeometry() method which creates a complete new shape. Trying to do scaling by setting the TopLoc_Location data of a shape doesn't really work anyway. The OCC data structure actually allows to set a scaling but it doesn't seem to work correctly. BTW, if you add a shape to an object the scaling is lost anyway.

Cheers,
Werner

[wmayer]

Here is a short example to demonstrate that boolean operations don't work as expected if a shape was scaled by setting TopLoc_Location.

Cut_Operation

cut.jpg (20.2 KiB) Viewed 3204 times

You'll see that when scaling this is only possible by modifiying the underlying geometry.

This was tested with pythonOCC just to make sure that is not FreeCAD-specific.

The Python code is:

Code: Select all

from OCC import BRepAlgoAPI, BRepPrimAPI, TopoDS, TopLoc, gp
import math

p=gp.gp_Pnt(0,0,0)
d=gp.gp_Dir(0,0,1)

mov=gp.gp_Trsf()
mov.SetValues(2.0,0.0,0.0,0.0,0.0,1.5,0.0,0.0,0.0,0.0,3.0,0.0,0.00001,0.00001)
loc=TopLoc.TopLoc_Location(mov)

box=BRepPrimAPI.BRepPrimAPI_MakeBox(gp.gp_Ax2(p,d),10,10,10).Shape()
box.Move(loc)
sph=BRepPrimAPI.BRepPrimAPI_MakeSphere(gp.gp_Ax2(p,d),6,-math.pi/2,math.pi/2,2*math.pi).Shape()
cut=BRepAlgoAPI.BRepAlgoAPI_Cut(box,sph).Shape()

display.DisplayShape(cut)

Werner

[jriegel]

Makes perfectly sense to me! If you think about the boolean operations. This algorithms are extremely complicated anyway. If they have to take care of arbitrary 4x4 matrices it would be nearly impossible!

So for me this leads to two ways:

• Positioning in the sense of Placement and TopLoc_Location without scaling and without changing the geometry.
• Transformation with either a Placement or a Matrix, which change the eventually the geometry.

Maybe we shut change the names again to "setLocation" and "Transform" and rename "Placement" to "Location"?

Jürgen

[yorik]

I also had some thoughts about the subject:

- I find Jürgen's argument valid: Freecad would prioritize working with placement only, scaling objects is secondary. Actually, I agree much, in the draft module I first thought about doing a scale tool ,and at the end I didn't do it because I didn't find necessary, and really, scaling an object is not something you do very often in cad, and when you do, it's a special operation that is most of the time carefully done because suddenly you are not sure anymore at which coordinates your vertices are, so it's potentially dangerous.
- In FreeCAD's structure, this is not too clear, because matrixes are very obvious (They are in the Base module and in the FreeCAD module itself). Really, before we had this discussion, I thought matrixes were intended by you guys as a very fondamental tool...
- The word Placement is not very used in 3D world, as far as I know... Maybe, indeed, there is a bit of confusion in all that nomenclature? Would using the word "Location" do any better? I don't know.
- What about rotation?

Yorik

[yorik]

To anyone else interested, I uploaded the occ 5.2 chm file here:
http://www.4shared.com/file/128871432/9 ... occ52.html

[malinand]

Hi All,
So I did some digging into Doxygen documentation...
It is not too much fun reading it ideed, but may be you can get some clue...
TopLoc_Location Class Reference:

A Location is a composite transition. It comprises a
series of elementary reference coordinates, i.e.
objects of type TopLoc_Datum3D, and the powers to
which these objects are raised.

Description of TopLoc_Datum3D doesn't expain too much, but one could guess that if it is datum, it should encode location (3D point) and may be rotation ( if we assume that datum is 3 orthogonal vectors)
So there is a check for it:

TopLoc_Datum3D (const gp_Trsf &T)
Constructs a Datum3D form a Trsf from gp. An error is
raised if the Trsf is not a rigid transformation.

I bet "rigid transformation" should preserve angles and distances. Scaling is not rigid transformation, so TopLocLocation should raise an exception if gp_Trsf matrix doesn't represent rigid tranformation...

Next step is what is gp_Trsf class:

Defines a non-persistent transformation in 3D space.
The following transformations are implemented :
. Translation, Rotation, Scale
. Symmetry with respect to a point, a line, a plane.
Complex transformations can be obtained by combining the
previous elementary transformations using the method
Multiply.
The transformations can be represented as follow :

V1 V2 V3 T XYZ XYZ
| a11 a12 a13 a14 | | x | | x'|
| a21 a22 a23 a24 | | y | | y'|
| a31 a32 a33 a34 | | z | = | z'|
| 0 0 0 1 | | 1 | | 1 |
.

I think most informative is description of Set Values() method:

SetValues (const Standard_Real a11, const Standard_Real a12, const Standard_Real a13, const Standard_Real a14, const Standard_Real a21, const Standard_Real a22, const Standard_Real a23, const Standard_Real a24, const Standard_Real a31, const Standard_Real a32, const Standard_Real a33, const Standard_Real a34, const Standard_Real Tolang, const Standard_Real TolDist)
Sets the coefficients of the transformation. The
transformation of the point x,y,z is the point
x',y',z' with :

x' = a11 x + a12 y + a13 z + a14
y' = a21 x + a22 y + a23 z + a24
z' = a31 x + a32 y + a43 z + a34

Tolang and TolDist are used to test for null
angles and null distances to determine the form of
the transformation (identity, translation, etc..).

The method Value(i,j) will return aij.
Raises ConstructionError if the determinant of the aij is null. Or if
the matrix as not a uniform scale.

My understanding of all of this:
1. Fourth line of the transformation matrix should not do anything, if it does it is the bug of OpenCASCADE.
2. If you are trying to use not rigid transformation matrix (like scaling) to set up Location OpenCASCADE should raise en error. If it doesn't it is a bug of OpenCASCADE
3. Because OpenCASCADE will accept non-rigid matrixes as the member of gp_Trsf class, the best way to deal with it would be to check the matrix for any translation and raise an error any time when non-rigid matrix is used.
4. If gp_Trsf is available (I think it is very good to have an option to work directly with transformation matrix), check that this matrix represent:

Translation, Rotation, Scale ,Symmetry with respect to a point, a line, a plane

Exception should be raised otherwise. If it is too difficult to implement, matrix should be accessible only throught set of methods representing full set of listed transformations. Othewise it is impossible to predict results...

Andrey