FreeCADView Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000839 | FreeCAD | Bug | public | 2012-09-19 18:43 | 2014-12-27 10:03 |
| Reporter | fcaponi78 | Assigned To | |||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | won't fix | ||
| Product Version | 0.12 | ||||
| Summary | 0000839: Bug on boolean cut | ||||
| Description | I've found a bug causing a shape to be non-solid after boolean cut on boxes. Detailed description of the problem can be found here: https://sourceforge.net/apps/phpbb/free-cad/viewtopic.php?f=3&t=2993 | ||||
| Additional Information | Verified on version 0.13 1453 nightly on windows 7 64 bit | ||||
| Tags | No tags attached. | ||||
| FreeCAD Information | |||||
|
2012-09-19 18:43
|
|
|
|
Even commercial modelers fail on filleting such a complex shape at once! I would suggest to do the filleting step by step from big to small! If that doesn't work we have at the moment no way to deal with it, since we use the method of the CAD kernel... |
|
|
I ran into the same problem, but I found this (under Win7-64): 0.13.1828 (32bit): BAD 0.14.2192 (32bit): OK 0.14.2370 (32bit): OK 0.14.2778 (64bit): BAD A somewhat "simpler" toy example: microAdj1b.FCStd posted in http://forum.freecadweb.org/viewtopic.php?f=3&t=3768&hilit=bolt&start=10#p37685 This model looks just fine when I open it, but with the BAD FreeCAD versions, when I make a virtual change to the sketch in order to force FreeCAD to recompute the model, or when I remove the difference operation and add it again, the model loses the faces of the cylinder (except for the flat top and bottom faces). Now, setting the height of "Helix" to the pitch (or smaller) brings back the faces, but setting it to anything bigger (i.e. letting the helix make more than just one turn), makes the faces disappear again. For the OK versions editing microAdj1b.FCStd or running fcaponi78's python script work fine. Edit: Actually, the model can also break with the OK versions. For example with 0.14.2370 and the above-mentioned example, enter -1° for the starting angle of the helix (Position/Angle). Then the lower part of the cylinder is lost, up to where the helix starts. I have models with more rotations and depending on the parameters, one or the other part of the cylinder is lost. The lost faces (= holes) seem to come in integer multiples of 360° and always start/end at x=0. |
|
|
the link in the original report is now: http://forum.freecadweb.org/viewtopic.php?f=3&t=2993 |
|
|
The recent file posted by wandererfan: I believe this is a product of our float to double issue that is now solved. I made some simple changes and numbers starting looking good. The file posted by Dreide: File looks good here. I would guess that any problems with this file could be fixed by not starting and terminating the sweep at the seem edge of the cylinder. We have seen this before. This isn't related to the other problem in any way. If need be, it should have it's own bug report. So unless I missed something this report could be closed. |
|
|
@tanderson69: I think it is all related to the boolean cut operation not working reliably (actually, it is also other boolean operations). You are right that it seems to happen when the seams or edges of the to-be-combined objects coincide in some way, so it is probably a problem of CASCADE rather than of FreeCAD, as already suggested by Jriegel. That this behavior has been seen before and that there might be a workaround in some situations does not make it less of a bug though. I don't think that going from float to double would really solve the problem, it might just make the problem less likely to appear. Just saying. |
|
|
On Windows using OCC 6.3 or 6.6 both as 64-bit version don't work at all. Neither the attached script nor the referenced project give valid results. It fails to build "ContenitoreArrotondato". |
|
|
@wmayer: in regards to the script: I am seeing the same thing here as you. Everything works except the final fillet. I am not convinced the fillet edges and sizes are done correctly. If they are done correctly, as jriegel pointed out, this is too much for one feature. in regards to the project: I am assuming you are talking about the file linked by wanderfan? I believe this file was created before we had the float vs double issue solved, as I have seen some sloppy numbers. It could also benefit from model refine before attempting the blends. |
|
|
I played a bit more with microAdj1b.FCStd mentioned in my first post. EDIT: Oops, wrong. It was "bug on phone stand.FCStd" from the forum post wandererfan referred to. In this simple example, the problems can actually be resolved by by tweaking the dimensions and positions of the objects being cut out so that the faces of these objects are not aligned with the faces already there. Another way to resolve this problem is to activate "Automatically refine model after boolean operation" in the Part Design preferences and to force a recalculation of the model (by temporarily changing a parameter of an object at the lowest hierarchy level). This will screw up filleting as some edges disappear, so the filleting dialog needs to be opened and closed via OK again (filleting might now be done for the wrong edges, but for test purposes this is good enough). Unfortunately, this reveals just another problem with FreeCAD/OCC - the handling of "MeshDeviation" (Tools->Edit parameters->Preferences->Mod->Part or in the individual object View properties). The described cure only works with MeshDeviation=0.5 but not with MeshDeviation=0.2 (set in Edit Parameters -> Preferences; a value change seems to require a restart of FreeCAD in order to be effective) EDIT: I cannot reproduce the difference between the 0.2 and the 0.5 setting anymore, so disregard this finding! Regarding MeshDeviation, it is not clear which value is applied when, and why it is also found in the View properties even though it not only affects the view (not clear though whether the values in View have an effect anyway). For scripts it seems that always FreeCAD's default value (0.2?) is used unless "Run Macros in local environment" in References->General->Macro is ticked off. Moreover, the function behind "Refine shape" is named removeSplitter(), which suggests the contrary of refinement. It is unclear which model resolution is used before "Refine shape" and how it could be tweaked. Obviously, model accuracy (especially at intermediate steps) is crucial when it comes to models that involve not only a bunch of simple boxes (not even rotated). It is surprising that even this simple case is not robustly handled with the default settings. How MeshDeviation is used in the FreeCAD source code suggests that the accuracy finally applied to the shape (or the entire model?) depends on the size of the bounding box. This does not make sense, neither in the context of alleviating problems with boolean operations, nor for the final resolution of the output (e.g. STL, which is probably often used for 3D printing where the desirable model accuracy does not scale with object size). It is also not so nice that the model topology (e.g. number of editable edges) might change with different MeshDeviation values, because this might require reassigning the filleting, as seen in the example. I am a bit surprised to find these issues (boolean operations, model accuracy), which I consider so fundamental to 3D modeling, still in so much disorder. |
|
|
I also think that the script does the filleting wrong. When running it you can double-click the final fillet object and then a panel opens up which highlights all used edges. Here you can easily see that the choice of edges is at least not symmetric. So, since the fillet object is always broken it's not unlikely that the boolean operation doesn't work, like: if you put garbage in you get garbage out :) |
|
|
> The described cure only works with MeshDeviation=0.5 but not with MeshDeviation=0.2 OCC seems to use the tessellation of shapes for boolean operations -- at least for more complex shapes. Maybe OCC uses the mesh for some rough bounding box checks but this is something we have no control over. > require a restart of FreeCAD in order to be effective No, not at restart but when a shape gets rebuilt. Inside FreeCAD the mesh deviation is only used for the tessellation accuracy which we use to display a part in the 3d view. > Moreover, the function behind "Refine shape" is named removeSplitter(), which suggests the contrary of refinement. The point is that OCC often adds (especially with boolean operations) further edges to a model (i.e. splits faces) which shouldn't be there. The "refinement" cleans up these edges by sewing the concerning faces. I must agree that from my background "refinement" means the opposite, i.e. splitting up a face into several faces. tanderson69 wrote the hard algorithmic part while I wrote the Python binding and called it "removeSplitter()". > It is unclear which model resolution is used before "Refine shape" and how it could be tweaked. The mesh deviation has nothing to do with the refinement. The tolerance to check if two faces can be joined is very strict and is set by the CAD kernel. And talking about "model resolution" in context of CAD doesn't make sense to me. In CAD you work with mathematically exact geometries and thus you don't need a "model resolution". This is true for mesh modeller like Blender but not for CAD. > How MeshDeviation is used in the FreeCAD source code suggests that the accuracy finally applied to the shape (or the entire model?) depends on the size of the bounding box. The tessellation output is mainly used for the visual representation and thus we want to have as less triangles as possible to show the part in a sufficient quality. That's why it makes absolutely sense to make this value dependent on the bounding box size. In the past we had this as fix value and when creating a huge object e.g. of several meters in each dimension the tessellation algorithm took "forever". It created millions of triangles and took some hours in extreme cases. > might change with different MeshDeviation values, because this might require reassigning the filleting, as seen in the example Again, MeshDeviation has absolutely nothing to do with number of edges or the like. And the deviation to produce an STL is an independent value which you can set in the panel manually. > , because this might require reassigning the filleting, as seen in the example. Where have you seen this? I haven't. I guess what you are talking about is that the order of edges may change if some input values change. This is the "topology naming" problem which some guys work on in some external branches. |
|
|
My previous post referred to findings with "bug on phone stand.FCStd" from the forum post wandererfan referred to, and part of the findings I cannot reproduce anymore, so I consider them wrong (see also the EDITs in that post) - sorry for the confusion. @wmayer. Thinking that the solution of the problem depended on the MeshDeviation value put me completely off the track. Now, that I've learned that this actually seems not to be true, everything makes much more sense. I am still not clear about what the spatial resolution of the exported STL depends on, but this is off topic. So regarding the original bug, I still think there is a problem, but apparently not one caused by FreeCAD. Maybe one could rename the "Refine shape" function to "Consolidate shape" which reflects more what this function does (likewise for the according preference switch). |
|
|
So do we close this bug as "won't fix"? |
|
|
Yes, I think it makes sense to close the ticket as there exists a solution to model this correctly. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2012-09-19 18:43 | fcaponi78 | New Issue | |
| 2012-09-19 18:43 | fcaponi78 | File Added: portatelefono2-bug.py | |
| 2012-12-20 19:44 |
|
Note Added: 0002694 | |
| 2012-12-20 19:44 |
|
Assigned To | => Jriegel |
| 2012-12-20 19:44 |
|
Status | new => feedback |
| 2013-12-31 22:30 | Dreide | Note Added: 0003992 | |
| 2014-01-01 09:30 | Dreide | Note Edited: 0003992 | |
| 2014-01-02 14:19 | wandererfan | Note Added: 0004002 | |
| 2014-01-02 18:49 | tanderson69 | Note Added: 0004006 | |
| 2014-01-02 18:50 | tanderson69 | Note Edited: 0004006 | |
| 2014-01-02 21:23 | Dreide | Note Added: 0004010 | |
| 2014-01-03 10:02 | wmayer | Note Added: 0004011 | |
| 2014-01-03 13:59 | tanderson69 | Note Added: 0004012 | |
| 2014-01-03 15:17 | Dreide | Note Added: 0004013 | |
| 2014-01-03 15:20 | Dreide | Note Edited: 0004013 | |
| 2014-01-03 15:29 | wmayer | Note Added: 0004014 | |
| 2014-01-03 16:23 | wmayer | Note Added: 0004015 | |
| 2014-01-03 16:42 | Dreide | Note Edited: 0004013 | |
| 2014-01-03 18:25 | Dreide | Note Edited: 0004013 | |
| 2014-01-03 18:26 | Dreide | Note Added: 0004018 | |
| 2014-12-26 18:33 | normandc | Note Added: 0005445 | |
| 2014-12-27 10:03 | wmayer | Note Added: 0005450 | |
| 2014-12-27 10:03 | wmayer | Status | feedback => closed |
| 2014-12-27 10:03 | wmayer | Resolution | open => won't fix |
