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.
LPub3D 1.3.0 Released !
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...
See http://forums.ldraw.org/showthread.php?t...3#pid20443
:-)
Jaco van der Molen
lpub.binarybricks.nl
lpub.binarybricks.nl
Jetro de Château Wrote:I'd love to be able to add arrows directly in LPub3d!
Me too! Much sharper then adding LDraw shaped arrows that generate shadows and all.
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").
Jaco van der Molen
lpub.binarybricks.nl
lpub.binarybricks.nl
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.
Enjoy,
Don
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.
Enjoy,
Don
Trevor Sandy Wrote:Hi Mattia,
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: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.
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.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.
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.
Take care,
- Mattia
The formatting of this forum makes it difficult for me to use, so I'll post updates on my progress with ldglite inLPub3D here, at my blog, with plenty of pictures and code and stuff.
I'll update it as I go, but there's already plenty there.
Have fun,
Don
I'll update it as I go, but there's already plenty there.
Have fun,
Don
Hello Don,
Many thanks for your efforts to help improve LPub3D's rendering quality. I think we share the same approach to solving problems - simply solve them.
I am in Brazil until the end of the month so I won't have much time to integrate the updated ldglite into LPub3D before then.
Again, thanks.
Cheers,
Many thanks for your efforts to help improve LPub3D's rendering quality. I think we share the same approach to solving problems - simply solve them.
I am in Brazil until the end of the month so I won't have much time to integrate the updated ldglite into LPub3D before then.
Again, thanks.
Cheers,
Hello,
I have just started with using LDraw software yeterday. Using LPub3D to create some instructions and so far everything worked out for me but one thing:
When I add callout step onto multistep page, there is step number missing for such step. No mattet how I tried, I can't manage to have it there.
Thanks for help!
I have just started with using LDraw software yeterday. Using LPub3D to create some instructions and so far everything worked out for me but one thing:
When I add callout step onto multistep page, there is step number missing for such step. No mattet how I tried, I can't manage to have it there.
Thanks for help!
Hello Jetro
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.
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.
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 ;-)
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 ;-)
Jaco van der Molen
lpub.binarybricks.nl
lpub.binarybricks.nl
Thank you!
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.
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.
I'll second that request.
A great starting point is http://lpub.binarybricks.nl/, but at times it can still feel like a lot is un(der)documented
A great starting point is http://lpub.binarybricks.nl/, but at times it can still feel like a lot is un(der)documented
Jetro de Château Wrote:A great starting point is http://lpub.binarybricks.nl/, but at times it can still feel like a lot is un(der)documented
LPub3D as a version is centainly not well documented... yet.
Most of the LPub 4.0.0.11 documentation of my site applies to LPub3D too. And that is pretty well documented (if I do say so myself :-)
Since LPub3D is still under development, more bugs will be solved and features added thanks to the hard work of Trevor!
However: aligning things and laying out you want, is still a troublesome job.
Keep in mind: its a hobby! :-)
Jaco van der Molen
lpub.binarybricks.nl
lpub.binarybricks.nl
Thanks, I'll check out your older doc.
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?
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?
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?
Don
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?
Don
Hi Don,
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.
Regards,
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.
Regards,
Don't worry about the delay. "Real Life" kept me busy so I've done nothing since posing the questions.
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
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
Hello Don,
- 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.
Cheers,
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.
Cheers,
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).
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 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
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
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.
Any idea?
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.
Any idea?
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?
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?
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.
(2016-05-19, 14:59)Philippe Hurbain Wrote: Slightly off-topic, but...Could this be it?
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...
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.
Jaco van der Molen
lpub.binarybricks.nl
lpub.binarybricks.nl
(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.
Jaco van der Molen
lpub.binarybricks.nl
lpub.binarybricks.nl
RE: LPub3D 1.3.0 Released !
2016-05-25, 7:21 (This post was last modified: 2016-05-25, 13:28 by Philippe Hurbain.)
2016-05-25, 7:21 (This post was last modified: 2016-05-25, 13:28 by Philippe Hurbain.)
(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!
RE: LPub3D 1.3.0 Released !
2016-05-25, 7:59 (This post was last modified: 2016-05-25, 13:29 by Philippe Hurbain.)
2016-05-25, 7:59 (This post was last modified: 2016-05-25, 13:29 by Philippe Hurbain.)
Ah! Glad I could help _you_ this time :-)
(2016-05-25, 7:21)Philippe Hurbain Wrote:(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!
Jaco van der Molen
lpub.binarybricks.nl
lpub.binarybricks.nl
(2016-05-25, 5:53)Jaco van der Molen Wrote:(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?
RE: LPub3D 1.3.0 Released !
2016-05-27, 2:12 (This post was last modified: 2016-05-27, 2:15 by Trevor Sandy. Edit Reason: typo )
2016-05-27, 2:12 (This post was last modified: 2016-05-27, 2:15 by Trevor Sandy. Edit Reason: typo )
(2016-05-26, 10:01)Milan Vančura Wrote:(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-26, 6:01)Trevor Sandy Wrote:(2016-05-25, 5:53)Jaco van der Molen Wrote:(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.
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, 21:49)Milan Vančura Wrote:(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.
RE: LPub3D 1.3.0 Released !
2016-05-30, 10:55 (This post was last modified: 2016-05-30, 11:12 by Trevor Sandy. Edit Reason: wrong text )
2016-05-30, 10:55 (This post was last modified: 2016-05-30, 11:12 by Trevor Sandy. Edit Reason: wrong text )
(2016-05-14, 11:00)Merlijn Wissink Wrote: I have a little feature request. I suppose this one is very easy to add.Merlijn - did you want to see this behavior on single-step pages only or also on multi-step pages ?
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
RE: LPub3D 1.3.5: Feedback
2016-06-04, 14:06 (This post was last modified: 2016-06-04, 15:17 by Trevor Sandy. Edit Reason: Update )
2016-06-04, 14:06 (This post was last modified: 2016-06-04, 15:17 by Trevor Sandy. Edit Reason: Update )
(2016-02-12, 18:35)Trevor Sandy Wrote: Thanks Travis,
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:
Code:
"C:\Program Files\LDView\LDView64.exe" -ca0.01 -cg23 -45,4106503 -SaveAlpha=1 -AutoCrop=1 -ShowHighlightLines=1 -ConditionalHighlights=1 -SaveZoomToFit=0 -SubduedLighting=1 -UseSpecular=0 -LightVector=0,1,1 -SaveActualSize=0 -SaveWidth=1275 -SaveHeight=1650 -SaveSnapShot=1 C:/Users/Trevor/Desktop/LPub/6964-01/LPub3D/tmp/3795_72_1275_150_DPCM_1_23_-45.ldr C:/Users/Trevor/Desktop/LPub/6964-01/LPub3D/tmp/3794a_378_1275_150_DPCM_1_23_-45.ldr
Any help to sort this out will be appreciated!
Cheers,
« Next Oldest | Next Newest »
Users browsing this thread: 12 Guest(s)