Steps forward to assembly infrastructure

Here's the place for discussion related to coding in FreeCAD, C++ or Python. Design, interfaces and structures.
User avatar
tanderson69
Posts: 1548
Joined: Thu Feb 18, 2010 1:07 am

Re: Steps forward to assembly infrastructure

Postby tanderson69 » Wed Oct 12, 2016 5:18 pm

DeepSOIC wrote:
tanderson69 wrote: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.
It sounds like you know what I mean. I was more concerned about an accurate representation than performance.
ickby
Posts: 2982
Joined: Wed Oct 05, 2011 7:36 am

Re: Steps forward to assembly infrastructure

Postby ickby » Fri Oct 14, 2016 8:58 am

@DeepSOIC:

I think your idea with a Instance stack requires that the instances cash their placement relative to the next toplevel instance, or to toplevel in document. As a instance could have multiple parent instances they need to cash a list of parent placements, one for each parent? I think kind of cashing is problematic, as normally objects do not see any change that happens elsewhere in the document. Now if a instance is moved from one container to annother or gets added to annother container which has annother parent Instance the instance in question does not know that and the cashed placements are invalid. I think for for this to work one needs a new recompute system to globally inform objects of global changes? This sounds very problematic.

If one would like to avoid that kind of recompute system changes one would calculate the instance placements always on the fly, just traversing the grah upwards. With the jriegel changes this will be fast and efficient. But than a generall question arises: why an special object for instances?

How I understand it, 95% of what you like to do with instances also works with Instance==GeoFeatureGroup.
Just imagine:
1. A GeoFeatureGroup which allows only a single object in its Group
2. The Viewprovidere would not show the childs in the tree

IMHO this is exactly what you want, except for the array functionality you described. Why not a new object would be beneficial:
1. Graph traversing would be general, you don't need to handle multiple objects, just GeoFeatureGroups. This makes the logic way simpler and more consitant.
2. No hard code changes as you described in the new Extension multiple inheritance approach. There is no need for a localCS that behaves different and is a different type than all other localCS.

For array functionality: For this you need to add a special handling interface to Instances anyway. It is easily possible to extend the GeoFeatureGroupExtension to allow offer this functionality. I don't think a new object is less work.

Honestly I don't see the benefits of a complete new Instance object compared to GeoFeatrureGroup. So I think it could come down to a merge of our two approaches: Stacking localCS like I proposed in GeoFeatureGroups, but with tree behaviour/User interface like you proposed. Assuming this approach, could you think of any functionality which would not be possible with this approach?
User avatar
DeepSOIC
Posts: 7810
Joined: Fri Aug 29, 2014 12:45 am
Location: Saint-Petersburg, Russia

Re: Steps forward to assembly infrastructure

Postby DeepSOIC » Fri Oct 14, 2016 9:30 am

Special things about Instance (as I see it), compared to GeoFeatureGroup.
* always has exactly one object linked
* cannot be activated like any other container can
* may need built-in support for array
* does not withdraw viewprovider of child object from document root
* does not show child object in tree (or optionally shows it).
* overrides placement of child object, not adds another placement on top of it
* to some extent, pretends that children of child object are its own children
* has special meaning, that allows to stick with handling container tree as a tree, not graph, allowing quite a lot of simplifications there
* allows to make more stable links (as I proposed, links are to remember only instance path, so rearranging containers inside Part won't break assembly constraint links)
* needs not be considered when searching for object's container in object's InList (again, assuming tree container structure)

I may have missed something, but as you may see, this list is quite big. So inheriting from GeoFeatureGroup doesn't make much sense IMO.

BLUE = edits
Jee-Bee
Posts: 2131
Joined: Tue Jun 16, 2015 10:32 am
Location: Netherlands

Re: Steps forward to assembly infrastructure

Postby Jee-Bee » Fri Oct 14, 2016 10:13 am

Maybe I'm to late for my comment...
I know in Pro-E have basically the instance method(i think most CAD software have. In the background there is some property that can set automatic recomputes on/off.
For small projects automatic recomputes is fine but for large assemblies (some take 10 - 15 minutes) it is horrible. So i had always the switch off and recomputes manually.

What i can imagine that in the assembly holds a list of versions of every part and when you recompute the parts it checks first if any parts are changed. if so then recompute and if not than does nothing. this speeds up the recompute speed if given the wrong command...
User avatar
DeepSOIC
Posts: 7810
Joined: Fri Aug 29, 2014 12:45 am
Location: Saint-Petersburg, Russia

Re: Steps forward to assembly infrastructure

Postby DeepSOIC » Fri Oct 14, 2016 10:18 am

Jee-Bee wrote:For small projects automatic recomputes is fine but for large assemblies (some take 10 - 15 minutes) it is horrible. So i had always the switch off and recomputes manually.
So true. But user control over recompute system is an independent story, that has nothing to do with this thread IMO. Please start a new one.
ickby
Posts: 2982
Joined: Wed Oct 05, 2011 7:36 am

Re: Steps forward to assembly infrastructure

Postby ickby » Fri Oct 14, 2016 10:32 am

Ok I see your points. Some of them could also be easily integrated into a special kind of GeoFeatureGroup with the same effort than making a new Object, but some are definitely not. And the whole amount of differences makes that new object that different to GeoFeatureGroup that is more convienient to have a new object.

What about the caching I described? It sounded like this was your plan. Or are you going for calculation on the fly?
User avatar
DeepSOIC
Posts: 7810
Joined: Fri Aug 29, 2014 12:45 am
Location: Saint-Petersburg, Russia

Re: Steps forward to assembly infrastructure

Postby DeepSOIC » Fri Oct 14, 2016 10:35 am

The plan was "on the fly". But some caching might be easily achievable, I haven't really thought of it.
ickby
Posts: 2982
Joined: Wed Oct 05, 2011 7:36 am

Re: Steps forward to assembly infrastructure

Postby ickby » Fri Oct 14, 2016 10:36 am

* overrides placement of child object, not adds another placement on top of it
I'm a bit puzzled about that point. Overriding means that you change the Placement property of the child object? But what if there are multiple instances of a single object at multiple different locations? I'm not actually sure what you mean here.
User avatar
DeepSOIC
Posts: 7810
Joined: Fri Aug 29, 2014 12:45 am
Location: Saint-Petersburg, Russia

Re: Steps forward to assembly infrastructure

Postby DeepSOIC » Fri Oct 14, 2016 10:39 am

I mean that:

Code: Select all

Document
    Part
        Box
    Assembly
        instance(Part)
Instance has Part as its child. But placement of Part does not affect instance. That is, I can move Part and Instance completely independently, one will not affect another. This is what Draft Clone kinda does (with bugs :lol: )
ickby
Posts: 2982
Joined: Wed Oct 05, 2011 7:36 am

Re: Steps forward to assembly infrastructure

Postby ickby » Fri Oct 14, 2016 10:40 am

DeepSOIC wrote: Instance has Part as its child. But placement of Part does not affect instance. That is, I can move Part and Instance completely independently, one will not affect another. This is what Draft Clone kinda does (with bugs :lol: )
ah ok, thanks for the explanation.