LDCad (More) Musings on ROTSTEP and BUFEXCHG

(More) Musings on ROTSTEP and BUFEXCHG
I only use LDraw to build official models, not MOCs. But although I don't need to create instructions, I like the build process in my model to match the official ones as closely as possible. (That's for the same reason I like the model itself to closely match the real model; it's all just part of the fun.)

Back in my Bricksmith days, I often used rotation steps to match the view in the official instructions, but I'd never experimented with buffer exchange. Since LDCad supports both, I decided to add them to my latest model and see how it affects the workflow. Here are some of my observations—and please regard them as just that: some ideas or suggestions perhaps, but no criticism intended. :-)

LDCad's implementation is a lot more intuitive than Bricksmith's. It's easy to set up the rotation you want—I don't get too precise, so I just use relative steps, but I could always match the instruction views exactly with absolute steps. (Haven't figured out a need for additive steps yet.)

There are a few drawbacks:
  • ROTSTEP necessitates using trackball camera control, which I really still can't get used to.
  • With relative steps, it depends on what the default view is. For perspective views, the default can be either left-sided or right-sided. It could be handy if LDCad allowed setting a default view per file, and maybe also allow fine-tuning the rotation for default views.
  • Because step commands go at the end of each step, if the final step in your model is a ROTSTEP then it adds an extra (empty) step to the model. This is only a problem for those of us who like things all nice and orderly. ;-)
Traditionally this is used to put parts in a temporary position for a step or two, but I used it almost entirely for another reason. Recent official instructions tend to include large sub-builds within the main step sequence, so you need the model to "disappear" for a while until you finish the sub-build, then "re-appear" so you can insert it.

Buffer exchange works very well for this. To make the model disappear, just RETRIEVE any unused buffer (I use buffer Z). You don't have to store an empty state ahead of time, though it might be a good idea if you plan to open the model in other programs.

I did all 249 steps of the model this way, and used up every last buffer from A to Z with none to spare, before realizing that you actually can have 26 simultaneous buffers! So you can just use buffer A over and over again, only advancing to the next letter if you need overlapping buffers. (For example, if a buffer occurs in a subfile, I start with buffer S and count from there, leaving A-B-C etc. for the main file.) I ended up with a maximum of 3 buffers active at any one time, to accommodate nested sub-builds in the instructions.

Like ROTSTEP, there are several drawbacks (none of which are really news):
  • Buffer exchange is an either/or operation. When you retrieve a stored view, you lose whatever work you've just done; you can't, for example, add a stored view to your current one. MLCad's REMOVE GROUP meta is said to allow more flexibility in certain cases, but LDCad doesn't support it at the moment.
  • If an assembly appears unrotated throughout a subfile, but rotated in the main model, you have to add a step to the end of the subfile to show the rotated assembly. Again, this is only a problem if your OCD kicks in, which for me is usually. :-)
  • As with all BUFEXCHG applications, it's necessary to re-insert everything you've added between STORE and RETRIEVE. In my case this means creating a subfile for each standalone section in the main step sequence, together with the individual instances of all those parts in the steps themselves.
This last one, to me, is the biggest issue with buffer exchange. Having to duplicate type 1 lines not only bloats the code, but also creates room for error, particularly if you change anything later on, since you have to remember to change the duplicate instances too. Also, duplicate code causes problems when opening the model in other programs, like LDView or Studio, which don't parse BUFEXCHG commands. I find it becomes necessary to save alternate versions of a file when I need to use it in one of those applications.

I can't think of just a single solution to provide the functionality of buffer exchange while solving this fundamental problem, but in another thread I did propose a pair of new metas, HIDEALL and FLOAT, that taken together I believe would. (HIDEALL would be used to clear the view up to that point, then reveal it again later with an END command, or UNHIDE ALL; FLOAT has been discussed extensively and would be used to provide temporary position and other information without having to duplicate type 1 lines.) Also, as mentioned above, being able to use REMOVE GROUP might be handy in some situations.

I think my verdict is, while ROTSTEP and BUFEXCHG do work well for my purposes, given the inherent drawbacks along with the added steps to my workflow I don't think I'll be fully adopting them just yet. But I did learn some things, so I thought it would be worth sharing!
RE: (More) Musings on ROTSTEP and BUFEXCHG
(2020-07-23, 0:37)N. W. Perry Wrote: To make the model disappear, just RETRIEVE any unused buffer (I use buffer Z).

You should be able to use the 0 CLEAR meta command to do this.
RE: (More) Musings on ROTSTEP and BUFEXCHG
(2020-07-23, 2:00)Orion Pobursky Wrote: You should be able to use the 0 CLEAR meta command to do this.

That was my original thought, but that old meta is not recognized.

And of course, you still need a way to make it reappear. Retrieving a stored buffer is one way, but hypothetically I'd like to be able to retrieve what I've cleared, and add it to my new steps rather than replacing them.

Maybe instead of thinking of a "clear" or a "hide all", it's actually placing a temporary marker where to start parsing the file, until you reach a corresponding end marker. I don't know what the ramifications of that would be in practice, however.
« Next Oldest | Next Newest »

Forum Jump:

Users browsing this thread: 1 Guest(s)