LPub3D 2.0 Released

[Trevor Sandy]

Ok. So, I updated to this new version yesterday and I'm now experiencing something very weird.
Whenever I start the computer, a windows explorer window opens (after Windows login of course) into the folder: C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp\LPub3D which contains 2 shortcuts to open or uninstall LPub3D.

First off: why does it open?
Secondly: why is LPub3D doing anything after boot anyway? It's not a service or anything 

Merlijn,

The icons your see are in your startup folder. This means when you start the computer they will display. LPub3D is not doing anything. The operating system manages the startup behavior - starting (or displaying) whatever is in the startup folder.

You can just remove/move them to where you want if you are not pleased with this behavior. Actually, it was unintentional. I was looking for a solution to install icons for standard users during installation. Normally, the icons should be deposited in the start menu programs. This is where they will continue to be deposited in version 2.0.5.

Cheers,

[Trevor Sandy]

For me the crash is completely consistent. Just have to fire LPub3D, then close it. No need to open/render a file. OS: Win7Pro SP1.

Ok thanks Philo. I'm going to setup a Win7 VMWare environment to see if I can make some progress on this.

Cheers,

I performed the test with a virgin install of Windows 7 (IE10) x32 and I could not reproduce this behaviour. For me the application performed as expected throughout.

Here is a video of the test for your review.

Cheers,

 Sorry i should have precised that I use 64 bits version. And it was not a fresh install but an update from previous version. Dunno if it makes difference...

I was trying to get my hands on an x64 build but I couldn't find it amongst the images MS makes available.

One thing you could try is to backup and then complete delete the registry key for LPub3D Software. Then backup and delete all the user data (...user/appdata/local/LPub3D Software/LPub3D). Install a fresh copy of 2.0.4 - without electing to install user data during installation. Once the installation is finished, launch the application and select copy to setup a fresh copy your user data. 

If there are settings your wanted to preserve in your parameter files (annotations etc...), just copy the specific backed up files overwriting the installed versions. For your custom library items, it is recommended to keep these items in your LDraw directory - under the Unofficial directory or in the Models directory. With this configuration, every time LPub3D starts, it will look to integrate any custom items into the LPub3D unofficial library archive file. This way, you can wipe out the LPub3D library archives as you want and not lose your custom content.

If you try this approach, let me know if your crash on end behavior still exist.

Cheers,

[Jaco van der Molen]

- When I close LPub3D it crashes. Settings are not saved.

I think you may like that it is now possible to freely move callouts on a multi-step page. For me, that was a nice one to do.

Oh, I see now. And the arrows are placed correct too! Great!

Philo also reported the crash on close. This behavior is hard for me to track down as I am on Windows 10 and I have not experienced it - at all. Can you tell me if the crash is consistent, i.e. crashes every time you exit the application or intermittent ? What is your operating system version ?

I am on Windows 7 professional sp1 and crash if every time I close LPub3D.

[Aleksandr Balbatunov]

I've installed 2.0.4 MinGW version, which is already good. Unfortunately it doesn't start. The error it gives me states:

Code:

This application failed to start because it could not find or load the
Qt platform plugin "windows".

Reinstalling the application may fix the problem.

Please note I've been using 64-bit version previously. So if there is anything that had to be installed previously - it is not.

[Willy Tschager]

I have repackaged the distributions to deploy the required Qt MSVC plugins and automatically detect and install the MS VC++ runtime dependencies.

Just installed LPub3D-2.0.4.737.2_20160702 to have a first look around for the upcoming AIOI. Win10 reports the following .dll missing:

VCRUNTIME140.dll
MSVCP140.dll

w.

BTW: How do I divide a large BOM over several pages. Say you'll list the BOM for the Cafe Corner?

[Trevor Sandy]

For me the crash is completely consistent. Just have to fire LPub3D, then close it. No need to open/render a file. OS: Win7Pro SP1.

Ok thanks Philo. I'm going to setup a Win7 VMWare environment to see if I can make some progress on this.

Cheers,

I performed the test with a virgin install of Windows 7 (IE10) x32 and I could not reproduce this behaviour. For me the application performed as expected throughout.

Here is a video of the test for your review.

Cheers,

 Sorry i should have precised that I use 64 bits version. And it was not a fresh install but an update from previous version. Dunno if it makesa difference...

Philo, what was your previous version of LPub3D? Thanks.

Cheers,

[Trevor Sandy]

- When I close LPub3D it crashes. Settings are not saved.

I think you may like that it is now possible to freely move callouts on a multi-step page. For me, that was a nice one to do.

Oh, I see now. And the arrows are placed correct too! Great!

Philo also reported the crash on close. This behavior is hard for me to track down as I am on Windows 10 and I have not experienced it - at all. Can you tell me if the crash is consistent, i.e. crashes every time you exit the application or intermittent ? What is your operating system version ?

I am on Windows 7 professional sp1 and crash if every time I close LPub3D.

Jaco - are you installing under a standard user or user with admin-level access ? What was your previous version of LPub3D ? Thanks.

[Philippe Hurbain]

Philo, what was your previous version of LPub3D? Thanks.

Sorry - can't remember. A recent one for sure, probably the one just before 2.0. I meant to make more tests (clean install), but didn't and will not be able to do so before some time

[Trevor Sandy]

I've installed 2.0.4 MinGW version, which is already good. Unfortunately it doesn't start. The error it gives me states:

Code:

This application failed to start because it could not find or load the
Qt platform plugin "windows".

Reinstalling the application may fix the problem.

Please note I've been using 64-bit version previously. So if there is anything that had to be installed previously - it is not.

Aleksandr,

This behavior should not be happening under an expected installation approach. Here is what I mean:

You have 2 options to install LPub3D - one by using the NSIS installer-packaged distribution and the other is just to unzip the 'portable' distribution (.zip).

For both cases, you will notice under the root install directory there is a 'plugin' directory called 'platforms' and within that directory there is a 'qwindows.dll'.

If your distribution was successfully installed or unzipped you should no be experiencing the missing plugin behaviour since the plugin is in fact not missing.

If you were previously running the installer-packaged x64 MSVC distribution (of version 2.0.3 let's say), I would recommend a you do a complete uninstall before installing the installer-packaged MinGW distribution. However, you can test the MinGW installation by just unzipping the portable distribution and launching the exe.

Let me know if your are still experiencing this message after following an expected installation approach.

Cheers,

[Trevor Sandy]

I have repackaged the distributions to deploy the required Qt MSVC plugins and automatically detect and install the MS VC++ runtime dependencies.

Just installed LPub3D-2.0.4.737.2_20160702 to have a first look around for the upcoming AIOI. Win10 reports the following .dll missing:

VCRUNTIME140.dll
MSVCP140.dll

w.

BTW: How do I divide a large BOM over several pages. Say you'll list the BOM for the Cafe Corner?

I can think of only one scenario where you can experience this behavior which is if you select the MSVC 'portable' distribution - the one that does not have MinGW in the name :-) - unzip the archive, and proceed directly to launch the LPub3D executable. 

Under this approach you would have missed the prerequisite of installing the Visual Studio 2015 runtime. If you look in the installation root directory, you will see vc_redist.x86[64].exe. It is necessary to manually install the contents of this package (or have a previous installation) before running LPub3D from a portable distribution.

With the NSIS installer-packaged distribution, the installer will automatically look in your System32 directory for vcruntime140.dll. If it is not found, the installer will proceed to install vc_redist.x86[64].exe. You can see the details of this activity if you select to show details during the install files dialog when the installer is running.

I have updated sourceForge with the source for version 2.0.4. You can look under tools/Win-setup to find '00 BuildLPub3D00AndCreateDistNoPack.bat' and 'LPub3DNoPack.nsi'. These are the scripts used to package all distributions of LPub3D and should help you with your AIOI packaging - particularly the latter script.

Let me know if this information resolves your issue.

To divide a bom, simply right click the BOM and select 'Split Bill of Materials' from the context menu. See image.
   

Cheers,

[Trevor Sandy]

I am not able to reproduce the crash on launch or crash on exit in my Windows 7 tests but I believe I know what may be causing them  in your installation. 

Please follow the instructions in this video [color=#7e57c2]LPub3D-Win7 Delete RegKey MainWindow and let me know if this helps with the crash on launch. This update is applicable to users updating from earlier versions of LPub3D only.[/color]

It could also be helpful to refresh and centralize your user data under the default LPub3D location. This will be done automatically if the existing locations are renamed (then deleted if you desire). You can see this behavior in video [color=#7e57c2]LPub3D-Win7 Refresh User Data. Please note that this type of refresh is only available with version 2.0.4 and later. This tip is useful to ensure that standard Windows 7 users are properly configured to run LPub3D.[/color]

I've also published 2 videos which show a virgin install and update from 1.3.5 on Win7:
- [color=#7e57c2]LPub3D-Win7 Virgin Install[/color]
- [color=#7e57c2]LPub3D-Win7 Update From Version 1.3.5 To 2.0.4[/color]

Cheers,

[Aleksandr Balbatunov]

Thanks for your patience helping to deal with my uncommon configuration.

So I've tried both MinGW files - the installer and portable versions and did a bit more of investigation.

Installer executes successfully, however generates error I've mentioned before upon launch. It turns out LPub3D v2.x doesn't like to be launched as Win7 emulated application (worked fine with v1.x though), but doesn't generate the error with WinXP emulatation. Running *.exe file later shows application interface for a second and disappear. Launching app from Windows command line generates the following error:

Code:

QWidget::repaint: Recursive repaint detected

Linux console mentions more details:

Code:

err:module:import_dll Library Qt5Svg.dll (which is needed by L"Z:\\home\\zux\\.wine\\drive_c\\Program Files (x86)\\LPub3D\\imageformats\\qsvg.dll") not found
...
err:seh:raise_exception Unhandled exception code c0000005 flags 0 addr 0x7ca7696

Last line appears at the moment app crashes.

Portable version has same stuff with Win7/WinXP emulation, but it is not a big issue. However it asks for "Data directory installation folder" to be created outside/inside Program files / (x86)" and fails in both (Yes/No) cases. "No" selection does nothing and simply terminates the application, while "Yes" gives same errors as installable version above.

[Jaco van der Molen]

Jaco - are you installing under a standard user or user with admin-level access ? What was your previous version of LPub3D ? Thanks.

Installing as user but have full admin rights.
I can't recall my previous version, but it must have been the latest one before 2.0, since I always updated.

New problem: on my WinXP machine, LPub3D does not start saying LPub3D_x32.exe is not a valid Win32 application.

[Willy Tschager]

Under this approach you would have missed the prerequisite of installing the Visual Studio 2015 runtime. If you look in the installation root directory, you will see vc_redist.x86[64].exe. It is necessary to manually install the contents of this package (or have a previous installation) before running LPub3D from a portable distribution.

With the NSIS installer-packaged distribution, the installer will automatically look in your System32 directory for vcruntime140.dll. If it is not found, the installer will proceed to install vc_redist.x86[64].exe. You can see the details of this activity if you select to show details during the install files dialog when the installer is running.

I have updated sourceForge with the source for version 2.0.4. You can look under tools/Win-setup to find '00 BuildLPub3D00AndCreateDistNoPack.bat' and 'LPub3DNoPack.nsi'. These are the scripts used to package all distributions of LPub3D and should help you with your AIOI packaging - particularly the latter script.

Hi Trevor,

many thanks for the insight. I'll see if the:

IfFileExists "$Windir\System32\vcruntime140.dll"

is enough or if the installer prog I work with comes with some additional tricks.

Looking through the script I noticed that you install a "lpub3dldrawunf.zip". I presume it is a copy of the ldrawunf.zip. You will surely have noticed that we do not distribute "unofficials" along with the LDraw Parts Library or in the AIOI, but just offer the download with the appropriate warning because of their delicate nature. The .zip comes with no license and is not meant to be redistributed as the official library.

w.

[Trevor Sandy]

Jaco - are you installing under a standard user or user with admin-level access ? What was your previous version of LPub3D ? Thanks.

Installing as user but have full admin rights.
I can't recall my previous version, but it must have been the latest one before 2.0, since I always updated.

New problem: on my WinXP machine, LPub3D does not start saying LPub3D_x32.exe is not a valid Win32 application.

I don't think I setup my VS2015 IDE to comply with WindowsXP. At any event. I'm sure i'll have to add more dlls to bring the distribution into compatability with XP.

In your opinion, is it necessary to spend time to produce this port ? After all, WindowsXP is very old.

P.S. I was thinking you could try the MinGW distribution. It does not depend on the MSVC runtime which is most likely the cause of your message. Let me know if it works for you on XP ?

Cheers,

[Trevor Sandy]

Thanks for your patience helping to deal with my uncommon configuration.

So I've tried both MinGW files - the installer and portable versions and did a bit more of investigation.

Installer executes successfully, however generates error I've mentioned before upon launch. It turns out LPub3D v2.x doesn't like to be launched as Win7 emulated application (worked fine with v1.x though), but doesn't generate the error with WinXP emulatation. Running *.exe file later shows application interface for a second and disappear. Launching app from Windows command line generates the following error:

Code:

QWidget::repaint: Recursive repaint detected

Linux console mentions more details:

Code:

err:module:import_dll Library Qt5Svg.dll (which is needed by L"Z:\\home\\zux\\.wine\\drive_c\\Program Files (x86)\\LPub3D\\imageformats\\qsvg.dll") not found
...
err:seh:raise_exception Unhandled exception code c0000005 flags 0 addr 0x7ca7696

Last line appears at the moment app crashes.

Portable version has same stuff with Win7/WinXP emulation, but it is not a big issue. However it asks for "Data directory installation folder" to be created outside/inside Program files / (x86)" and fails in both (Yes/No) cases. "No" selection does nothing and simply terminates the application, while "Yes" gives same errors as installable version above.

Aleksandr - thanks for the detail description of your issues. 

I've fixed the "Data directory installation" behavior. Actually, I changed it to be more automated. Look for it in version 2.0.5.

I imagine the qwindows.dll plugin message is linked to the version of Qt i'm using and Wine since the plugin is not missing but cannot be found and the problem is only present on Win7 and not WinXP. I'm not sure what I can do about this but I'll continue to track this issue.

I've attached the qt5svg.dll. Unzip and put it in the root installation folder and let me know if it resolves your dependency messages. In fact, qsvg.dll which is generating this dependency is not required by LPub3D - if your remove it, LPub3D should execute without issues. However, Qt's Windows deployment tool list all 'possible' dependencies and qsvg.dll is one of them so I included it in the distribution to be safe. You can try running your configuration without it and qt5svg.dll.


  Qt5Svg.zip (Size: 121.88 KB / Downloads: 1)

Looking at the videos in my previous post, you can use the v2.0.4 portable distribution to test the addition/removal of the dlls by following the steps to refresh the user data directory or your can wait for 2.0.5 which will be released sometime today.

Cheers,

[Trevor Sandy]

Under this approach you would have missed the prerequisite of installing the Visual Studio 2015 runtime. If you look in the installation root directory, you will see vc_redist.x86[64].exe. It is necessary to manually install the contents of this package (or have a previous installation) before running LPub3D from a portable distribution.

With the NSIS installer-packaged distribution, the installer will automatically look in your System32 directory for vcruntime140.dll. If it is not found, the installer will proceed to install vc_redist.x86[64].exe. You can see the details of this activity if you select to show details during the install files dialog when the installer is running.

I have updated sourceForge with the source for version 2.0.4. You can look under tools/Win-setup to find '00 BuildLPub3D00AndCreateDistNoPack.bat' and 'LPub3DNoPack.nsi'. These are the scripts used to package all distributions of LPub3D and should help you with your AIOI packaging - particularly the latter script.

Hi Trevor,

many thanks for the insight. I'll see if the:

IfFileExists "$Windir\System32\vcruntime140.dll"

is enough or if the installer prog I work with comes with some additional tricks.

Looking through the script I noticed that you install a "lpub3dldrawunf.zip". I presume it is a copy of the ldrawunf.zip. You will surely have noticed that we do not distribute "unofficials" along with the LDraw Parts Library or in the AIOI, but just offer the download with the appropriate warning because of their delicate nature. The .zip comes with no license and is not meant to be redistributed as the official library.

w.

Willy - Indeed, I use 2 archive library files, complete.zip which I use as-is, and lpub3dldrrawunf.zip which is used to store all non-official content. This includes generated fade files, custom part 'assemblies', or any content found within the LDraw\Unofficial directory (other than parts under 'p' or 'parts' subdirectories). Keep in mind the purpose of LPub3D is to generate instructions so, I have found, sometimes it's necessary to create custom part configurations.

Of course I could use an empty archive file with just the folder structure (no LDraw unofficial content) whereby the user can choose to pull single files or whatever into their archive by simply placing them at the appropriate location under their Unofficial directory; however, to keep the behaviour efficient, I load the full archive. There is functionality form the UI menu to update the archive files, in their entirety, at any time which will allow the user to sync with LDraw anytime they want.

I'm not sure I understand everything about all the sensitivity and licensing stuff. For me, the content is freely available, and it adds efficiency to include it in the package. Of course, as you have said, there are pitfalls with the unofficial content so it's inclusion must be done in a way that maintains flexibility, exclusion from official content and efficient update.

Cheers,

[Trevor Sandy]

Greetings,

LPub3D 2.0.5 has been released.

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

LPub3D 2.0.5.744.3 
 
Features and enhancements 
------------ 
-Fix: Portable distribution create and populate user data directory when installed under Program Files/(x86) (r744) 
-Fix: Revert to deposit LPub3D icons in Programs menu (versus startup menu) (r743) 
-Fix: Remove MAINWINDOW registry group if exist (r742) 
 *I believe the settings in this group are contributing to the intermittent crash at startup. 
-Fix: LDConfig load order; first, LDraw directory; second, extras directory; third, resource cache (r741) 
-Fix: Automatically load ldglite during installation/application launch (r740) 

Cheers,

[Jaco van der Molen]

Jaco - are you installing under a standard user or user with admin-level access ? What was your previous version of LPub3D ? Thanks.

Installing as user but have full admin rights.
I can't recall my previous version, but it must have been the latest one before 2.0, since I always updated.
New problem: on my WinXP machine, LPub3D does not start saying LPub3D_x32.exe is not a valid Win32 application.

I don't think I setup my VS2015 IDE to comply with WindowsXP. At any event. I'm sure i'll have to add more dlls to bring the distribution into compatability with XP.
In your opinion, is it necessary to spend time to produce this port ? After all, WindowsXP is very old.
P.S. I was thinking you could try the MinGW distribution. It does not depend on the MSVC runtime which is most likely the cause of your message. Let me know if it works for you on XP ?

I know XP is old, but also know that many machines still run it.
Do I just install MinGW?

[Jaco van der Molen]

Please follow the instructions in this video [color=#7e57c2]LPub3D-Win7 Delete RegKey MainWindow and let me know if this helps with the crash on launch. This update is applicable to users updating from earlier versions of LPub3D only.[/color]

I do not have the RegKey MainWindow, so cannot delete it.
Updating to 2.0.5 does not help either.
Still crashing after quit on win 7.

[Trevor Sandy]

Jaco - are you installing under a standard user or user with admin-level access ? What was your previous version of LPub3D ? Thanks.

Installing as user but have full admin rights.
I can't recall my previous version, but it must have been the latest one before 2.0, since I always updated.
New problem: on my WinXP machine, LPub3D does not start saying LPub3D_x32.exe is not a valid Win32 application.

I don't think I setup my VS2015 IDE to comply with WindowsXP. At any event. I'm sure i'll have to add more dlls to bring the distribution into compatability with XP.
In your opinion, is it necessary to spend time to produce this port ? After all, WindowsXP is very old.
P.S. I was thinking you could try the MinGW distribution. It does not depend on the MSVC runtime which is most likely the cause of your message. Let me know if it works for you on XP ?

I know XP is old, but also know that many machines still run it.
Do I just install MinGW?

Ok.

[Trevor Sandy]

Please follow the instructions in this video [color=#7e57c2]LPub3D-Win7 Delete RegKey MainWindow and let me know if this helps with the crash on launch. This update is applicable to users updating from earlier versions of LPub3D only.[/color]

I do not have the RegKey MainWindow, so cannot delete it.
Updating to 2.0.5 does not help either.
Still crashing after quit on win 7.

Ok, Thanks! This issue is quite common (3 people reporting it). I don't understand how come I can't reproduce it on my test environment. Anyway, if you're still experiencing it with the MinGW build, I imagine the only other variable that changed is the version of Qt (to v5.x) so i'll start looking there. 

From the dump files i've received, the crash is pointing to ntdll.dll. This means it could be anything but most likely i've written something that throws Qt/Windows out of sync causing a segmentation fault down in the Qt stack somewhere. 

I'll keep looking.

Cheers,

[Merlijn Wissink]

I've maybe found a bug, but I'm not sure.

It looks like the callout placement relative to the assembly on a multi-step page doesn't work properly. It always aligns to the outside of the assembly, not the insdie. No matter if I choose from the inner square (on the dialog).

So, when I choose Top from the inner square, it actually does to Top:Center from the out square. The same with Right and Right:Center etc. etc.

I haven't tested it very extensive though.

[Trevor Sandy]

I've maybe found a bug, but I'm not sure.

It looks like the callout placement relative to the assembly on a multi-step page doesn't work properly. It always aligns to the outside of the assembly, not the insdie. No matter if I choose from the inner square (on the dialog).

So, when I choose Top from the inner square, it actually does to Top:Center from the out square. The same with Right and Right:Center etc. etc.

I haven't tested it very extensive though.

Merlijn,

I couldn't reproduce the behaviour you described.

For me the behaviour is as expected. How is your behaviour different from this video demonstration ?

Cheers,

[Merlijn Wissink]

I've maybe found a bug, but I'm not sure.

It looks like the callout placement relative to the assembly on a multi-step page doesn't work properly. It always aligns to the outside of the assembly, not the insdie. No matter if I choose from the inner square (on the dialog).

So, when I choose Top from the inner square, it actually does to Top:Center from the out square. The same with Right and Right:Center etc. etc.

I haven't tested it very extensive though.

Merlijn,

I couldn't reproduce the behaviour you described.

For me the behaviour is as expected. How is your behaviour different from this video demonstration ?

Cheers,

I did watch your video and now I start to doubt myself though. What exactly is the (intended) difference between the inner square and the outer square on the dialog? Just to be sure.

Sorry for the 'late' reply. I was a bit busy. I'll retry and get back to you tomorrow.

[Merlijn Wissink]

Ok, so I've tested it more and to me it looks like I indeed found a bug.

I thought that the inner square in the 'Placement Dialog' represents the object that you want to place relative to. Most of the time it is the 'Assem' when working with a callout.
So, when I move a callout (relative to the assembly) to Top/Right in the inner square, I expected it to go to the top right of the assembly (so it's on the assembly). When I set it to Top/Right on the outer square, I expected it to go the top-right outside of the assembly (so lining the bottom-left corner of the callout with the top-right corner of the assembly).

As it is now, Top/Right in the inner and outer square do exactly the same, always positioning outside the assembly, but only on a multi-step page. When doing the same thing with the same callout on a single step page, it actually behaves differently when selecting Top/Right on the inner square or the outer square (which is correct).

I actually tried this in the old original LPub and it behaves exactly as LPub3D does now, so it's either a very old bug or I'm expecting behavior that I shouldn't expect. What do you think?

Btw, maybe I explained it a bit vague. Just let me know and I'll make a video or something to try explaining it better

[Trevor Sandy]

Ok, so I've tested it more and to me it looks like I indeed found a bug.

I thought that the inner square in the 'Placement Dialog' represents the object that you want to place relative to. Most of the time it is the 'Assem' when working with a callout.
So, when I move a callout (relative to the assembly) to Top/Right in the inner square, I expected it to go to the top right of the assembly (so it's on the assembly). When I set it to Top/Right on the outer square, I expected it to go the top-right outside of the assembly (so lining the bottom-left corner of the callout with the top-right corner of the assembly).

As it is now, Top/Right in the inner and outer square do exactly the same, always positioning outside the assembly, but only on a multi-step page. When doing the same thing with the same callout on a single step page, it actually behaves differently when selecting Top/Right on the inner square or the outer square (which is correct).

I actually tried this in the old original LPub and it behaves exactly as LPub3D does now, so it's either a very old bug or I'm expecting behavior that I shouldn't expect. What do you think?

Btw, maybe I explained it a bit vague. Just let me know and I'll make a video or something to try explaining it better

Merlijn,

For me, the placement behaviour is as expected. Perhaps you should make a video to precise your point.

Indeed, the inner and outer placement commands represent perimeters that you can place your content relative to.

For example, it would not make sense to place content relative to the page using the outer placement commands. On the other hand, it would not make sense to use the inner placement commands to place content relative to the step number. In fact, these examples are strictly controlled and if you select page, the outer commands are disabled. If you select step number, the inner commands are disabled. 

For an assem[bly] however, both outer and inner commands are enabled because while most of the time it is likely content will be placed outside the assem border; however, there are times when content may have to be placed inside. An example of placing content inside the assem's border is when a very large assem consumes the entire page so placing a callout would have to use the inner placement commands.

Keep in mind that once the item is placed inside the assem's border the border is recalculated to account for dimensions of the added item. 

Cheers,

[Trevor Sandy]

Greetings,

LPub3D 2.0.6 is released.

You can download the various builds from sourceforge.net or check for updates in your existing installation.

With this build, I believe I have finally addressed the intermittent crash on launch and persistent crash on exit issues particularly present on Windows7 machines. However, as I have not been able to reproduce crash on exit, I'll need those who have to let me know if this behavior continue to exist on their system with this release. For the crash on launch issue I believe this issue was linked to a Qt5 bug because I was able to reproduce it with 2 different code bases and in both bases the problem was resolved with the update to Qt 5.7. Again, I will look to users to confirm that the crash on launch no longer exist. Thanks to all who took the time to provide feedback on these issues.

I've also fixed some interesting items reported by users. Here is the changelog:

LPub3D 2.0.6.761.3 
 
Features and enhancements 
------------ 
-Fix: Set radial and conical background gradient parse fail with 'Malformed background...' (r759)
 *Parse fail for radial and conical gradient meta commands. Linear, radial and conical gradients are all now working as designed. 

-Fix: Scale in Page Globals Setup dialog not working (r756) 
 *Cover Image and Logo double spin control not working. Issue corrected. 

-Fix: Save and restore application window state and geometry (r755) 
 *Was causing crash on launch before update to Qt5.7. 

-Fix: Application crash on launch (r754) 
 *Update to Qt5.7 on MSVC2015 and MinGW5.3. There must have been a big, nasty bug in Qt 5.5/5.6 because the code that consistently generated the crash immediately resolved upon update to Qt5.7 

-Fix: Crash on application close on Windows7 (r753)
 *Expected scoped pointer main window to destruct all children on close but it seems like 3d viewer application and mainwindow were not treated as children and were not deleted at application close by the scoped pointer on Windows7 machines. Manually delete 3D viewer application instance and mainwindow at LPub3D termination. 

-Fix: Substitute parts use only file name; file path not required (r752) 
 *When editing substitute parts list, it is not necessary to enter the absolute file path for the substitute file.  Just entering the substitute file name will be sufficient. 

-Fix: Title annotations displays when only Freeform annotation selected in setup preference (r751)
 *Logic processed title annotations when it should not have. Corrected.

-Fix: setGeometry: Unable to set geometry 600x800 warning message (r749) 
 *Use QDesktopWidget.availableGeometry(this) setting to support single and multi-screen configurations.

-Fix: Parameter file edit window highlighting part description containing '#' (r748) 
 *Highlight only lines where first character is '#'.

-Fix: Generate fade colour parts list crash (r747) 
  *Redesigned functionality to process parts from archive libraries (unofficial and official) versus LDraw disc directories. This approach improves performance and reliability as all parts, including those from additional search directories, are collected in the archive libraries. Working with archive files is much faster than working with disc directories.

Cheers,

[Merlijn Wissink]

Ok, so I've made a video to demonstrate the difference between the (imo expected) behaviour on a single step page and the 'wrong' bahaviour on a multi-step page.
If you watch this together with my post above, it might get a little more understandable.

Here's the video. Don't mind the weird text on the right and the resolution. I just made a quick recording and haven't really looked into the settings of the recorder

If you've still got questions, let me know

[Trevor Sandy]

Ok, so I've made a video to demonstrate the difference between the (imo expected) behaviour on a single step page and the 'wrong' bahaviour on a multi-step page.
If you watch this together with my post above, it might get a little more understandable.

Here's the video. Don't mind the weird text on the right and the resolution. I just made a quick recording and haven't really looked into the settings of the recorder

If you've still got questions, let me know

Jerlijn,

Thanks for making the recording. I'll take a look to see why the different behavior between single and multi-step pages.

Cheers,

[Trevor Sandy]

[color=#333333]Greetings,[/color]

LPub3D 2.0.7 is released. 

[color=#333333]You can download from sourceforge.net or check for updates in your existing installation.[/color]

Features and enhancements 
------------ 
-Fix: Elapsed timer on file open (r771) 
 *Display elapsed time to load a file. 

-Fix: Archive library copy function not working if [empty] library directoy exist (r770) 
 *If user data libraries directory exist, library copy from installed base is ignored. This is an issue if there are no libraries in the library directory. The correct behaviour is to verify that libraries exist and copy if they don't. 

-Digitally sign LPub3D executable distributions (r769)
 *Secure installation content and reduce the likelihood of triggering antivirus quarantine.

-Fix: Inconsistent fade behaviour when using BUFEXCHG parts and added parts in the same step (r764) 
 *Behaviour previously used the size of the previous step's CSI to determine the fade position index of the current step in all cases. This approach could lead to an inconsistent fade position after retrieving a buffer. Behaviour corrected to use the size of the previous buffer parts list (versus the CSI) to determine the current step's fade position when BUFEXCHG RETRIEVE meta command is used. This approach removes the necessity to follow the BUFEXCHG RETRIEVE meta command with a STEP/ROTSTEP meta command to process the fade sequence which will unnecessarily render the buffered items twice, in the buffered view and the modelled view. Usually only the buffered view render is desired in the current step (that's why the assembly is buffered in the first place) but the modelled view CSI should be carried forward to the next step. Here are two examples: 

 Example 1: No unbuffered parts in step 1, render buffered skeleton with arrow in step 1 but render only modelled skeleton faded and the current parts in step 2 

Code:

0 !LPUB ASSEM MODEL_SCALE LOCAL  0.6500 
0 BUFEXCHG A STORE 
0 GHOST 1 0 201.2 -844.25 0 1 0 0 0 1 0 0 0 1 skeleton.ldr 
0 BUFEXCHG B STORE 
0 BUFEXCHG A RETRIEVE 
0 !LPUB PART BEGIN IGN 
0 GHOST 1 0 201.2 -960.25 0 1 0 0 0 1 0 0 0 1 skeleton.ldr 
0 GHOST 1 4 -131.2 -216.25 -70 -1 0 0 0 1 0 0 0 -1 arrow88.dat 
0 !LPUB PART  END 
0 STEP 
0 !LPUB PLI CONSTRAIN LOCAL HEIGHT 5.67 
0 !LPUB PLI PLACEMENT LOCAL LEFT PAGE INSIDE 0.0115693 -0.118771 
0 BUFEXCHG B RETRIEVE 
1 0 -130 -232 -70 -1 0 0 0 1 0 0 0 -1 3069b.dat 
1 0 -130 -232 70 -1 0 0 0 1 0 0 0 -1 3069b.dat 
0 STEP 

 Example 2: Unbuffered (modelled) parts in step 1, render hobspine, crossbrace, and outerrib with arrow (buffered) in step 1 but exclude arrow and show faded, step 1 modelled parts plus current parts in step 2. Step 1 terminates with ROTSTEP 

Code:

0 GHOST 1 0 0 0 0 1 0 0 0 1 0 0 0 1 hobspine.ldr 
0 !LPUB CALLOUT BEGIN 
0 !LPUB CALLOUT POINTER BOTTOM_LEFT 0.608 0.763 0 
1 0 0 0 0 1 0 0 0 1 0 0 0 1 crossbrace.ldr 
0 !LPUB CALLOUT PLACEMENT RIGHT ASSEM INSIDE 0.41159 0.062474 
0 !LPUB CALLOUT END 
0 BUFEXCHG A STORE 
1 0 0 0 -40 1 0 0 0 1 0 0 0 1 outerrib.ldr 
1 71 -70.196 804.976 -55 -0.924 -0.383 0 -0.383 0.924 0 0 0 -1 32123a.dat 
1 71 -218.11 743.75 -55 -0.707 -0.707 0 -0.707 0.707 0 0 0 -1 32123a.dat 
0 BUFEXCHG B STORE 
0 BUFEXCHG A RETRIEVE 
0 !LPUB PART BEGIN IGN 
0 GHOST 1 0 0 0 -120 1 0 0 0 1 0 0 0 1 outerrib.ldr 
0 GHOST 1 71 -70.196 804.976 -165 -0.924 -0.383 0 -0.383 0.924 0 0 0 -1 32123a.dat 
0 GHOST 1 71 -218.11 743.75 -165 -0.707 -0.707 0 -0.707 0.707 0 0 0 -1 32123a.dat 
0 GHOST 1 4 -70.196 804.976 -95 1.00023 0.000246369 0 0 0 -1 -0.000246369 1.00023 0 arrow88.dat 
0 !LPUB PART END 
0 ROTSTEP 0 75 0 ABS 
0 BUFEXCHG B RETRIEVE 
0 !LPUB PLI CONSTRAIN LOCAL HEIGHT 3.51333 
1 0 -378.303 402.398 -50 0 1 0 -1 0 0 0 0 1 3460.dat 
1 0 -378.303 402.398 50 0 1 0 -1 0 0 0 0 1 3460.dat 
0 STEP 

-Fix: LDView single call render crash on multi-step page generation (763) 
 *Crash if multi-step page's steps contain more than PLI and CSI components. Corrected. 

-Fix: Preference dialog version change log cleared on update check when there is no available update (r762) 
 *If no update available, ignore updating the change log dialog.

Cheers,

[Roland Melkert]

I think I found a bug in LPub3D (and Lpub4 as it does the same).

given this ldraw fragement:

Code:

1 14 0 0 -90 1 0 0 0 1 0 0 0 1 3005pt1.dat
1 14 40 0 -90 1 0 0 0 1 0 0 0 1 3005pt2.dat
0 BUFEXCHG A STORE
1 14 490 0 -110 1 0 0 0 1 0 0 0 1 3005pe5.dat
0 STEP
1 14 490 0 -110 1 0 0 0 1 0 0 0 1 3005pe5.dat
0 BUFEXCHG A RETRIEVE
1 14 80 0 -90 1 0 0 0 1 0 0 0 1 3005pt3.dat
1 14 120 0 -90 1 0 0 0 1 0 0 0 1 3005pt4.dat
1 14 160 0 -90 1 0 0 0 1 0 0 0 1 3005pt5.dat

LPub will display 4 bricks for the 2nd step. But (imho) it should exclude  3005pe5.dat

I'm not sure about this though, I ran into this when validating the new LDCad 1.6 bufexchg stuff.

       

[Trevor Sandy]

I think I found a bug in LPub3D (and Lpub4 as it does the same).

given this ldraw fragement:

Code:

1 14 0 0 -90 1 0 0 0 1 0 0 0 1 3005pt1.dat
1 14 40 0 -90 1 0 0 0 1 0 0 0 1 3005pt2.dat
0 BUFEXCHG A STORE
1 14 490 0 -110 1 0 0 0 1 0 0 0 1 3005pe5.dat
0 STEP
1 14 490 0 -110 1 0 0 0 1 0 0 0 1 3005pe5.dat
0 BUFEXCHG A RETRIEVE
1 14 80 0 -90 1 0 0 0 1 0 0 0 1 3005pt3.dat
1 14 120 0 -90 1 0 0 0 1 0 0 0 1 3005pt4.dat
1 14 160 0 -90 1 0 0 0 1 0 0 0 1 3005pt5.dat

LPub will display 4 bricks for the 2nd step. But (imho) it should exclude  3005pe5.dat

I'm not sure about this though, I ran into this when validating the new LDCad 1.6 bufexchg stuff.

Yep - I agree. The PLI should display 3005pt3.dat, 3005pt4.dat and 3005pt5.dat.

I'll take a look.

Cheers,

[Trevor Sandy]

I think I found a bug in LPub3D (and Lpub4 as it does the same).

given this ldraw fragement:

Code:

1 14 0 0 -90 1 0 0 0 1 0 0 0 1 3005pt1.dat
1 14 40 0 -90 1 0 0 0 1 0 0 0 1 3005pt2.dat
0 BUFEXCHG A STORE
1 14 490 0 -110 1 0 0 0 1 0 0 0 1 3005pe5.dat
0 STEP
1 14 490 0 -110 1 0 0 0 1 0 0 0 1 3005pe5.dat
0 BUFEXCHG A RETRIEVE
1 14 80 0 -90 1 0 0 0 1 0 0 0 1 3005pt3.dat
1 14 120 0 -90 1 0 0 0 1 0 0 0 1 3005pt4.dat
1 14 160 0 -90 1 0 0 0 1 0 0 0 1 3005pt5.dat

LPub will display 4 bricks for the 2nd step. But (imho) it should exclude  3005pe5.dat

I'm not sure about this though, I ran into this when validating the new LDCad 1.6 bufexchg stuff.

Yep - I agree. The PLI should display 3005pt3.dat, 3005pt4.dat and 3005pt5.dat.

I'll take a look.

Cheers,

Roland, I took a look. Basically the issue is if you call BUFEXCHG RETRIEVE after inserting parts in the step, those parts will be overwritten with parts from the buffer.

So here is what happens with each meta command:
  0 BUFEXCHG A STORE: put all parts in the step up to the pont of the command into a buffer.
  0 BUFEXCHG A RETRIEVE: overwrite the current parts list (csiParts) with the parts from the buffer.
If I use your sample:

Code:

1 14 0 0 -90 1 0 0 0 1 0 0 0 1 3005pt1.dat
1 14 40 0 -90 1 0 0 0 1 0 0 0 1 3005pt2.dat
0 BUFEXCHG A STORE
1 14 490 0 -110 1 0 0 0 1 0 0 0 1 3005pe5.dat
0 STEP
1 14 490 0 -110 1 0 0 0 1 0 0 0 1 3005pe5.dat
0 BUFEXCHG A RETRIEVE
1 14 80 0 -90 1 0 0 0 1 0 0 0 1 3005pt3.dat
1 14 120 0 -90 1 0 0 0 1 0 0 0 1 3005pt4.dat
1 14 160 0 -90 1 0 0 0 1 0 0 0 1 3005pt5.dat

We can expect for step one three parts will be in the CSI and PLI (3005pt1.dat, 3005pt2.dat and 3005pe5.dat). Two parts are stored in the buffer (3005pt1.dat and 3005pt2.dat)
   

For step 2 we can see the parts from the buffer have been retrieved in the CSI (3005pt1.dat and 3005pt2.dat); however, they correctly do not show in the PLI. We can also correctly see step 2's parts in the PLI (3005pe5.dat, 3005pt3.dat, 3005pt4.dat and 3005pt5.dat) but part 3005pe5.dat is not displayed in the CSI.
   

 That part 3005pe5.dat is missing from the CSI, I believe, is the problem in your example. As stated earlier, this behaviour is because retrieving the buffer overwrites any parts in the CSI list so because BUFEXCHG A RETRIEVE in your example is after the declaration of part 3005pe5.dat; we see this part in the PLI but it is not in the CSI image.

If we move BUFEXCHG A RETRIEVE to be the first declaration in step two. The behavior is as designed.

Code:

1 14 0 0 -90 1 0 0 0 1 0 0 0 1 3005pt1.dat
1 14 40 0 -90 1 0 0 0 1 0 0 0 1 3005pt2.dat
0 BUFEXCHG A STORE
1 14 490 0 -110 1 0 0 0 1 0 0 0 1 3005pe5.dat
0 STEP
0 BUFEXCHG A RETRIEVE
1 14 490 0 -110 1 0 0 0 1 0 0 0 1 3005pe5.dat
1 14 80 0 -90 1 0 0 0 1 0 0 0 1 3005pt3.dat
1 14 120 0 -90 1 0 0 0 1 0 0 0 1 3005pt4.dat
1 14 160 0 -90 1 0 0 0 1 0 0 0 1 3005pt5.dat

   

You can see above, part 3005pe5.dat is now visible in the CSI. 

If it is your intention to hide a part. You can use the ignore commands as in this example: 

Code:

0 !LPUB PART BEGIN IGN
1 14 490 0 -110 1 0 0 0 1 0 0 0 1 3005pe5.dat
0 !LPUB PART END

I could include logic to check if any parts are declared in the step before the BUFEXCHG A RETRIEVE command but this could get complicated if multiple buffer commands are declared within a step. I think it is ok to just advise that, in a step, one should declare the BUFEXCHG A RETRIEVE first or before any parts are declared.

What do you think?

Cheers,

[Roland Melkert]

I could include logic to check if any parts are declared in the step before the BUFEXCHG A RETRIEVE command but this could get complicated if multiple buffer commands are declared within a step. I think it is ok to just advise that, in a step, one should declare the BUFEXCHG A RETRIEVE first or before any parts are declared.

What do you think?

Cheers,

I know this is not very common usage, I was just trying weird things to test my implementation.

So you could make it a 'known limitation' as it won't be used in that way often anyway.


While implementing this stuff for LDCad I did realize the main trick in processing the BUFEXCHG metas is to loop trough the model's lines BACKWARDS, that way it won't matter how many buffers are nested even if you would be using more then just A-Z ones    This might be helpful for LPub too.

[Trevor Sandy]

I could include logic to check if any parts are declared in the step before the BUFEXCHG A RETRIEVE command but this could get complicated if multiple buffer commands are declared within a step. I think it is ok to just advise that, in a step, one should declare the BUFEXCHG A RETRIEVE first or before any parts are declared.

What do you think?

Cheers,

I know this is not very common usage, I was just trying weird things to test my implementation.

So you could make it a 'known limitation' as it won't be used in that way often anyway.


While implementing this stuff for LDCad I did realize the main trick in processing the BUFEXCHG metas is to loop trough the model's lines BACKWARDS, that way it won't matter how many buffers are nested even if you would be using more then just A-Z ones    This might be helpful for LPub too.

That's right. When combined with the exponential amount of scenarios that can present with so many meta commands, it can be a bit challenging to know if you have covered all possibilities when you add to or change the current behaviour. It would not be big deal to read the step backward from the BUFEXCHG meta to identify any declared parts. It's just a matter of reading backward until either you hit a BUFEXCHG STORE or a STEP. 

On another topic. Today I successfully compiled Qt 5.7 on MinGW 6.1 x64 using the MSYS2 PKGBUILD framework. The build setup process was quite efficient but took 6 hours to complete. LPub3D builds without issue on this platform so now I've only to update the deployment scripts and I'll be back to 100% MinGW. I'm so happy to get away from MSVC   . 

Cheers,

[Roland Melkert]

That's right. When combined with the exponential amount of scenarios that can present with so many meta commands, it can be a bit challenging to know if you have covered all possibilities when you add to or change the current behaviour. It would not be big deal to read the step backward from the BUFEXCHG meta to identify any declared parts. It's just a matter of reading backward until either you hit a BUFEXCHG STORE or a STEP. 

On another topic. Today I successfully compiled Qt 5.7 on MinGW 6.1 x64 using the MSYS2 PKGBUILD framework. The build setup process was quite efficient but took 6 hours to complete. LPub3D builds without issue on this platform so now I've only to update the deployment scripts and I'll be back to 100% MinGW. I'm so happy to get away from MSVC   . 

Cheers,

Yes all those metas can be quite a pain when combined

mingw54/MSys2 is indeed a nice platform I'm using it for LDCad too. For me the most time went into choosing a threading/exception model. After that wxWidgets compiles in about 10 minutes (-j8) or so.

[Travis Cobbs]

mingw54/MSys2 is indeed a nice platform I'm using it for LDCad too. For me the most time went into choosing a threading/exception model. After that wxWidgets compiles in about 10 minutes (-j8) or so.

I've personally found the free Microsoft compilers to be pretty good over the years (especially more recently with C++), so I'm curious why you both feel that MinGW does a better job. Note: this post isn't intended to be at all negative: I'm honestly curious. Is it because of the 3rd-party toolkits you're using (Qt and wxWidgets)? Or is it so that you can use the same compiler on both Windows and Linux?

I feel that the fact that LDView gets compiled on three completely different compilers (VC on Windows, gcc on Linux, and Clang on Mac) improves its code, because each compiler contributes warning messages that the others don't.

[Roland Melkert]

I've personally found the free Microsoft compilers to be pretty good over the years (especially more recently with C++), so I'm curious why you both feel that MinGW does a better job. Note: this post isn't intended to be at all negative: I'm honestly curious. Is it because of the 3rd-party toolkits you're using (Qt and wxWidgets)? Or is it so that you can use the same compiler on both Windows and Linux?

I feel that the fact that LDView gets compiled on three completely different compilers (VC on Windows, gcc on Linux, and Clang on Mac) improves its code, because each compiler contributes warning messages that the others don't.

When I started with LDCad is was looking for a seamless solution for developing multi platform, GCC seemed the only logical way to go as it is available almost everywhere. Also the msys/mingw stuff makes the building environment very Linux like so not only code will be portable but the makefile etc too.

Being mainly a Delphi developer at the time I also wanted to have a minimal amount of dll dependencies as deploying is just so much easier that way.

It was quite a step back IDE wide though, but on the upside GDB integration with code::blocks is improving all the time.

[Travis Cobbs]

Being mainly a Delphi developer at the time I also wanted to have a minimal amount of dll dependencies as deploying is just so much easier that way.

FYI, contrary to popular belief, Microsoft's compiler can be used without DLL dependencies. In fact, LDView does so, which makes the LDView executable file larger, but avoids problems that people run into otherwise. (Yes, LDView depends on Windows DLLs, but all Windows programs depend on Windows DLLs.)

[Trevor Sandy]

mingw54/MSys2 is indeed a nice platform I'm using it for LDCad too. For me the most time went into choosing a threading/exception model. After that wxWidgets compiles in about 10 minutes (-j8) or so.

I've personally found the free Microsoft compilers to be pretty good over the years (especially more recently with C++), so I'm curious why you both feel that MinGW does a better job. Note: this post isn't intended to be at all negative: I'm honestly curious. Is it because of the 3rd-party toolkits you're using (Qt and wxWidgets)? Or is it so that you can use the same compiler on both Windows and Linux?

I feel that the fact that LDView gets compiled on three completely different compilers (VC on Windows, gcc on Linux, and Clang on Mac) improves its code, because each compiler contributes warning messages that the others don't.

For me it is mostly because of the history of the LPub3D codebase. LPub3D appear to do better under MinGW. I imagine because the original LPub4 base was not a MSVC port. Also, some of the additional open source components I've added to create LPub3D were not MSVC compliant - notably LDrawini and Quazip. 

However, probably the biggest turn-off is Microsoft's culture of 'bloat,' dependencies and uni-platform architecture. Despite their efforts to combat these items recently, they are still quite persistent in desktop development.

[Trevor Sandy]

Greetings,
LPub3D 2.0.8 is released. 

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

This release reverts to MinGW distributions for both x86 and x64 architectures. I will not produce MSVC distributions going forward.

Features and enhancements 
------------ 

-Fix: Print/export 'page range' option output incorrect (r785) 

 *For print/export option "All pages," images are generated in numerical order. However, for option "Page Range," images are generated in "alphabetical" order for lack of a better description. If one selects pages 1-115, the order the pages are generated is 1, 10, 100, 11, 12, 13, 14, 15, 16, 17, 18, 19, 2, 20... The order is now as expected 1...10...100 etc... 

-Fix: Revert to MinGW distributions - for both x32 and x64 architectures (r784) 
 *Discontinue all MSVC LPub3D distributions. 

-Fix: Refactor loading model file into Ldraw editor window (r783) 
 *File load hangs for an unusual amount of time when loading a large model file. This behaviour appears usually when the LDraw editor tab is not in focus. If the file is loaded with the editor tab in focus, the file is loaded nominally. 

-Fix: Exclude fade directories from search directory list if fade step not enabled (r781) 
 *Improve just a little bit the performance during model file load. 

-Fix: Refactor adding parts to archive library (r780) 
 *Improved logging detail and added checks to not submit an empty search directory. 

-Fix: Log all status entries add date time stamp (r779) 
 *Capture all status bar updates to the log files. Increase log file size to 5Mb rotating across 5 files. Log files located at  Software/LPub3D/logs 

-Fix: Backup parameter files during install (r778) 
 *Backup user-editable parameter files that must be overwritten during installation of updates. This way, any additions created by the user will not be lost. However, it will be necessary to manually update the new parameter file with your additions. 

-Fix: Refactor fade step behaviour (r777) 
 *Update fadeStepColorParts.lst attributes to allow faster library parsing to generate static colour parts. 
 NOTE: FILE UPDATE REQUIRED. fadeStepColourParts.lst file updated with new required column so it is necessary to update your installed file. LPub3D will automatically backup and overwrite the existing file during installation. 

-Fix: Adjustable renderer process timeout (r776) 
 *All the user to manage the amount of time to keep alive the renderer process. The default is 6 minutes but can be changed between -1 which is run indefinitely and 99 minutes. For high definition using POV-Ray, rendering process time can easily exceed the default. This setting is located at Preferences/Rendering/Process timeout.

-Fix: Reload archive libraries into memory (r775) 
 *On model file load, do not reload library if no new parts discovered. LPub3D sweeps the defined search directories upon file load. This update makes a little more efficient the load process. 

-Fix: Update aboutdialog display version of Qt (r774) 
 *Display version of Qt from the platform versus hard coded. 

-Fix: Compile on MinGW x64 (r773) 
*Convert int to intptr.

Cheers,

[Roland Melkert]

Trevor would it be interesting if I added substitute information to LDCad's generated content. That way LPub3D could do auto substituting without the user having to surround the generated part with pli meta's.

I could add something to the 'GENERATED' meta, maybe something like...

for a tread:

Code:

0 !LDCAD GENERATED [generator=LDCad 1.6] [substRef=3827.dat] [substCnt=40]

or for a shock:

Code:

0 !LDCAD GENERATED [generator=LDCad 1.6] [substRef=73129.dat] [substCol=16]

Or for things like strings, hoses etc (would need unofficial parts though at least until official ones are available.) :

Code:

0 !LDCAD GENERATED [generator=LDCad 1.6] [substRef=foo.dat] [substCol=16] [substLen=500mm]

What do you think?

[Merlijn Wissink]

That sounds like a pretty cool and really useful idea! 

[Trevor Sandy]

Trevor would it be interesting if I added substitute information to LDCad's generated content. That way LPub3D could do auto substituting without the user having to surround the generated part with pli meta's.

I could add something to the 'GENERATED' meta, maybe something like...

for a tread:

Code:

0 !LDCAD GENERATED [generator=LDCad 1.6] [substRef=3827.dat] [substCnt=40]

or for a shock:

Code:

0 !LDCAD GENERATED [generator=LDCad 1.6] [substRef=73129.dat] [substCol=16]

Or for things like strings, hoses etc (would need unofficial parts though at least until official ones are available.) :

Code:

0 !LDCAD GENERATED [generator=LDCad 1.6] [substRef=foo.dat] [substCol=16] [substLen=500mm]

What do you think?

Roland - This would be a good attribute to add especially if the user also has the ability to set it from the template GUI. This way, the user would have the ability to choose whatever representation s/he wanted to display in the PLI.

In LPub3D, as you said, the advantage is the ability to fully automate the substitution process. A disadvantage would be to not have the ability to choose your substitute representation. However, I can work around this by first checking for entries in the substitute list then the LPub meta and finally LDCad.

Cheers,

[Merlijn Wissink]

Trevor, if you're looking for feature suggestions, I have a nice one that surfaced on eurobricks.com.

Sometimes a model uses the same submodel multiple times, but not all in the same step. However, LPub always displays the submodel/callout for the total amount that it's being used in the model.

An example: when a model has 4x the same submodel, but 2 of those are used in step 10 and the other 2 are used in step 20, LPub will create 1x the submodel building steps with a 4x next to it.

The usual workaround is to copy the submodel and give it another name. It would be way easier though, if LPub would automatically count how many times a submodel is used in a certain step and adjust the (using the above example) 4x to 2x and generating a second submodel building steps at step 20.

Well, if that sounds kinda vague, probably my problem. I'm not too good at explaining things...

[Trevor Sandy]

Trevor, if you're looking for feature suggestions, I have a nice one that surfaced on eurobricks.com.

Sometimes a model uses the same submodel multiple times, but not all in the same step. However, LPub always displays the submodel/callout for the total amount that it's being used in the model.

An example: when a model has 4x the same submodel, but 2 of those are used in step 10 and the other 2 are used in step 20, LPub will create 1x the submodel building steps with a 4x next to it.

The usual workaround is to copy the submodel and give it another name. It would be way easier though, if LPub would automatically count how many times a submodel is used in a certain step and adjust the (using the above example) 4x to 2x and generating a second submodel building steps at step 20.

Well, if that sounds kinda vague, probably my problem. I'm not too good at explaining things...

Merlijn,
Noted. Thanks. Your description is clear.

Cheers,

[Trevor Sandy]

Greetings,

LPub3D 2.0.9 is released.

You can download the various builds from sourceforge.net or check for updates in your existing installation.

The key update in this release is moving the fade parts folder from the ldraw/unofficial directory to the LPub3D user data directory. I made this change avoid write access issues when ldraw is installed under a different user appdata than LPub3D, or ldraw is installed in Program Files (x86). This change particularly target environments running LDraw AIOI where the ldraw library is installed under the public Windows user. From this release, all LPub3D updateable content will be located under the LPub3D user data location. Please note that for portable distributions, this location is the LPub3D root folder. For installed distributions, the user data defaults to <Drive>\Users\<User>\AppData\Local\...  

LPub3D 2.0.9.792.2 

 
Features and enhancements 
------------ 
-Fix: Align 3Dviewer and rendered csi image rotation (r791) 
 *The model loaded in the 3D viewer and its corresponding csi step image are now similarly rotated. 

-Change: Move fade part files folder to lpub3d data directory - was previously under ldraw/unofficial directory (r790) 
 *Remove potential conflict when ldraw disc library is located under Program Files(x86) or a user data directory which is different from the user LPub3D is installed under. For example, LPub3D may be installed under standard user 'foo' while the ldraw disc library is installed under user 'public' [or under Program Files (x86). In both cases, LPub3D will likely be blocked from creating fade part files under the ldraw directory - i.e. in Unofficial/fade. Moving the fade folders will ensure write access is always available as the fade part files folder will be under the LPub3D data directory (e.g. C:\Users\foo\AppData\Local\LPub3D Software\LPub3D\fade) 
Note: If you are using an ldraw.ini configuration file which include paths to the fade/parts and fade/p folders, you must update the paths accordingly. You must also update the extra search directories dialog in LDView if you are using it as your renderer. 
Here is an example of what the new paths should look like if you are running an installed distribution: 
C:\Users\[userid]\AppData\Local\LPub3D Software\LPub3D\fade\p 
C:\Users\[userid]\AppData\Local\LPub3D Software\LPub3D\fade\parts 

-Fix: Fade parts functionality update (r789) 
 *Update logging, archive fade parts after model file load as necessary - previously only updated on application launch. 

-Fix: Move cache to root install folder for portable distributions (r788) 
 *Allow all runtime components of portable distribution to be contained within the folder structure of the distribution. 

-Fix: Extract archive library after download (r787) 
 *After archive library download, extract contents to defined LDraw disc library location. Archive libraries can be downloaded at application launch if no archive was found and at the tools menu where one can 'Refresh' the libraries at any time. The aim of this enhancement is to synchronize and automatically update both the archive and disc LDraw library content. 

Cheers,

[David Manley]

Greetings,

LPub3D 2.0.9 is released.

<snip>

Hi Trevor,

I've done a clean install of 2.0.9 (uninstalling prior versions and manually deleting leftover files e.g. fade files within the LDraw unofficial folder hierarchy).

Running the following simple model:

Code:

0 Name: test
0 !LPUB MULTI_STEP BEGIN
1 71 0 14 -41 1 0 0 0 1 0 0 0 1 58120.dat
0 STEP
1 1 20 14 -41 0 0 1 0 1 0 -1 0 0 43093.dat
0 STEP
1 1 -20 14 -41 0 0 1 0 1 0 -1 0 0 43093.dat
0 STEP
0 !LPUB MULTI_STEP END
1 71 0 44 -21 1 0 0 0 1 0 0 0 1 3034.dat
0 STEP
0 !LPUB INSERT MODEL
0 !LPUB INSERT PAGE
0 STEP

This is how the first page is being rendered:

   

From the screenshot it appears that LeoCAD is seeing the faded motor but some how it isn't making it into the instructions.

I have attached the LPub3D log file on the assumption that it may help in diagnosing the undesirable behaviour.

Regards,

David

[David Manley]

Some further investigation implies it may be something to do with LDView not having visibility of the path to the faded part.
I opened the "csi.ldr" file within the LPub3d/tmp folder using a text editor and could see the three parts for the last step on the first page. I then opened the "csi.ldr" file using LDView, which yielded the first screenshot shown below. Using the LDView menu option "File/Extra Dirs ...", I then added the path "D:\users\Vista\djm\AppData\Local\LPub3D Software\LPub3D\fade\parts" within LDView, reloaded the file in LDView which yielded the second image shown below. The second screenshot is what I expected LDPub3D would have generated.

   

Note that even though LDView now has the extra directory explicitly added, it does not appear to be using it when invoked by LPub3D.

Regards,

David