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.
   

• 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.
  

• 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
  

(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).
   

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.

Quote:ASR/NSR switch because if ASR is enabled you can lose current orientation by switching steps, so I constantly check the switch.

Quote:Flexible nets are not supported

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.

Quote:The worst thing is speed.

(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.

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

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...

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...

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.

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

(2020-05-22, 23:30)Daniel R Wrote: The worst thing is speed.

Quote:Both are equally fast (slow)

(2020-05-26, 6:40)Johann Eisner Wrote: I also don't like the auto-zoom behavior of the native renderer.

(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:
https://sites.google.com/view/workingwithlpub3d/advanced-lessons/buffer-exchange

• 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.).
  

(2020-05-26, 16:53)N. W. Perry Wrote: ...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?

(2020-05-26, 17:24)Jaco van der Molen Wrote: I have absolutely no idea. I've never fully understood how it works.
The way I describe it is my interpretation.

Only recently I discovered the usage of other letters the A for a buffer (see my showcase model for the Telehandler)

So I guess you can put it the way you say too. No clue however.
Maybe someone can enlighten us?

(2020-05-26, 16:53)N. W. Perry Wrote: Is that an accurate understanding of the process?

(2020-05-26, 17:49)N. W. Perry Wrote: EDIT: Actually, I guess not—LDCad doesn't seem to recognize the CLEAR meta. Instead, you'd put the STORE command at the very top of the model, before anything's added. Then once you get to the sub-build, you'd first STORE the build so far into a second (B) buffer), then insert a RETRIEVE A command to bring back that first (empty) build state.

(2020-05-26, 20:26)Merlijn Wissink Wrote: For example, in the case of buffer-exchange: just throw it out the window and start with something new.

(2020-05-26, 20:30)Roland Melkert Wrote: I never seen a CLEAR meta used with bufxchg, it isn't mentioned in MLCad documentation ether.

Is there any documentation available on its goal/usage, so I might add support for it in 1.7.

Quote:Clear

Clears the screen

Format:
0 CLEAR

This command causes all previous drawn sub-files and line types to be cleared (erased). Any following line types are drawn as normal.

(2020-05-26, 20:57)Orion Pobursky Wrote: Well, none of these META commands are official. Buffer exchange, for example, came from MLCad. Nothing is stopping someone from creating a new instruction language using LDraw as a base. The problem is that you have to do the legwork and actually create the program to go along with it and this is where things fall apart. I look forward to the day that another Kevin Clague comes along, has a need, and creates the successor to LPub.

(2020-05-26, 21:03)N. W. Perry Wrote: All I know of it is what's in the official File Format, which is, in its entirety:


But it seems like it should work, as:

Code:

<some building steps>
0 BUFEXCHG_STORE
0 STEP
0 CLEAR
<some new parts>
0 BUFEXCHG_RETRIEVE
<building continues…>

But my other way seems to work fine, too (storing the empty model and retrieving it when isolating a sub-build).

(2020-05-26, 6:40)Johann Eisner Wrote: I think the speed problem is more of a graphics card problem.

(2020-05-26, 20:26)Merlijn Wissink Wrote: So, everything just goes along as it used to. And now it's getting passed by newer initiatives like stud.io or mecabricks. They're more modern, easier to work with, have a lower learning curve and have all kinds of fancy new features. Sure, it's certainly not as flexible as LDCad + LPub3D and that's the reason I still use that combination for everything I do, but it's not hard to imagine that with time there will be more feature-parity.

(2020-05-26, 7:58)Jaco van der Molen Wrote: To work with it and understand fully, please refer to one of the many tutorials that are out there, like mine:
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

(2020-05-26, 7:58)Jaco van der Molen Wrote: What version of LPub3D do you use? I do not experience that many crashes. In fact, almost none.

(2020-05-26, 7:58)Jaco van der Molen Wrote: You say "LPub3D default settings should follow current Lego visual language". Why?

(2020-05-26, 7:58)Jaco van der Molen Wrote: ... I add the metacommands for those manually to speed things up...

(2020-05-26, 7:58)Jaco van der Molen Wrote: 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.

(2020-05-26, 7:58)Jaco van der Molen Wrote: IMHO I think you expect too much of the software

(2020-05-26, 17:49)N. W. Perry Wrote: I have a specific use case in mind for buffer exchange, in fact, based on a recent convention in official building instructions. The habit these days is to show a sub-build of a model as part of the main step sequence, rather than a series of sub-steps. 

(2020-05-26, 17:24)Jaco van der Molen Wrote: Only recently I discovered the usage of other letters the A for a buffer (see my showcase model for the Telehandler)

(2020-05-26, 20:26)Merlijn Wissink Wrote: LDraw is an old format, and lots of things work, no offense, kinda old-fashioned. And a lot of things stem from concepts made 15-20 years ago. LDraw is very focused on backwards-compatibility and that's a good thing, don't get me wrong. But sometimes, it becomes too much and there just has to be drawn a line somewhere. For example, in the case of buffer-exchange: just throw it out the window and start with something new.

(2020-05-26, 7:58)Jaco van der Molen Wrote: IMHO I think you expect too much of the software. We could never make official LEGO like instructions, but can get very close.

(2020-05-26, 20:26)Merlijn Wissink Wrote: LDraw is an old format, and lots of things work, no offense, kinda old-fashioned. And a lot of things stem from concepts made 15-20 years ago. LDraw is very focused on backwards-compatibility and that's a good thing, don't get me wrong. 

• Some way to make the ASR/NSR indicator always visible
  
• Make flexible part length visible inside the nested submodel
  
• Support to change color bin contents based on current selected part and external configuration
  
• Arrow generator
  

• Include arrows in the official library
  
• Make convention to include the substitute part name in the subfile header (see arguments for this in the first post)
  

(2020-05-27, 3:14)N. W. Perry Wrote: For parts that need to hover for more than one step, you could either devise a BEGIN and END system, or just add a parameter [n] to the FLOAT line, telling it to use that matrix for the next n steps. (And maybe a negative [n] could mean to hover until step number n is reached.)

(2020-05-27, 15:48)Daniel R Wrote: So while some parts of my first post are suggestions for the next LDCad version, namely

• Some way to make the ASR/NSR indicator always visible
  
• Make flexible part length visible inside the nested submodel
  
• Support to change color bin contents based on current selected part and external configuration
  
• Arrow generator
  

(2020-05-27, 16:01)Daniel R Wrote: A very minor nitpick: I don't think [n] would be a good idea, as it is hardcoding, which we are trying to get rid of.

(2020-05-27, 16:22)N. W. Perry Wrote: What would be a better way?

(2020-05-27, 16:32)Daniel R Wrote: I described my vision (which is similar yours) in the following message. I am not saying it is the way, but I think it is easier to implement in LDCad and applies to more situations. On the other hand, it requires more boilerplate (all these group definitions) and maybe it is a bit less logical (because it requires first to place part in a wrong (temporary) location and only then move it to the correct location).

Quote:Specifically, I dislike the number of steps suggestion because steps order and count can change and you would need to correct all these numbers.

(2020-05-27, 16:55)N. W. Perry Wrote: I actually took the presumption the "applies to more situations" would be objectionable rather than desirable

• Simple hovering of parts used in this step
  
• Movement of parts attached some time ago 
  
• Connection of flexible parts ends
  

(2020-05-27, 16:55)N. W. Perry Wrote: we'd want to limit ourselves to one ref line per part used (to avoid having to adjust the parts list/BOM, etc.). With buffer exchange, you have to reference each part twice (or more)

(2020-05-27, 16:55)N. W. Perry Wrote: Would your MOVE GROUP command have some way to handle multi-step hovering, or would it just not allow for this possibility?

(2020-05-27, 16:55)N. W. Perry Wrote: Yes, of course either the software or the user would have to keep track of that. Of course, the parameter would be configurable, so at the end of your workflow you could easily adjust a part's float settings

(2020-05-27, 15:48)Daniel R Wrote: I would love to contribute to LDCad code but it is closed and I respect this Roland's decision. Still, if this changes I would gladly contribute there (for instance, I can do some minor features which are thought to be necessary).

(2020-05-27, 15:48)Daniel R Wrote: 0 ROTSTEP 23 45 0 ABS CENTER 1 2 10 ABS DISTANCE 200 ABS

(2020-05-27, 15:48)Daniel R Wrote: Maybe it should reuse existing LDCad grouping capabilities, maybe like this

(2020-05-27, 16:32)Johann Eisner Wrote: Where all users sacrifice their free time and make everything free of charge.

(2020-05-27, 16:32)Johann Eisner Wrote: I'm currently drawing a Technic MOC with about 14,000 parts, (yes 14 thousand)

(2020-05-27, 16:32)Johann Eisner Wrote: And I still believe that the MOC is buildable.

(2020-05-27, 17:38)Daniel R Wrote:

• Movement of parts attached some time ago
  
• 
  
• Connection of flexible parts ends
  

(2020-05-27, 17:41)Roland Melkert Wrote: I'm not sure if people would be that happy working on LDCad code as I like to do things the hard way

(2020-05-27, 19:33)Jaco van der Molen Wrote: This can be done with REMOVE GROUP using MLCad Group meta.

(2020-05-27, 19:58)Daniel R Wrote: I also would be very glad if you post your opinion on some of the other suggestions above.

(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
  

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.

Quote:I don't quite understand you here, sorry. Perhaps you could elaborate a little bit?

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.

Quote:Maybe you could explain how that interface could look?

(2020-05-27, 1:39)Daniel R Wrote: While you can replicate this with BUFEXCHG, LPub3D now has a setting to enable continuous step numbering, so you can use submodels as usual. I think it is much easier

(2020-05-27, 20:24)Merlijn Wissink Wrote: I proposed a BUFFER END a long time ago already: https://github.com/trevorsandy/lpub3d/issues/43
Never really led anywhere.

(2020-05-27, 22:37)N. W. Perry Wrote: I'm having trouble understanding the problem as described. It says "everything after the start command is placed in the buffer"—but really, it's everything before the start (STORE) command that's buffered, no? Then when you RETRIEVE it, that's basically like the end command already. Or am I getting something mixed up?

(2020-05-28, 8:45)Merlijn Wissink Wrote: Due to this limitation, buffer exchange cannot work through multiple steps. If you want to do that with the current implementation, you'd have to repeat the same STORE/RETRIEVE over multiple steps.

(2020-05-28, 11:51)Philippe Hurbain Wrote: As you say, it does work but you must "re-add" all parts between store and retrieve after the retrieve (tedious I agree). What really annoys me is "submodel wih moving parts" (eg. submodel where you must push pins after attaching to the main model), I have no other solution than to make two different submodels

(2020-05-27, 18:58)Daniel R Wrote: Certainly. I understand this and do not ask anyone to implement some changes for me. I am sorry if I have sounded this way.

(2020-05-27, 18:58)Daniel R Wrote: That is very cool! Do you use LPub3D to make callout arrows? What is your typical wait time to display next page?

(2020-05-27, 18:58)Daniel R Wrote: Moreover, I think we limit ourselves and change the way we produce instructions due to technical difficulty of some commands. At least I do. So I think I would use it much more often if it was an easier process.

(2020-05-27, 22:14)N. W. Perry Wrote: Assigning some kind of ID to each FLOAT command could be a way around that.

(2020-05-27, 22:14)N. W. Perry Wrote: 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.

(2020-05-28, 8:45)Merlijn Wissink Wrote: It's been a little while since I last used buffer exchange, but I'm pretty sure everything after the STORE command is what is buffered.

Quote:In any case, an example for the problem described there. Imagine you're making instructions for which need a part in a temporary positions for a certain number of steps. Everything after the STORE command will be removed once RETRIEVE is called. So, if you add temporary part in step 20, then in steps 21-24 you add other ('normal') parts and then call RETRIEVE in step 25 to place the temporary part in the final positions, all the other parts in steps 21-24 will be removed too, because the STORE command never ends (until RETRIEVE).