View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002676||Part||Bug||public||2016-08-19 06:18||2018-11-13 22:50|
|Target Version||0.18||Fixed in Version||0.18|
|Summary||0002676: Differences in python API depending on OCC version|
|Description||The 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 Reproduce||1. Load Brep file|
2. Select Brep file
3. Execute macro
4. Compare results
|Additional Information||See forum post for additional information:|
|Tags||No tags attached.|
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.
||And I want to note that the change of behavior of Part Fuse breaks many of my old projects.|
||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.|
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:
•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.
||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.|
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.
||bumped forum thread: https://forum.freecadweb.org/viewtopic.php?f=3&t=17054&p=157122#p157122|
||Postpone to 0.18|
||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|
|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|