Make Move Feature Absolute and/or Relative

[maruska]

Currently, if I move a body, a move feature is created in the timeline. If I moved the body 8 mm in the X axis then edit the feature later, the X axis field shows zero. This is a relative movement behavior - each time I edit the feature it assumes I'm starting from zero.

I would like there to be history in my move features, so I can recall or even link that movement to another parameter or variable.

[Timmah450]

I agree with this suggestion. I think it is one of the big reasons direct modeling has not been as widely accepted. Often times when designing a parametric model I will have a rough model that I later come back and put specific features and bolt patterns etc in. Direct modeling is great for changing one feature quickly. If there was a way to incorporate the measure or dimension tool or to help fill in the desired move amount. It would be even cooler if the referenced driven dimensions would show up when you edit the direct modeling feature. 

[jakefowler]

@maruska, @Timmah450, All -

We're looking into this improvement now, as part of wider improvements to the Move and Align commands. There are a few alternative approaches we can take for recording Move history; if anyone has answers/thoughts on the questions below, that'd be extremely helpful feedback:

1. Say we recorded object movements as a series of sequential 'steps' (we're thinking these could be presented as a table). Would you consider each drag/value change as 1 discrete editable step? Or would you prefer sequential moves to be grouped together? (e.g. if you moved in Y by 10mm, then X by 20mm, should this be represented as two seperately editable steps, or a single "X: 20mm, Y: 10mm" step)

2. If you perform a point-to-point move, would you expect the timeline feature to just store + allow editing of the XYZ transform values? Or actually remember the two selected points in an adaptive manner? (i.e. so that if one of the bodies were modified 'before' the Move in the timeline, the Move would adapt to that change)

3. Something we've also discussed as part of this is merging Move and Align into a single command. If we were to do this, question 2 applies to Align as well; should the timeline feature remember the transform values, or remember the picked geometry? (also very welcome are thoughts on whether combining the Move + Align commands would be sensible/useful)

Thanks in advance!

Jake

[maruska]

Hey Jake,

For me, I would want the Move history just to record the delta of the move when I click "ok" or whatever. I don't need it to record all the increments it took to get there. If I want multiple stages of the move, I would just make another Move history object in the timeline separately. Much like I do with Snapshots (Capture Positions). Actually, just making the Move tool work like Capture Positions would help a ton.

As for the point-to-point - yes, I would expect it to maintain associativity with the point selected. Point-to-point might even be a separate tool.

I think merging Move and Align could be a good thing, as long as arbitrary moves are still supported. I suppose I could make a feature prior to the move to help define the align, but it seems an extra step.

Cheers,

J.

[jakefowler]

Hi @maruska,

Great feedback, many thanks!

One of the reasons for us considering 'steps' within a single command is that we can't really capture both translations and rotations as a single 'flat' delta - rotating then moving gives a different result to moving then rotating, so if we want to show these movements as editable values, they need to be recorded in sequence. 

We could go with an approach that didn't have multiple steps within a command, but every rotation would need to be a standalone feature in the timeline; does that seem reasonable from your perspective?

Regarding combining Move and Align: of course, we wouldn't do that without keeping the existing functionality from both. The idea wouldn't be to remove any existing workflows; it would just be to have a consistent access point and UI for both commands.

Much appreciated,

Jake

[maruska]

Hey Jake,

Sorry - lost track of this one...

I personally think that if you were to make the transform tools have history, then they'd need to broken-up into separate tools. So I'd have a move function in the time line and then a rotate function. You already do this with scale.

I'd also like to have the option to "zero" the orientation within the rotate function - so I can avoid gimbal lock in certain cases. This is less critical in the non-parametric tool at the moment since the transform widget resets (or can be repositioned) each time you use the tool, but I could see having the option to either maintain a body's quaternion identity or reassign it when you click OK - so if I were to add another rotate function in the time line I'm either starting from its previous rotation widget's orientation, or a new one reset to align with the parent's XYZ. 

I could also see how just letting the user reorient the rotate widget at the time of rotation could solve it - but then that becomes a parametric value to be stored as well.

I guess I'd need to play with it to see what works best...

J.

[promm]

Thank you for your idea, parametric move is in our backlog and when work gets started the status will be changed to accepted.

Thank you,

Mike Prom

[Timmah450]

In the meantime. The youtube content creators should highlight the differnt ways to use the move point-to-point tool. It can be very powerfull if you use it to snap feature to premade sketches. Its great for adding your own features when re-working or modifing a model.