Trevor Sandy Wrote:LPub3D 1.3.3.590.2Thanks so much for fixing those bugs and crashes!
Jaco van der Molen
lpub.binarybricks.nl
lpub.binarybricks.nl
LPub3D 1.3.0 Released !
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?
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?
Jaco van der Molen
lpub.binarybricks.nl
lpub.binarybricks.nl
If you can put the source archive somewhere on the internet, I'll fetch it and fold in the changes.
Or if it's not too large a change, you could make a patch file and submit that here. http://sourceforge.net/p/ldglite/patches/
It looks like I got a patch once before and managed to get it into the code.
Or if it's not too large a change, you could make a patch file and submit that here. http://sourceforge.net/p/ldglite/patches/
It looks like I got a patch once before and managed to get it into the code.
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.
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.
Hi Trevor,
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.
Take care!
- Mattia
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.
Take care!
- Mattia
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.
Jaco van der Molen
lpub.binarybricks.nl
lpub.binarybricks.nl
Jaco van der Molen Wrote: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 :-)
Thanks a lot.
- Mattia
May I throw some gravel in the machine here...?
I love the work you guys are doing here, but one thing people talked about in the fuzz about LDD, was the easy creation of build instructions and part lists.
Is LDCad or LPub3D able to create anything like that? Click a button and auto generate a partlist or a BI on a html-page, or any other file format?
I love the work you guys are doing here, but one thing people talked about in the fuzz about LDD, was the easy creation of build instructions and part lists.
Is LDCad or LPub3D able to create anything like that? Click a button and auto generate a partlist or a BI on a html-page, or any other file format?
Magnus Forsberg Wrote:Is LDCad or LPub3D able to create anything like that? Click a button and auto generate a partlist or a BI on a html-page, or any other file format?In LPub3D there is an option to place a BOM on a page (intended to be used on an empty page - I usually include it at the end of my PDF file)
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
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
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.
Jaco van der Molen
lpub.binarybricks.nl
lpub.binarybricks.nl
Jetro de Château Wrote:The render quality of Blueprint is fabulous though. I'd love to be able to generate higher quality instructions with LPub.
Setting the resolution to 150 or even 300 DPI produces printable and good enough quality for professional print.
I only got Blueprint to produce transparant outlined images....
Jaco van der Molen
lpub.binarybricks.nl
lpub.binarybricks.nl
Jetro de Château Wrote:Where do I change that setting? I checked under Configuration > Preferences, but don't see an option to choose quality.
You can find that in Configuration > Project setup
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.
Jaco van der Molen
lpub.binarybricks.nl
lpub.binarybricks.nl
Jaco van der Molen Wrote: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.
Travis Cobbs Wrote:Jaco van der Molen Wrote: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.
Jaco van der Molen
lpub.binarybricks.nl
lpub.binarybricks.nl
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.
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?
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.
Hi Jetro,
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!
Good luck,
- Mattia
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!
Good luck,
- Mattia
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?
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".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.
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.
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...
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.)
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.
Travis Cobbs Wrote: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.1. Does anyone know why that functionality was removed from LPub?
2. Can it be added again?
Jaco van der Molen
lpub.binarybricks.nl
lpub.binarybricks.nl
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.
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.
Travis Cobbs Wrote: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.I don't recall seeing this option/behavior, and I was not aware of it, but I also see no reason why it cannot be reintroduced.
Cheers,
Hi Don,
I also like using ldglite for the speed. The string I send from LPub3D is in the test file I sent you in the 1.3.0 patch so you can see exactly what commands are transferred to ldglite.
It would be great if you could share some 'tricks' to improving the image quality - even if I have to write some code to do it.
Cheers,
I also like using ldglite for the speed. The string I send from LPub3D is in the test file I sent you in the 1.3.0 patch so you can see exactly what commands are transferred to ldglite.
It would be great if you could share some 'tricks' to improving the image quality - even if I have to write some code to do it.
Cheers,
Hi Mattia,
Many thanks for your kind words. This all started because I wanted to help my daughter describe her Mindstorms project.
Perhaps a feature worth considering is being able to launch the current model file in your preferred modelling application.
Cheers,
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: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.
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.
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.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.
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.
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 :-)
Cheers,
Hi Don,
See my remarks below.
Cheers,
See my remarks below.
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.
Don Heyse Wrote:I noticed that code like this: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.
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?
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.
Cheers,
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 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?
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.
« Next Oldest | Next Newest »
Users browsing this thread: 9 Guest(s)