[Bug ?]Draft Array works with Part container only if contained feature is visible

[openBrain]

Hi, just found a weird behavior when using Draft Array with Part container.
To reproduce :

1. Open the attached file => Everything is fine
2. Go in the tree view and hide the "Extrude" feature (eg. using 'Space' key) => "Part" container shows it needs a recompute
3. Recompute (eg. using 'F5' key) => Error triggers on "Array" feature with message "'Array' cannot build shape of 'Part'"

If you make "Extrude" visible and recompute, everything's back OK...

Can you confirm ?
---
OS: Ubuntu 18.04.3 LTS (KDE/plasma)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.18213 (Git)
Build type: Unknown
Branch: master
Hash: 22babc09954ac6fda9135ee71d68550921659b1c
Python version: 3.6.8
Qt version: 5.9.5
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: French/France (fr_FR)

[chrisb]

Open the attached file

There is no file attached.

[kisolre]

Confirmed with a simple file with:

OS: Windows 8.1 (6.3)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.18213 (Git)
Build type: Release
Branch: master
Hash: 22babc09954ac6fda9135ee71d68550921659b1c
Python version: 3.6.8
Qt version: 5.12.1
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: Bulgarian/Bulgaria (bg_BG)

Code: Select all

If there is some geometry visible inside Part Draft works. If all is hidden Draft gives error:
Traceback (most recent call last):
  File "E:\New Download\FreeCAD\_FreeCAD_x64\Mod\Draft\Draft.py", line 5854, in execute
    return _DraftLink.buildShape(self,obj,pl,pls)
  File "E:\New Download\FreeCAD\_FreeCAD_x64\Mod\Draft\Draft.py", line 5762, in buildShape
    obj.Name,obj.Base.Name))
<class 'RuntimeError'>: 'Array' cannot build shape of 'Part'

Recompute failed! Please check report view.

Without the part container Draft works as expected.
Here is my test file:

[openBrain]

Open the attached file

There is no file attached.

Too late a post. I know you know this problem. First post corrected for future correctness.

[Markymark]

Confirmed with separate file.
__________________________________________________
OS: Windows 10 (10.0)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.22164 (Git)
Build type: Release
Branch: master
Hash: f2a9f712e8d68ee2393d0fe748c02096c4148a32
Python version: 3.8.5
Qt version: 5.12.5
Coin version: 4.0.0
OCC version: 7.4.0
Locale: German/Germany (de_DE)

[vocx]

Hi, just found a weird behavior when using Draft Array with Part container.
...

The array commands are not intended to be used in this way. The arrays are intended to work on a Part_TopoShape (Shape), that is, directly with objects.

A Std_Part does not have a Shape of its own; it is a container for Shapes. So the Array could be contained inside one Part, but not the other way around.

The reason the first case works when the Extrusion is visible is probably due to changes in the code by realthunder, during the LinkMerge, in August 2019, some days before this post was made.

If I recall correctly, realthunder introduced some methods so that basically any object would return a Shape if requested. However, I think this still has some bugs. These types of visualization bugs affect all group-like objects, like Std_Parts, Std_Groups, and, say, Arch_BuildingParts. See [ Bug ] Project object: visibility of sub-objects is ignored. However, maybe when those pull requests from realthunder are merged, maybe this will work as intended with no issues.

[Markymark]

Thanks for this explanation. This is even stated in the wiki-pages (This tool can be used on any object that has a Part TopoShape ...).

It is just that you really must have a deeper understanding of the FC internals to derive the consequences of that comment. But this is a more general issue.

Good to know now.

Rgrds,

Mark

[vocx]

...
It is just that you really must have a deeper understanding of the FC internals to derive the consequences of that comment. But this is a more general issue.
...

Yes, in my opinion, as the Std Parts work now, the workflow followed here is not very intuitive. Parts should be top level containers; they could be contained by other Parts (assemblies of subassemblies), but they shouldn't participate in any other transformation, like boolean operations, or in this case, duplication. However, this may change, that is, depending on what realthunder does with the code.

ping

Any idea on this? Is it planned that Std_Parts support more transformations, or will they be kept as containers only? Can Array, or DraftLink be modified in this case to work as the first post wishes?

[TheMarkster]

Related to this, should an assembly object from assembly3 have a Shape property? Should Draft Arrays work with Assembly objects? It has a shape property currently, but seems to be null in my cursory experiments. For example Part.show(App.ActiveDocument.Assembly.Shape) produces an object, but it is an empty object. Attempting to make a rectangular orthogonal draft array with Assembly as a base crashed FreeCAD (crashed in this case meaning FreeCAD just exited without even offering to save the current document).

[vocx]

Related to this, should an assembly object from assembly3 have a Shape property? Should Draft Arrays work with Assembly objects? It has a shape property currently, but seems to be null in my cursory experiments...

As I said, I think realthunder has some ideas on how this should work. I think he has even considered performing boolean operations with two Std_Parts. This would improve the "in-context" workflow in which you create the assembly parts at the same time that you assemble them.

If I'm not mistaken, he implemented the Part.getShape method precisely to extract a Shape from any object, even groups, so that you could extract shapes from built assemblies for different operations.