FreeCADView Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001228 | FreeCAD | Bug | public | 2013-08-23 13:23 | 2013-09-22 11:33 |
| Reporter | ulrich1a | Assigned To | wmayer | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | trunk | ||||
| Fixed in Version | 0.14 | ||||
| Summary | 0001228: Cross section of Torus in Part Workbench fails or give wrong results | ||||
| Description | Make 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 Information | Windows 7, 32 bit Freecad 0.14, 2370(Git) installed from unstable installer. | ||||
| Tags | No tags attached. | ||||
| FreeCAD Information | |||||
|
|
git show 348fcef |
|
|
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. |
|
|
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? |
|
|
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? |
|
|
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. |
|
|
Then I wonder if this could be a regression in OCE (compared to OCC). |
|
|
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. |
|
|
Using occ 6.6.0 everything is fine for me. So, with three different occ versions I do not have any problems. |
|
|
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. |
|
|
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
|
|
|
|
I upload a python script (slitor.py), 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. |
|
|
On my 32-bit system it creates four rings. The other tests on the 64-bit platforms will follow... |
|
|
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 |
|
|
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. |
|
|
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: https://www.dropbox.com/s/ms56jymulhou82x/20130916d%20Torus.avi 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 |
|
|
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. http://opencascade.blogspot.de/2009/04/all-inclusive-bounding-box.html |
|
|
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
|
|
|
|
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. |
|
|
I applied the slice.patch on my Debian 32-bit version of FreeCAD. It works for me too. Thank you tanderson69! |
|
|
git show e34a68e |
| 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: slitor.py.zip | |
| 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 |
