View Issue Details

IDProjectCategoryView StatusLast Update
0001228FreeCADBugpublic2013-09-22 11:33
Reporterulrich1a Assigned Towmayer  
Status closedResolutionfixed 
Product Versiontrunk 
Fixed in Version0.14 
Summary0001228: Cross section of Torus in Part Workbench fails or give wrong results
DescriptionMake a torus in the Part Workbench. Select the torus and make a cross section in xy-plane: Only the outer circle of the cross section is created.
Select the torus and make a cross section in the yz-plane: no circles are created.
I would expect two circles in both cases.
Additional InformationWindows 7, 32 bit
Freecad 0.14, 2370(Git) installed from unstable installer.
TagsNo tags attached.
FreeCAD Information


related to 0001137 closedwmayer Incomplete slices when using Part.slice on a torus 



2013-08-25 13:36

administrator   ~0003520

git show 348fcef


2013-08-26 16:28

reporter   ~0003521

The cross section in the xy-plane works now for me.
I did not get circles for the xz-plane or yz-plane of the cross sections of the torus.
I got the following message in the command line:
Cannot compute Inventor representation for the shape of Torus_cs001.
Traceback (most recent call last):
  File "<string>", line 1, in <module>
<type 'exceptions.Exception'>:
Stack Trace: Traceback (most recent call last):
  File "<string>", line 1, in <module>

Tested with Debian Wheezy 32 bit.


2013-08-28 09:15

administrator   ~0003526

Did you get the very latest sources? I have tested this on two platforms:
* Windows 7, 64-bit with OCC 6.3
* Ubuntu 12.04, 64-bit with OCC 6.5
and on both everything work perfectly. What OCC/OCE version do you have?


2013-08-28 13:18

reporter   ~0003528

I did a git pull and a compilation run just before the test. There was also the improvement visible: I got two rings in the xy-plane.
I am using OCE 0.13 which bases on OCCT 6.6.0.
It could be a 32-bit-problem again.
Do you have a recommendation or hint for debugging?


2013-08-28 13:50

developer   ~0003529

I can confirm this also. I am at 38f0f73fbe(1 commit ahead of fix). I have oce 0.13.1 (cascade 6.5.0).

It has something to do with position set to zero.

default torus: (same with both xz and yz planes)
*z plane, position = .0000: fails(no output)
*z plane, position = .0001: works
*z plane, position = -.0001: works

default torus (translated 1.0, 1.0, 0.0): (same with both xz and yz planes)
*z plane, position = .0000: fails(no output)
*z plane, position = .0001: works
*z plane, position = -.0001: works

Kubuntu 13.04 64bit.


2013-08-29 09:42

administrator   ~0003530

Then I wonder if this could be a regression in OCE (compared to OCC).


2013-08-29 17:55

developer   ~0003532

whoops my oce is based from cascade version 6.5.4 not 6.5.0 as posted before.

BRepPrimAPI_MakeHalfSpace is throwing the exception.

it is a little difficult to follow the changes to BRepPrimAPI_MakeHalfSpace.cxx in the oce repo. what is the latest version of occt that works?

this has nothing to do with a torus as I am seeing the same behavior with a block.


2013-09-01 12:52

administrator   ~0003535

Using occ 6.6.0 everything is fine for me. So, with three different occ versions I do not have any problems.


2013-09-13 10:40

reporter   ~0003569

I tested on Windows 7 32 bit, with OCC 6.5.1 (Libpack), Version: 0.14.2497 (Git).
I still have the same issues as reported before. It works only with an offset of 0.0001. So could it be an issue with 32 bit versions? OCC has a lot of conditional code depending on Linux / Windows / 32bit /64 bit.


2013-09-14 09:34

administrator   ~0003576

I have tested this on two 64-bit platforms and one 32-bit platform with different OCC versions but never experienced this problem.

But it could be the general limitation of the boolean operations when two faces are partly coincident. On the other hand tanderson69 said he gets an exception when creating a half-space object which at this point has nothing to do with boolean operations.

2013-09-14 19:30 (Attachment missing)


2013-09-14 19:35

reporter   ~0003579

I upload a python script (, which produces the exeception on my system. Can you test it on one of your working systems? If it runs without failure, it should make 4 rings.


2013-09-14 21:45

administrator   ~0003580

On my 32-bit system it creates four rings. The other tests on the 64-bit platforms will follow...


2013-09-16 11:34

administrator   ~0003586

So, on all my three tested systems I got the expected result of four rings. These are:
* Ubuntu 12.04, 64-bit, OCC 6.5.0
* Ubuntu 12.04, 32-bit, OCC 6.5.0
* Windows 7, 64-bit, OCC 6.3.0


2013-09-16 16:13

reporter   ~0003587

I would be happy, if I could also get the four rings.
I tried without success at the following installation:
OS: Windows 7
Platform: 32-bit
Version: 0.14.2512 (Git)
Branch: master
Hash: e157152c962fe1fe5340dbe825f31f1e21f9a09a
Python version: 2.6.2
Qt version: 4.5.2
Coin version: 3.1.0
SoQt version: 1.4.1
OCC version: 6.5.1

Build with Libpack 8.1 with VC9 express.
What I am doing wrong?
The compilation ran without an error, but with a lot of warnings like: double converted to float, signed unsigned problems and others.


2013-09-17 01:22

reporter   ~0003591

I too cannot get any cross section through an object created in Part Workbench by the "Create a Torus Solid" or "Create a Box Solid" button (I didn't try with any other shapes), but do get cross sections when made through parts created by padding a sketch in Part Design Workbench.

So tried an experiment. From Part Design Workbench I made a rectangular sketch, padded it, mapped a new sketch to the top face, created a smaller rectangular sketch, and Pocketed "Through All". Then I switched to Part Workbench and created a torus which was inside my hollowed out cube. Then I selected both Pocket and Torus (Ctrl-left-click both one at a time in the hierarchy tree), then clicked the Sections Bottom. It only sectioned the Box, not the torus.

Here's a link to a quick video of it:

OS: Windows XP
Platform: 32-bit
Version: 0.14.2370 (Git)
Branch: master
Hash: a836759ebd91404954a778ff8885e152611576e1
Python version: 2.6.2
Qt version: 4.5.2
Coin version: 3.1.0
SoQt version: 1.4.1
OCC version: 6.5.1


2013-09-21 07:25

administrator   ~0003598

I don't think it makes a difference which OCC version is used and how it is compiled. But there is one point which is not so obvious and was not taken into consideration so far:

in the preferences there is a parameter (Part design > Shape view) "Maximum deviation depending on the model bounding box". This parameter here is set to 0.5. The parameter is used as a meshing tolerance and the lower it is the finer your shape is and thus the exacter many algorithms work.

FYI, it is known that the bounding box of a shape is computed by using its internal mesh representation. If this mesh is cleared the bounding box can be totally wrong. And my guess is that for the slicing the mesh is also used.


2013-09-21 13:56

reporter   ~0003609

I just tried again, changing Part Workbench -> Edit -> Preferences -> Part design -> Shape view -> Tessellation -> Maximum deviation depending on the model bounding box. Changing from the default value of .5000% to something like .0020% caused a warning dialog box to appear with the message "Setting a too small deviation causes the tessellation to take longer and this freezes or slows down the GUI". And indeed it did, trying to create a torus from the "Create a torus solid" tool button took several minutes and with no result visible I terminated FreeCAD. I tried again by changing the default from .5000% to .0200% but still I was not able to get a section through the torus.

2013-09-21 15:37


slice.patch (Attachment missing)


2013-09-21 15:38

developer   ~0003613

Finally poked my head into this again. I think the point for the halfspace construction isn't correct. Here is a small patch that appears to have fixed it. At least here.


2013-09-21 17:29

reporter   ~0003615

I applied the slice.patch on my Debian 32-bit version of FreeCAD. It works for me too.
Thank you tanderson69!


2013-09-22 11:33

administrator   ~0003620

git show e34a68e

Issue History

Date Modified Username Field Change
2013-08-23 13:23 ulrich1a New Issue
2013-08-24 11:06 wmayer Relationship added related to 0001137
2013-08-25 13:35 wmayer Status new => assigned
2013-08-25 13:35 wmayer Assigned To => wmayer
2013-08-25 13:36 wmayer Note Added: 0003520
2013-08-25 13:36 wmayer Status assigned => closed
2013-08-25 13:36 wmayer Resolution open => fixed
2013-08-25 13:36 wmayer Fixed in Version => 0.14
2013-08-26 16:28 ulrich1a Note Added: 0003521
2013-08-26 16:28 ulrich1a Status closed => feedback
2013-08-26 16:28 ulrich1a Resolution fixed => reopened
2013-08-28 09:15 wmayer Note Added: 0003526
2013-08-28 13:18 ulrich1a Note Added: 0003528
2013-08-28 13:50 tanderson69 Note Added: 0003529
2013-08-29 09:42 wmayer Note Added: 0003530
2013-08-29 17:55 tanderson69 Note Added: 0003532
2013-09-01 12:52 wmayer Note Added: 0003535
2013-09-13 10:40 ulrich1a Note Added: 0003569
2013-09-14 09:34 wmayer Note Added: 0003576
2013-09-14 19:30 ulrich1a File Added:
2013-09-14 19:35 ulrich1a Note Added: 0003579
2013-09-14 21:45 wmayer Note Added: 0003580
2013-09-16 11:34 wmayer Note Added: 0003586
2013-09-16 16:13 ulrich1a Note Added: 0003587
2013-09-17 01:22 bejant Note Added: 0003591
2013-09-21 07:25 wmayer Note Added: 0003598
2013-09-21 13:56 bejant Note Added: 0003609
2013-09-21 15:37 tanderson69 File Added: slice.patch
2013-09-21 15:38 tanderson69 Note Added: 0003613
2013-09-21 17:29 ulrich1a Note Added: 0003615
2013-09-22 11:33 wmayer Note Added: 0003620
2013-09-22 11:33 wmayer Status feedback => closed
2013-09-22 11:33 wmayer Resolution reopened => fixed