LPub3D 2.0 Released

[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,