An idea how to solve cross-cs support and assembly recompute

Discussion about the development of the Assembly workbench.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
User avatar
DeepSOIC
Veteran
Posts: 7896
Joined: Fri Aug 29, 2014 12:45 am
Location: used to be Saint-Petersburg, Russia

An idea how to solve cross-cs support and assembly recompute

Post by DeepSOIC »

I had a brainstorming on how to extend FreeCAD API for experimenting with part-o-magic's scoped recompute, and came to an interesting idea. The idea allows to make standard App::PropertyLink work seamlessly across coordinate systems, without the need to patch existing features. It also solves problems of making recompute system and assemblies work together.

Part1 of the idea. Recompute system revolution

* make recompute system nested.
Here's how the new recompute system would work.
1. Document::recompute:
1.1 gathers list of top level objects (typical situation: a spreadsheet, a master sketch, and a few Part containers).
1.2 topological sorts only these objects. Consider all objects, but treat links between objects as dependencies of top-level-object on top-level object
1.3 recompute these objects. As Part::Execute is called, it behaves as a subdocument, and takes care of recomputing all objects it contains. For example, a recompute routine of Body may look like:

Code: Select all

class Body(...):
    ...
    def execute(self, selfobj):
        self.recomputeExpressionsionsInSelf() #epsecially, in selfobj.Placement. These expressions should not use any objects contained by Body!, otherwise throw an error
        
        execute_order = TopologicalSort(self.Group, context= self)
        removeUntouchedObjects(execute_order)
        for obj in execute_order:
            obj.recompute()
        
        selfobj.Shape = copy_shape_get_rid_of_placement(selfobj.Tip.Shape)
And for assembly container, it will look like:

Code: Select all

class AssemblyConainer(...):
    ...
    def execute(self, selfobj):
        self.recomputeExpressionsionsInSelf() #epsecially, in selfobj.Placement. These expressions should not use any objects contained by Assembly!, otherwise throw an error
        
        # it is important that constraint objects don't put up their geometric links as dependencies
        # it recomputes contained Parts, instances, ..., and evaluates expressions in assembly constraints. But does not solve the assembly.
        execute_order = TopologicalSort(self.Group, context= self) 
        removeUntouchedObjects(execute_order)
        for obj in execute_order:
            obj.recompute()
        
        self.solveAssembly()
This creates quite a few benefits:
* scoped recompute becomes easy
(scoped recompute means that when a Part is active, only the objects contained by Part are recomputed, not the whole project.
* tolerance to dependency loops.
(if there is a dependency loop in some Part, the rest of the project will still recompute just fine)
* solves problems with dependencies on assembled pieces
* solves dependency-delated problem of accounting for Part.Placement from within Part itself.
* makes it possible to create brand new kinds of objects.
For example, a container that supports non-DAGness inside, for using it as an iterative process. Or support for a container that would optimize a Part's strength-to-weight ratio by recomputing the internals multiple times.
* possibility to do the Part2 of the idea!

And of course, drawbacks.
* certain cross-dependencies between containers are more restricted.
For example: Body2.Sketch2 links to Body1.Sketch1, and Body1.Sketch3 dependent on Body2.Sketch2. As of now, it will work just fine. With the nested recompute, this is a circular dependency between the bodies.

Part2 of the idea. Coordinate systems
Reimplement PropertyPartShape to account for coordinate system within getShape()/getValue(). PropertyPartShape finds out the transformation by querying Document.getActiveCS, and applies the transform to returned shape implicitly. The getActiveCS is to return the active CS container depending on situation:
* when recomputing, getActiveCS should always retuen the container of the object being recomputed right now.
* in other cases, getActiveCS should return activeContainer's CS.

So, execute of Body needs to be extended a bit:

Code: Select all

class Body(...):
    ...
    def execute(self, selfobj):
        selfobj.Document.setRecomputingActiveCS(selfobj) #but it can be done automatically by FreeCAD, implicitly
        
        self.recomputeExpressionsionsInSelf() #epsecially, in selfobj.Placement. These expressions should not use any objects contained by Body!, otherwise throw an error
        
        execute_order = TopologicalSort(self.Group, context= self)
        removeUntouchedObjects(execute_order)
        for obj in execute_order:
            obj.recompute()
        
        selfobj.Shape = copy_shape_get_rid_of_placement(selfobj.Tip.Shape)
        
        selfobj.Document.resetRecomputingActiveCS(selfobj)
Same applies to PropertyPlacement, and other geometry related properties (meshes, for example). It is tricky with PropertyVector.

Benefits:
* eliminates the need to have separate link class for cross-cs linkage
* gives cross-cs link support for all existing features without needing to modify them
Problems:
* the implementation of getActiveCS requires global variables, which creates obstacles for bringing recompute system into a separate thread.
* does not solve cross-cs links through Instances, does not give immediate support for using instances to all existing features.

As a consequence, Placement property of an object will appear to change, as different containers are activated. Which IMO is quite cool 8-) .

I feel like this idea came way too late :oops:
triplus
Veteran
Posts: 9471
Joined: Mon Dec 12, 2011 4:45 pm

Re: An idea how to solve cross-cs support and assembly recompute

Post by triplus »

Hi @DeepSOIC.

The way i see it from FreeCAD 0.17 point of view. More or less we are in the feature freeze phase now and fixing bugs should likely be it until the release happens. From FreeCAD 0.18 development cycle point of view i feel that all options are opened.

As for your proposal therefore you would split DAG in smaller scopes? In the past i do remember such ideas. To somehow make relation awareness localized. And if conditions are not resolvable to only affect that localized situation. And you would care about things like active coordinate system and forget about the rest? Valid observations in my opinion but i must say there are always more ways to tackle something. And in my opinion changing PartDesign to prepare it for Assembly was only one approach possible among more options. And in my opinion it turned out to be rather complex undertaking and a lot of it is only somehow related to Assembly effort directly. More or less it is about changing PartDesign workbench itself to something else.

Therefore in my opinion only working directly on Assembly workbench should fuel the discussions about what Assembly effort actually needs in the future. Until we do that we simply don't know. As for again working on something else and saying we are preparing FreeCAD for Assembly. Sorry but that doesn't cut it for me anymore. If somebody is actually prepared to work on Assembly workbench effort directly (hopefully not just from the PartDesign prism) keep talking i'm all ears.
ickby
Veteran
Posts: 3116
Joined: Wed Oct 05, 2011 7:36 am

Re: An idea how to solve cross-cs support and assembly recompute

Post by ickby »

Hello Deepsoic,

nice to see you are at this stuff again! I did not had much time to think about your idea, but here a few questions that came up.

Part1: I like this idea. It is more flexible, as it allows custom object dependend behaviour. Also it makes the Containres more integrated into the base system and hence more useful. Could you elaborate what you mean with those two points, I don't really get them:
* solves problems with dependencies on assembled pieces
* solves dependency-delated problem of accounting for Part.Placement from within Part itself.
Annother open question I have is how you think inter-container depndencies should work. For example the shapebinder, which brings geometry from one container to annother. In your approach such a dependencie cannot really be handled, and it seems impossible to establish the recompute order in a way that the shapebnder containing part is recomputed after the part it takes the shape from?

Part2: I don't understand the benefit of this idea. You noticed those two points:
* eliminates the need to have separate link class for cross-cs linkage
* gives cross-cs link support for all existing features without needing to modify them
But I can't see how your Idea will do that. You still have the problem that you can't link everywhere, as you don't know if the thing you link to was already recomputed if it is in annother Container (This is especially true for your approach, as recompute order is not anymore link dependend but container tree dependend). Furthermore, you solve assembly constraitns aftert the part features, so you still can't even link within the same AssemblyContainer, as the placements are able to change after the feature recompute. Hence I think you still need the linking restriction, and with that restriction arises the need to allow certain features to cirumvent this restriction by special properties.

So could you elaborate a bit more how you think you can achive the mentioned benefits? Most likely there are a few details I did miss in my short evaluation.
ickby
Veteran
Posts: 3116
Joined: Wed Oct 05, 2011 7:36 am

Re: An idea how to solve cross-cs support and assembly recompute

Post by ickby »

Therefore in my opinion only working directly on Assembly workbench should fuel the discussions about what Assembly effort actually needs in the future.
This is working on Assembly workbench, all the containre/linking stuff etc is. We are defining how to enable assemblies and how they will work with those discussions and codes. The actual assembly workbench is only a small thing once we have done this. So those discussion may be abstract, but they are tremeandusly important. Errors done now will affect the future usability massivly.
triplus
Veteran
Posts: 9471
Joined: Mon Dec 12, 2011 4:45 pm

Re: An idea how to solve cross-cs support and assembly recompute

Post by triplus »

ickby wrote: Mon Sep 04, 2017 5:54 am This is working on Assembly workbench, all the containre/linking stuff etc is. We are defining how to enable assemblies and how they will work with those discussions and codes. The actual assembly workbench is only a small thing once we have done this. So those discussion may be abstract, but they are tremeandusly important. Errors done now will affect the future usability massivly.
Hopefully.

P.S. But i do have a feeling we are seriously underestimating the Assembly workbench effort with such strategy. And the gap between such abstract discussions and the actual work needed to be done could end up being huge anyway. Therefore hopefully we will soon take more direct approach when it comes to Assembly as an ongoing effort.
User avatar
DeepSOIC
Veteran
Posts: 7896
Joined: Fri Aug 29, 2014 12:45 am
Location: used to be Saint-Petersburg, Russia

Re: An idea how to solve cross-cs support and assembly recompute

Post by DeepSOIC »

ickby wrote: Mon Sep 04, 2017 5:29 am So could you elaborate a bit more how you think you can achive the mentioned benefits?
OK, I will try post something in the evening.
Mark Szlazak
Posts: 439
Joined: Tue Apr 04, 2017 6:06 pm
Location: SF Bay Area, California

Re: An idea how to solve cross-cs support and assembly recompute

Post by Mark Szlazak »

Thank you for looking at this again!
User avatar
DeepSOIC
Veteran
Posts: 7896
Joined: Fri Aug 29, 2014 12:45 am
Location: used to be Saint-Petersburg, Russia

Re: An idea how to solve cross-cs support and assembly recompute

Post by DeepSOIC »

ickby wrote: Mon Sep 04, 2017 5:29 am So could you elaborate a bit more how you think you can achive the mentioned benefits? Most likely there are a few details I did miss in my short evaluation.
I created too many pictures for a forum post, so see here:
https://docs.google.com/document/d/1miI ... sp=sharing
EDIT:
anyone should be able to comment the doc ;)
teaser:
touch2.png
touch2.png (200.39 KiB) Viewed 3107 times
ickby
Veteran
Posts: 3116
Joined: Wed Oct 05, 2011 7:36 am

Re: An idea how to solve cross-cs support and assembly recompute

Post by ickby »

Thanks for the detailed explanaiton ( and the nice sketches ;) ) I added some comments.
User avatar
DeepSOIC
Veteran
Posts: 7896
Joined: Fri Aug 29, 2014 12:45 am
Location: used to be Saint-Petersburg, Russia

Re: An idea how to solve cross-cs support and assembly recompute

Post by DeepSOIC »

I plan to doodle some assembly graphs, stay tuned. It's going to be even more pictures, so it's going to take a while.

There is one more downside to this cross-cs linking solution. It lets us stick to these "classic" links for longer, while they don't support using instances. As a result, the switchover to instance-aware linking is going to be slower.
Post Reply