LDraw.org Discussion Forums
Instruction making rant - Printable Version

+- LDraw.org Discussion Forums (https://forums.ldraw.org)
+-- Forum: LDraw Programs (https://forums.ldraw.org/forum-7.html)
+--- Forum: LDraw File Processing and Conversion (https://forums.ldraw.org/forum-22.html)
+--- Thread: Instruction making rant (/thread-24051.html)

Pages: 1 2 3 4 5 6


Instruction making rant - Daniel R - 2020-05-22

I made two instruction for reasonably complex (but not even too big) Technic models, and the process is needlessly painful. So I have a couple of questions and a rant about the future of instruction making software. This is a completely newbie post, so I hope it does not sound too offensive. As English is not my native language it is a little hard for me to write criticism correctly, but I do recognize the seniority of the forum members about these matters. I certainly do not know much about the whole Ldraw software, so I would gladly read explanation why things are done the way they are done. Also some of my nitpicks may be explained by me failing to find some features.

Questions
  1. Is there a way to use buffer exchange without pain? How do you insert the BUFXCHG line? I know that you can insert it by dragging it from LDCad part bin (which usually inserts it in a wrong place) or write it manually in the source (which requires to reload the model). What is worse, if you apply buffer exchange to a submodel, you have to copy and flatten the whole submodel later (and also ignore it in PLI).
  2. What is the relation between Studio part library and LDraw? Do they just copy it or do they contribute something?
  3. Is there a way to show model from different angle easily? Currently the only way I know is copy the whole model as a subfile, ignore all the parts in the subfile and display it as a callout without arrows. This does not scale well: suppose you have to change something in the beginning of the model, then you'll have to change all the copies too.
Rant

In my opinion, if we want to keep anyone use open software and not Studio (which is also somewhat slow, buggy, closed-source and uses proprietary format), LPub3D and LDCad should be way better. My feeling is that now all new users come to Studio, as it is actually usable.

LDCad is really great, it works very fast, even with huge models and on weak computers, its GUI is really effective and documentation is good. I have only minor nitpicks about it:
  • You can't pin compass window. I don't really need the whole compass, it is too big anyway. But I do need the the ASR/NSR switch because if ASR is enabled you can lose current orientation by switching steps, so I constantly check the switch.
  • You need to go to the outer submodel to check the flexible part length
  • Flexible nets are not supported
  • I know you can make part bin with colors (even with counts, that is very cool, much faster than Studio), but it would be useful to quickly change color bin selection to only physically available colors for the part. Maybe even make such mode default, but quickly switchable to current mode.
At the same time, LPub3D experience is terrible, some of that is due to the current implementation and some is due to general design choices (IMHO).
The worst thing is speed. It usually take more than a full minute to render an new page after the next button click. Than is on a decent hardware IMO (quad-core i7-8650U, NVMe storage, more than enough RAM). "Convert to callout" can take several minutes, and even right mouse click can take several seconds to actually show the menu. LDCad is capable of displaying models in real time with reasonably high FPS, so that is definitely possible.

The whole thing is buggy, it crashes regularly, once it deleted a whole subfile. There are a lot of minor bugs in the current implementation, to name a few:
  • Part annotations do not show in callouts
  • Output depends on platform and environment
  • Incorrect BOM with REMOVE GROUP
  • BOM looks terrible compared to official ones (I tried many sorting options, it all looks wrong and unreadable)
  • Export to rebrickable and bricklink works not flawlessly
  • LPub crops images with small camera distance, so it is not possible to pan to specific part of a model
  • LPub inserts another submodel preview on every page of multi-page submodel if the page is a multi-step
  • Part annotations are only inserted once per part
  • Submodel-level colors work not quite the same way as they do in the official manuals
The whole LPub3D automatic layout and margin management is hard to use. Even small movement makes several elements to change position, so it is very hard to place elements, especially with enormous redraw times. I end up using absolute (page) position. The whole relative element placement is very frustrating, it is hard to control.

LPub multi-step layout and margins look very wrong (compare https://imgur.com/5DYF5Cx and https://i.imgur.com/kYRTVWf)

Lack of full spec does not help (https://trevorsandy.github.io/lpub3d/assets/docs/lpub3d/metacommands.html is partially incorrect)

I believe if I had such problems with LPub it is hard to maintain so big thanks to Trevor for doing this. I opened several issues and made some minimal contributions on the Github and Trevor provided very quick answers and edits. But I spent some time even figuring out how to build it to make minimal changes to the code. I think simpler build process and more instructions would be helpful.

Future

As for the future of LPub and LDCad, I have some thoughts about features which would make the process easier and make some competition with Studio possible.

LPub3D default settings should follow current Lego visual language (colors, fonts, margins, rotation icon look, BOM sorting order, line width, which parts use annotations and which don't). The default output should look like 42111 instruction, not like some adhoc script output.

LDCad, preferably, should have ability to store zoom and pan steps and display them in same way in does with ROTSTEPs

Rotation icon should be inserted automatically if the next step is a ROTSTEP (with an option to suppress this default)

I'd like to make callouts with complex shape (see https://imgur.com/ixTDV8b) and more complex callout arrows (https://imgur.com/41eIKeo) easier. Also it would be nice to allow to have submodel last step and its application on same page with a divider, (see https://imgur.com/QGdf5kb)

Maybe subfile header should include part substitution info. As usually you don't need the whole flexibility of PLI BEGIN SUB, as you don't replace arbitrary subsets of a model with arbitrary parts, you only need to replace a submodel with bent part with it's original state. Moreover, even if the said submodel is used multiple times, it is always replaced with the same part. I know that LDCad has partName and partDescr metas (which are not used anyway), but this could also be used with universal joints, shock absorbers, hinges and other parts.

Both current possibilities to change assembled model, BUFEXCHG and REMOVE GROUP are hard to use (unless I am missing something) and limiting. Official instruction use them all the time, see the beginning of 42082 manual (https://imgur.com/jgzpMnd), it is quite time consuming to replicate such steps. Also sometimes you need to rotate parts of a model, move pins or connect cables or tubes. I don't have any ideas of a new syntax for this. Maybe the problem is that the current mechanism is too generic, as you really don't replace random parts with some other random parts, you only substitute the same parts with different positions, and you very rarely need to actually remove parts. I'm not saying saying it shouldn't be supported though

LDCad should have arrow generator, similar to current path generator, so that such arrows (https://imgur.com/bOJdK71) could be made easily.
Generally, there should be two kinds of arrows, "real arrows" and "sprite arrows" (I am not sure whether it is a correct name).
Real arrows should be parts, maintained and distributed officially by LDraw. As LDraw aims to make an official Lego part library with all (and only) official parts produced by Lego, it is reasonable to also maintain official design elements. Instruction designers will have a unified set of them, so they don't have to ship their custom arrows with the instruction. Big yellow arrows used to move parts of a model (https://imgur.com/D6iyDpb) should also be included as parts. Highlighting frames and circles such as https://imgur.com/Ag5Te9E could also be included.
Sprite arrows should be generated by LDCad (they could be straight, maybe aligned to relative grid or curved, exactly the same as paths like cables and tubes) and rendered by LPub in such way that the arrow always faces the camera and always has the same width.


RE: Instruction making rant - Roland Melkert - 2020-05-23

It's kinda late here, so I'll look into the whole post tomorrow.

(2020-05-22, 23:30)Daniel R Wrote:
  1. Is there a way to use buffer exchange without pain? How do you insert the BUFXCHG line? I know that you can insert it by dragging it from LDCad part bin (which usually inserts it in a wrong place) or write it manually in the source (which requires to reload the model). What is worse, if you apply buffer exchange to a submodel, you have to copy and flatten the whole submodel later (and also ignore it in PLI).

You writing "which usually inserts it in a wrong place" makes me suspect you're not yet discovered the source window which allows inserting and moving of otherwise invisible content.

You open one with "views/new source window", and if needed dock it by holding down the ctrl key while moving it around.


RE: Instruction making rant - Philippe Hurbain - 2020-05-24

Quote:Is there a way to show model from different angle easily? Currently the only way I know is copy the whole model as a subfile, ignore all the parts in the subfile and display it as a callout without arrows. This does not scale well: suppose you have to change something in the beginning of the model, then you'll have to change all the copies too.
If I understand correctly what you want, you need to use ROTSTEP to change viewpoint of your current view. Note that ROTSTEP is to be placed at the END of the step you want to display with another viewpoint.


Quote:ASR/NSR switch because if ASR is enabled you can lose current orientation by switching steps, so I constantly check the switch.
That's something I almost never use... but there is a defined keyboard shortcut (b) that you can customize if needed.


Quote:Flexible nets are not supported
Tough problem, this has been asked for several times...


Quote:I know you can make part bin with colors (even with counts, that is very cool, much faster than Studio), but it would be useful to quickly change color bin selection to only physically available colors for the part. Maybe even make such mode default, but quickly switchable to current mode.
This needs a properly updated database of available colors for a given part. Possible by tapping in external inventories websites, but it create a dependancy to that website...


Quote:The worst thing is speed.
I definitely agree with you, but have you tried to use LPub3D native renderer? Not a panacea as it comes with some other issues (scaling management), but it's definitely faster. Still, it's still not that fast in some cases, I'm currently struggling with it for a model that includes large Technic baseplate: takes a while...


RE: Instruction making rant - Daniel R - 2020-05-24

I discovered the source window but as I already had a text editor with the model file opened, I didn't see value in it. It indeed does not reload the whole model when you reorder lines so thank you! It makes life better Smile


RE: Instruction making rant - Daniel R - 2020-05-24

(2020-05-24, 7:05)Philippe Hurbain Wrote: If I understand correctly what you want, you need to use ROTSTEP to change viewpoint of your current view. Note that ROTSTEP is to be placed at the END of the step you want to display with another viewpoint.

No, I failed to explain what I want. See this page from 42082 instruction
[Image: 5mMaM7c.png]
The only way of producing this I know is to make a separate submodel with this view and display it as a callout without arrows. This is a very bad pattern, as it requires copying all the parts, making it hard to make changes in that part of the model.

Quote:That's something I almost never use... but there is a defined keyboard shortcut (b) that you can customize if needed.

That shortcut is partially the reason of my problem. I use it all the time, and, as I don't open the compass window to use it, I sometimes don't remember the current state of this switch. Because if it is on, you can lose your carefully chosen orientation by switching steps.


Quote:This needs a properly updated database of available colors for a given part. Possible by tapping in external inventories websites, but it create a dependancy to that website...


That is not a problem at all. What this needs is API support from LDCad, namely an ability to change color bin contents based on current selected part and external configuration. Also this should be quickly enough not to annoy the user by high latency but with the configuration file loaded and preprocessed in advance (on LDCad start) it should not be hard. The configuration file itself does not need to change more often than three or four times a year and its current version could be shipped with LDCad the same way the shadow files are shipped. The data itself can be easily grabbed from Rebrickable. Because this would be a plain text configuration file (as all LDCad configs are), the users can make updates themselves.


Quote:I definitely agree with you, but have you tried to use LPub3D native renderer? Not a panacea as it comes with some other issues (scaling management), but it's definitely faster. Still, it's still not that fast in some cases, I'm currently struggling with it for a model that includes large Technic baseplate: takes a while...

Yes, I use the native renderer. I used LDView previously as I couldn't use the native one due to some bug, but the bug was reported to Trevor and fixed. It still sometimes requires more than one full minute to show the next page


RE: Instruction making rant - Philippe Hurbain - 2020-05-25

Quote:The only way of producing this I know is to make a separate submodel with this view and display it as a callout without arrows. This is a very bad pattern, as it requires copying all the parts, making it hard to make changes in that part of the model.
Got it. For this I make a snapshot of the needed area (generally with LDView) and insert the image in LPub3D. But that also duplicates data and also make changes tricky...

Quote:Yes, I use the native renderer. I used LDView previously as I couldn't use the native one due to some bug, but the bug was reported to Trevor and fixed. It still sometimes requires more than one full minute to show the next page
I solved my large technic baseplate (39369) problem by temporarily removing all of its subparts from Lpub3D library archive. This makes editing possible again, I'll restore these files for final rendering... and report the problem to Travis!


RE: Instruction making rant - Johann Eisner - 2020-05-26

(2020-05-22, 23:30)Daniel R Wrote: The worst thing is speed.
I think the speed problem is more of a graphics card problem.  I use a slightly older notebook, and I don't care whether I use Native or LDView.  Both are equally fast (slow).  The only difference is that I have LDView running much, much more stable.  I also don't like the auto-zoom behavior of the native renderer.


RE: Instruction making rant - Philippe Hurbain - 2020-05-26

Quote:Both are equally fast (slow)
For me, (and a friend who makes BIG Technic BIs) native renderer is MUCH faster (or should I say much less slow? Big Grin )
(2020-05-26, 6:40)Johann Eisner Wrote: I also don't like the auto-zoom behavior of the native renderer.
I hate it!!!


RE: Instruction making rant - Jaco van der Molen - 2020-05-26

Hi Daniel, I see you are new here, so welcome to the LDraw community!

To answer some of you questions, here goes.

Buffer exchange is a pain, no way to soften that. Surely if you are depending on it heavily like in technic model instructions.
It originated from MLCad and was implemented later in LPub(3D) and LDCad.
To work with it and understand fully, please refer to one of the many tutorials that are out there, like mine: Blush
https://sites.google.com/view/workingwithlpub3d/advanced-lessons/buffer-exchange

Maybe you can study my showcase Technic set 42061 - Telehandler model too.
https://sites.google.com/view/workingwithlpub3d/showcase

These instructions feature some of your wishes and might answer some of your questions too, I think.

As for the software development: you know this is done by hobbyists and comes as is.
I do agree that there are missing features and some could be improved or added.
But we are dependent on the authors of the software and the amount of time and effort they are willing to put in to it.

Development of LDCad is still going strong.
Development of LPub3D has come to a hold it seems.

What version of LPub3D do you use? I do not experience that many crashes. In fact, almost none.

You say "LPub3D default settings should follow current Lego visual language". Why? If you want to mimic exact LEGO instructions you can make your own "template".
I have a whole set of standard settings I just copy in the LDraw file before I start editing in LPub.
But most of the time I try making my own style for instructions though.

Render speed: I start going through the whole model using the native renderer, not creating any callouts, multi step pages, etc. Just go through it to see if the whole building process seems logic. I try to make as much instruction logic while modelling.
Once that is done, I start thinking of callouts. I add the metacommands for those manually to speed things up. Much faster than directly in LPub.
Once happy with the way things look, I start using LDView as rendere and finish instructions. Then often edit the PDF or PNG's manually.

Callouts with complex shapes like your example won't be done any time soon. This is too complex. Again: we depent on the developer of LPub3D and like said that has come to a hold it seems.
Complex callout arrows can be done.

Submodel last step and its application on same page with a divider should somehow be possible, but I haven't figured that one out.

You state that BUFEXCHG and REMOVE GROUP are hard to use. You are right about that. These are very complex and advanced features and hard to learn techniques.

IMHO I think you expect too much of the software. We could never make official LEGO like instructions, but can get very close.

Still, your wishes and ideas are very good.


RE: Instruction making rant - N. W. Perry - 2020-05-26

(2020-05-26, 7:58)Jaco van der Molen Wrote: Buffer exchange is a pain, no way to soften that. Surely if you are depending on it heavily like in technic model instructions.
It originated from MLCad and was implemented later in LPub(3D) and LDCad.
To work with it and understand fully, please refer to one of the many tutorials that are out there, like mine: Blush
https://sites.google.com/view/workingwithlpub3d/advanced-lessons/buffer-exchange

There's something I wonder about in that tutorial—you mention a couple of times that the BUFEXCH_STORE command is used to "store" the hovering parts in the buffer. But isn't it true that what's actually being stored is the view up until that point—in other words, everything before you start to add hovering parts?


So the sequence goes like this:
  • You build your model up to a certain point, then "store" that building state in the buffer, like a save point in a video game.
  • You add some new parts that you plan to change in some way later—move them, or not display them at all, etc. These are simply added to the building state you had so far.
  • You then "retrieve" the building state that you stored—essentially, you "revert" to the save point (losing all changes made since then).
  • You continue building from your saved state, first by adding those same new parts in their changed condition (moved, or just not shown, etc.).
Is that an accurate understanding of the process?

I see why it makes sense, though, to think of the hovering parts themselves—everything between the STORE and RETRIEVE commands, essentially—as being the "buffer". But maybe there are other use cases where it helps to go by the "save" and "revert" concept instead.