It sounds like you know what I mean. I was more concerned about an accurate representation than performance.
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:
- A GeoFeatureGroup which allows only a single object in its Group
- 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:
- Graph traversing would be general, you don’t need to handle multiple objects, just GeoFeatureGroups. This makes the logic way simpler and more consitant.
- 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?
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
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…
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.
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?
The plan was “on the fly”. But some caching might be easily achievable, I haven’t really thought of it.
- 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.
I mean that:
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 
)
ah ok, thanks for the explanation.
*overrides placement of child object, not adds another placement on top of it
I read this as independent placement. 
That is independent placement for Draft Clone alike assembly solid feature. Or alternative description i guess could be “Part Tip” linked simple copy alike assembly solid feature.
And here i feel we will need to get clever as:
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)
This assumes topology isn’t an issue. It is and assembly constraints will break and will break often. Therefore FreeCAD assembly infrastructure should accommodate to that. I feel that if doable something like this could work:
Each feature that can represent “Part Tip” gets UUID assigned. This would be useful in a lot of places not just for Assembly purposes. For example simple tool like adding a note to existing feature can’t be made reliably ATM. As original feature label/name can easily change and the note gets assigned to another feature after. If there would be UUID that problem wouldn’t exist or it would be greatly reduced.
Now Part Tip is a feature itself and lets imagine it has its UUID. Storing this UUID therefore is the only thing needed for assembly feature to preserve link to the correct feature. The Part Tip feature itself provides topology to assembly feature. Adding for example plane/face constraint to such feature results in creation/storage/using of signature pair like (one pair):
- UUID: value
- Face: 7
This is all that should be needed. Now as for robustness. Solver should be made in a way if Part Tip gets deleted (unknown UUID) or if Face 7 isn’t the correct face anymore due to changed topology of the Part Tip. Or if Face: 7 simply doesn’t exist anymore due to the changes done to Part (Tip). That should represent localised issue. It shouldn’t brake everything after that point in assembly tree. Constraints for assembly features considered to be added after should only care about corresponding UUID and topology of other assembly features (from another Part Tip). And as there was nothing changed there this doesn’t affect the constraints made between them. Therefore only one single constraint needs to be redone to satisfy solver if some unresolvable condition was produced. Or if users simply decided to redefine one constraint. And the rest should just work after.
Likely one feature would need to be considered “base assembly feature” and after each constraint is resolved in some order independently. If something like this would be done maybe similar approach could be explored for PartDesign in the future. To better manage topology issues between features in the PartDesign workflow.
Triplus! What you are suggesting is to replace object name with some UUID, when object name already is a “UUID” (well, it’s unchangeable and unique within one document).
Not replacing just adding additional identifier that could be reliably used and would likely substantially reduce the effort needed to preserve links between features. For example if i would do a Python based Note module i wouldn’t be comfortable in using:
UUID: Cube
As reliable identifier of the feature in the tree. And probably it really shouldn’t be made more complex than that (hence UUID). Therefore yes this is what i am proposing to be considered as a part of the future FreeCAD assembly infrastructure.
And basically this is how i understand the issues involved and possible solutions without much further ado:
http://forum.freecadweb.org/viewtopic.php?f=10&t=17864&start=50#p141240
If i would be coding it i would likely take this approach as the first approach to be explored. As i won’t be coding it and i feel that i shared my understanding gathered over the years (thanks for listening) it is now appropriate (from my point of view) for developers actually doing it to take over the discussion and decide on the appropriate direction to take. Good luck and looking forward to seeing progress being done.