(2020-05-27, 17:38)Daniel R Wrote: That is correct. Nevertheless, there should be some mechanism for all use cases. Maybe there should be different mechanisms, I don't know. These use cases are:
- Simple hovering of parts used in this step
- Movement of parts attached some time ago
- Connection of flexible parts ends
Yep, all of these would be handled by my imaginary FLOAT command. :-) Let's say that we allow a complete type 1 line to follow the meta, plus an optional step parameter, and is followed by another type 1 line; so:
0 !FLOAT <color> x' y' z' a' b' c' d' e' f' g' h' i' <file> (n)
1 <color> x y z a b c d e f g h i <file>
For simple hovering, you'd just change the x'y'z' triplet in the float line (the position).
For movement of parts attached earlier, change the position (x'y'z') or orientation (a'…i') matrix in front of each such part. To un-rotate them at a certain step, enter a negative number for n, so if the parts are moved into position in step 32, then enter -32 for n.
(A disadvantage is that this only allows for parts to be moved or rotated once. Assigning some kind of ID to each FLOAT command could be a way around that.)
For connecting flexible part ends, you'd provide a different file reference in the FLOAT line. So if you wanted a 12L flex axle, you'd reference 32200.dat in the FLOAT line, and in the following line use your LDCad path reference (say, "technicFlexAxle-1.ldr").
Quote:Unfortunately, sometimes you need to rotate of move several parts which were not a submodel and we not attached in a single step. I am not saying that this should be done using group. In fact, maybe my suggested solution should not support multi-part groups at all. Indeed, this can be done by creating (automatically) one single-part group per part being moved. I only suggested LDCad groups as a way to reference previously added parts.
Yeah, as you see above, this would be handled by putting the same -n in front of each part wherever it's added. A good editing program could recognize all parts with the same -n and allow you to change them all at once.
Quote:I don't quite understand you here, sorry. Perhaps you could elaborate a little bit?
With buffer exchange, you add each hovering part to the model twice: once in its hovering position, and again in its final one. As you've noted, this throws off the count for that part in the PLI/BOM, requiring further commands to offset it. With FLOAT, you add the part only once, and just modify its position (etc.) temporarily.
Quote:Yes. My suggestion is that you first add you part in the hovering position (and it is counted for that step's part list), then you add a step or a number of steps (maybe even finish this submodel and go to the outer one), then you decide that part should be moved, then you switch to "move mode" of LDCad and move the part as if you were just adjusting its original position. LDCad then would add a group definition to the step the part originally appeared and a MOVE GROUP meta to the current step. When you would go to some following steps, LDCad would keep track of all MOVE GROUP metas and display the part in its correct (updated) location, very similar to the way it currently handles buffer exchange.
Got it. That's similar to how FLOAT could work, if you put in some kind of ID. Maybe not as complex as "move mode", but perhaps also not as powerful.
Quote:Maybe you could explain how that interface could look?
Well, if we take the existing part properties dialog in LDCad, imagine a new "float" panel (or tab) in that dialog. You'd have a checkbox to enable "float", which inserts the meta command. That could invoke a new matrix, color reference, and part reference field in the dialog, where'd you enter the floating values. Also, imagine two additional checkboxes, either "Float for next _ steps" or "Float until step number _", which adds the n parameter.
At the same time, you'd probably want some way to visually edit the float position/orientation, perhaps by invoke "float" mode with a hotkey or menu command, or from the editing compass, or perhaps up with normal and nested modes. Maybe the part would show in a sort of transparent, "ghost-like" way as you move it around in float mode.
Now of course, let me be clear that I'm going about this completely backwards by thinking about the end result rather than how it's actually achieved, so I really don't know how easy this would actually be to pull off.
But the main thing here is to look at the problem of buffer exchange and how it could be made more understandable by the user. Theoretically, you could just keep using the exact buffer exchange method "under the hood" and just change how the user interacts with it, but I feel like FLOAT has the advantage of requiring far fewer changes in the code.