support for App::Link assemblies in FCStd format

[khimaros]

FreeCAD has not settled on a single assembly system, but an underlying primitive App::Link has emerged as a standard and is used by most of the assembly workbenches. it allows the same geometry to be used multiple times, across multiple files if desired.

attached here is the simplest assembly that i could come up with to demonstrate the failure mode (3DViewer hangs indefinitely when importing).

there are two test cases:

• simple-assembly-unified.FCStd is a standalone assembly that uses App::Link within a single file.
• simple-assembly.FCStd and simple-cube.FCStd are used to demonstrate cross-file links.

both of these were made with the Assembly3 workbench, which is freely available from the FreeCAD addon manager.

[khimaros]

diving in a bit to the implementation details.

in all cases, the linked objects are like any other <Object>

there are a few properties which are important for properly handling a linked object LinkedObject, LinkPlacement, Scale, ScaleVector, ShowElement, and Visibility.

when App::Link is using objects across multiple files, there is a property in Document.xml which references the file containing the linked object, as in <XLink file="simple-cube.FCStd" stamp="2022-10-10T02:56:54Z" name="Box"/> where Box is the name of the object in the referenced file.

when the object is linked from the same file the property will have file="" but otherwise behaves identically.

here's a complete example of a new object with the name Link being created from the Box object in a the external file simple-cube.FCstd:

        <Object name="Link" Extensions="True">
            <Properties Count="24" TransientCount="0">
                <Property name="LinkedObject" type="App::PropertyXLink" status="256">
                    <XLink file="simple-cube.FCStd" stamp="2022-10-10T02:56:54Z" name="Box"/>
                </Property>
                <Property name="LinkPlacement" type="App::PropertyPlacement" status="264">
                    <PropertyPlacement Px="10.0000000000001066" Py="-0.0000000000000000" Pz="0.0000000000000000" Q0="0.0000000000000000" Q1="0.0000000000000000" Q2="0.0000000000000107" Q3="1.0000000000000000" A="0.0000000000000000" Ox="0.0000000000000000" Oy="0.0000000000000000" Oz="1.0000000000000000"/>
                </Property>
                <Property name="Scale" type="App::PropertyFloat" status="256">
                    <Float value="1.0000000000000000"/>
                </Property>
                <Property name="ScaleVector" type="App::PropertyVector" status="67109120">
                    <PropertyVector valueX="1.0000000000000000" valueY="1.0000000000000000" valueZ="1.0000000000000000"/>
                </Property>
                <Property name="ShowElement" type="App::PropertyBool" status="256">
                    <Bool value="true"/>
                </Property>
                <Property name="Visibility" type="App::PropertyBool" status="648">
                    <Bool value="true"/>
                </Property>

i suspect multi-file support would be blocked on changing the way 3DViewer handles multiple files. as of now, it lets you upload multiple but only allows you to open one of them at a time.

[khimaros]

i believe this is the source of the hang, because App::Link objects won't have their own brep content: https://github.com/kovacsv/Online3DViewer/blob/dev/source/engine/import/importerfcstd.js#L361

let currentObject = objects[convertedObjectCount];
        this.worker.postMessage ({
            format : 'brep',
            buffer : currentObject.fileContent
        });

the backtrace i see when loading these files is:

Uncaught TypeError: a is undefined
    ConvertObjects importerfcstd.js:373
    ImportContent importerfcstd.js:335
    Import importerbase.js:29
    ImportLoadedMainFile importer.js:218
    ImportLoadedFiles importer.js:172
    onReady importer.js:120
    DecompressArchives importer.js:257
    onReady importer.js:119

[kovacsv]

I've already "fixed" that: https://github.com/kovacsv/Online3DViewer/commit/d7345647fcc617fb2513160173841f9a11d86ab8. It still doesn't import assemblies, but at least doesn't hang. 🙂

[khimaros]

ah great! you're moving so quickly, i wasn't expecting you to already be hacking on this! :)

[Zolko-123]

Szia Viktor, ez igazán fontos lenne ! Üdvözlettel, Zoltán

[khimaros]

it looks like the primary blocker for this might be resolved!

is this something that you think would be relatively easy to add now?