sketch features not sketches on the timeline / dependency graph

[roambotics_scott]

The timeline and associated parametrics are a great concept but there are a lot of weird side-effects associated with them.

Most notably for me, my natural workflow often includes things like

start with a sketch -> extrude / otherwise derive geometry from sketch -> return to sketch to further build and then derive more geometry

This is fine in direct modeling but becomes insane with the timeline. Whenever you return to a sketch, everything jumps backwards in time [automatically / without user interaction or intention], which means the derived geometry can't be used to further define the geometry, or the user has to manually go through extra steps to create another co-planar sketch on top of the one that already exists [more time and effort and pollutes the browser with many co-planar sketches]

Much better would be to allow the user to start a sketch, work, and go back to the same sketch to do more work without rolling back in time.

Individual lines, circles, edits, etc should exist in the present [wherever that happens to be] while the sketch, itself, is more of a timeless entity.

Whenever someone actually wants to edit the past, they still could roll back in time, but for anyone who just wants to keep building, they could without having to worry about knock-on effects from editing the past, or a huge proliferation of co-planar sketches in the browser. 

[cekuhnen]

interesting idea but I am not sure if this makes sense as well.

the advantage of how things are is because you establish clear relationships.

when ever I go back to a sketch in time all objects using that sketch will be updated.

but I see the problem you mean. that is why I think that it is not a good idea to only work in one mode.

In my class I teach 3 applications and with each a specific process

Fusion is the last step because while the parametric aspect makes design adjustments later very fast

it is not ideal for the ideation or concept face - or in other words other modeling approaches are faster in that phase.

Alias or SolidThinking have parametric abilities without being linked to a timeline, rather a curve influences a modeling tool or such.

Adjusting that curve instantly adjusts the surface that makes use of the curve.

This is blazing fast and nicely interactive - the down side is you cannot so easily go forward and backwards in time

and only see what you generated.

That I love in the timeline because you can see where maybe building mistakes were done and restructure your approach.

Not possible in Alias - you would have to restart.

[roambotics_scott]

I love the timeline too.. but much more in concept than in practice.

Not really sure what the downside to this would be tbh. If you want to go back and move something around in a sketch then you'd still be totally free to, but, as it is, it either ends up breaking things, or with something like this [where there are really only about 5 sketch planes] for any slightly non-trivial design.

[cekuhnen]

Yeah that's why I state that this type of designing is not ideal as a start but only when you know what you need to build.

DM is cool to try something out then rebuild it for the engineer later.

Sent from my iPhone

[kb9ydn]

What you're seeing here is a natural consequence of history based modelling.  In order to edit something that was created in the past, you MUST return to that point in the past.  There is no way around it.  Making efficient use of history based modelling requires you to do some amount of planning ahead so that you don't end up modelling yourself into a corner that you can't get out of.  This means that it isn't particularly well suited for rapid concept generation, especially with more complex shapes.

For me personally, history based modelling works quite well, at least at the individual part level.  Where Fusion really falls apart for me, is in putting together assemblies; because if you want your parts to be history based, the assembly has to be history based as well (unless you use externally linked components, but that has other issues).  This is a serious annoyance because 99.99% of the time I don't care what order an assembly is modelled in.  The timewise order is completely irrelevant and it is FAR more important that I be able to edit a particular component in context of the entire assembly, without components disappearing or changing position.

I have tried direct modelling, but for me it's very uncomfortable having everything be completely non-associative.  It would take a long time for me to get used to it.

C|

[roambotics_scott]

No @kb9ydn that's totally wrong.

If I make a circle on a sketch, derive geometry from it, and then go to the sketch and add a line, there is no reason that line has to be in the past. 

If it's not obvious how wrong that is currently, think of what it'd be like if the same happened when you replace 2D geometry with 3D geometry: add a cube, do some things, then add a cylinder.. and for some reason have the timeline jump back to the instant the cube was created. It's wildly inconsistent.

The problem [and the reason for this idea] is that currently the sketch, itself, exists at one moment in the timeline, not the 2D geometry within it.

[kb9ydn]

Ok, I see what you're saying with sketches existing outside of the timeline.  That's an interesting idea but I'm pretty sure it wouldn't work, because it would allow for circular relationships that are unsolvable.

As an example, lets say you create a sketch, call it sketch1, with a circle of diameter D.  Now extrude that circle and you have a cylinder of diameter D.  Now create a second sketch, call it sketch2, on the other end of that cylinder and create an offset circle linked to the outer diameter of the cylinder profile, so that this new circle has a diameter of 1 less than the outer profile of the cylinder.  So its diameter would be D-1.  Close that sketch.  Now go back to sketch1 and set its diameter equal to the diameter of the offset circle from sketch2.  This is now unsolvable because we are trying to set D = D-1.

So this is why in the history mode environment sketches don't exist before they were created, to prevent you from creating circular relationships.  Now I suppose you could add some other sorts of controls to prevent this from happening, but I'm not sure if that would be any better.

All this being said, I do like that you're trying to push the boundaries of history based modelling and how the timeline works (and this is why I voted for this idea even though I don't think it would work).  Because I do find the way the timeline works in Fusion rather annoying, as compared to the way it works in Solidworks.  It works fine for single bodies/components, but when you start assembling multiple bodies/components it gets in the way.

C|

[roambotics_scott]

That circular dependency only arises because you're going into the past and creating a paradox.

If everything is in the present by default then it'd be no different than adding a new sketch in a parallel plane. Geometry derived from a sketch should be derived from the state of the sketch at the point in time where it was derived.

To put a finer point on it - if I make a circle, extrude, and delete that circle in the present, that shouldn't break the extruded geometry because the circle still exists with diameter D at the point in the timeline where it was extruded. It's only sloppiness in the dependency system that makes manipulating the past seem necessary

[cekuhnen]

@roambotics_scottlooks like you want is alias fusion and hudinin have a baby

you want generative design with time based abilities to delete add parts 

but it I do not know any app that can do that being free and yet interactive 

[kb9ydn]

---

roambotics_scott wrote:   

That circular dependency only arises because you're going into the past and creating a paradox.

If everything is in the present by default then it'd be no different than adding a new sketch in a parallel plane. Geometry derived from a sketch should be derived from the state of the sketch at the point in time where it was derived.

To put a finer point on it - if I make a circle, extrude, and delete that circle in the present, that shouldn't break the extruded geometry because the circle still exists with diameter D at the point in the timeline where it was extruded. It's only sloppiness in the dependency system that makes manipulating the past seem necessary 

---

Ooooh, I see what you're getting at now.  You want sketches to be able to exist at multiple points in time in different states.  I think that would be conceptually the same as making a (now) copy of an existing (past) sketch and then editing the (now) copy.  You can sort of do this now by copying existing sketch geometry to a new sketch, but the process seems rather cumbersome.  You ought to be able to just select a sketch from the the browser and ctrl-c to copy, then select a face or plane and ctrl-v to paste.  Edit the copy and you're off. 

The other issue you bring up about cluttering up the browser (and timeline) with sketches I think could be handled with some more intelligent grouping behavior.  In the timeline at least you can do this now, but again it's a somewhat tedious manual process.

C|

[roambotics_scott]

Sure you can kind of do it now but you end up with «a huge proliferation of co-planar sketches in the browser.» 🙂

It's not that I want to copy the other stuff in the previous sketch but I just want to build from it without timetravel and creating paradoxes, or generating dozens of new sketches that are on top of each other.

Not really sure why this would be controversial tbh. All I want is for the sketches to behave as an organization group that contains features that exist in the timeline like bodies and components, rather than an entity that exists at a specific point in the timeline.

It might not be trivial to implement but in terms of UX, it's the most obvious and natural thing to do, it'd be consistent with the rest of the app's behavior, and it'd reduce pages of sketches like this to something much more managable (in this case, comfortably under 10)

[kb9ydn]

It sounds like using multiple coplanar sketches would work for what you're trying to do if there was a way to group all the coplanar sketches together somehow, like layers almost, where each layer exists at its own point in time.  In the browser you would see just the first sketch, and all the associated layers would be underneath it in tree format (collapsible of course to reduce clutter).

C|