I had some difficulty with adding multiple search directories (essentially allowing for any number of Ldraw libraries) which took me longer than I anticipated. In fact, I had to write an enhancement for ldglite - not so easy updating old c code.

As before, you can download from sourceforge.net or check for updates in your existing installation.

-Add dialog to print or export to image all pages, current page and custom range of pages (e.g. 1,3,5,7-9)

-Add ability to detect additional ldraw content search directories using ldrawini c api
I implemented the ldrawini c api to maintain compatability with LPub3D 3rd Party renderers - LDView, L3P(PovRay) and Ldglite. Additional directories must have either the same tree as LDraw Unofficial directory (i.e. parts and/or p subdirectories...) or alternatively, content can be deposited at the root of the additional directory (i.e. C:/ldrawFiles/*.dat). Content from all defined ldraw search directories are archived in the ldrawunf.zip archive and loaded into memory - enabling access to the 3DViewer.
If no ldraw.ini file is detected. LPub3D will automatically search all subdirectories under the ldraw/Unofficial directory - except directories p and parts. Unofficial subdirectories p and parts as well as official p and parts subdirectories are never searched because they are automatically loaded during default behavior during startup.
There are 2 ways to define search directories: 1. using the Ldraw.ini file (there is now a menu button to edit the ldraw.ini file) and 2. editing the 'Ldraw Content Search Directories text edit dialog under the 'Other' tab in Preferences. If you are using an LDraw.ini file, the preferences dialog will be read only - you must use the menu edit button under 'Configuration' to edit the ldraw.ini file. The ldraw.ini edit button only appears if a ldraw.ini file is detectected. If you are not using ldraw.ini, it is possible to add,remove and reset to the default search directories in the Preferences tab.
ldglite renderer updated with the ability to process additional directories beyond official/unofficial parts, p and Model. I implemented this enhancement to allow all 3 LPub3D renderers(LDView, Ldglite, L3P/PoV Ray) the same functionality supporting additional ldraw content search directories. LPub3D now passes 2 env variables to ldglite - LDRAWDIR and LDSEARCHDIRS. LdView and L3P already uses the ldrawini.c library. They can also be configured to detect additional ldraw content search directories if no ldraw.ini file is configured. I also upgraded ldglite's openGL API from glut (deprecated) to freeglut 3.0 released in June 2015. Ldglite os not versioned at 1.3.0 (from 1.2.7).

-Add ability to manage additional ldraw content search directories whether using Ldraw.ini or not.
If not using Ldraw.ini file, automatically detected search directories are limited to those under the Unofficial directory. The user has the ability to exclude and reset search directories within this edit list. Unofficial P and Parts directories are automatically excluded from the search directory list as they are loaded automatically by the application.
-Add Rotate Icon - indicate that the builder should "flip" the model

-Add PLI/BOM part substitution - substitute modeled part in PLI/BOM with alternate
This feature is useful when you have a modeled part (e.g. Power Functions Light) that will
take alot of space in the BOM/PLI, you can substitute the modeled version with an alternate
representation that is suitable for the PLI/BOM view. This feature is complementary to LDCad's
template functionality which allows you to model adjustable parts as needed. To use this
functionality, simply edit the substituation list from Configuration= BOM/PLI Substitute Parts List

-Add memu item 'Refresh Unofficial Parts' which downloads and replaces the ldrawunf.zip archive
in the Ldraw/LPub3DVoiewer-Library. LPub3D places all search directory parts in the ldrawunf.zip archive so they
can be made available for the LPub3D Viewer. This feature allows you to reset the archive file to
it's latest default content if desired. The ldrawunf.zip unofficial archive is used, along with the complete.zip,
by the 3DViewer.

-Remove PartsList class, use instead lcPiecesLibrary class to verify parts and capture part title. This is a consolidation to
improve the application's performance.

-Move process fade colour parts to separate thread.

-Move fade parts directory from under LDraw/Unofficial/parts and LDraw/Unofficial/p to as single directory
under LDraw/Unofficial. So from this version of LPub3D, the fade directory will be autogenerated and populated
as LDraw/Unofficial/fade. Old fade directories under Unofficial/parts and p must be manually removed if desired.

-Fix: Changing step number attributes on multi-step pages are now working

-Fix: PLI/BOM sort routine, sort on 'part colour' part(s) appear out of place relative to part size and colour.

-Fix: Do not create instruction page(s) for unofficial part

-Fix: Create s/8/48 subdirectory in lpub/tmp directory when needed. This fix will resolve the issue of LPub3D not being able to create inline unofficial subparts and 8/48 primitives when rendering models where these parts are defined in the model file.
-CHANGE: In previous versions of LPub3D, custom and fade parts were loaded under the Unofficial directory allowing detection by all renderers and the 3D viewer. From this version of LPub3D (v1.3.0), the fade directory will reside at the root of the the Unofficial directory. Custom content added to Unofficial P and Parts directories will not detected by LPub3D.

-CHANGE: Change part count routine to use ldraw archive files to look at '!LDRAW ORG...' part type meta tag. I think there are still some issue with this routine however - especially with large complex models using in-lined unofficial parts that may not be in ldrawunf.zip.

-CHANGE: Change 'Reset All Caches' to 'Reset Image and Model' Caches

-CHANGE: BOM default sort to sort by colour then size, previous default was size only (PLI default sort by size)

Although the gradient background is difficult to comprehend, I am getting results!
Is it possible to create a horizontal gradient with one color on top fading to another color at the bottom?
So far I only got a mirrored gradient.

I am really grateful for the rotation icon. Though the placement does things I do not expect. Perhaps we can take a look?

However then on the next page (step 4) on screen (see screenshot) the stepnumber is under the assem, but when I export as png it is where I expect it to be right under the PLI. But then, when I reload (clear cache) and export as either PNG of PDF the stepnumber is under the assem?

I think it has something to do with the hierarchy of the LPUB metacommands, but I cannot be sure.

Hi Jaco - so if I understand well, you would like to place the rotation icon under the step number (bottom left outside) without having the next step's step number repositioned under the assy - is this correct?

I'll take a look to see if I can find and correct this unexpected behavior once I have you confirmation that I understand the issue.

Trevor Sandy Wrote:Hi Jaco - so if I understand well, you would like to place the rotation icon under the step number (bottom left outside) without having the next step's step number repositioned under the assy - is this correct?

Yes, that is correct!

Trevor Sandy Wrote:I'll take a look to see if I can find and correct this unexpected behavior once I have you confirmation that I understand the issue.

Would it be possible to sort the LPUB metacommands by type?
When working on a file I make settings to the page, the PLI, assem, stepgroup, etc. where I see fit and to try various things.
LPub3D creates a line with the metacommand for global setting on top of the file, but it does that in the order that one makes the settings it. Which is logic.

Once hapy with all settings I "sort" all commands by type and "group" them by adding command zero's between every section.
Here is a pice of LDraw code lines of a model I have and should illustrate what I mean:

So I wonder if it is possible to force LPub to kind of sort the metacommands that go together in a certain group? For instance starting with page settings, then assembly, stepnumber multistep, PLI, callout, etc. (not the way I sorted above example btw)

- local page orientation (but you already know that one :-)
- be able to scale the rotation icon (I think it is one size now on all instances?)

- add a corner to callout arrows
I personally dislike oblique lines comming from callouts pointing to where a calledout submodel is in the model. Even more it somtimes makes images of the step difficult to see when a line runs over the model (assembly image).
I usally try to avoid that so I place callouts where I can where I can keep the arrow line horizontal or vertical, but sometimes this seems impossible of unavoidable. Being able to add one or more corners to the line of the arrow would solve that.

- one part callouts
To be able to callout individual parts instead of submodels only
This to emphasis where a part is that one cannot see wholy.
Or for example bricks with print, studs on side (placed so that you cannot see it), etc.

It is impossible to identify where the brick with one stud or two studs goes.
Calling out either one of them and showing in a certain angle should make it easier to see what part it is.
What I do now is create a submodel with only one of the bricks in it and then use that submodel for the brick to be able to call it out with a rotation step to show the right angle

Being able to call out a single brick like this, would make it less code intensive
The code would be something like this?

Jaco van der Molen Wrote:[...]
- one part callouts
To be able to callout individual parts instead of submodels only
This to emphasis where a part is that one cannot see wholy.
Or for example bricks with print, studs on side (placed so that you cannot see it), etc.
[...]

This is a very interesting idea. I like it!
I imagine it isn't that difficult to implement in LPUB (I mean, it's the same as every other callout, except that it's a part instead of a submodel, but I can be wrong of course), but it would be much easier for the instruction-author.

Positioning a callout in a step-group relative to the assembly (phew, what a sentence) is also broken. Everything on the right doesn't work, top is bottom and bottom is top and left of the assembly becomes left of the parts-list. In a non-stepgroup (so no multiple steps on 1 page), it seems to work fine.

There might be more that's not working, but there are so many possible combinations of relative to ... and the position

Thanks for the update. I have not played too much with callouts mostly because I don't believe they are necessary. To put another way, there are other model structure patterns that communicate the efficient building without the use of callouts.

Furthermore, the underlying placement architecture of LPub - which drives what is efficiently possible for me to implement - is quite brittle and restrictive. I think it is why placement - especially for multi-step items - is not fully enabled, or properly working in the original LPub.

Anyway, I understand there are those who use LPub3D and indulge in producing instructions as complex and sophisticated as their models so I will do what I can to investigate and correct the behavior you described.

Well, it was working correctly in the originial LPub and also the previous version of LPub3D, so I suppose you broke something in the 1.3.0 update

Also, I've been experimenting a bit with the 1.3.0 update a bit yesterday. And it seems way faster that the original LPub and even the previous version of LPub3D. Is it just me or did you really make some under-the-hood improvements? (Or could it be that I was experimenting with a small 100pcs model instead of the 2000+ Technic models I normally use?)

Well - if you think I broke something then I am definitely interested to know more about the behavior you are experiencing.

Can you send an example model file with the metas causing the issue - that you believe worked previously?

This would be very helpful in expediting my research. Many thanks !

Indeed, I think the performance has improved a bit.

There was some feedback about the slow performance so I spent considerable time implementing multi-threading where I could. I also moved around some of classes and tried to cleanup some deprecated functions like RegExp etc...

Trevor Sandy Wrote:Furthermore, the underlying placement architecture of LPub - which drives what is efficiently possible for me to implement - is quite brittle and restrictive. I think it is why placement - especially for multi-step items - is not fully enabled, or properly working in the original LPub.Cheers,

I can confirm that. Way back, when Kevin was still working on LPub, I pointed this out too.
It was (is) to complex to fully implement "free" placement.

I could not reproduce your behavior. When I move model description to the right of pieces, that's where it goes - see screenshot below. Perhaps you can post a screenshot?

As you may know, the underlying behavior of placement is based on items being relative to another with the root item being relative to the page. For the cover page, the Title is the root item. The move dialog should show the available placement options and the items they are relative to.

Features and enhancements
------------
-Fix: PLI Parts annotation restored to short value (r555)
-Fix: Control manual page number entry. (r562)
-Fix: Remove silent_alloc which would trap the Callout meta 0 !LPUB CALLOUT [HORIZONTAL|VERTICAL] and throw a parse error.
However silent_alloc was not fully implemented and does not serve any current purpose.
The correct meta to allocate a Callout Horizontally or Vertically is 0 !LPUB CALLOUT ALLOC [HORIZONTAL|VERTICAL]

Features and enhancements
------------
-Fix: Crash when pieceinfo is null - this occurs when a file has no FILE meta and is imported as an ldr (versus an mpd).(r575)
-Fix: Periodic crash when changing margin of assembly (CSI) in multi-step page (r577)
-Fix: Periodic crash when adding divider to multi-step page or callouts (r577)
-Fix: Periodic crash every time a second successive rotation icon is added to multi-step page (r577)
-Fix: If using LPub3D archive distribution (no installer), use distribution's extras folder instead of creating one in AppData (r579)
-Fix: Print/export dialog progress bar (r585)
-Fix: Upon "Add assembled image to parent page" a rotation icon is added to the callout if rotation icons were present in the callout step(s). Assembled and rotated callouts will not display rotate icons on the parent page. Only unassembled callouts will display rotate icons if present in the callout step(s). (r587)
-Fix: 2 page refreshes when Parameters menu item is accepted - only a single refresh needed. (r588)

One suggestion: I have made some changes and additions to the part and freeform annotation files.
If I install an update my files are overwritten by new (old) ones.
Could you implement some detection whether one made changes to these files to not overwrite them when installing an update?

I'm a heavy user of your lPub3D and I would like to thank you a lot for it and for all the great improvements you are bringing to it. At the same I apologize for not providing you feedback so far. What I personally appreciated a lot were the addition of the BOM by color and the export of single pages, these boosted significantly my efficiency.

I finally take the opportunity to provide you a few inputs:

1) The incompatibility related to the "Add/CHANGE line type attribute to border configuration" with previous LPub versions should be in my opinion be fixed by assigning a value by default to the missing value in case of older file, instead of generating a parsing error which might not be trivial to understand to unexperienced users. This is of course just a suggestion.

2) wrong text (I'm just being picky here!): when you export to PNG the window title says "Print to pdf"

3) in the menu which appears when right clicking on the main page the first top choice now is "Change page background". I personally preferred it before when it was "Add next step", just because I guess this command to be more often used overall. (I might be wrong though)

New possible features:
1) Currently when you click on an step image the cursor moves to the corresponding location on the right commands list, which is great. It would be useful if the same would happen when while clicking on a line of code the corresponding instruction image would get highlighted.

2) Rotation steps: Not sure whether it is just me, but when it comes to rotation steps I happen to more or less always use the same angles of vision. (example: 25 50 0 ABS). In my view it would be very convenient to have some buttons to generate these standard rotsteps with just a click. (customzable in the prefs?) Additionally it could help to have buttons to rotate by +/- 90° each axis on the currently selected rotstep. Just throwing ideas out there :-)

3)When I generate BIs I find myself often going back and forth from and to MLCAD to fix small issues, like an inaccurate bricks positions, or a wrong brick color.
In this sense it would be great to have the ability to change the color directly in LPub. Of course this can already be done by typing the color code, but it would be more convenient to have a table with the colors and just have to click on the proper one.
When it comes to brick position also here it would be great to be able to adjust the position of bricks back and forth up and down and so forth by just clicking on some buttons which makes them move by standard distances like 1 plate in height and 1/2 brick in x,y. (or custom configurable in the prefs)
I also like to move bricks temporarily to generate more clear instructions (For this there is a specific Ldraw instruction, but I find too cumbersome and time consuming to use). I personally indeed export everything to PNG and combine instructions in Photoshop.

4) possibility to add extra custom arrows? This is something I personally do not need, but somebody might find useful.

For the moment that's all I can think of.
As I wrote above I'm just throwing ideas out there based on the experience accumulated while working on the generation of 40+ models instructions for my new book. So, in case you feel creative anytime soon... ;-))

Trevor, thanks a lot for your efforts which I personally appreciate very very much.

Mattia Zamboni Wrote:3) in the menu which appears when right clicking on the main page the first top choice now is "Change page background". I personally preferred it before when it was "Add next step", just because I guess this command to be more often used overall. (I might be wrong though)

Good point. I was have trouble adjusting to that too. I am so used to right click and pick the first option for adding steps.

Mattia Zamboni Wrote:New possible features:
1) Currently when you click on an step image the cursor moves to the corresponding location on the right commands list, which is great. It would be useful if the same would happen when while clicking on a line of code the corresponding instruction image would get highlighted.

2) Rotation steps: Not sure whether it is just me, but when it comes to rotation steps I happen to more or less always use the same angles of vision. (example: 25 50 0 ABS). In my view it would be very convenient to have some buttons to generate these standard rotsteps with just a click. (customzable in the prefs?) Additionally it could help to have buttons to rotate by +/- 90° each axis on the currently selected rotstep. Just throwing ideas out there :-)

3)When I generate BIs I find myself often going back and forth from and to MLCAD to fix small issues, like an inaccurate bricks positions, or a wrong brick color.
In this sense it would be great to have the ability to change the color directly in LPub. Of course this can already be done by typing the color code, but it would be more convenient to have a table with the colors and just have to click on the proper one.
When it comes to brick position also here it would be great to be able to adjust the position of bricks back and forth up and down and so forth by just clicking on some buttons which makes them move by standard distances like 1 plate in height and 1/2 brick in x,y. (or custom configurable in the prefs)
I also like to move bricks temporarily to generate more clear instructions (For this there is a specific Ldraw instruction, but I find too cumbersome and time consuming to use). I personally indeed export everything to PNG and combine instructions in Photoshop.

4) possibility to add extra custom arrows? This is something I personally do not need, but somebody might find useful.

I like all 4 ideas.

Specially number 4! Vector arrows would be so nice.
I gave this some thought: right clicking on an assembly image should have the option "Add arrow" (just like a callout).
A standard black arrow of some length and line thickness should be generated then.
Click this arrow will show 2 handles (like with the callout arrows) to manipulate the start and end point of the arrow.
Right-clicking the arrow must allow to change color, line width (and type since this is in now) and size of arrowhead.
It would be more awesome to add corners to arrows (callouts) or even curved arrows.

Point 3: Since I turned to LDCad as my favorite editor I think both LDCad and LPub3D should be made aware of eachother changing a file.
I think LDCad already does this: change a file in say a texteditor and returning to LDCad prompts it has detected changes and gives the option to reload. Make this vice versa and you could easily switch back and forth from your editor and LPub3D.
Personally I think LPub3D should remain a layout tool and not and LDraw editor.

Pont 2: This could be done with the Leocad editor? Though I have never used it.

Mattia Zamboni Wrote:3) in the menu which appears when right clicking on the main page the first top choice now is "Change page background". I personally preferred it before when it was "Add next step", just because I guess this command to be more often used overall. (I might be wrong though)

Good point. I was have trouble adjusting to that too. I am so used to right click and pick the first option for adding steps.

Mattia Zamboni Wrote:New possible features:
1) Currently when you click on an step image the cursor moves to the corresponding location on the right commands list, which is great. It would be useful if the same would happen when while clicking on a line of code the corresponding instruction image would get highlighted.

2) Rotation steps: Not sure whether it is just me, but when it comes to rotation steps I happen to more or less always use the same angles of vision. (example: 25 50 0 ABS). In my view it would be very convenient to have some buttons to generate these standard rotsteps with just a click. (customzable in the prefs?) Additionally it could help to have buttons to rotate by +/- 90° each axis on the currently selected rotstep. Just throwing ideas out there :-)

3)When I generate BIs I find myself often going back and forth from and to MLCAD to fix small issues, like an inaccurate bricks positions, or a wrong brick color.
In this sense it would be great to have the ability to change the color directly in LPub. Of course this can already be done by typing the color code, but it would be more convenient to have a table with the colors and just have to click on the proper one.
When it comes to brick position also here it would be great to be able to adjust the position of bricks back and forth up and down and so forth by just clicking on some buttons which makes them move by standard distances like 1 plate in height and 1/2 brick in x,y. (or custom configurable in the prefs)
I also like to move bricks temporarily to generate more clear instructions (For this there is a specific Ldraw instruction, but I find too cumbersome and time consuming to use). I personally indeed export everything to PNG and combine instructions in Photoshop.

4) possibility to add extra custom arrows? This is something I personally do not need, but somebody might find useful.

I like all 4 ideas.

Specially number 4! Vector arrows would be so nice.
I gave this some thought: right clicking on an assembly image should have the option "Add arrow" (just like a callout).
A standard black arrow of some length and line thickness should be generated then.
Click this arrow will show 2 handles (like with the callout arrows) to manipulate the start and end point of the arrow.
Right-clicking the arrow must allow to change color, line width (and type since this is in now) and size of arrowhead.
It would be more awesome to add corners to arrows (callouts) or even curved arrows.

Point 3: Since I turned to LDCad as my favorite editor I think both LDCad and LPub3D should be made aware of eachother changing a file.
I think LDCad already does this: change a file in say a texteditor and returning to LDCad prompts it has detected changes and gives the option to reload. Make this vice versa and you could easily switch back and forth from your editor and LPub3D.
Personally I think LPub3D should remain a layout tool and not and LDraw editor.

Pont 2: This could be done with the Leocad editor? Though I have never used it.

Hey Jaco, glad to hear you share some of my ideas.

When it comes to layout tool vs Ldraw editor I think that generally speaking having some redundancy doesn't hurt, so that everyone can choose to use the tool he prefers.
As an example Steps and Rotation steps -being purely instructions related- to me should belong more to the layout tool rather than the editor, but I don't mind having it in MLCAD as well.

Personally my (dream!) vision of the future LPub would be to have a powerful tool that starting from a model would allow to generate instructions almost from scratch. Is this possible? I don't know, mostly because it would probably require a quicker render response... but it would be surely very convenient.

An additional idea I had for LPub3D would be that when you move the mouse over the code on a specific line, to have the thumbnail of a part pop up when you mouse hover. This way if you need to shift a piece to a different step you can immediately recognize it. Of course having it highlight on the instruction page would be even better, but with the current solution requiring a manual refresh it is not feasible.

When you generate instructions for a physical printed book your space is defined. Sometimes you need to compress things in order to avoid generating a phone book(!), sometimes you need to expand them to fill nicely the page and avoid a new chapter to start on an odd page. For this reason there is a lot of back and forth to be done to add/remove/tweak steps.
That's the whole point of having a more powerful Layout tool.

I hope everyone understands that I am just doing a brainstorming here, since I feel that currently that's the most valuable contribution I can give to LPub. But it is of course up to you guys to comment whether my inputs make any sense and eventually to Trevor to decide which ones (if any) to implement :-)

LPub3D (or any LDraw software as far as I know) can't create building instructions on its own, like LDD. However, I don't think a lot of people use LDD's instruction generator, because aside from very basic brick-only models, it produces weird, unlogical and unbuildable instructions. The algorithm isn't smart enough. There is a program available that's similiar to LPub but for LDD, which is relatively popular.

Merlijn Wissink Wrote:LPub3D (or any LDraw software as far as I know) can't create building instructions on its own, like LDD. However, I don't think a lot of people use LDD's instruction generator, because aside from very basic brick-only models, it produces weird, unlogical and unbuildable instructions. The algorithm isn't smart enough. There is a program available that's similiar to LPub but for LDD, which is relatively popular.

I totally agree with Merlijn here. The instructions that LDD produces are virtually unreadable (very bad and low res quality) and quite unlogical with many hovering parts and tends to build so that with real bricks it is impossible.
Although Blueprint does the job far better then LDD, it still does not provide the freedom that LDraw and related tools do.
Let alone the modelling where LDD has only that many parts to use and some building techniques are not allowed.

Jetro de Château Wrote:Also, what LDView settings does LPub use for rendering?

I think these are the last settings you make in LDView.

At one point in time, I think LPub would use the "LPub" preference set in LDView, if that preference set was present. You can verify that by creating an "LPub" preference set and configuring it to do something obvious (like wireframe), and then switch to another preference set that doesn't have the same configuration.

Jetro de Château Wrote:Also, what LDView settings does LPub use for rendering?

I think these are the last settings you make in LDView.

At one point in time, I think LPub would use the "LPub" preference set in LDView, if that preference set was present. You can verify that by creating an "LPub" preference set and configuring it to do something obvious (like wireframe), and then switch to another preference set that doesn't have the same configuration.

I thought so too.
It would be nice to make it so again?
Has any of you tested this? I will do so tomorrow.

Yes guys, you are right. It took me several time to figure all out a couple of years ago, so let me share what I found:

LDview is a stand alone software which runs on its own configuration and parameters.
Within LDview you can set a bunch of preferences which can be saved in profiles to be defined in LDview, which unfortunately cannot be exported nor imported.
There is also no external config file (like an .ini file) but everything is stored directly in the Windows registry.
This implies that if you want to make a backup of your settings or pass them to somebody else you need to play with Regedit(careful!), look for the proper parameters and save them into a .reg file. This way you can load them into a different PC to restore the same settings.

That being said LPub is using the active preference set used by LDview. So if while using LPub you open LDview and change something, changes will be reflected in LPub the next time you refresh your page.
I personally would prefer LPub using its own LDview settings, but I doubt LDview currently allows this.

When it comes it render engine there are 2 options: LDGlite, and LDview. In my testing I found LDGlite to be much quicker but with lower image quality. LDview on the contrary can generate superb image quality but at the cost of speed. So my strategy is to use LDGlite during my work in LPub and switch to LDview just before printing/exporting.

If you are using LPub to generate the final instructions it is suggested to use 300dpi setting, which the standard commercial printing quality. If - like me - you are using an external software to combine your instructions, I personally got best results by exporting images at 600dpi and then scaling them back down to 300dpi within your graphics software. With this last solution I am able to generate excellent steps images in terms of quality.

Make sure to play around with the LDview settings (it is fun!) since you have tons of possible settings, including perspective, lighting, transparency, quality, colors, wireframe, gap between adjacent bricks, etc. This will allow you to generate your very own style instructions ;-)

Back then I unfortunately found no documentation on this, so it would be convenient to share all this on the LDraw website somewhere, instead of in my post. In addition all what I found was based on experiments, so I might be still be missing a few pieces of the puzzle :-)

Good luck with your activities!

- Mattia

PS: I'm on Windows, so I can't tell how LDView works in other operating systems.

Thank you for your insights. Very helpful. However, there are a few things I'd like to comment on.

I tried LDGLite and the render speed is fabulous. However, the result is different from LDView, not simply in quality, but for some strange reason, in size. See attached images (each with name of render engine used) and you'll see what I mean. I prepared the instructions using LDView, then switched to LDGLite to test render speed and got this surprising result.

I imagine I could set up a low quality render style in LDView to improve render speed in LPub and then change to a higher quality setting for generating the instructions. Still, that might not work. On one occasion I had been working on several instruction files and when I generated instructions one of the pages in the PDF was actually from another file!! What I had done was the following:
- I prepared instructions and created PDF file 1.
- I prepared and also created PDF instructions for file 2.
- I went back to file 1 because I realised there was a mistake on one page and only viewed/changed that page
- I then generated PDF instructions for file a again, but when I opened them one of the pages was from file 2!?!
Since then I make it a point to visualise every page in LPub before generating PDF instructions

Has anyone been able to get LDView to render studs with the LEGO logo?

Quote:I tried LDGLite and the render speed is fabulous. However, the result is different from LDView, not simply in quality, but for some strange reason, in size.

Ah, still the same old problem. I hoped it had been solved since I tried the same process (LDView only for final rendering)...

Quote:Has anyone been able to get LDView to render studs with the LEGO logo?

Yes, you have to enable it in LDView: preferences -> Primitives tab -> Enable primitive substitution (suggest to use second notch of slider) and check "Texture studs".
Not sure that it is worth the trouble since the logos are barely visible at model scale, it takes more time and make the image a tad less legible.

Philippe Hurbain Wrote:Yes, you have to enable it in LDView: preferences -> Primitives tab -> Enable primitive substitution (suggest to use second notch of slider) and check "Texture studs".
Not sure that it is worth the trouble since the logos are barely visible at model scale, it takes more time and make the image a tad less legible.

Thanks. I missed them mostly on the LDView render I did to create an image of the complete model for the front page. Including them in building steps doesn't sound like a good idea indeed.

Edit: just checked and it turns out I had that option set. I had to zoom in really close and then I could just make out the letters. I thought they were more visible...

Is LPub3D using the default isometric view in ldglite? That might explain the size differences. I'm pretty sure I added some options to override that on the command line way back when Kevin was still working on LPub. But I don't remember exactly what it was. The secret might be in the lugnet logs, or possibly in the CVS logs of the ldglite sourceforge repository. The same options should also let you move the light source to better match ldview.

The best trick for improving ldglite output image quality is to scale up the display with -S2 and -W2 and then resample the output image file to half size with an external program like imagemagick. This trick is documented in the readme.txt file and may have been used once upon a time by the parts tracker. It makes the edge lines nice and smooth without resorting to the cheesy -q setting, and it eliminates the hideous dithering on transparent parts.

But since it's extra work to pass it through another program I decided to incorporate the decimation filter into the png output code of ldglite instead. So with the latest sources in CVS you can use -2x,2g to indicate that you want to double the size and then resample back down with an antialiasing blur filter on output. I also incorporated the lpub3d changes for ldsearchdirs, albeit with a special makefile.lpub3d so I can still build my own version with a plain C compiler.

Another trick you can try is moving the light source directly behind the viewer to match ldview better with something like -lc0,1000,1000 on the command line. I'd love to try and test some of these tricks directly in lpub3d but I don't know how to add things to the command line it passes to ldglite.

I'm sorry ... you are right: I took a shortcut in my explanation.
Yes, when I said LDGlite is producing lower quality images I should have said also different. Color shadows and gradients on the brick are poor, the wire isn't always black as it should (except for black bricks), anti-aliasing not as good as LDView, well generally speaking not usable in my opinion for high quality instructions and size is not quite matching.... but it is amazingly fast and help speed up the rough work.
I personally try to make the instructions as close as possible as the LEGO Group, so I personally don't care about the LEGO logo since they are not using it either.

The mixup happened to you is because LPub is keeping a cache of step images in a temp folder in order to speed up image rendering process. From time to time if you change a step and do not refresh, or if you load different files form the same folder mixups can happen. Just make sure to empty the cache (there are 2 menu items for this in LPub3D) and you are good to go!

Mattia Zamboni Wrote:The mixup happened to you is because LPub is keeping a cache of step images in a temp folder in order to speed up image rendering process. From time to time if you change a step and do not refresh, or if you load different files form the same folder mixups can happen. Just make sure to empty the cache (there are 2 menu items for this in LPub3D) and you are good to go!

Maybe there could be an option in preferences that allows you to force LPub to empty the cache before creating a PDF?

Mattia Zamboni Wrote:That being said LPub is using the active preference set used by LDview. So if while using LPub you open LDview and change something, changes will be reflected in LPub the next time you refresh your page.
I personally would prefer LPub using its own LDview settings, but I doubt LDview currently allows this.

At one time LPub included -PreferenceSet=LPub on the command line. This allowed a power user to create an LPub preference set in LDView and configure it exactly like they wanted.

Mattia Zamboni Wrote:When it comes it render engine there are 2 options: LDGlite, and LDview. In my testing I found LDGlite to be much quicker but with lower image quality. LDview on the contrary can generate superb image quality but at the cost of speed. So my strategy is to use LDGlite during my work in LPub and switch to LDview just before printing/exporting.

It's worth mentioning that (possibly minor) changes in LPub could increase rendering speed using LDView. Specifically, if it asks LDView to render multiple files using a single call to LDView, things speed up some. A test with three random unrelated LDR files gave 4.3 seconds to generate snapshots for the 3 files with 3 separate executions of LDView, and 2.6 seconds with one command line requesting that LDView render all three files. I suspect that if the files were multiple steps of the same source model, the speedup would be greater.

Rendering multiple files is done by using -SaveSnapshots=1 instead of -SaveSnapshot=somefile.png. Then, simply listing all the LDR files at the end of the command line will cause all to be rendered in a single call. This does require that all other command line options be the same, and you have no control over the snapshot filenames. (They'll be the original LDR filename, but with an appropriate extension, like png.)

This is good information. Indeed, it would be a relatively straightforward enhancement - assuming no intelligence is expected from the output file name which I suspect may not be the case.

Cheers,

Well - this enhancement most certainly was not straightforward !!
LPub3D dynamically uses attributes from each image' file name and content as it builds each step (list parts and model). Significant rework is also necessary to manage to maintain the file name intelligence. Therefore, one must practically rewrite part of this core logic to isolate the generation of images to a single call as described by Travis.

Anyway, I have done it! However, the command output is not as expected.

Only the first input file is rendered and it is given the name '1' without extension. Additionally, when I run the command with the LPub3D parameter set, the rendered image is cropped. With only the '-SaveSnapShot=1' parameter a complete image is rendered.

Here is the command I am generating - formatted with current LPub3D parameters to test from the command window or batch file:

Many thanks for your kind words. This all started because I wanted to help my daughter describe her Mindstorms project.

Mattia Zamboni Wrote:1) The incompatibility related to the "Add/CHANGE line type attribute to border configuration" with previous LPub versions should be in my opinion be fixed by assigning a value by default to the missing value in case of older file, instead of generating a parsing error which might not be trivial to understand to unexperienced users. This is of course just a suggestion.

I thought about this option and finally decided the time to write logic to do a one-time update was not worth the update itself. If it was the case where files would be useable between LPub and LPub3D then for sure I would have silently addressed this change but this is not the case. So old border metas must be manually updated and once a file is configured for LPub3D there is no further action for LPub3D or the user to do.

Mattia Zamboni Wrote:2) wrong text (I'm just being picky here!): when you export to PNG the window title says "Print to pdf"

I'll take a look at this - thanks.

Mattia Zamboni Wrote:3) in the menu which appears when right clicking on the main page the first top choice now is "Change page background". I personally preferred it before when it was "Add next step", just because I guess this command to be more often used overall. (I might be wrong though)

I'll take a look at this also - thanks.

Mattia Zamboni Wrote:New possible features:
1) Currently when you click on an step image the cursor moves to the corresponding location on the right commands list, which is great. It would be useful if the same would happen when while clicking on a line of code the corresponding instruction image would get highlighted.

What functional value does this feature provide ? A user must still 'select' the image by a context menu right-click to perform an action. While there may be some 'kool!' factor in having this behavior, I'm not sure what else it achieves.

Mattia Zamboni Wrote:2) Rotation steps: Not sure whether it is just me, but when it comes to rotation steps I happen to more or less always use the same angles of vision. (example: 25 50 0 ABS). In my view it would be very convenient to have some buttons to generate these standard rotsteps with just a click. (customzable in the prefs?) Additionally it could help to have buttons to rotate by +/- 90° each axis on the currently selected rotstep. Just throwing ideas out there :-)

Ok, this is a vary contextual request. If I were to implement this then I'd have to satisfy every user's expectation of having the options they 'more or less' use - so that would be a selection of 4 angles x 2 directions (positive, negative) x 2 ABS/REL x 3 axes = 48 buttons.

Mattia Zamboni Wrote:3)When I generate BIs I find myself often going back and forth from and to MLCAD to fix small issues, like an inaccurate bricks positions, or a wrong brick color.
In this sense it would be great to have the ability to change the color directly in LPub. Of course this can already be done by typing the color code, but it would be more convenient to have a table with the colors and just have to click on the proper one.
When it comes to brick position also here it would be great to be able to adjust the position of bricks back and forth up and down and so forth by just clicking on some buttons which makes them move by standard distances like 1 plate in height and 1/2 brick in x,y. (or custom configurable in the prefs)
I also like to move bricks temporarily to generate more clear instructions (For this there is a specific Ldraw instruction, but I find too cumbersome and time consuming to use). I personally indeed export everything to PNG and combine instructions in Photoshop.

Considering the effort to implement this this behavior in LPub3D, one should be sure every step is sufficiently configured before embarking on producing instructions - or be prepared to return to their modeling solution to make adjustments. With sophisticated modelers like LDCad, the experience should be better.
Perhaps a feature worth considering is being able to launch the current model file in your preferred modelling application.

Mattia Zamboni Wrote:4) possibility to add extra custom arrows? This is something I personally do not need, but somebody might find useful.

Ok - since you do not need this an no one else has requested this and as custom arrows can be added in any modelling application at this time - will you pay 1,000 Euros for this enhancement :-)

Jetro de Château Wrote:And what about adding a circle to highlight something?

I do this by adding the letter O like, for example red, text in a large font size suitable of a font that has a near shaped circle for the letter O or any other font that has some kind of circle in it.

Come to think of it... I also use this trick sometimes with arrows. For example I use the character of the either Wingdings font that represents certain arrows. However, these can only be used if the arrow is staight. You cannot exactly manipulate the way the textfield is rotated to compensate the correct direction the arrow must be in.

Thinking while I type this reply: you could in theory create a font with some tools and draw certain arrows and symbols you can use in instructions.

I also steel some symbols of official instructions that have vector graphics in them and then use a tool like Adobe Acrobat Professional to add these to my instructions (see the attachment to this reply "Symbolen.pdf").

Many thanks for your kind words. This all started because I wanted to help my daughter describe her Mindstorms project.

Mattia Zamboni Wrote:1) The incompatibility related to the "Add/CHANGE line type attribute to border configuration" with previous LPub versions should be in my opinion be fixed by assigning a value by default to the missing value in case of older file, instead of generating a parsing error which might not be trivial to understand to unexperienced users. This is of course just a suggestion.

I thought about this option and finally decided the time to write logic to do a one-time update was not worth the update itself. If it was the case where files would be useable between LPub and LPub3D then for sure I would have silently addressed this change but this is not the case. So old border metas must be manually updated and once a file is configured for LPub3D there is no further action for LPub3D or the user to do.

I was probably not clear enough on this, I'm sorry. When I talk about LPub itself I am just being generic not necessarily referring to the previous version of LPub3D. In this case I just though it is weird that going from LPub3D 1.3.0 to LPub3D 1.3.4 it generates this kind of errors. This occurs to me since I have been using your rev 1.3.0 for quite a while and generated a lot of files. But again, nothing major.

Trevor Sandy Wrote:

Mattia Zamboni Wrote:New possible features:
1) Currently when you click on an step image the cursor moves to the corresponding location on the right commands list, which is great. It would be useful if the same would happen when while clicking on a line of code the corresponding instruction image would get highlighted.

What functional value does this feature provide ? A user must still 'select' the image by a context menu right-click to perform an action. While there may be some 'kool!' factor in having this behavior, I'm not sure what else it achieves.

Well, please understand: I would never suggest a feature if I don't think it could be really useful. When you are navigating the code it is not always trivial to immediately understand a line of code to which step image it is related. When generating building instructions for complex models in order to generate them as clear as possible it occurs a lot that you need to shift parts from one step to another. So getting oriented in the code is fundamental and can save a lot of time of retrial and error. The goal is really just to understand whether the code you are about to tweak is referring to the right step image. But again this is just a suggestion.

Trevor Sandy Wrote:

Mattia Zamboni Wrote:2) Rotation steps: Not sure whether it is just me, but when it comes to rotation steps I happen to more or less always use the same angles of vision. (example: 25 50 0 ABS). In my view it would be very convenient to have some buttons to generate these standard rotsteps with just a click. (customzable in the prefs?) Additionally it could help to have buttons to rotate by +/- 90° each axis on the currently selected rotstep. Just throwing ideas out there :-)

Ok, this is a vary contextual request. If I were to implement this then I'd have to satisfy every user's expectation of having the options they 'more or less' use - so that would be a selection of 4 angles x 2 directions (positive, negative) x 2 ABS/REL x 3 axes = 48 buttons.

Well, I totally understand your point, but that is of course not what I meant. I was thinking that adding a button which just with a click adds a rotation step with values taken from the prefs (same way the grids values in MLCAD) could be really useful. Generally speaking every callout should have its own rotstep definition, since if not it inherits it from the main assembly. When generating instructions you can easily forget to define some of them and that's just an example of where it could be handy. And the +/- 90 deg buttons (even just x,y axis in my opinion) would be the cherry on the pie.

Trevor Sandy Wrote:

Mattia Zamboni Wrote:3)When I generate BIs I find myself often going back and forth from and to MLCAD to fix small issues, like an inaccurate bricks positions, or a wrong brick color.
In this sense it would be great to have the ability to change the color directly in LPub. Of course this can already be done by typing the color code, but it would be more convenient to have a table with the colors and just have to click on the proper one.
When it comes to brick position also here it would be great to be able to adjust the position of bricks back and forth up and down and so forth by just clicking on some buttons which makes them move by standard distances like 1 plate in height and 1/2 brick in x,y. (or custom configurable in the prefs)
I also like to move bricks temporarily to generate more clear instructions (For this there is a specific Ldraw instruction, but I find too cumbersome and time consuming to use). I personally indeed export everything to PNG and combine instructions in Photoshop.

Considering the effort to implement this this behavior in LPub3D, one should be sure every step is sufficiently configured before embarking on producing instructions - or be prepared to return to their modeling solution to make adjustments. With sophisticated modelers like LDCad, the experience should be better.
Perhaps a feature worth considering is being able to launch the current model file in your preferred modelling application.

I like your idea and you are probably right that it might more convenient to simply have the main editor open for this. Important is the integration of the different software which in this case should guarantee proper files syncronization.

Trevor Sandy Wrote:

Mattia Zamboni Wrote:4) possibility to add extra custom arrows? This is something I personally do not need, but somebody might find useful.

Ok - since you do not need this an no one else has requested this and as custom arrows can be added in any modelling application at this time - will you pay 1,000 Euros for this enhancement :-)

Somebody apparently already answered you on this, so you might be eventually able to raise your 1000 Euros ;-))

---

On a different note I would like to give you a background and explain where my comments are coming from. I am totally aware what I am about to say might sound like I'm bragging, but this is really not my intention.
Just like everyone on this forum I love LEGOs and in particular virtual LEGOs: especially in relation with graphic design.
And that's why I love to dedicate my spare time to create books. For the last 2 years I have been working on this new book of mine which will include full instructions for about 40 models, all from several model designers. For most of them I had to recreate the 3D model and for all of them the instructions. Models even if small in size are at times using quite fancy building techniques, making the building instructions generation a true nightmare. Working with a publisher I'm also facing the real world problems when it comes to the physical book, its size, pages counts, etc.
As you can imagine I spent quite some time on the Ldraw tools including LDD.
Since this is not my main occupation I have to make sure I use my time in the most efficient way, so that's why even a single mouse-click saved (repeated tons of times) can eventually make a difference.
As mentioned before, right now I feel the most valuable thing I can do is provide my feedback as a "heavy" user, that's all.
But everyone should just take it as input for discussion. I am personally not expecting anything, just want to share my experience and point of view.
This is and will always be the spirit behind my comments.

Once more thank you Trevor and everyone who has contributed to the Ldraw tools: you are really doing a lot for this community and this is commendable.

Trevor - thanks so much for everything you've done. It's very nice to have a version of LPub being actively developed again.

Here are a few random bugs / issues I've made note of recently:

- Split BOM will often (perhaps always?) duplicate one part onto both pages
- When changing the orientation of a callout to Rows or Columns, if you right-click a model in the callout and not the callout itself, the ALLOC is placed after the CALLOUT END and has no effect
- when page or BOM background is transparent, right-click context menu functionality is lost (minor, obvious workaround is to not set to transparent until I'm ready to export)
- Request: draw an outline of the page bounds when background is set to transparent

Thanks for the source updates. I've got a few questions if it's not too much trouble...

Have the changes been put to the test on any systems other than Windows? If not, I'll try and see what happens on linux (and OS-X if my ancient emac still runs, or the icebook I suppose).

Where do I find ldsearchdirs.h? I have a vague memory that makes me think maybe there was a sourceforge project somewhere with the ldrawsearchdirs code, but I haven't found it yet.

I noticed that code like this:
function("Some String")
is replaced quite often by code that looks like this:
{
char* str = "Some String";
function(str);
}

Is there some new C standard that forces that construct on us? I don't like it, but I guess times change... Or is this maybe a C++ thing caused by some of the files foolishly using the .cpp extension when they're actually plain old C code?

And finally, if anyone remembers how to use manage a sourceforge cvs repository I could use some hints. Apparently cvs is deprecated to the point where they've removed most of the documentaion. Right now I'm limited to the annonymous read-only access that's still documented. I'm almost tempted to start over with ldglite code someone stashed on github.

Don Heyse Wrote:Have the changes been put to the test on any systems other than Windows? If not, I'll try and see what happens on linux (and OS-X if my ancient emac still runs, or the icebook I suppose).

No, but I did the enhancement using Cygwin.

Don Heyse Wrote:Where do I find ldsearchdirs.h? I have a vague memory that makes me think maybe there was a sourceforge project somewhere with the ldrawsearchdirs code, but I haven't found it yet.

It's part of the LPub3D source, you can see on sourceforge.net - follow the link in the LPub3D about menu item.

Is there some new C standard that forces that construct on us? I don't like it, but I guess times change... Or is this maybe a C++ thing caused by some of the files foolishly using the .cpp extension when they're actually plain old C code?

The mingw 4.9.2 compiler was complaining about the original code being obsolete. I didn't change any extensions just used what i downloaded. My goal was to implement the functionality I needed for LPub3D - as described in update notes. I did not think this code base was maintained. Please feel free to throw out anything I've done as you please.

Don Heyse Wrote:And finally, if anyone remembers how to use manage a sourceforge cvs repository I could use some hints. Apparently cvs is deprecated to the point where they've removed most of the documentaion. Right now I'm limited to the annonymous read-only access that's still documented. I'm almost tempted to start over with ldglite code someone stashed on github.

You could use TortoiseCVS to download your source and repost on SVN or github.

I wouldn't exactly say the ldglite codebase is maintained. I haven't touched it in a few years, and then there's this ldraw-linux fork which hasn't even kept up with my latest efforts. However if it's still useful as a quick and dirty previewer for lpub then that's worth investigating, because lpub is really neat. In the long run, I think you'll have better luck if you work out some IPCs with ldview so you only incur the startup penalty once per model. I could imagine an ldview server with an IPC channel that accepts commands. That'd be perfect for this. The only reason I can see why ldglite might be faster right now is because there are no startup costs. It uses very little memory and renders as it reads the file.

meanwhile I've managed to access the ldglite sourceforge cvs repository and make a small change to the linux makefile, so I'm all set with that. I even forked that github archive and tried to push my changes from downstream to see if there's anyone home there.

I think I'm gonna rename the .cpp files from L3 to .c so they don't confuse the compiler and force silly changes like that string stuff. CVS doesn't make that easy, which is probably why I never did it before.

I was confused between ldrawsearchdirs and ldrawini but I think I'm good now. Thanks.

So what can I do to ldglite that would make it work better for lpub?

I think I'd like to tackle that scaling problem for starters. I spent some time trying to make it compatible with the L3p view configuration and had some success with that. But I don't remember if Kevin ever asked for anything specific to make it mesh better with ldview. I could use a set of batch files (ldglite, ldview, l3p) that should generate the same image for say the car.dat sample file, but don't because the scaling is off in ldglite. I'll get them myself eventually, but that'll take a while.

It's worth mentioning that the lpub code mentions scaling ldglite line widths because ldglite is 72DPI. I imagine that's because ldglite uses ldraw units for everything and they work out to 72ldraw units per inch. If LPUB runs things at 100 DPI then perhaps we only need to add -s0.72 to the ldglite command line to make the scaling compatible.

It's also possible that this patch could fix the problem. It tries to avoid using the weird squished LDRAW.EXE compatible view whenever a perspective projection is selected. ie. with -J on the command line. That's been on my todo list for a few years now. I hope lpub3d will install on my ancient pentium3 windows laptop so I can test the patch.

What else needs work? I guess ldview uses a different light source location. That should be easy to fix. Anything else?

I think I've come up with some reasonably good solutions for the rendering issues with ldglite in LPub3D. To take advantage would require a few small changes to the LPub3D render.cpp file, but nothing major.

Now I'm attempting to incorporate the directory search changes into ldglite and I've got a few questions about the difference between LDrawIni and the ldrawsearchdirs code in patch. Scroll down to the end of the blog post for the questions. It pretty much boils down to whether or not there were intentional deviations from LDrawIni, and if so, do I need to keep them to maintain LPub3D compatibility? Or can I just use LDrawIni as is?

Sorry for the delay to respond. I read the questions in your blog. Indeed, you are correct in your conclusion that "LPub3D search strategy makes use of the LDrawIni codebase, but takes some shortcuts on the LDrawIni approach."

In fact, I've incorporated the LDrawini class and I also make use of LDView's codebase to instantiate the search directories. Keep in mind that the LDrawini class' purpose is to process the ldraw.ini configuration settings - it passes the "hard coded" defaults if unable to process the .ini file. One must still write something to initialize and process the search directories passed by LDrawini - this is what the ldsearchdirs class does.The ldsearchdirs class also supports other functionality in LPub3D like resetting the search dirs in preferences.

The LDSEARCHDIRS environment variable is unique to LPub3D in that its purpose is to pass to ldglite a processed set of search directories. The LDSEARCHDIRS list is a '|' delimited list of directories that does not include Unofficial P and Parts because those directories are already searched by ldglite. In the event LDrawini is not used, i.e. no LDraw.ini configuraiton file found, LPub3D will populate LDSEARCHDIRS with all Unofficial sub-directories except P and Parts. You can see more details on this behavior in the LPub3D README file.

For LPub3D's use case, I did not implement LDrawini in ldglite because I did not want to engage un-necessary cycles searching arbitrary directories on each image submission. Instead, I just passed the explicit directories I wanted searched to preserve ldglite's performance advantage.

So to conclude, I would keep the LDSearchdirs code for two reasons: 1. Performance advantage, 2. If LDrawini is not used (no ldraw.ini file) ldglite will still be able to process multiple search directories prepared by LPub3D.

I don't think using ldrawini would add any significant performance delays in ldglite. I never included it before due to laziness, and eventually I simply forgot about it. No matter. It sounds like my plan of incorporating both ldrawini AND the LDSEARCHDIRS additions is the way to go. Perhaps I'll check and remove any duplicate dirs from the search list(s) after the RealDir macro expansion, just in case...

In the meantime, do you have any questions on the solutions I came up with for the rendering issues? You could probably pull the new main.c and ldglpr.c from CVS into your ldglite codebase and try it along with a few small changes to the LPub3D render.cpp code. I'm curious if the resampling filter in ldglpr.c adds any noticeable delays to LPub3D. I'm also still wondering if the LDView scaling fudge factors truly are unnecessary and incorrect.

Don Heyse Wrote:In the meantime, do you have any questions on the solutions I came up with for the rendering issues ?

Yes, I have some questions:

- Are the render.cpp changes to add the new command line parameters and updated existing parameter values you mention in your blog ?

- Can you summarize what the updated command line should look like including which new parameters could be static and which must be calculated ?

- Do you use freeglut in your latest build ?

I have not yet had an opportunity to include the new code you suggested. However once I have, I will let you know if I have more questions. I'll also take a look at the "LDView scaling fudge factors" and let you know if they are unnecessary/incorrect.

These are probably all static settings, unless LPub3D can move the light source.
Head on Lighting: "-lc0,1000,1000"
Black background: "-b0x2000000"

With the new ldglite code you should try this:
Filtered Resampling: "-2x,2g"

Instead of this:
Quality (AA) lines: "-q"

Everything else should remain the same.

I haven't switched to freeglut yet. But I kept your makefile mostly intact, I just renamed it to Makefile.lpub3d with a few tweaks. (I was considering adding -Wno-write-strings or maybe -Wno-deprecated to appease g++5 but haven't done it yet).

I've tried updating to the latest version that LPub informed me about (update available 1.3.3 > 1.3.5) and I've had to turn off my my Avast Anti Virus as it recognised the installer as malware

Does LPub3D need the path to an image I insert to be absolute or can it be relative too. I moved some files to a different location and had to reset the path to the cover image I used. A relative path would have avoided this situation.

Not sure if this is the best place to report issues, but here goes:
Inserting a front cover page doesn't work correctly if the current first page is a multi step page.
When you insert a front cover page on a normal page, a step is added before the current first step. No step is added if the first page is a multi step page so the inserted page isn't displayed. Manually adding a step solves this, but that ought to be automatic behaviour.

If I don't place a STEP command before ROTSTEP command the ROTSTEP command will affect the previous step.
AFAIK a ROTSTEP command is supposed to change the orientation of the next series of elements, not the previous ones.

No. It affects the previous step in LPub4, too. (And same in MLCAD, if I remember this correctly). That would be an incompatible behavior change, affecting all users. So I vote for keeping this behavior even we may feel it would be more logical to have it defined in another way. It's a matter of getting used with that, anyway. For me, it's important if/to LDCad author (Roland) implements the same logic.

Hi Trevor, I noticed since upgrading that pages with transparent backgrounds now have drop shadows for all elements, including when exported as .png. Is there any way to turn these off? Haven't found a setting anywhere. Apologies if this has already been asked, forum search didn't turn up any results.

From what I can see the callout is on top of your step number.
In the other two steps, the step number is immediately below the PLI. Here the callout is immediately below the PLi so it icovers the step number.

I like your layout though. What configuration do you use for this page setup?

this was my thought as well (and I should have specified in first post already) so I tried to move callout box around - still no number. On other page, I have single callout step with box on the right and still the number is not there.

When I tried to figure out what's happening, I tried switching the position of part list with respect to step number (the option is there) and when I select e.g. 'top left', the part list box jumps up above the page (only the very bottom stripe remains visible). In general, sometimes I got really weird things during playing around with positions. Many times, everything disappeared and I had to Ctrl+Z to get it back...

[EDIT] Restarted app and it works now, like you said! Thank you.

What exactly are you interested in regarding layout? I am absolute beginner so I did most of things ad-hoc and try'n'error

Actually I'd be interested in some guide on how to controll the layout - for example I'd like these steps always to fill the page (up to given page margins). For now, I have them centered and each page looks a bit different.

I like the PLI placement above the step number.
I'm going through the different configuration windows again to try and find out what they do, but there are so many options and it isn't always immediately clear what they do

True Jetro: the behavior of certain elements in a multi step layout are somewhat unpredictable.
The way Krištof places the PLI and stepnumber is the way LEGO does too. I use that too often.

Krištof: you'll have to find out by trial and error how to layout your page.
I am somewhat amazed that you are a beginner in using the software and what accomplished to make in a day!
Well done and welcome to the club ;-)

Well, within my engineering classes, dealing with obscure software is my daily bread To be honest, I quite like when I can edit the code which then compiles. The more automatic functions, the worse for me.

Actually I have to say that all LDraw software features are way more comprehensive than this forum - I struggle searching for anything here.

Therefore may I ask for any recommendation onto some command documentation for LPub3D? I'd like to learn some commands for more uniform and exact layout alignment, if only there are any.

Yep, I'm indeed very grateful for all the dedication Trevor puts into - it's a hobby, yet a high end one

I have now just basic question (hopefully) which I need to start with - refference points - that's something I don't understand yet. I found that I can position almost anything with respect to also almost anything, yet there is nowhere stated what is kept as the (top parent) fixed entitiy.

For instance I can position STEP_NUMBER under PLI and then ASSEM under STEP_NUMBER - that works but sometimes weirdly.

Similarly, I tried positioning STEP_NUMBER above ASSEM and PLI above STEP_NUMBER - which seem to work better. But now, what determines the position of ASSEM?

Isn't there any 'coordinate-ish' option how to determine exact positioning?

So where do I set the PLI above the stepnumber?
Or even better, what command does that?
(I'm building my own cheat sheet so I can simply copy it into a new set of instructions instead of going through all the menus every time)

I have a little feature request. I suppose this one is very easy to add.

It would be nice if the parts lists would be on top of the assembly image and not under. Just like the callouts. It's quite annoying when an assembly image overlaps a tiny bit of the parts list, while it's not necessary to see that particular little part of the assembly. I'm currently manually editing pages in Adobe Acrobat to have the parts list on top of the assembly image on pages where it happens. It would be nice if LPub3D did it automaticially

(2016-05-14, 11:00)Merlijn Wissink Wrote: I have a little feature request. I suppose this one is very easy to add.

It would be nice if the parts lists would be on top of the assembly image and not under. Just like the callouts. It's quite annoying when an assembly image overlaps a tiny bit of the parts list, while it's not necessary to see that particular little part of the assembly. I'm currently manually editing pages in Adobe Acrobat to have the parts list on top of the assembly image on pages where it happens. It would be nice if LPub3D did it automaticially

Merlijn - did you want to see this behavior on single-step pages only or also on multi-step pages ?

Slightly off-topic, but...
I'm trying to use LPub3D to render building instructions of my VEX models, and I face two issues. The main one is that part lists are missing (assemblies are rendered fine). I tried regular LPub (4.0.0.14) and here everything works fine...
The other problem is that I can't get the 3D preview to work, I directed the 3D viewer library archive to an archive of VEX parts, but all I get is bolored boxes.

(2016-05-19, 14:59)Philippe Hurbain Wrote: Slightly off-topic, but...
I'm trying to use LPub3D to render building instructions of my VEX models, and I face two issues. The main one is that part lists are missing (assemblies are rendered fine). I tried regular LPub (4.0.0.14) and here everything works fine...

Could this be it?http://forums.ldraw.org/thread-20962.html
LPub3D looks for unofficial parts in ldrawunf.zip in the folder LDraw3DViewer-Library
(on my system C:\Users\Public\Documents\LDraw\LDraw3DViewer-Library)
Putting parts in that zip that did not show up in the PLI worked fine.

(2016-05-25, 5:50)Jaco van der Molen Wrote: Could this be it?http://forums.ldraw.org/thread-20962.html
LPub3D looks for unofficial parts in ldrawunf.zip in the folder LDraw3DViewer-Library
(on my system C:\Users\Public\Documents\LDraw\LDraw3DViewer-Library)
Putting parts in that zip that did not show up in the PLI worked fine.

Thanks Jaco! That was not exactly the problem, but closely related, so you put be on the right track and solved both issues at the same time! It turns out that PLI/BOM images are created from complete.zip and ldrawunf.zip, not from the main library. ldrawunf.zip was not the problem, as all VEX parts are put in main library (though there are no "official" parts in VEX library: no part went through the Tracker approval process ). But my complete.zip didn't have the right structure, main folder inside the archive beeing named "VEXIQ Snapcad parts package - 2016-05-18" instead of "ldraw". Once renamed, both PLI/BOM and 3D-viewer worked fine!

(2016-05-25, 5:50)Jaco van der Molen Wrote: Could this be it?http://forums.ldraw.org/thread-20962.html
LPub3D looks for unofficial parts in ldrawunf.zip in the folder LDraw3DViewer-Library
(on my system C:\Users\Public\Documents\LDraw\LDraw3DViewer-Library)
Putting parts in that zip that did not show up in the PLI worked fine.

Thanks Jaco! That was not exactly the problem, but closely related, so you put be on the right track and solved both issues at the same time! It turns out that PLI/BOM images are created from complete.zip and ldrawunf.zip, not from the main library. ldrawunf.zip was not the problem, as all VEX parts are put in main library (though there are no "official" parts in VEX library: no part went through the Tracker approval process ). But my complete.zip didn't have the right structure, main folder inside the archive beeing named "VEXIQ Snapcad parts package - 2016-05-18" instead of "ldraw". Once renamed, both PLI/BOM and 3D-viewer worked fine!

(2016-05-20, 7:58)Jetro de Château Wrote: Another feature request I hope will be easy to implement:
LPub5 (https://sites.google.com/site/workingwit...om-version) has custom BOM options - particularly spreading a BOM over more than one page. Any change this can be added to LPub3D?

(2016-05-20, 10:45)Don Heyse Wrote: That's interesting. I never heard of this variant before but the lpub5 source code is available, and it looks to be about 10 commits beyond the baseline lpub4.

That would be a nice feature in LPub3D too. I suggested it before. And since the source is there, perhaps it is not too difficult to implement.
Depending on Trevor to do it! :-)
Speaking of: Trevor, how is the development of LPub3D going? I am sure you are busy, like all of us, but I am curious.

(2016-05-20, 7:58)Jetro de Château Wrote: Another feature request I hope will be easy to implement:
LPub5 (https://sites.google.com/site/workingwit...om-version) has custom BOM options - particularly spreading a BOM over more than one page. Any change this can be added to LPub3D?

(2016-05-20, 10:45)Don Heyse Wrote: That's interesting. I never heard of this variant before but the lpub5 source code is available, and it looks to be about 10 commits beyond the baseline lpub4.

That would be a nice feature in LPub3D too. I suggested it before. And since the source is there, perhaps it is not too difficult to implement.
Depending on Trevor to do it! :-)
Speaking of: Trevor, how is the development of LPub3D going? I am sure you are busy, like all of us, but I am curious.

Greetings Jetro - The bad news is I did not have any spare time to update LPub3D over the last 3 months. The good news is I now have some time and have been doing some bug-fixing. I'll also take a look at some of the requested enhancements, including the one above. Cheers.

(2016-05-26, 6:01)Trevor Sandy Wrote: Greetings Jetro - The bad news is I did not have any spare time to update LPub3D over the last 3 months. The good news is I now have some time and have been doing some bug-fixing. I'll also take a look at some of the requested enhancements, including the one above. Cheers.

Hi Trevor. It's nice to see you back. Please, can one of those feature requests or bugs fixed be "fix the Linux/Mac build" so I can both test and use LPub3D instead of LPub4 - and others, too?

(2016-05-26, 6:01)Trevor Sandy Wrote: Greetings Jetro - The bad news is I did not have any spare time to update LPub3D over the last 3 months. The good news is I now have some time and have been doing some bug-fixing. I'll also take a look at some of the requested enhancements, including the one above. Cheers.

Hi Trevor. It's nice to see you back. Please, can one of those feature requests or bugs fixed be "fix the Linux/Mac build" so I can both test and use LPub3D instead of LPub4 - and others, too?

Milan - A Mac port is on my short list of enhancements. Should not be a problem just a lot of busy work to qualify all functionality on that platform. I'll probably need some outside help with the Linux port as I don't have a dev environment - but let's see. Tonight I finished a long and painful LPub3D foundation upgrade to Qt 5.6. A lot of new capabilities will now be available. Cheers.

(2016-05-27, 2:12)Trevor Sandy Wrote: Milan - A Mac port is on my short list of enhancements. Should not be a problem just a lot of busy work to qualify all functionality on that platform. I'll probably need some outside help with the Linux port as I don't have a dev environment - but let's see. Tonight I finished a long and painful LPub3D foundation upgrade to Qt 5.6. A lot of new capabilities will now be available. Cheers.

Hello Trevor. I'm very busy with the next LEGO exhibition preparations, till next Sunday. But then, I offer you all my help with Linux: the dev machine image for you, my testing etc. And, if everything goes fine, we can add LPub3D as a new package of "Linux Ldraw" project and build rpm and deb packages automatically in the Build Service. I can help you with that as well, of course.

(2016-05-27, 2:12)Trevor Sandy Wrote: Milan - A Mac port is on my short list of enhancements. Should not be a problem just a lot of busy work to qualify all functionality on that platform. I'll probably need some outside help with the Linux port as I don't have a dev environment - but let's see. Tonight I finished a long and painful LPub3D foundation upgrade to Qt 5.6. A lot of new capabilities will now be available. Cheers.

Hello Trevor. I'm very busy with the next LEGO exhibition preparations, till next Sunday. But then, I offer you all my help with Linux: the dev machine image for you, my testing etc. And, if everything goes fine, we can add LPub3D as a new package of "Linux Ldraw" project and build rpm and deb packages automatically in the Build Service. I can help you with that as well, of course.

Excellent - I'll let you know when I start on the Mac port so we can work in parallel. Cheers.

(2016-05-20, 7:58)Jetro de Château Wrote: Another feature request I hope will be easy to implement:
LPub5 (https://sites.google.com/site/workingwit...om-version) has custom BOM options - particularly spreading a BOM over more than one page. Any change this can be added to LPub3D?

(2016-05-20, 10:45)Don Heyse Wrote: That's interesting. I never heard of this variant before but the lpub5 source code is available, and it looks to be about 10 commits beyond the baseline lpub4.

That would be a nice feature in LPub3D too. I suggested it before. And since the source is there, perhaps it is not too difficult to implement.
Depending on Trevor to do it! :-)
Speaking of: Trevor, how is the development of LPub3D going? I am sure you are busy, like all of us, but I am curious.

Greetings Jetro - The bad news is I did not have any spare time to update LPub3D over the last 3 months. The good news is I now have some time and have been doing some bug-fixing. I'll also take a look at some of the requested enhancements, including the one above. Cheers.

Ok, so I took a look at the LPub5 BoM management behavior and I have concluded the existing functionality in LPub3D already covers most of this behavior. The only part missing is the ability to generate a BoM with custom specified colors.

Currently in LPub3D one can "split" the BoM as often as one likes. Furthermore, there is the ability to sort the BoM by color and part size (default sort).

Because the current BoM management functionality in LPub3D is fully automatic - BoM parts are automatically divided across the number of BoM occurrences in the model file - I would have to reimplement this functionality to take into account adding BoMs where only a specifically defined color of parts are allowed.

Additionally, in LPub5, the meta entry to define the custom color choice is completely manual. This is impractical for models with a significant number of colored parts.

My main point is to efficiently implement this feature in LPub3D, will require considerable, albeit manageable, redesign and coding effort. So I don't think it will be in the next release.