LPub3D 2.0 Released

[Jaco van der Molen]

For LPub3D 2.1 and beyond, there are already quite a few interesting new features coming from the Porsche GTS instructions book, I'll add this one also.

OH nice

[Trevor Sandy]

Greetings,

LPub3D 2.0.19 is released.

You can download this release from sourceforge.net or check for updates in your existing installation.

Change Log:

LPub3D 2.0.19.877.2

Features and enhancements
------------
Fix: Callout not displayed and part count incorrect when loading a model using multiple, separate ldr-format files (r877)
* These behaviours were introduced in LPub3D 2.0.0. The immediate work around is to merge the individual ldr files into a single MPD-format file. However, these behaviours are now corrected.

Cheers,

[Merlijn Wissink]

This callout in a callout doesn't look very well :


I don't know what's happening here, but it sure isn't what it's supposed to do. Any ideas?

[Trevor Sandy]

...callout in a callout doesn't look very well :
I don't know what's happening here, but it sure isn't what it's supposed to do. Any ideas?

I didn't know nested callouts were possible in LPub3D or LPub for that matter

I certainly haven't released any functionality of the sort; furthermore, the legacy LPub code suggest this behaviour is explicitly forbidden.

Code:

// This is what's supposed to happen when a callout [begin] meta is encountered.
case CalloutBeginRc:
              if (callout) {
                  parseError("Nested CALLOUT not allowed within the same file",current);
                } else {
                  callout = new Callout(curMeta,view);
                  callout->setTopOfCallout(current);
                }
              break;

Did the behaviour you expected exist on any earlier version of the software?

It would be interesting to see an example of the LPub meta pattern you used in the model file to produce nested callouts.

Cheers,

[Milan Vančura]

Hi Trevor.

I'm finally back, having time for ldraw things again. I see you have released several versions since summer holidays, that looks nice. Did you have time for a research why LPub3D stopped being compilable on Linux, too? Can I still help you with that in any way?

You know - it's a strong feeling of pity as original LPub was for both Linux and Windows and today I see many nice features but as pictures in ldraw forum only ;(

[Merlijn Wissink]

...callout in a callout doesn't look very well :
I don't know what's happening here, but it sure isn't what it's supposed to do. Any ideas?

I didn't know nested callouts were possible in LPub3D or LPub for that matter  

I certainly haven't released any functionality of the sort; furthermore, the legacy LPub code suggest this behaviour is explicitly forbidden.

Code:

// This is what's supposed to happen when a callout [begin] meta is encountered.
case CalloutBeginRc:
             if (callout) {
                 parseError("Nested CALLOUT not allowed within the same file",current);
               } else {
                 callout = new Callout(curMeta,view);
                 callout->setTopOfCallout(current);
               }
             break;

Did the behaviour you expected exist on any earlier version of the software?

It would be interesting to see an example of the LPub meta pattern you used in the model file to produce nested callouts.

Cheers,

I'd swear I've seen callouts in callouts in the past. But, I couldn't quickly find an example. Now I start to doubt myself   
Still, I can 'remember' it so clearly: the red box inside the yellow box; callout in a callout. I'll browse through some more instructions, see if I can find something like that anywhere. Maybe my mind is just plain wrong...

How I produced it: I'm not 100% sure (my memory is not... great ), but I believe I just created a callout from the 'parent' callout. Then I saw that little square and I realized the submodel in the parent also used a callout. I thought I needed to create the child-callout first, so I pressed undo, went to the child-submodel, transformed that into a callout (the child-callout) and then transformed the parent submodel back into a callout (parent callout). Still, just a little square.

[Philippe Hurbain]

Done that in the past...
Head calls Head2 that calls Head2a.

[Trevor Sandy]

Ah, got it. Many thanks for the example Philo !

Nested callouts are indeed supported when the 'child' callout is in a different mpd-format FILE (meta) or separate ldr-format file [Philo's example].

The LPub3D behaviour you are experiencing is a current limitation of the recently released LDView Single Call Rendering feature.

If you un-check 'Use multiple files single call rendering' (Configuration/Preferences/Rendering Tab/LDView is installed menu group) or change your 'Preferred renderer' to LDGLite, the nested callout will display as expected.

The current behaviour is a result of the single call parse not iterating to the level of the nested callout assembly (CSI) so only the PLI (if displayed) is presented. I will take a look at redesigning this logic.

Cheers,

[Trevor Sandy]

Hi Milan,

Where have you been ? It's a rhetorical question  

Did you have time for a research why LPub3D stopped being compilable on Linux, too?

Between v2.0.0 and v2.0.7, I was compiling my release distributions with MSVC 2015 which I understand broke Linux compatibility. From 2.0.8 I reverted back to exclusively releasing MinGW compiled distributions (x86 and x64).

It is my understanding that LPub3D can run under POSIX-compliant operating systems, such as Linux, Mac OSX, & BSD using WINE HQ (www.winehq.org ).

If you are ok to run the currently available distributions of LPub3D - WINE is your friend

Can I still help you with that in any way?

Sure, the LPub3D source should be cross-platform compile compatible because I develop exclusively with the QtCreator/MinGW tool chain.

If you care to share any content on compiling on and packaging for Linux, I'll be pleased to incorporate and validate the build and release.

If you care to compile and package LPub3D, you can see the source here.

Cheers,

[Kevin]

If you are ok to run the currently available distributions of LPub3D - WINE is your friend  

And if you are using LPub3D, POV-Ray, and Python to create a 4000-frame animation of a MOC, bourbon is your friend.

[Milan Vančura]

Sure, the LPub3D source should be cross-platform compile compatible because I develop exclusively with the QtCreator/MinGW tool chain.

If you care to share any content on compiling on and packaging for Linux, I'll be pleased to incorporate and validate the build and release.

Thanks, Trevor!
This version looked much more promising so I spent some hours on that and made it working on Linux, natively.
Qt part was easy, there were only details to fix. The other parts contained, sometimes, Windows-specific code or #ifdef's were not used 100% properly. And, of course, some filenames were referenced with improper character case, as Windows  do not care about that. Plus the "wrapper" header file unistd.h, specific for Windows, was placed in a way it was impossible to #define how not to use it on Mac and Linux.

I fixed all that, you can see it in the first git commit. The second one is a fix of one annoying issue coming from old LPub4 times: the file mask of Open file dialogs caused people on Mac and Linux saw nothing in the dialog. This commit applies on top of the first one. Both are ready to be used directly by git ('git am') so you can check them easily.

Thanks again for your work, it was nice feeling to see LPub3D working, in the end   Even there are still some problems (and they don't look Linux-specific), I report them later. Of course, tell me if you need anything more about Linux, I hope LPub3D stays multiplatform since now and I'll be able to prepare Linux binary package every time you release new version.

[Trevor Sandy]

...tell me if you need anything more about Linux, I hope LPub3D stays multiplatform since now and I'll be able to prepare Linux binary package every time you release new version.

Excellent !

I'll apply the relevant updates to my development branch so it will be much easier to compile for Linux going forward.

I actually already have a running Mac port and I'm aware of some issues like the splash screen on startup when installing a fresh instance of LPub3D. I have already addressed items, including some you have also addressed for 2.0.6 (e.g. unistd.h), ldrawini_global.h, updates to ldrawini, quazip modules and several classes in the mainApp module.

Many thanks for your effort on the port. I'll be sure to add you to the list of credits for this contribution.

Cheers,

[Milan Vančura]

Great!

I'm glad it looks we can cooperate this way. If I had the read access to your development git branch I could prepare commits based on the current code - that saves time of both me (some fixes already done) and you (every merge easier for you). I can continue sending commits via forum or e-mail so I do not need any write access to you tree. What do you think about that?

Also, it would be great if you can have a virtual machine with Linux so you can test your builds there. Of course, I may help you with this if needed. Installation of Debian or Ubuntu is easy, same about openSuse or Fedora.

For example, the following is a list of issues I was hit by - and I plan to work on them if needed, after Christmas:

First run - the creation of the first user configuration:

* LPub3D creates new directory tree on its own ($HOME/.local/share/LPub3D Software/LPub3D/) but it forgets to create some files there and complains to me instead: "extras/titleAnnotations.lst", "extras/fadeStepColorParts.lst", "extras/pliSubstituteParts.lst".

* to make it more annoying, it cries later about missing titleAnnotations.lst file before rendering each and every step

* Preferences: after typing the ldglite path manually the roller "preferred renderer" does not get any value and "Required settings are missing..." warning pops up after hitting "OK" button. The workaround is to click on "Browse", even I do not need to change the path. Then, everything works.

* LPub3D asks me for both complete.zip and ldraw directory - why??

* LPub3D tries to get some archive of unofficial parts - how can I point it to my "Unofficial" subdirectory of my ldraw tree instead? Same as what I use and/or used with LDCad, LPub4, SR3D Builder...


in the application:

* ctrl-O does not work

* ctrl-S tries to "save the project" even when nothing is open

* I do not understand how to "synchronize" the angle of current step and the angle in that 3D window. A different angle is shown there and if I rotate with that 3D view and press "insert rotstep" button, I get completely different view in the rotstep than it is shown in the 3D sidebar.



generic:

the program crashes with segmentation fault in several cases, I try to map them and solve what I can.


I expect more but this is what I have found so far. It looks like a set of problems big enough to prevent me getting bored between Christmas and the end of year I'd be very glad if you can tell me more: what makes sense to spend time with, what you have already solved in your development branch, what looks like a Linux-specific problem etc.

[Milan Vančura]

A bug I cannot reproduce now but it happened twice: after first run and all those configuration questions, program set the LDraw path to $HOME/.local/share/LPub3D Software/LPub3D/ldraw directory which it created but left empty. Then it was a surprise why LPub3D looks working somehow but I see empty pages, only a box with numbers of each part amount was there, no pictures. After long debugging I found it was just a matter of this misconfiguration.
But, as I wrote above, I'm not able to reproduce this behavior now, I forgot that combination of my options which caused this.

[Trevor Sandy]

Milan - see my remarks below...

If had the read access to your development git branch I could prepare commits based on the current code - that saves time of both me (some fixes already done) and you (every merge easier for you). I can continue sending commits via forum or e-mail so I do not need any write access to you tree. What do you think about that?

You should have read access. Read permissions are enabled for anonymous users by default. If you care to set up and forward your sourceforge user id, I'll be pleased to add you to the repository with read/write access. Or, we can continue to exchange via mail/posts. You can see my email in the help/about dialogue.

Also, it would be great if you can have a virtual machine with Linux so you can test your builds there. Installation of Debian or Ubuntu is easy, same about openSuse or Fedora.

I'm currently running an Osboxes.org CentOS 7 distribution  as well as OSX Sierra - both via VM. I am launching LPub3D on CentOS without issue but I can't seem to find any binaries for the renderers (ldglite, LDView) so I'm blocked at the moment. I setup and compile the renderers but I think it would be more efficient to switch to another Linux distribution where the renderers are already available. What do you think is the optimum Linux distribution for LDraw tools ?

I'd be very glad if you can tell me more: what makes sense to spend time with, what you have already solved in your development branch, what looks like a Linux-specific problem etc.

Here are some useful guidance and insights on the behaviours you encountered:

- I have updated the latest release source (v2.0.19) with the changes required for POSIX/x11 compatibility and created a new  x11 branch on sourceforge. The LPub3D master branch has also been updated to the latest release.

- To best understand the internals of LPub3D, I would recommend performing a thorough read of the README.txt which capture explanations of the changes, features and updates for each release. This information is important to also track the evolution of features over time. Of course it would also be wise to review the source, particularly the deployment scripts. When compiling your distribution, it could be good to also take a look at the portable distribution to well understand the composition of components for a successful runtime instance.

First run - the creation of the first user configuration:

* LPub3D creates new directory tree on its own ($HOME/.local/share/LPub3D Software/LPub3D/) but it forgets to create some files there and complains to me instead: "extras/titleAnnotations.lst", "extras/fadeStepColorParts.lst", "extras/pliSubstituteParts.lst".

* to make it more annoying, it cries later about missing titleAnnotations.lst file before rendering each and every step

This behaviour most likely results from an incomplete runtime state. LPub3D is not runtime ready after compilation. There is additional content required which is positioned by the deployment scripts during installation or pre-positioned, as is the case for portable distributions. If you expect to successfully launch after compilation then it will be necessary to pre-position the dependent content accordingly.

* Preferences: after typing the ldglite path manually the roller "preferred renderer" does not get any value and "Required settings are missing..." warning pops up after hitting "OK" button. The workaround is to click on "Browse", even I do not need to change the path. Then, everything works.

I'll take a look. This behaviour is unexpected as the error message should not present if the renderer path dialog is not empty - which it is not because you manually typed in the entry.

* LPub3D asks me for both complete.zip and ldraw directory - why??

This is a good question and further details are captured in the readme I mentioned earlier. But to give a brief explanation, for performance and interoperability between LPub3D editor and the 3D viewer - based on LeoCAD, the solution architecture uses Ldraw archive libraries for official and unofficial LDraw content. This approach is vaguely similar to the shadow files of LDCad for example. Particularly when considering the unofficial LDraw library which is supports the loading and exchange of custom and faded part files between the editor and viewer.

The LDraw library path is required as it is used to update the archive libraries (mainly the unofficial archive) with any new parts added to the library. It is also used to generate the part list used to identify parts with static colours and as a possible location of the ldrawini file.

* LPub3D tries to get some archive of unofficial parts - how can I point it to my "Unofficial" subdirectory of my ldraw tree instead? Same as what I use and/or used with LDCad, LPub4, SR3D Builder...

The loading of unofficial parts into the unofficial archive at startup is an automatic function which does not need or support user intervention. The only requirement is to point LPub3D to your LDraw directory at installation. If your LDraw directory is not detected at startup, you will be prompted by LPub3D as you have discovered. If one would like to add other unofficial file locations, this is possible using the ldrawini framework and/or directly updating entries in Preferences/Other/LDraw Content Search Directories.

* ctrl-O does not work

Many of the shortcuts do not currently work. I keep forgetting to fix them. I'll fix for the next release. The behaviour root cause is mostly because of conflicts with similar shortcut definitions between the the LPub3D editor and 3D viewer.

* ctrl-S tries to "save the project" even when nothing is open

This behaviour was corrected sometime after 2.0.6.

* I do not understand how to "synchronize" the angle of current step and the angle in that 3D window. A different angle is shown there and if I rotate with that 3D view and press "insert rotstep" button, I get completely different view in the rotstep than it is shown in the 3D sidebar.

In 2.0.6 the difference in views represent a fixed offset between the editor and viewer. This behaviour is because the LPub and LeoCAD (3D Viewer) coordinate system are not the same - If I can remember well, the Y axis is inverted in LeoCAD. Moreover, the default camera globe settings were not the same either. Lastly, LPub3D (legacy LPub behaviour) performed rotation on all CSI parts equal to the the default rotation (x=23,y=45,z=0) before rendering, presenting these 'rotated' parts to the viewer then resulted in further rotation offset. You can see details of this behaviour in step.h/cpp and rotate.h/cpp source files

I have improved this behaviour after 2.0.6 but it is still not as I would like it and I continue to look for a better scheme to synchronize the 2 views.

The program crashes with segmentation fault in several cases, I try to map them and solve what I can.

It would be quite helpful to know a bit more about where/when the application crashes.

Cheers,

[Milan Vančura]

Thanks for your reply, Trevor. This casts new light: I found a link to the git tree on sf.net but to that old one (2.0.6) only, I did not understand why. But probably it was caused by the fact I was there anonymously. I'm not at home today but tomorrow, I try to create my own account at sf.net and see what branches I'll get then. This might change a lot

About Linux testing, renderers and so on: that's exactly what I'm working on, with one friend of mine. We created a set of repositories for many of well-known linux distros and we package the ldraw SW there. I want to add LPub3D as well, that's my goal, of course. So you can use packages we already have there. Unfortunately, we did not have time to fix some dependencies issues of ldglite at RedHat systems (Fedora, CentOS). I might try to fix them if you need CentOS. Meanwhile, you can install that on openSUSE, Debian or Ubuntu. I'm not sure now but Arch Linux should work as well.

What I still don't understand is your way of ldraw library management. All other tools (including ones we do not have in our repositories, like LDCad) know to use a directory tree so one of our goals is to configure them automatically, that they all touch the same ldraw library when installed from our packages. It's important to prevent those really-not-funny situations when you can see some parts in your editor but they are silently missing in the generated PDF with instructions, etc. This is something to think more about, in LPub3D case, as I see. But it's too soon for that, I need to create my sf.net account, watch the current code and learn about your "deploy scripts" first.

[Trevor Sandy]

I found a link to the git tree on sf.net but to that old one (2.0.6) only, I did not understand why.

Just click on the link in my previous post to go directly to the x11 branch. Here it is again  x11 branch on sourceforge.

RO git access is: 

Code:

git clone git://git.code.sf.net/p/lpub3d/code lpub3d-code

You should get both the master and x11 branches with this access url.

Unfortunately, we did not have time to fix some dependencies issues of ldglite at RedHat systems (Fedora, CentOS). I might try to fix them if you need CentOS.

CentOS is more of a server platform and not so common for desktop. I was using it because I used it for work. Anyhow, I've switched to Ubuntu so don't bother to fix any dependencies on my account.

However, ldglite specifically has been updated by Don Heyse (see Don's blog and github) to accommodate LPub3D additional search directories and ldrawini. This is the only version compatible with LPub3D so you should consider updating your ldglite rpm package from 1.2.10 to 1.3.1 with the 2g2x modification.

What I still don't understand is your way of ldraw library management.

Just consider that LPub3D uses the LDraw archive libraries instead of the unarchived libraries to identify parts and to display parts in the 3D viewer. The archive libraries should be provided for runtime but can also be downloaded on demand.

In addition to what was mentioned in my previous post, LPub3D must still capture the unarchived LDraw library path as it is part of the parameter set sent to the ldglite renderer.

Cheers,

[Trevor Sandy]

A bug I cannot reproduce now but it happened twice: after first run and all those configuration questions, program set the LDraw path to $HOME/.local/share/LPub3D Software/LPub3D/ldraw directory which it created but left empty. Then it was a surprise why LPub3D looks working somehow but I see empty pages, only a box with numbers of each part amount was there, no pictures. After long debugging I found it was just a matter of this misconfiguration.
But, as I wrote above, I'm not able to reproduce this behavior now, I forgot that combination of my options which caused this.

Milan, the behaviour described here is not due to the reason stated. In fact, it is because of the 3D viewer part cache corruption. Here are the details:

Symptom:
After opening a model file, the status indicates 0 parts were loaded. The log states Item [<part.dat>] not in the LPub3D archives. <path>/lpub3dldrawunf.zip <path>/complete.zip. This x11-specific behaviour presents on launching LPub3D after a previous abnormal termination (crash).
Problem:
Corrupt 3D Viewer (LeoCAD) cache
Solution:
Delete the cache at $HOME/.cache/LPub3D Software and relaunch the application.
Root Cause:
Abnormal termination of the application

I have taken a first look at the x11 port and I believe there are some areas, notably the user menus, to address before a reasonable release can be qualified.

Cheers,

[Milan Vančura]

You should have read access. Read permissions are enabled for anonymous users by default. If you care to set up and forward your sourceforge user id, I'll be pleased to add you to the repository with read/write access. Or, we can continue to exchange via mail/posts. You can see my email in the help/about dialogue.

Just a quick update, I will have more time during the weekend: I can see both master and x11 branch and it's the same tree I made the clone before - I see you added big commits forwarding the code to 2.0.19 at once. That's good, I can work with more current code now. But it would be even better if you can give me the access to the real development branch where I can see separate commits with features and fixes - this would help me a lot to understand the code.
If it is possible...

I'll send more on Sunday, I hope.

[Merlijn Wissink]

I haven't used buffer-exchange in quite a while, but I need it again now. But, it looks like LPub3D doesn't handle it correctly (anymore). Or I'm just not using buffer-exchange correctly, that's also a possibility 

This is an excerpt from my file (I added some extra step numbers for clarity, they are not in the actual file):

Code:

[STEP 1]
1 4 0 -101.461 390.329 -1 0 0 0 0.966 0.259 0 0.259 -0.966 submodel-94.ldr
0 BUFEXCHG C STORE
1 4 15 -62.824 400.681 1 0 0 0 0.966 -0.259 0 0.259 0.966 32062.dat
1 0 -50 -62.821 400.689 0 0 1 -0.966 0.259 0 -0.259 -0.966 0 HashL2.dat
0 ROTSTEP 20 165 0 ABS

[STEP 2]
0 BUFEXCHG C RETRIEVE
1 4 -70 -62.824 400.681 1 0 0 0 0.966 -0.259 0 0.259 0.966 32062.dat
0 BUFEXCHG D STORE
1 4 -15 -62.824 400.681 1 0 0 0 0.966 -0.259 0 0.259 0.966 32062.dat
1 0 50 -62.821 400.689 0 0 -1 0.966 0.259 0 0.259 -0.966 0 HashL2.dat
0 ROTSTEP 20 -165 0 ABS

[STEP 3]
0 BUFEXCHG D RETRIEVE
1 4 70 -62.824 400.681 1 0 0 0 0.966 -0.259 0 0.259 0.966 32062.dat

So, let's go through this step by step when viewing this in LPub3D:

• Step 1, everything seems fine. It shows the submodel, the buffered part and the arrow (which for whatever reason is not in the parts list, but that's good obviously   )
  
• Step 2, here things get a bit wrong. LPub3D correctly removes the buffered 32062 and the arrow from the assembly view and it correctly shows the new buffered 32062 and arrow. BUT, it hows 2x 32062 in the parts list. That should be 1x.
  
• Step 3, the same as step 2. It correctly removes the buffered parts from the view, but it still lists 1x 32062 again in the parts list...
  

I have added 2 buffer exchanges so far and both show this behavior.
So, am I doing something wrong or is LPub3D doing something wrong?

[Trevor Sandy]

I haven't used buffer-exchange in quite a while, but I need it again now. But, it looks like LPub3D doesn't handle it correctly (anymore). Or I'm just not using buffer-exchange correctly, that's also a possibility 

This is an excerpt from my file (I added some extra step numbers for clarity, they are not in the actual file):

Code:

[STEP 1]
1 4 0 -101.461 390.329 -1 0 0 0 0.966 0.259 0 0.259 -0.966 submodel-94.ldr
0 BUFEXCHG C STORE
1 4 15 -62.824 400.681 1 0 0 0 0.966 -0.259 0 0.259 0.966 32062.dat
1 0 -50 -62.821 400.689 0 0 1 -0.966 0.259 0 -0.259 -0.966 0 HashL2.dat
0 ROTSTEP 20 165 0 ABS

[STEP 2]
0 BUFEXCHG C RETRIEVE
1 4 -70 -62.824 400.681 1 0 0 0 0.966 -0.259 0 0.259 0.966 32062.dat
0 BUFEXCHG D STORE
1 4 -15 -62.824 400.681 1 0 0 0 0.966 -0.259 0 0.259 0.966 32062.dat
1 0 50 -62.821 400.689 0 0 -1 0.966 0.259 0 0.259 -0.966 0 HashL2.dat
0 ROTSTEP 20 -165 0 ABS

[STEP 3]
0 BUFEXCHG D RETRIEVE
1 4 70 -62.824 400.681 1 0 0 0 0.966 -0.259 0 0.259 0.966 32062.dat

So, let's go through this step by step when viewing this in LPub3D:

• Step 1, everything seems fine. It shows the submodel, the buffered part and the arrow (which for whatever reason is not in the parts list, but that's good obviously   )
  
• Step 2, here things get a bit wrong. LPub3D correctly removes the buffered 32062 and the arrow from the assembly view and it correctly shows the new buffered 32062 and arrow. BUT, it hows 2x 32062 in the parts list. That should be 1x.
  
• Step 3, the same as step 2. It correctly removes the buffered parts from the view, but it still lists 1x 32062 again in the parts list...
  

I have added 2 buffer exchanges so far and both show this behavior.
So, am I doing something wrong or is LPub3D doing something wrong?

Merlijn - take a look at this post on a good pattern for using the BUFEXCHG meta in LPub3D. 

Let me know if after you adjust your BUFEXCHG procedure accordingly, the unexpected behaviour continue ?

The post presents a detail use case with supporting LPub3D and LPub assets comparing and explaining how the BUFEXCHG meta should be used. I believe an anomaly in the way LPub managed its cache files, and the difference in the way MLCAD treats the meta, have led to incorrect expectations about the way the meta can be used with LPub3D.

Cheers,

[Merlijn Wissink]

Merlijn - take a look at this post on a good pattern for using the BUFEXCHG meta in LPub3D. 

Let me know if after you adjust your BUFEXCHG procedure accordingly, the unexpected behaviour continue ?

The post presents a detail use case with supporting LPub3D and LPub assets comparing and explaining how the BUFEXCHG meta should be used. I believe an anomaly in the way LPub managed its cache files, and the difference in the way MLCAD treats the meta, have led to incorrect expectations about the way the meta can be used with LPub3D.

Cheers,

Well, as in the post you linked, I expect 'V1 correct behavior' but I'm seeing 'V1 incorrect behavior'. I'm 1000% sure that an old version of LPub had the 'correct' behavior, as shown by Johann.

But of course it depends on what you think is correct. Now that I think of it, I think it's better to call the 'incorrect' version on your link the 'correct' version (because technically, it's doing exactly what the file says) and to call the 'correct' version the 'desired' version. Because, 99% of the time you use buffer exchange, you want a floating part with arrows in step 1 and the part in its final position in step 2 without adding it to the PLI again.

As the post described, a way of doing it currently is by adding ignore commands to all final-position parts. But, in a large model, that'll start to clutter up a lot of things and it's very inconvenient. Maybe, just maybe, we need to introduce a new command? After all, buffer-exchange is an (ancient) MLCad-command and LPub just added support for that. There's no reason LPub3D can't introduce its own command (there are so many already after all).

I'm just thinking out loud here, but maybe something like this (based on MLCad's version, it doesn't have to be completely different):

Code:

[other parts in the step]
0 !LPUB BUFFER A STORE BEGIN
[parts and arrows to store here]
0 !LPUB BUFFER A STORE END
[other parts in the step]

0 STEP

[other parts in the step]
0 !LPUB BUFFER A RETRIEVE BEGIN
[final position parts]
0 !LPUB BUFFER A RETRIEVE END
[other parts in the step]

It's not too different from the MLCad version, but it does solve a lot of headaches. Because it has a clear begin and end for both the store and retrieve commands, it would be fairly easy for LPub3D to automatically make correct assemblies and PLIs. And, it also makes adding it way less of a headache, current buffer exchange is position-dependent, which is incredibly annoying if you forget to move a line up or down 
Now, of course, you could also take it a step further and make a more complicated buffer exchange with more features. Cross-submodel buffer store/retrieve for example (in other words, e.g. buffer A is not only known in the submodel it's in, but is known model-wide), but I have no idea if that would be easy to use at all.

[Trevor Sandy]

Very well. Your write up looks interesting.

On the post I linked, I hadn't really looked at Johann's update so If his scenario is different from Artius' then I will certainly update LPub3D if it is determined to be in regression. On the other hand, I clearly demonstrated that Artius' expectation was actually not the way either LPub3D or even LPub actually behaved. This position is demonstrated in the post I shared.

So. I am open to evolving the BUFEXCHG behaviour (while keeping backward compatibility of course) to make it more efficient because some users seem to be confused by the current behaviour (I get lots of request on the good pattern to implement). Moreover, the feature is quite valuable to producing hi-fidelity instructions.

Im wrapping up my x11 ports (Linux and OSX) so I should be in a position to take a look at putting this on the stack after that. Do not hesitate if you have any additional ideas on how we could improve this feature.

Cheers,

[Merlijn Wissink]

If you don't mind, I have another feature request 

It would be nice if the callout command would also work on parts. Sometimes, a callout is handy to point out a difficult to see part. Currently, one would need to create a submodel with a single part to create a callout for that part. It would be nice if the current callout command would also work on parts. 

[Merlijn Wissink]

Very well. Your write up looks interesting.

On the post I linked, I hadn't really looked at Johann's update so If his scenario is different from Artius' then I will certainly update LPub3D if it is determined to be in regression. On the other hand, I clearly demonstrated that Artius' expectation was actually not the way either LPub3D or even LPub actually behaved. This position is demonstrated in the post I shared.

So. I am open to evolving the BUFEXCHG behaviour (while keeping backward compatibility of course) to make it more efficient because some users seem to be confused by the current behaviour (I get lots of request on the good pattern to implement). Moreover, the feature is quite valuable to producing hi-fidelity instructions.

Im wrapping up my x11 ports (Linux and OSX) so I should be in a position to take a look at putting this on the stack after that. Do not hesitate if you have any additional ideas on how we could improve this feature.

Cheers,

Great! I'll see if I can think about other things that would be nice to have.
One thing popped up yesterday already: with the current buffer exchange, if I store a buffer in the last step of a submodel, there's no way to retrieve that buffer without adding an (unnecessary) extra step. That's another reason a global buffer (vs a submodel-level buffer) would be nice.

Another example: a lot of Technic models use that pin-with-bush part. Often times, it's attached on a submodel not fully pressed. Then you place the submodel on the main model and you fully press the pins-with-bushes. With the current buffer, that's also not possible*.

I hope that all makes a bit sense. Writing clear texts is by far not my greatest skill  

*unless you make a little hack and you create 2 submodels, one with fully pressed pins and one with semi-pressed pins. Then buffer the whole submodel with semi-pressed pins and then retrieve that one and swap it with the one with fully pressed pins.

[Merlijn Wissink]

Ok, I believe I found another 'bug':

when I change the orientation of a call-out in a submodel, it actually places/changes the command in the main model instead of in the submodel. Which means that when I have multiple call-outs in a single submodel, things keep getting changed. Lemme (try to) explain:

Let's say I have a example.mpd with a submodel subA which contains 2 other submodels subB and subC:
example.mpd
    subA.ldr
        subB.ldr
        subC.ldr

subB and and subC are both callouts. However, subB needs a horizontal orientation and subC needs a vertical orientation.
So, while formatting the instructions in LPub3D, I come across subB and I change it to horizontal. LPub3D however, places the '!LPUB CALLOUT ALLOC HORIZONTAL' in example.mpd instead of in subA. It still works as desired though, because LPub3D reads the file from top to bottom. But, then I come across subC. It needs to be vertical, so I change it to vertical. But, LPub3D just changes the command in example.mpd from horizontal to vertical, which means that subB is now also vertical again. You'd go back to subB, set it to horizontal again, but that changes subC again. It's an endless circle.

If LPub3D would just put the '!LPUB CALLOUT ALLOC [orientation]' in the subfile where the callout is, it would solve all problems. I'm currently adding these commands manually and it works like a charm.
I haven't investigated it very much though, so it might be a little different than how I've explained it.

Hope that makes sense 

[Willy Tschager]

Trevor,

I'm at a good point with the AIOI (glad I didn't have to add the vc2015) just extracting content from the zip. However the dialog for "Change log for 2.0.19" says:

Code:

Failed to open C:/Users/XXXX/Desktop/README.txt
No such file or directory

a copy of README.txt is present in the docs folder (I stripped the one in LPub3D_x32-2.0.19.877.2_20161208 folder in the zip as it would end up in the C:\Program Files (x86)\LDraw folder). I also checked the registry for a path but couldn't find any. The only source I found was:

Code:

 SetOutPath "$INSTDIR"
 File "..\docs\README.txt"

in your installer script. I therefore wonder why you would store a change log file on the Desktop and where I do change the search path?

w.

[Walt White]

Using the POV-Ray rendering in version 2.0.19 is _very_ slow generating the image for a Panel 1 x 2 x 2 - Hollow Studs — BrickLink part 4864b in color 47 trans clear.  It's OK; I have time; it's possibly a clue that my computer is maxed out somehow.  But eventually LPub3D crashes.

I'm building a chimney for a Great Ball Contraption ball pump and LPub3D can successfully generate a POV image with up to eight of those panels.  When adding more of them, LPub3D crashed and asked me to forward this dump file to the developers.

I'm going to experiment with using solid studs part 4864a and a more opaque color.

Walt

[Merlijn Wissink]

Ok, so I found another bug (kinda I think). And it would be great if you could quickly fix this one 

I want the placement of the step-number the same as in official instructions: under the parts list at the left side. So, I right-clicked the step number and positioned it at the bottom-left of the parts-list. But, then the part number went into the parts list. That's already wrong. Doesn't matter which position I chose relative to the parts-list, the part number always went to the top-left corner of the PLI.

I thought I could maybe fix it by changing the PLI position. I changed the PLI position from relative to the part-number to relative to the page (top-left corner). Then I changed the position of the step number again. Again, bottom-left relative to the PLI. But, now the part number constantly goes to the center of the page (whichever position relative to the PLI I choose) 

[Merlijn Wissink]

Today I fired up LPub3D and it said there was a new version available (2.0.20 I believe).  There was a button to view 'Whats new', but it had horrible formatting and was super tiny. So, I just pressed update and went online to find a better changelog. But I can't find any (in fact, the sourceforge page doesn't even show 2.0.20). Does anyone know the changelog? 

EDIT: nevermind, found it in the installation folder

[Trevor Sandy]

Noted - I'll take a look.

Cheers,

[Trevor Sandy]

Very well. I'll take a look.

Cheers,

[Trevor Sandy]

in your installer script. I therefore wonder why you would store a change log file on the Desktop and where I do change the search path?

Willy - Sorry for the delayed response

LPub3D does not store its README on the desktop. The README is stored at install_root and install_root/docs 

The 'Change log' dialogue on the Preferences form (and also on the Help->About LPub3D form) looks for the README at the current working directory (cwd.absolutePath()) - this defaults to where the LPub3d.exe is located.

I'm not sure how you got the response you did but I imagine you would have to run the LPub3D portable distribution from your desktop to get that response.

Code:

 SetOutPath "$INSTDIR"
 File "..\docs\README.txt"

This code is meaningless in your context. The first line instructs NSIS to set the working directory to where LPub3D will be installed. The second line defines where to find the README file for packaging in the NSIS installer.

You can follow the logic from these source files:

lpub_preferences.cpp

Code:

lpub3dPath = cwd.absolutePath();

preferencesdialog.cpp

Code:

QString readme = tr("%1/%2").arg(Preferences::lpub3dPath,"README.txt");

aboutdialog.cpp

Code:

QString readmeFile = QString("%1/%2").arg(Preferences::lpub3dPath).arg("README.txt");

Cheers,

[Trevor Sandy]

Using the POV-Ray rendering in version 2.0.19 is _very_ slow generating the image for a Panel 1 x 2 x 2 - Hollow Studs — BrickLink part 4864b in color 47 trans clear. 

Hello Walt. I'll take a look. However, note that LPub3D does not do any rendering, it is responsible only to send L3P the appropriate flags and part list to be rendered. L3P produces the .pov file which LPub3D then forwards to POV-Ray and waits for the POV-ray process result before attempting to consume the rendered image - get the size details, convert to pixmap and place in the document.

If you are experiencing excessive delay, the source is likely POV-Ray. However, it is a good idea to confirm the .pov file is well formed. The command line used to generate the pov image is captured in the .pov file and in the POV-Ray console during execution. You can use it to confirm the source of your delay.

Cheers,

[Trevor Sandy]

Interesting! I'll take a look in the coming days as time permit.

Cheers,

[Trevor Sandy]

Today I fired up LPub3D and it said there was a new version available (2.0.20 I believe).
...
But I can't find any (in fact, the sourceforge page doesn't even show 2.0.20).

This is because 2.0.20 was not released at that time

You received the new update prompt because I was testing the update capability for the new Linux/Mac distributions. In fact, the download could have actually been 2.0.19 even if the file name said otherwise.

It would be a good idea to update your installation with the LPub3D 2.0.20 I released today - some hours ago.

Cheers,

[Trevor Sandy]

Greetings,

LPub3D 2.0.20 is released.

This release introduces 4 new platform distributions for Mac OSX, Arch Linux, Debian/Ubuntu Linux, and SUSE/Fedora/Red Hat Linux.

You can download this release from sourceforge.net or check for updates in your existing installation.

Available binary downloads:
Mac OSX:                                  DMG Package 64bit [Updated!]
Windows (Installed):                 Win Installer 32/64bit
Windows (Portable):                 Win Zip Archive 32bit
Windows (Portable):                 Win Zip Archive 64bit
Arch Linux:                               PKG.tar.xz Package 64bit
Red Hat/Fedora/SUSE Linux:    RPM Package 64bit
Ubuntu/Debian Linux:              DEB Package 64bit

It is also possible to build LPub3D Mac and Linux distribution packages from source by running a single shell script.

LPub3D source (master branch) is now available on Github at https://github.com/trevorsandy/lpub3d.

Change Log: 
LPub3D 2.0.20.0.645 
 
Features and enhancements 
------------ 
Fix: Introducing LPub3D ports for Linux (Debian, Red Hat and Arch based distros) and Mac (OSX). [0853680] 
 * LPub3D is now available across Windows, Linux and Mac platforms. The LPub3D package can be accessed via direct download from sourceforge.net and is available in .dmg (OSX), .rpm (Red Hat) 
   .deb (Debian) and .pkg.tar.xz (Arch) formats. Additionally, LPub3D can be built directly from source with the provided .spec, Debian configuration files or PKGBUILD build 
   configuration files. LPub3D source for building Linux distros is available at https://github.com/trevorsandy/lpub3d; LPub3D source also remains available at http://sourceforge.net/p/lpub3d/code/. 
Fix: When the preferred renderer is manually typed into the preference dialogue, it is not validated upon exit of the preferences dialogue.  [44548f4] 
 * This behaviour has been corrected. Manually entered preferred render path is validated when the preference dialogue is closed. 
Fix: Automatically load LDraw archive libraries on initial application launch. [ff06bc9] 
 * To further improve the user experience at initial application launch. When LPub3D is loaded for the first time, it there are no archive libraries in at the user's application data path. LPub3D will automatically install the libraries packaged in the distribution. 
Fix: Update QuaZip library to v0.7.2 
 * Improve robustness. 
Fix: Enable and correct menu shortcuts.  [48ca363] 
 * LPub3D menu item keyboard shortcuts have been repositioned to allow both Editor, and 3DViewer's short cuts to reside on the main menu tool-bar. This redesign allows for more seamless integration on OSX and some Linux distros - e.g. Debian. 
   Additionally, all available LPub3D menu item short cuts are now enabled. Here are the new mappings: 
 
   Main Page Design 
Open                         = Ctrl+O 
Save                          = Ctrl+S 
Print File                    = Ctrl+T (Currently Disabled) 
CloseFile                    = Ctrl+X 
First Page                  = Ctrl+P 
Last Page                  = Ctrl+L 
Previous Page           = Ctrl+E 
Next Page                 = Ctrl+N 
Export Bmp              = Alt+B 
Export Png               = Alt+N 
Export Pdf                = Alt+F 
Export Pdf Preview   = Alt+P 
Export Jpg               = Alt+J 
Fit Page Width         = Alt+W 
Fit Page Visible         = Alt+V 
Actual Size                = Alt+A 
Redo                        = Ctrl+Y (Also affects LDraw Editor Menu) 
Undo                        = Ctrl+Z (Also affects LDraw Editor Menu) 
Exit Application         = Ctrl+Q 
 
  LDraw Editor Menu 
Cut                           = Ctrl+X 
Paste                        = Ctrl+V 
Copy                         = Ctrl+C 
Select All                   = Ctrl+A 
Redraw                     = Ctrl+R 
Find                          = Ctrl+F 
Delete                       = DEL 
 
  Parameter Editor Menu 
Cut                           = Ctrl+X 
Paste                        = Ctrl+V 
Copy                        = Ctrl+C 
Select All                  = Ctrl+A 
Save                        = Ctrl+S 
Find                         = Ctrl+F 
Undo                       = Ctrl+Z 
Redo                       = Ctrl+Y 
Delete                      = DEL 
 
  3D Viewer Menu 
Insert ROTSTEP       = Shift+O 
ROTSTEP Absolute   = Shift+B 
ROTSTEP Relative    = Shift+E 
Select                       = Shift+S 
Zoom                       = Shift+Z 
Zoom Region           = Shift+G 
Rotate Camera View = Shift+T 
Pan                          = Shift+P 
Select Invert             = Ctrl+Shift+I 
Save As                    = Ctrl+Alt+S 
Find                         = Ctrl+Shift+F 
Copy                        = Ctrl+Shift+C 
Select All                  = Ctrl+Shift+A 
Hide Selected           = Ctrl+H 
Hide Unselected       = Ctrl+Shift+H 
Unhide All                = Ctrl+U 
Unhide Selected       = Ctrl+Shift+U 
Undo                       = Ctrl+Shift+Y 
Redo                       = Ctrl+Shift+Z 

Cheers,

[Jaco van der Molen]

Greetings,

LPub3D 2.0.20 is released.

This release introduces 4 new platform distributions for Mac OSX, Arch Linux, Debian/Ubuntu Linux, and SUSE/Fedora/Red Hat Linux.

You can download this release from sourceforge.net or check for updates in your existing installation.

Available binary downloads:
Mac OSX:                                  DMG Package 64bit

Hi Trevor,

It has been a while since I've been here, read or posted.
Reading this is good news!
I'll take a look at the Mac version.

Jaco

[Jaco van der Molen]

Hi Trevor,

Just installed LPub3D on Mac. Which was a pain (sorry)...

Finding the LDraw folder was no problem, but then I got the first error:

  Schermafbeelding 2017-02-12 om 11.57.13.png (Size: 37.96 KB / Downloads: 289)

With the LPub3D logo right on top of it. Had to switch to finder to be able to click the OK button.

Next:

  Schermafbeelding 2017-02-12 om 11.51.24.png (Size: 41.72 KB / Downloads: 289)

Then the settings dialog:
   


Also difficult to find and choose LDView as my renderer.

Done that, I opened a first model.
Again the dialogs

  Schermafbeelding 2017-02-12 om 11.57.13.png (Size: 37.96 KB / Downloads: 289)
  Schermafbeelding 2017-02-12 om 11.51.24.png (Size: 41.72 KB / Downloads: 289)
With every step rendered.

Then, quitting LPub3D and starting again, I had to do all settings again.

Perhaps something is wrong on my machine but do you have any idea what can be done?

[Trevor Sandy]

Perhaps something is wrong on my machine but do you have any idea what can be done?

Hi Jaco,

Interesting, the behaviour you are experiencing should not be so under a normal scenario.

Basically, during launch LPub3D is looking for it's AppData store (at the location indicated in the response message) but somehow it is not there. The strange part is LPub3D will normally create the AppData store and populate it with the required content during application launch if it is not detected. So it looks like your installation is not able to create and populate the AppData content during application launch.

The AppData content is archived during the application installation at '/Applications/LPub3D.app/Contents/Resources'.

You can manually copy and paste this content from the archive location to the AppData location. Be sure to put the archive libraries under '/Users/jaco/Library/Application Support/LPub3D Software/LPub3D/libraries'.

I didn't add any logic to hide the splash screen during AppData population as this is not supposed to fail. However, I'll revisit this since that premise is obviously false.

About trying to find LDraw directory, the behaviour is to automatically look at /Users/jaco/Library/LDraw, then /Library/LDraw, then prompt the user to enter a valid LDraw path. If the entered/selected path is not valid, then you will receive a message to exit or continue. Continuing will restart the logic to find a valid LDraw directory as described above. When prompted, the splash screen should be hidden from view.

I tested this routine multiple time so it's surprising to see it's failing. I'll check once again as I'm updating the packaging process for open build service implementation.

Let me know if you environment is unusual in any way or if you performed/encountered any non-standard behaviour during installation. This way I can treat any exceptions accordingly.

Cheers,

[Jaco van der Molen]

I manually create the folders and put the files in. But apparently not in the right folder.
Since my Mac is localized as a Dutch machnine, I thought the "/Users/jaco/Library/" part would translate to "Gebruikers/jaco/Bibliotheek".

Somehow, I still was able to find /Users/jaco/Library/Application Support/LPub3D Software/LPub3D/libraries


There were no files titleAnnotations.lst and pliSubstituteParts.lst in the LPub3D package, so I copied them from my Windows installation.
I also missed the freeformAnnotations.lst.

So, still I am unsure how I did it, but it seems LPub3D can fine the .lst files now.

Now for the settings: they are not kept.

Rendering a model works fine now. But every time I have to look for LDView...

[Trevor Sandy]

Thanks for the update.

There were no files titleAnnotations.lst and pliSubstituteParts.lst in the LPub3D package, so I copied them from my Windows installation.
I also missed the freeformAnnotations.lst.

So it looks like the parameter files are missing - this explains why they were not written. I'll take a look at the build to see if there was  problem I missed  

Now for the settings: they are not kept.

Rendering a model works fine now. But every time I have to look for LDView...

This one is a bit strange. Perhaps these anomalies are linked to mis-matched localization (Dutch/English)  ? Are the application parameters written to

Code:

~/Library/Preferences/

? I don't remember exactly the plist names but they should all include lpub3d...


For your installation, did the 

Code:

/Applications/LPub3D.app/Contents/Resources

folder contain any files at all ? It's quite strange because if those parameter files were not packed, the packaging process should fail - it did not

Cheers,

[Jaco van der Molen]

This is the LPub3D package content:
   

I cannot seem to find any reference to LPub3D preferences.

[Trevor Sandy]

This is the LPub3D package content:
I cannot seem to find any reference to LPub3D preferences.

You are correct ! My apologies I just took a look at the build archive and concluded the same !

I only see the following:

1. excludedParts.lst
2. fadeStepColorParts.lst
3. pli.mpd

Missing are:

1. freeformAnnotations.lst
2. pliSubstituteParts.lst
3. titleAnnotations.lst
4. LDConfig.ldr

I'm not sure what happened with my packaging solution, but it apparently only packed half of the required files.

As you already know, the work-around here is to manually copy the missing files into LPub3D.app/Contents/Resources or
~/Library/Application Support/LPub3D Software/LPub3D/extras.

Regarding the splash screen. for future reference. I you are blocked by it, just click on any other open window/document on the screen and the OS will automatically hide the splash as the other component takes focus. It will come back when you click on the 'covered dialogue' but the dialogue will still take your action to move/close whatever.

I'll publish a corrected release shortly - possibly before tomorrow.

Cheers,

[Trevor Sandy]

The Mac OSX dmg package is fixed. All parameter files are present.

Cheers,

[Merlijn Wissink]

So, is it possible to implement something like that in LPub3D?

Indeed, it's possible and somewhat straightforward to do too. Instead of automatically resetting the step number at every new submodel (or callout), I can add a preference setting to optionally reset or not.

For LPub3D 2.1 and beyond, there are already quite a few interesting new features coming from the Porsche GTS instructions book, I'll add this one also.

Cheers,

Any update on the continued step number? I'm not in a hurry or anything, but it seems to be a much wanted feature. I've already heard multiple people looking for this feature in the past few weeks alone. 

[Jaco van der Molen]

The Mac OSX dmg package is fixed. All parameter files are present.

Cheers,

OK, thanks. I'll take a look.

Settings are still not kept by the way. Perhaps it is my Machine?

[Merlijn Wissink]

I believe I found a new bug.

I have an LDraw file which starts at portrait, then goes to landscape and then to portrait again.
It looks perfectly fine in the LPub3D editor. But, when I export, it switches to landscape 1 page to early. It does switch back to portrait at the right page though.

It's kinda confusing, because the editor shows one thing, while the export does the other thing.

[Merlijn Wissink]

I have the feeling this problem is kinda related to the one above. I have a 'raw' LDraw file without any LPub commands. I open it in LPub3D and set the page to A4 landscape. Everything looks fine in the editor, but the exported pdf is in A4 portrait   

Not the whole pdf though, the very last page is in landscape. The LDraw is still a WIP. It has a bunch of submodels that are all thrown together in the main model at the last page (so the main model has just 1 'step'). The instructions start at a submodel. Maybe that has something to do with the problem?

Also, the pdf is in portrait mode, but you can clearly see that the thing it was trying to export was landscape and has been cut off to portrait again.

The weirdest thing to me still, is how the editor can show the page correctly in landscape, while the pdf export is in portrait. How does that happen?

[Merlijn Wissink]

I'm still waiting for the 'continuous step-number'. So step numbers don't reset for every submodel but keep on counting (except for call-outs).

I believe this has been asked before, but if this feature can be released within a few weeks that would be a godsend. I could use it very well for a project I'm working on.

It seems like Trevor hasn't been online here anymore for quite some time. I figured I could take a look at the source code myself and I actually got a (very) vague idea of where to (possibly) make such a change. But I've almost never used c++ and I don't know all the ins and outs of compiling and building the actual application. It also needs the qt stuff and all of that and I have no idea how to use that either.

So, if someone could add this feature I would be eternally grateful