ppemawm wrote: ↑Tue Oct 20, 2020 3:31 pm
I have now broken up that assembly file into several sub-assemblies as you have suggested and certainly agree that the assembly model tree is better organized and easier to work with. I can animate the sub-assemblies in the separate files, but this does not seem possible at the top assembly file. Or, at least I do not know how.
That is indeed a tough nut to crack, and I have tried to wrestle with it with different ideas for a few times already. As pointed out by many forum members, the root of the problem is the need for circular dependencies between the (sub)assemblies, which violate the (mathematically correct) requirement for DAGs. To overcome the problem, I believe there are several not fully satisfactory methods, one of which is using a global mastersketch in the main assembly file, which e.g. Zolko suggested, and which works reasonably well, but unfortunately then you'd lose the idea of modularity (i.e., all the animated movements within the subassemblies must be re-created at the main assembly level). So, that works, but it's hardly optimal, as the true power of modularity of the subassemblies is lost, as their animation is not truly modular (although the geometry and assemblies continue to be).
The other method is to make everything (main assembly and subassemblies) depend on a third-party structure (e.g. spreadsheet or variable table
in a separate file). The file containing the third-party structure does not contain anything else but the animation variables, so that it does not need to depend on any other file, particulary there does not need to be a dependency to the (sub)assemblies. Of course, all the (sub)assemblies depend on this variable file, which is totally fine, as there won't be circular dependencies in the DAG. However, the problem with this method (at least for me) has been that I haven't been able to animate such a structure with Asm4 workbench; I've tried e.g. deleting the "Variables" container from the main assembly and replacing it with a link to the "Variables" in the special file, but this doesn't seem to work. Of course, animating such a system with Python macro works, but it'd be nice to get such (or similar) funtionality to work with the official Asm4 workbench.
Note that even the 2nd method is not truly optimal, as all the variables in the special "variable" file would not be modular in the sense that subassemblies would depend on them, and the subassemblies could therefore not be fully independent from the main system; although it would be rather easy to re-use the subassemblies in another model by just re-pointing the variable links to somewhere else. Notwithstanding that, I think the best way to keep a fully modular system would be to introduce "link variables" into the main assembly; i.e. variables in the main assembly that could be just links to variables in subassemblies. When the main assembly animator would access such a link, it would actually access and modify the sub-assembly variable through the link. Note that this would not create a circular dependency, as the link would make the main assembly to depend on the sub-assembly, but not vice versa. Also, during run-time modification of the variable, it would be the variable of the sub-assembly that would be changed by the animator workbench, so no circular dependency there either. This would keep the animation and the part re-usability as fully modular. However, I have no idea how easy or hard it would be to add such a "link variable" to the Asm4 variable system, but that would be the Holy Grail of Asm4 animation, IMHO.
Is there any way this capability could be accommodated in the top assembly file in Assembly4?
That is an interesting question, and I'm kind of hoping that Zolko is considering to enhance his workbench into that direction, somehow.