View Issue Details

IDProjectCategoryView StatusLast Update
0002676Part[FreeCAD] Bugpublic2018-11-13 22:50
Reporterickby Assigned Towmayer  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Version[FreeCAD] 0.17 
Target Version[FreeCAD] 0.18Fixed in Version[FreeCAD] 0.18 
Summary0002676: Differences in python API depending on OCC version
DescriptionThe attached script works fine with OCC 6 and the attached brep shape. It does not work correctly with OCC 7.0. This use case should be used to find differences in OCC depending in Version and to counteract those in FreeCAD source. It is not acceptable that FreeCAD behaves differently depending on used OCC version as this breaks backwards compatibility.

One known example: multiFuse returns a fused shell in 6.8, but only a compound of faces in 7.0

There are additional differences as replacing multifuse alone makes the script not run correctly.
Steps To Reproduce1. Load Brep file
2. Select Brep file
3. Execute macro
4. Compare results
Additional InformationSee forum post for additional information:
http://forum.freecadweb.org/viewtopic.php?f=3&t=17054
TagsNo tags attached.
FreeCAD Information

Relationships

related to 0003333 closedwmayer Wrong behaviour of fuse operation 

Activities

ickby

2016-08-19 06:18

developer  

slice.brep (Attachment missing)

ickby

2016-08-19 06:18

developer  

slice.FCMacro (Attachment missing)

DeepSOIC

2016-08-19 09:59

developer   ~0007286

Part Fuse is also affected, of course.

I was thinking of fixing this when making new GFA-based tools, but shape history management stopped me. I wanted to redirect Part Fuse to use TopoShape fuse, but then I need to introduce history management to TopoShape, which is something ezzieyguywuf is busy with.

DeepSOIC

2016-08-19 10:00

developer   ~0007287

And I want to note that the change of behavior of Part Fuse breaks many of my old projects.

ickby

2016-08-19 11:07

developer   ~0007288

DeepSOIC: do you know if there is any rational behind this from occ side, some discussion or announcement why this is the case? If not I would bring the discussion to them, either forum or tracker, because IMHO this is a bug: The faces are not fused together if they stay seperate and dont form a shell.

DeepSOIC

2016-08-19 11:51

developer   ~0007289

I don't know why.
But the behavior matches to what is written in OCCT manual:
"Case 11: Two intersecting faces

Let us consider two intersecting faces F1 and F2:

boolean_image027.png
•The result of Fuse operation is a compound containing split parts of arguments i.e. 2 new faces F11 and F21. These faces have one shared edge En1."
This is exactly what happens.

https://www.opencascade.com/doc/occt-6.9.0/overview/html/occt_user_guides__boolean_operations.html#occt_algorithms_9_4_11

ickby

2016-08-19 12:42

developer   ~0007290

Thanks, did not yet know those examples. I asked the OCC guys on the forum, let's see if a answer will be given. I do have the feeling that it is a question of consistant return types: face/face fuse can result in a shell only in certain circumstances like coplanar faces, but e.g. not for "cutting" faces like shown in the example you linked. Hence to have the same return type for every face/face fuse the more general result is returned: the individual faces.

DeepSOIC

2016-08-19 13:02

developer   ~0007291

I was successful at making shell off the "cutting" faces like shown in OCCT guide. I just used Connect which internally is GeneralFuse + Part.makeShell. (Can I attach files here?)

That shell passes the BOPCheck, so I assume it's not terribly invalid, apart from being non-manifold.
So, return types can still be consistent.

Kunda1

2017-01-30 20:15

administrator   ~0008110

bumped forum thread: https://forum.freecadweb.org/viewtopic.php?f=3&t=17054&p=157122#p157122

wmayer

2018-01-02 13:45

administrator   ~0010663

Postpone to 0.18

wmayer

2018-11-13 22:50

administrator   ~0012193

The output of fused faces to create a shell instead of a compound of faces has been fixed. The script of the referenced forum thread gives again the expected result. However, Part.Line must be replaced with Part.LineSegment

Issue History

Date Modified Username Field Change
2016-08-19 06:18 ickby New Issue
2016-08-19 06:18 ickby File Added: slice.brep
2016-08-19 06:18 ickby File Added: slice.FCMacro
2016-08-19 09:59 DeepSOIC Note Added: 0007286
2016-08-19 10:00 DeepSOIC Note Added: 0007287
2016-08-19 11:07 ickby Note Added: 0007288
2016-08-19 11:51 DeepSOIC Note Added: 0007289
2016-08-19 12:42 ickby Note Added: 0007290
2016-08-19 13:02 DeepSOIC Note Added: 0007291
2017-01-30 20:15 Kunda1 Note Added: 0008110
2017-10-18 14:20 wmayer Project FreeCAD => Part
2018-01-02 13:45 wmayer Target Version 0.17 => 0.18
2018-01-02 13:45 wmayer Note Added: 0010663
2018-01-30 11:12 Kunda1 Relationship added related to 0003333
2018-11-13 22:50 wmayer Assigned To => wmayer
2018-11-13 22:50 wmayer Status new => closed
2018-11-13 22:50 wmayer Resolution open => fixed
2018-11-13 22:50 wmayer Fixed in Version => 0.18
2018-11-13 22:50 wmayer Note Added: 0012193