Steps forward to assembly infrastructure

[DeepSOIC]

There is one thing i don't understand when it comes to @ickby proposal. In tree view there would be only one entry?

See point 4 of the very first post:

Gui adoptions
a.Enable the tree to show a object multiple times

[triplus]

I see. Therefore tree view itself would need to be adapted for this change. And after having a representation of the same part multiple times would be possible. In addition each part could i guess be expanded to see all the features in it. To be honest that doesn't sound all that bad.

And what about the actual geometry in 3D View? How would that be done? For each "copy" of the part i am guessing each feature could be accessed directly? Wouldn't that introduce huge performance penalty? Or would there be some smart mechanism involved and performance penalty would be basically the same as when using single part?

[tanderson69]

Whatever you need to do. please don't hide a DAG structure behind a tree view.


Have you guys considered drawing something up to describe your document/assembly structures? A picture is worth a thousand words! Here is a screen dumped example. You can find the file in 'src/Gui/DAGView/DAGViewerDesign.svg'(inkscape)

Screenshot_20161011_101800.png (93.48 KiB) Viewed 1487 times

[DeepSOIC]

This also means that you still would do a lot of "bottom-up" searching of the graph (e.g. from object to all objects linking to that object) where the current document object model is not well suited for. Hence jriegels adoptions are still valuable for speeding this up.

I'd be curious to know what was done. I thought of that too, and the best I've come up with is that as soon as InList of anything is queried, document graph is built and cached, so that calls to InList of this and other objects that will follow will be super fast. Then, if document changes, the cached graph is either updated, or simply thrown away. The bad thing about that is that getInList will become non-const and non-reentrant.

I would still like to think a few days about it, you know, I'm a marked child regarding failed assembly structures and want to be sure there is not a show stopper we miss.

This is your advantage in this case, IMO. At least you know something that lead to trouble in past. I don't know, so I can fall into that trap too.

[DeepSOIC]

And one more thing that probably must be taken into consideration upfront. Array support.
Array of instances, I mean. Arrays can be dynamic in object count. So, during recomputing, instances may pop up and vanish.

I see two approaches:
* generate and delete instance objects during recompute
or
* collapse the array into one instance object

I think the easiest way is the second one - "array instance". It will be a single document object, but it will render the linked Part in multiple placements. Consequently, paths must include array item number when an array instance is in path!

[ickby]

I'd be curious to know what was done.

In general it is rather straight forward. Every DocumentObject has a std::vector InList that holds all objects that link to it. Than all PropertyLink properties are adopted to keep this list up-to-date. Every time a link is made or dropped the objects Inlists are updated. I actually like it very much, keeps the updating-work localized and the effort minimal compared to current way of doing it. The only downside is the need to really find all link codes.

[DeepSOIC]

Every DocumentObject has a std::vector InList that holds all objects that link to it. Than all PropertyLink properties are adopted to keep this list up-to-date. Every time a link is made or dropped the objects Inlists are updated.

Sounds good to me.
In addition to PropertyLink-derived properties, expression binding should be tracked too. Or, alternatively, add a specialized path-tracking variant of InList, that is only updated by containers/instances.

[DeepSOIC]

Whatever you need to do. please don't hide a DAG structure behind a tree view.

I don't quite understand what you mean. But. That made me think of tree view, and ickby's proposal to make tree view show an object multiple times.

First, I thought, OK! great, I've been wanting this long before I saw Part/Body containers! But then, after a bit of thinking, I realize it's not as great as it was at first glance.
First, imagine this situation.

cross-container-link.png (48.49 KiB) Viewed 1393 times

The tree view might show this:

Code: Select all

Document
    Part
        Extrude
            Sketch
    Part001
        Sketch

Now this is misleading, because Sketch is not in Part, but it appears like it is. This is easily revealed by hiding Part001 - Sketch suddenly gets hidden, even though Part is visible.
So what I would like to see, is that tree filling algorithm must be redesigned to have containers hard-coded into it. It should take children of container, and compute a subtree made from only those children. So that the tree will look like this:

Code: Select all

Document
    Part
        Extrude
    Part001
        Sketch

Then, I realized there is another interesting problem. If we are to show every claimed child, the size of the tree can grow exponentially with the number of objects. A specific example that demonstrates the possibility is this:

exponential-tree.png (53.1 KiB) Viewed 1393 times

This will generate ~160 items in tree, and adding another layer will roughly triple that number. So, adding about 14 more layers like that will make the computer run out of memory trying to build the whole tree.
Of course, it's a worst-case scenario, but it's just a proof that this can be such a problem. It can be avoided of course by building the tree on-demand, at the moment user expands the subtree.

[triplus]

Currently tree view does behave in a way when adding more and more items to it selection operation in the tree view starts to get slower and slower. Therefore i do imagine adding the whole part with its history to it (for each part "copy") could potentially influence performance. And i do imagine the situation in 3D view would become similar.

Comparing it to "Draft Clone" like assembly solid feature where each part "copy" is just another (standalone) feature (made on top of the "Part Tip").

[triplus]

I feel that 2 concepts are competing here.

1.) More "Draft Clone" alike and things can be figured out sooner. As after all Assembly2 module figured out a lot of it already. Generic assembly solver would likely work on all sorts of geometry not just on "Part Tip". Users would likely grasp the concept quickly.

2.) More complex and likely idealised vision. That is you can move the whole parts with all it features in 3D View easily and edit them in place when assembled... This in my opinion is more PartDesign centric solution and a lot of things are currently only a theory. I feel that nobody really knows the potential caveats ahead. Workflow involved would likely be more powerful but at the same time more hardware intensive and likely harder to grasp due to the fact adding complexity in the back-end by developers usually results in complex interaction in the front-end. Likely due to the fact resources are extremely limited and it is impossible to think about front-end interaction more in depth.

Now if things don't change there are 3 potential developers capable of progressing this. It looks like only 1 will work on it in foreseeable future.

P.S. Potential possible strategy:

Assembly2 -> Results (focused on concept 1 and Python based) -> FreeCAD 0.17
Assembly1 -> Long term FreeCAD assembly infrastructure related work (focused on concept 2 and beyond) -> It's done when it is done.