Wed, 02/02/2011 - 16:41
Hi, I'm importing the attached STEP file. The result ought to be a circularly trimmed plane, translated along its normal vector by 2.0 units. But actually the plane's normal is still pointing along the z axis, but the translation is done along the x axis!
In line 104 of test.stp, the translation is defined
#77=CARTESIAN_POINT('S2->Labor',(0.,0.,2.));
After importing the STEP file in OCC, I took a look at the transformations. The plane's root compound shape reports as the translational part of its TopLoc_Location
Position(-2, -0, -0)
the TopLoc_Location's rotation matrix on the other hand has rows
Row 1(1, 0, 0)
Row 2(0, 1, 0)
Row 3(0, 0, 1)
So obviously the directions x and z are not swapped.
The TopLoc_Location contains only a single Datum3d object and the coumpound shape has no superior node, which could be responsible for a xz-swap.
When I re-export the file from Open CASCADE to STEP again, it prompts a line
#16 = CARTESIAN_POINT('',(-2,,0,E+000,0,E+000));
Rhino3d and other CAD programs are correctly importing the file (resulting in a circular trimmed plane, translated along it's normal vector by 2.0 units)
Wed, 02/02/2011 - 16:43
whoops sorry, i attached the version where i actually did the translation using
#77=CARTESIAN_POINT('S2->Labor',(2.,0.,0.));
resulting in the required z translation
attached is the correct file now
Thu, 02/03/2011 - 11:01
Hi,
I would like to inform you that the posted problem is checked and reproduced.
The corresponding issue with ID = OCC22238 has been registered.
Later you can know if the issue is resolved by checking references to the specified ID in OCCT Release Notes. The analysis of the issue will take some time depending on our technical capability and availability of resources.
If you can't wait and the problem is urgent for you, you may contact us via Contact Form http://www.opencascade.org/about/contacts/.
We will try to find a solution/workaround acceptable for you.
Regards
Fri, 02/04/2011 - 16:52
I can produce a z translation in Open CASCADE doing the following:
-switch the order, in which the vectors for the axis2 placements #52 and #53 are given. z,x instead of x,z
This seems to be the root cause for differences to other programs. Now Open CASCADE as well as Rhino3d translate the plane by -2.0 units in z direction.
Any idea why the other programs interpret the reverse order of directions that way?
Wed, 02/02/2011 - 17:18
Hello,
I can confirm the problem, result is not the same when imported in OCC Release 6.4.0 versus Catia V5R18...