Steps forward to assembly infrastructure

[tanderson69]

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]

@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?

[DeepSOIC]

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]

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...

[DeepSOIC]

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]

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?

[DeepSOIC]

The plan was "on the fly". But some caching might be easily achievable, I haven't really thought of it.

[ickby]

* 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.

[DeepSOIC]

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 )

[ickby]

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.