Clean timeline groups: Suggested workflow guideline to augment/test RULE #1
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report
I'd like to suggest a workflow guideline that builds off @TrippyLighting's RULE 1.
I don't want to minimize the importance of RULE 1 with my suggestion. RULE 1 remains THE fundamental workflow essential for happy Fusioning in parametric projects with anything more than a simplistic complexity. Also, my suggestion won't matter in direct (non-parametic) design projects.
I like to keep my projects highly optimized by refactoring my entities, subassemblies, and assemblies after significant new work or edits. For me, optimization means the project is organized for rapid computability (minimum compute cycles in geometry processing), for human readability of the timeline and browser, for portability of subassemblies, for preventing or fixing error flags, and for IP (Intellectual Property) control. Such optimization ensures minimal errors in understanding a model's structure and dependency organization whenever other team members (or the future YOU) must get involved in a design they are unfamiliar with. I realize this is extra work some may not be interested in. But I will suggest that for projects which are or are destined to become complex, this guideline is going to prove helpful.
Notice that some entities in the timeline sometimes cannot be moved to where you might prefer them. Notice further that some entities in the browser can sometimes be moved up or down or across the hierarchy, and sometimes can't be. Both of these challenges are usually due either to workflow errors in building the model (because RULE 1 wasn't strictly followed,) or to a suboptimal design path because often assemblies and subassemblies simply can't always be initially built in an optimal order. Designers can always control for RULE 1, but they cannot always control for out-of-order design because of the iterative and exploratory nature of the act of creative and functional designing. In either case, periodic refactoring, essentially re-structuring your model after the initial build using your now improved after-the-fact perspective on the model's geometry and dependencies, is to me an essential if not always fun task.
A big clue to having a sweet assembly design without hidden dependencies and with the benefits of having always correctly applied RULE 1 is that you are able to reorder your timeline after the fact into a contiguous series of timeline steps that can be grouped so as to completely bracket a particular complex elements's or assembly's design steps - and that no other entity or assembly's design-steps are "stuck" within this contiguous timeline group. So if you CAN'T reorder your timeline into such "clean" groups, or such a reorder generates single or cascading geometry errors, then you may have a suboptimal design that could (and I suggest SHOULD) be refactored if you plan to do anything significant with the design in future. There may be cases where such grouping perfection is unattainable, but I haven't seen one yet in my admittedly limited experience with Fusion. A good result of having a clean complex timeline is that you can reduce it to a series of discrete groups with no outliers in-between so that you can nicely hide the distracting details of your design, each timeline group is representing just one entire entity or assembly and nothing else. This makes future edits MUCH simpler.
Another side-benefit of my above suggestions is that entities in the browser that were stuck where you didn't want them may now be movable to a more sensible location up, down, or sideways in the browser hierarchy. Software nerds will note how this suggestion results in a system that is analogous to the ideas in support of object-oriented programming.
So my suggested augmentation or test of RULE1 is to always look for a clean, organized timeline where each complex entity or subassembly can be contiguously grouped. If it can't then understand why and fix it soon!
