Having this information in selection only is not enough. One needs an API to query a objects positions in the document on App level, even if it forms a graph in reality. Initially I thought you try to prevent that with a tree structure, but I think I misunderstood you there, as you only hide the graph from the user. So such an API is easily possible, one would add a few functions to DocumentObject like "getAllInstances()" or "getAllPathsToObject()" which allow to handle the graph, with instances or without doesn't matter much.I already said how it is to be done: Selection object should include the list of instances, through which the object was selected. Nothing impossible.ickby wrote:2. ... Getting the global position of a shape? Not possible.
I thought about this today too, this is a clear advantage of your approach. No need for reference counting.DeepSOIC: there is a master Part, that is editable, and instances of the Part, that aren't editable. Deleting master part will delete actual geometry, and break all its instances.
ickby: there is no master part. Any "instance" of part is just another part re-using some objects. Any "instance" can be deleted with no consequences; only when the very last instance that uses the objects is deleted, the actual objects (geometry) will get lost
Code: Select all
CS2 CS3 | | Instance2 Instance3 \ / \ / CS1 | Instance1 | CS0
Hi Normand,NormandC wrote:Without pretending to understand the whole issue, I think this is where implementing specific file extensions would have a huge advantage: for example *.FCPart for a document containing a single part, *.FCAsm for an assembly file linked to other files. All the major commercial parametric CAD programs do that. They even have a separate file extension for drawings (*.FCDwg ).
I confirm and I like that.Editing the part would open the FCPart document separately. It could be done from any instance shown in the tree, not only from the "original" one.
Now that I think about it, it is exactly what the Assembly2 module does.
I think neither approach has advantage, as with so many objects, rendering/selection will be the bottleneck. Or.. maybe ickby's approach is at win here, because one could select an object in tree. With instances, assuming they don't allow to expand their content in tree view, only picking in 3d view will be possible.triplus wrote:And what about performance. Having for example 1000 instances of the part (@DeepSOIC) vs. 1000 times reusing objects form the part (@ickby)?
If we really would want to achieve that it could happen with your approach couldn't it? Anyway if there isn't any fundamental difference good. But if one approach would have a clear advantage (performance) that would need to be acknowledged.DeepSOIC wrote:With instances, assuming they don't allow to expand their content in tree view...
In ickby approach - yes, it is trivial. Just activate the "instance" (which is a Part container most likely), and add extra features to it. With my approach (instance objects) - no you can't. You must either edit the original Part, which will automatically propagate to all instances of the Part, or create another Part with the new features, and replace the instance.triplus wrote:And what about using the assembly geometry after directly. To add additional feature to it (only to one "instance" and not all of them). Would any of the proposed approaches provide that?
Actually, your assumption is almost right. You should replace "graph top" with "top of the document", or "global CS", and "one path" with "container path".ickby wrote:1. My assumption " from every Instance there is only one path to the graph top" is wrong. As one can stack assemblies and parts wildly the following is easily achived. A simplified example, where Instance1 is at 2 places, but many more complex things are possible (e.g. nut is 10 times in motor which is 5 times in machine):
Code: Select all
Document Part Box Part001 Cylinder SubPart Wedge SubAssembly instance(Part) instance001(Part) instance002(Part001) Part002 sphere Torus FinalAssembly instance003(SubAssembly) instance004(Part002) Constraint