> Thats exactly what I looking for.

Great! It actually did turn out to be easy to do with just kind of re-arranging the sequence to be more similar to how the Move command currently worked.


> I wish you will put this feature in V2.

Yes it will be - that video that I showed was actually v2 in action there. So this will be in the first beta. It should be out pretty soon!

Please let me know if you run into any problems when you get a chance to use it.


One note - one thing that does not work is if your base point that you first pick is exactly on the target line that you specify next (like if the circle center was already directly on the line). It doesn't know which direction from the line it should move towards in that case.

Right now it will just switch to standard point-to-point move in this case, but you can use the regular distance constraint to move by a specific amount in this case already.

- Michael

Hi Michael....


>I was thinking a bit about making the command go in a loop
>to allow you to keep picking new distances and new edges
>without repeating the whole command.
>But then that would make you do an extra action
>to finish the command in just the simple case where you just want to apply one distance...

Good idea michael, more & more faster...

>One note - one thing that does not work is if your base point
>that you first pick is exactly on the target line that you specify
>next (like if the circle center was already directly on the line).
>It doesn't know which direction from the line it should move towards in that case.

Yup, i think this behavior is same in SW. When a the center of circle already connected with a line ( concident ), then we cant move the circle in a specific direction. Because the circle already constraint with the line.

No problem ( at least for me ).

Now, I am looking for your another work / idea on "object management / properties".
Maybe next week ???

Thanks Michael,

-Anis

Hi Michael,

> That seemed to be the same as the SolidWorks workflow that was shown where one constraint dimension is added at a time.

Yes, you're right, what you've done is good, if you could make the command go in a loop, that would be even better.

I was also wondering from going through this post is it possible to have a script or command to combine circle > position > extrude > boolean diff as a sort of one step hole function ?

.

Hi Danny,

> I was also wondering from going through this post is
> it possible to have a script or command to combine
> circle > position > extrude > boolean diff as a sort of one step hole function ?

It's certainly possible, but it presents a pretty big UI challenge - so far I have tried to shy away from having too many operations that kind of duplicate other things that already have the basic "ingredients" available for them.

That's part of a kind of general effort to avoid UI bloat.

That would probably go in a category with some other operations like Rib, Boss, etc... It's better from a UI perspective to treat these all as a kind of batch set all together, which also kind of ups the bar for the amount of time needed to make them happen.

What I'd like to do before that is to kind of build up the ingredients another step more directly, like make it an option within the current Extrude command to do a boolean built in.

- Michael

Hi Michael,

> What I'd like to do before that is to kind of build up the ingredients another step more directly, like make it an option within the current Extrude command to do a boolean built in.

Thats an excellent start.

Can MoI incorporate user recordable macros (record common user functions) or is that the same thing as scripts ?

.

> Can MoI incorporate user recordable macros (record common
> user functions) or is that the same thing as scripts ?

That is basically what scripts are for - to automate some kind of process that is slightly different than what the standard command will do.

It would be great to make a macro recorder type thing, but that is really quite a substantial amount of work involved to make a good version of something like that.

- Michael

< It would be great to make a macro recorder type thing
but terrific for the plugins makers :)
For the V3? :)

Hi Michael,

>>you aren't just limited to applying this distance to an edge
>>in the x or y axis directions, you can do it to any edge currently.

Is that distance measured in the x or y cplane axis direction or perpendicular to the edge?

Petr

Hi Petr,

> Is that distance measured in the x or y cplane axis
> direction or perpendicular to the edge?

This new option is measured perpendicular to the edge.

Actually one thing I didn't think about for this is what if the base point and target line are on different elevations.

Right now it will move it in kind of an angled way, making the 3D distance the specified distance, but maybe it should try to use a projected distance instead... But then should it place the final point on the line's elevation or on the base point's elevation? I guess SolidWorks probably places these constraints only on things that it knows are all on one sketch plane.

- Michael

Hi Michael,

add:3D distance versus projected one

Could it these alternatives be driven by "Project to plane in ortho view" option?


>> it should try to use a projected distance instead...
>>But then should it place the final point on the line's elevation or
>>on the base point's elevation?

I rarely want to change all three base point's coordinates of object at the same time while running a move command so I think it should place final point on the base point's elevation there.

I guess the final point inherits the elevation of base point in case of 3D distance measurement in current implementation(?)

Petr

Hi Petr,

> Could it these alternatives be driven by "Project to plane in
> ortho view" option?

Maybe... But to be similar to a constraint-based modeler it kind of seems like this particular function should always be relative to a plane.


> I rarely want to change all three base point's coordinates of
> object at the same time while running a move command so I
> think it should place final point on the base point's elevation there.

Yeah, I think that makes the most sense and is the most consistent with other functions, like if you draw a line in an ortho view (with that default project option on) the elevation is set by the first point you pick.

There is one additional factor yet, which is that the line may be angled diagonally upward instead of being parallel to the construction plane.

So to handle this different elevation type problem, I'll get a construction plane with the base point's elevation, then project the line on to that plane and then find the distance to that projected line.


> I guess the final point inherits the elevation of base point in
> case of 3D distance measurement in current implementation(?)

It was along a vector between the base point and the point projected on to the line. So it could have been kind of traveling diagonally in 3D and not on either elevation... But now I have it set up so it will use the base point's elevation.

- Michael