It looks like you're new here. If you want to get involved, click one of these buttons!
You will find the transparent command FROM useful when doing the mentioned process.
Drag cursor in Zed direction
This obviates re-selecting the objects to make the Zed offset.
It can be chained with other transparent commands to compose quite powerful combinations.
I just realized that the Ron Myers course is the tutorial I already finished.
As Roseanne Roseannadanna would say - 'never mind'.
ME on CADTutor, I deny all knowledge, I deny it mumble mumble twim brother mumble mumble, yeak OK you might find me on a few others as well.
I have used 'from' as you indicated. When I tried using it with a DMMOVE, it was ignored. It went through all the motions, but the end result was an offset from the Base Point. I tried it several times and couldn't make it work.
I demonstrated the process for COPY (also works with MOVE).
Perhaps the Dynamic Modeling commands DmMove etc don't fully accept transparent commands. You'd need to ask the BricsPeople.
I thought MOVE and DMMOVE were the same thing. So, I looked them up. I'll have to play with them to see the difference.
Live and learn.
I'd be interested in hearing your description of the distinctions.
Dmmove is part of the direct modeling group of commands, and no doubt the internal programming of those commands work in a different way, although you might envision using it in a certain way I can well imagine that it would be difficult to implement in other situations, have you tried using dmmove on a single face or even a single edge of say a cube, the same procedure fails with the standard move command, but is really clever within dmmove.
We have to accept that Bricscad is in a confused transitional phase (which may last forever) - maintaining Acad-lookalike traditional commands, such as MOVE, alongside vastly improved own-brand similar commands such as DMMOVE (terrible nomenclature, in which DM means Direct Modelling) particularly suitable for 3D work.
Hi Tom why confused? they do different things!
They do largely overlapping things, but in sometimes same, sometimes v different style (as seen by the end user) - despite I guess very different process 'under the hood'.
We could decide to 'go modern' and use only the DM* commands, remove the legacy-mode toolbars. Mainly the 'modern' ones do lots more things, but there a few things that only the old one will do - e.g. there one thing (can't remember offhand) that EXTRUDE will do but DMEXTRUDE won't. As both have the same icon it can be unclear which one you're picking.
That the 'modern' ones are lumbered with cumbersome prefixes (for evermore?) is bad enough, sabotaging memorable abreviation and keyboard proxies, but that the prefixes are so alike - BIM, BM, DM - is quite incredible.
To a newcomer, these arcane peculiarities must seem bizare black art - far from the streamlined simplicity of new-style competitors like OnShape. Bricsys is really good at re-thinking things (why we love it) but boy did they miss the bus on this one - not finding an ingenious way to modernise the 'familiarity' of the Acad UI, but just piling stuff on top to making it far worse.
It looks like a quick'n'dirty way to get the 'modern' commands available as soon as they arrived, pending future rationalisation, which never happened, and now it's too late. I can live with it, for lots of other wonderful benefits - but the User Experience is ... unimpressive.
You asked for it but you're not going to believe the strange results I got.
I read the doc on MOVE very carefully. It moves an 'entity' when entity is never defined anywhere in the HELP doc.
I experimented with a box (1,unknown,1) with UCS/W in TopFrontLeft view in 3D Modeling. I wanted to shorten the box to a known y=1.
I discovered that 'entity' for MOVE means the whole solid. I also learned there's a difference in appearance between picking and then executing MOVE and executing MOVE and then picking.
If I pick a face and then execute MOVE (Entities in set : 1) , only that face lights up during the operation giving the impression that face will move. If I pick more than 1 face and execute MOVE, those faces stay lit but entity count remains 1. If I execute MOVE and then pick a face the whole solid lights up giving the correct impression that the whole solid will move. Lesson learned - execute command before picking.
The subtle clue is the entity count for MOVE.
The doc on DMMOVE clearly states it will move 'solids, faces or edges of a solid, or inserts using a vector.' I have no idea what the vector part means.
Again, picking a face and then executing DMMOVE is different than executing DMMOVE and then picking a face.
Pick Front face, it lights up.
DMMOVE - it immediately asks for a base point as though it's going to do something. If you move the mouse off the face into white space, the face highlight is gone. If the mouse stays on the face, the face stays lit. Move off the face into white space and back on the face and the highlight returns.
Pick a vertex on the face without temporarily lighting up any other face. Highlight disappears but it keeps going with 'Enter Second Point' .
Option A: It's not possible to pick a second point with the mouse as no vertex will highlight with the red box. Mouse click anywhere and the command terminates doing nothing.
Option B: Enter some x,y,z at the keyboard and it will move the face the z distance (plus or minus direction).
Option C: Enter 'From'. It asks for a 'Base Point' as though it was going to cooperate, but there's no way to pick with the mouse as the red box won't appear. Pick anywhere and it continues to appear to cooperate by asking 'Offset or regular point'. Enter any value and the command just quits.
Conclusion - DMMOVE is Schizo-phrenic.
Now it gets really weird.
Pick Front face, it lights up.
DMMOVE - it immediately asks for a base point.
Move the mouse over the Top face to temporarily highlight it, then pick a vertex on the Front/Top face.
Now the display provides a visual of what will happen and you CAN pick a secondary point which you couldn't before.
Using From (pick Rear/Top vertex) goes through the motions, but the from is ignored. Any distance you key in is off the Front face.
It took me a long time to figure out what causes two different outcomes when you pick before entering DMMOVE.
Executing DMMOVE and then picking a face acts as expected except From is again ignore except to use any offset off the picked face.
Seems like you've discovered PICKFIRST
I knew about everything in your link. I don't see any mention of where you get different results or no results depending on pick first or command first, all else being equal.
Haha that's the legacy of 3d solids, in Autocad the command move will only move the entire solid. In Bricscad, the command move will also only move the entire solid, and both can use the "From" modifier. Now the Schizophrenic command Dmmove, within certain conditions it will stretch a face, in a direction perpendicular to that face, it will stretch an edge deforming the cube but keeping connected faces intact creating some amazing shapes, and to my mind is a tool of beauty and that is Direct Modeling. In Autocad you can only get that type of object by adding and subtracting multiple simple shapes, in Bricscad you have a much more powerful tool. I can see the problem with it looking as though it is about to accept the "From" modifier and then just ignoring it, rather than saying it is not a valid option, but have you tried stretching a solid cube in Autocad? I haven't fully figured out what it will allow and dissallow and yes the help is a bit lacking in that, but it looks like it allows a lot of movement for edges but keeps faces planar, and will only allow faces to move perpendicular to themselves.