LPub3D Unofficial parts in PLI

[Jetro de Château]

I ran into an issue today with unofficial parts not showing up in the PLI. They do turn up in the model itself though.
Specifically I am building a WeDo 2.0 model and when I add any of the unofficial parts they won't show up in the PLI (see attached image 1)
When I use a template that includes such a part all is OK (attached 2), but when I do a part substitution to get rid of the oddly shaped cable the part again goes missing (attached 3)

Is this a bug or is something wrong in my configuration?

I have tried restarting LPub3D, I have changed my renderer from LDView64x to LDView32x and LDGLite, but the problem persists with all of them. I have not been able to find any other settings that might affect this behaviour

[Trevor Sandy]

I ran into an issue today with unofficial parts not showing up in the PLI. They do turn up in the model itself though.
Specifically I am building a WeDo 2.0 model and when I add any of the unofficial parts they won't show up in the PLI (see attached image 1)
When I use a template that includes such a part all is OK (attached 2), but when I do a part substitution to get rid of the oddly shaped cable the part again goes missing (attached 3)

Is this a bug or is something wrong in my configuration?

I have tried restarting LPub3D, I have changed my renderer from LDView64x to LDView32x and LDGLite, but the problem persists with all of them. I have not been able to find any other settings that might affect this behaviour

Jetro,

I'll take a look. However, there is an alternative approach to substitutions via the part substitution list. You can see the list and instructions from the Configuration Menu (Edit PLI/BOM Substitute Parts List).

Cheeers,

[Jetro de Château]

I'll take a look. However, there is an alternative approach to substitutions via the part substitution list. You can see the list and instructions from the Configuration Menu (Edit PLI/BOM Substitute Parts List).

Cheeers,

I've looked at the substitution list before, but I'm afraid it won't work in this case. The motor is part of a template I inserted in LDCad. Templates are converted to MPD (sub)files and so each time you insert a template it could have a different name.

I added a BOM to the project and the unofficial parts don't turn up there either.

[Trevor Sandy]

I'll take a look. However, there is an alternative approach to substitutions via the part substitution list. You can see the list and instructions from the Configuration Menu (Edit PLI/BOM Substitute Parts List).

Cheeers,

I've looked at the substitution list before, but I'm afraid it won't work in this case. The motor is part of a template I inserted in LDCad. Templates are converted to MPD (sub)files and so each time you insert a template it could have a different name.

I added a BOM to the project and the unofficial parts don't turn up there either.

From my understanding LDCad templates are created with the name you define - or you can accept the default name proposed.  Therefore, you simply edit the substitute parts list file with the template name you defined as the default part and the shortcut or whatever representation you want as the alternate/substitute:

In this example the templates extension have been changed to .dat but this is not necessary to have the behaviour depicted.
   

I know very well this configuration. One may be likely to think that with the .ldr extension and 0 !LDRAW_ORG Unofficial_Model meta, the template is a model but, in fact, if you look at the source you will see it is also declared as a part with the meta 0 UNOFFICIAL PART; hence, why it automatically shows up in the LPub3D PLI.

I have been asking Roland for some time to consider allowing users the option to save a template with all the attributes of a part (i.e. .dat extension, 0 !LDRAW_ORG Unofficial_Part) but I understand this would conflict with the LDraw rules of 'unofficial' parts being parts that have not yet been approved. I can understand this position, even if I don't like it, so I have adapted LPub3D to recognize the 0 UNOFFICIAL PART meta; therefore, recognizing LDCad templates as parts (versus models) which they almost always are.

I could not reproduce your behaviour when I tested with 0 !LPUB PLI BEGIN SUB <part> <colour>/!LPUB PLI END metas. For me the behaviour was as expected.
   
   

Cheers,

[Jetro de Château]

From my understanding LDCad templates are created with the name you define - or you can accept the default name proposed.  Therefore, you simply edit the substitute parts list file with the template name you defined as the default part and the shortcut or whatever representation you want as the alternate/substitute:

In this example the templates extension have been changed to .dat but this is not necessary to have the behaviour depicted.


I know very well this configuration. One may be likely to think that with the .ldr extension and 0 !LDRAW_ORG Unofficial_Model meta, the template is a model but, in fact, if you look at the source you will see it is also declared as a part with the meta 0 UNOFFICIAL PART; hence, why it automatically shows up in the LPub3D PLI.

I have been asking Roland for some time to consider allowing users the option to save a template with all the attributes of a part (i.e. .dat extension, 0 !LDRAW_ORG Unofficial_Part) but I understand this would conflict with the LDraw rules of 'unofficial' parts being parts that have not yet been approved. I can understand this position, even if I don't like it, so I have adapted LPub3D to recognize the 0 UNOFFICIAL PART meta; therefore, recognizing LDCad templates as parts (versus models) which they almost always are.

I could not reproduce your behaviour when I tested with 0 !LPUB PLI BEGIN SUB <part> <colour>/!LPUB PLI END metas. For me the behaviour was as expected.



Cheers,

I had a feeling it might work that way, but my concern is that if I want to use the same template more than once I will be forced to rename the second and so substitution won't work.

Anyway, my concern wasn't so much with the substitution. I added that because I thought it odd the unofficial part did show up in the PLI if inside a template, but not if used directly. My real "problem" is that unofficial parts are not included in the PLI and I'm trying to figure out why (mainly because I really want them to show up).

I tried with a few more unofficial parts that weren't WeDo 2.0 related to see if it made any difference, but none show up in the PLI or BOM.

For now I guess I'll just dump the unofficial parts in the official parts folder to circumvent the issue...

---------------------------

I placed the "offending" parts in the official library and got no results. Now I am really lost.

I searched around a little more and checked out the refresh options in the Tools menu. Those allow you to download the latest version of the complete ldraw library or a specialised LPub version of the unofficial files (lbupdldrawunf.zip) which are then stored in C:/user/<username>/Appdata/Local/LPub3D Software/Lpub3D/libraries. However, under Configuration > Preferences the path to the LDraw root directory is selected as a different location (C:\Users\Public\Documents\LDraw). 

Could this be the source of the conflict? Is LPub not looking where I told it to (and where my unofficial parts are included in both the unofficial and official libraries)?

[Philippe Hurbain]

For now I guess I'll just dump the unofficial parts in the official parts folder to circumvent the issue...

Isn't it the same old problem with LPub3D that looks for parts in unofficial zip (for BOM and PLI only) instead of library? I understand the rationale for this behaviour but it remains a pain to maintain coherency between library and zip files. (note: that might not be relevant with latest LPub3D versions, not tested for some time)

[Jetro de Château]

For now I guess I'll just dump the unofficial parts in the official parts folder to circumvent the issue...

Isn't it the same old problem with LPub3D that looks for parts in unofficial zip (for BOM and PLI only) instead of library? I understand the rationale for this behaviour but it remains a pain to maintain coherency between library and zip files. (note: that might not be relevant with latest LPub3D versions, not tested for some time)

I am using the latest version: LPub3D 2.0.7 Revision 770 Build 4

----

Damn! Now I see an update was released only a couple of hours ago. I don't expect any changes though, based on the changelog. Downloading...

I suppose I'd have to manually add the missing files to the .zip file then...(?)

[Trevor Sandy]

From my understanding LDCad templates are created with the name you define - or you can accept the default name proposed.  Therefore, you simply edit the substitute parts list file with the template name you defined as the default part and the shortcut or whatever representation you want as the alternate/substitute:

In this example the templates extension have been changed to .dat but this is not necessary to have the behaviour depicted.


I know very well this configuration. One may be likely to think that with the .ldr extension and 0 !LDRAW_ORG Unofficial_Model meta, the template is a model but, in fact, if you look at the source you will see it is also declared as a part with the meta 0 UNOFFICIAL PART; hence, why it automatically shows up in the LPub3D PLI.

I have been asking Roland for some time to consider allowing users the option to save a template with all the attributes of a part (i.e. .dat extension, 0 !LDRAW_ORG Unofficial_Part) but I understand this would conflict with the LDraw rules of 'unofficial' parts being parts that have not yet been approved. I can understand this position, even if I don't like it, so I have adapted LPub3D to recognize the 0 UNOFFICIAL PART meta; therefore, recognizing LDCad templates as parts (versus models) which they almost always are.

I could not reproduce your behaviour when I tested with 0 !LPUB PLI BEGIN SUB <part> <colour>/!LPUB PLI END metas. For me the behaviour was as expected.



Cheers,

I had a feeling it might work that way, but my concern is that if I want to use the same template more than once I will be forced to rename the second and so substitution won't work.

Anyway, my concern wasn't so much with the substitution. I added that because I thought it odd the unofficial part did show up in the PLI if inside a template, but not if used directly. My real "problem" is that unofficial parts are not included in the PLI and I'm trying to figure out why (mainly because I really want them to show up).

I tried with a few more unofficial parts that weren't WeDo 2.0 related to see if it made any difference, but none show up in the PLI or BOM.

For now I guess I'll just dump the unofficial parts in the official parts folder to circumvent the issue...

---------------------------

I placed the "offending" parts in the official library and got no results. Now I am really lost.

I searched around a little more and checked out the refresh options in the Tools menu. Those allow you to download the latest version of the complete ldraw library or a specialised LPub version of the unofficial files (lbupdldrawunf.zip) which are then stored in C:/user/<username>/Appdata/Local/LPub3D Software/Lpub3D/libraries. However, under Configuration > Preferences the path to the LDraw root directory is selected as a different location (C:\Users\Public\Documents\LDraw). 

Could this be the source of the conflict? Is LPub not looking where I told it to (and where my unofficial parts are included in both the unofficial and official libraries)?

Jetro,

I had a feeling it might work that way, but my concern is that if I want to use the same template more than once I will be forced to rename the second and so substitution won't work.

You don't have to rename anything unless you want the PLI representation to somehow change every time you use the template - this would be very unusual because normally, the PLI representation should be a static view of the part across all PLIs/BOM etc...

Don't add any unofficial parts to your official library - archive or disc. If you want to consolidate, add them to your unofficial/parts directory instead. Keep in mind the archive libraries (complete.zip, lpub3dldrawunf.zip) are used exclusively by the 3D Viewer. Renderers use the disc library files.

Your behaviour is really unusual because normally if the part is rendered in the CSI then there should be a PLI representation. In the LPub3D directory created in the directory where you host your model file, you can check in the LPub3D/parts directory and see if the PLI parts are being rendered. If they are not, you can then check in the LPub3D/tmp directory to see if the PLI files are being generated for your custom parts. It's very easy to see all the CSI part files, if you have set LDView w/multiple files single call rendering - in such case each PLI file will be created with a file name starting with the part name. Open the PLI file with LDView to check if all is ok with the file. If the PLI files exist but no part images generated, you can also check to see if your naming convention for your custom parts is consistent.

Cheers,

[Jetro de Château]

From my understanding LDCad templates are created with the name you define - or you can accept the default name proposed.  Therefore, you simply edit the substitute parts list file with the template name you defined as the default part and the shortcut or whatever representation you want as the alternate/substitute:

In this example the templates extension have been changed to .dat but this is not necessary to have the behaviour depicted.


I know very well this configuration. One may be likely to think that with the .ldr extension and 0 !LDRAW_ORG Unofficial_Model meta, the template is a model but, in fact, if you look at the source you will see it is also declared as a part with the meta 0 UNOFFICIAL PART; hence, why it automatically shows up in the LPub3D PLI.

I have been asking Roland for some time to consider allowing users the option to save a template with all the attributes of a part (i.e. .dat extension, 0 !LDRAW_ORG Unofficial_Part) but I understand this would conflict with the LDraw rules of 'unofficial' parts being parts that have not yet been approved. I can understand this position, even if I don't like it, so I have adapted LPub3D to recognize the 0 UNOFFICIAL PART meta; therefore, recognizing LDCad templates as parts (versus models) which they almost always are.

I could not reproduce your behaviour when I tested with 0 !LPUB PLI BEGIN SUB <part> <colour>/!LPUB PLI END metas. For me the behaviour was as expected.



Cheers,

I had a feeling it might work that way, but my concern is that if I want to use the same template more than once I will be forced to rename the second and so substitution won't work.

Anyway, my concern wasn't so much with the substitution. I added that because I thought it odd the unofficial part did show up in the PLI if inside a template, but not if used directly. My real "problem" is that unofficial parts are not included in the PLI and I'm trying to figure out why (mainly because I really want them to show up).

I tried with a few more unofficial parts that weren't WeDo 2.0 related to see if it made any difference, but none show up in the PLI or BOM.

For now I guess I'll just dump the unofficial parts in the official parts folder to circumvent the issue...

---------------------------

I placed the "offending" parts in the official library and got no results. Now I am really lost.

I searched around a little more and checked out the refresh options in the Tools menu. Those allow you to download the latest version of the complete ldraw library or a specialised LPub version of the unofficial files (lbupdldrawunf.zip) which are then stored in C:/user/<username>/Appdata/Local/LPub3D Software/Lpub3D/libraries. However, under Configuration > Preferences the path to the LDraw root directory is selected as a different location (C:\Users\Public\Documents\LDraw). 

Could this be the source of the conflict? Is LPub not looking where I told it to (and where my unofficial parts are included in both the unofficial and official libraries)?

Jetro,

I had a feeling it might work that way, but my concern is that if I want to use the same template more than once I will be forced to rename the second and so substitution won't work.

You don't have to rename anything unless you want the PLI representation to somehow change every time you use the template - this would be very unusual because normally, the PLI representation should be a static view of the part across all PLIs/BOM etc...

Don't add any unofficial parts to your official library - archive or disc. If you want to consolidate, add them to your unofficial/parts directory instead. Keep in mind the archive libraries (complete.zip, lpub3dldrawunf.zip) are used exclusively by the 3D Viewer. Renderers use the disc library files.

Your behaviour is really unusual because normally if the part is rendered in the CSI then there should be a PLI representation. In the LPub3D directory created in the directory where you host your model file, you can check in the LPub3D/parts directory and see if the PLI parts are being rendered. If they are not, you can then check in the LPub3D/tmp directory to see if the PLI files are being generated for your custom parts. It's very easy to see all the CSI part files, if you have set LDView w/multiple files single call rendering - in such case each PLI file will be created with a file name starting with the part name. Open the PLI file with LDView to check if all is ok with the file. If the PLI files exist but no part images generated, you can also check to see if your naming convention for your custom parts is consistent.

Cheers,

Let's separate this into two parts:

1) missing PLI images

I am not using any custom parts. I have simply downloaded all the new WeDo 2.0 parts Philo created that are on the tracker and added them to my unofficial parts folder. These parts work fine when viewing a model in LDView or for building steps in LDPub3D. For some strange reason no PLI images are generated. I have checked the LDPub3D/Parts directory and the unofficial parts are not there. I have tried with a new ldr file that includes a number of different unofficial parts and the same thing happens: the build turns up, but the PLI is not generated.

I'm attaching an example file that includes some unofficial parts that don't generate a PLI and on the last page a template onverted to subfile that does display the very same motor that is not displayed earlier.

2) templates and substitution

When you include a template in an MPD file LDCad converts it to an independent submodel and requires you to provide a name for that ldr file. If you use the template a second time you need to provide a second, different name. In the case of the LPF2 M Motor for example the proposed file name is powerFunc2MotorM-1.ldr. If I need a second motor+cable assembly I would name it something like powerFunc2MotorM-2.ldr. I could of course add powerFunc2MotorM-[1-9].ldr to all change to 21980.dat...

[Trevor Sandy]

For now I guess I'll just dump the unofficial parts in the official parts folder to circumvent the issue...

Isn't it the same old problem with LPub3D that looks for parts in unofficial zip (for BOM and PLI only) instead of library? I understand the rationale for this behaviour but it remains a pain to maintain coherency between library and zip files. (note: that might not be relevant with latest LPub3D versions, not tested for some time)

Philo,

Not at all. Perhaps there is some misunderstanding here. 

LPub3D fully automates the setup and transfer of parts from the disc library to the unofficial archive library (lpub3dldrawunf.zip) checking each time on startup (you can see notifications in the splash progress). This is also why the LPub3D install program no longer prompts the user for the archive library path since 1.2.

Custom parts should be maintained by the user in the disc library only. 

Renderers, use the LDraw disc library to render both PLI and CSI renderings. Therefore, one should store their custom parts under the unofficial disc directory. The simplest configuration is just to dump your custom parts in the unofficial/parts folder. More complex configurations can be prepared if you are using an Ldraw.ini file - in which case you can define any number of personal directories under LDraw/unofficial. LPub3D looks under LDraw/unofficial and LDraw/models to automatically populate the unofficial archive library at startup. Archive libraries are used by the 3D Viewer only.  

Cheers,

[Trevor Sandy]

From my understanding LDCad templates are created with the name you define - or you can accept the default name proposed.  Therefore, you simply edit the substitute parts list file with the template name you defined as the default part and the shortcut or whatever representation you want as the alternate/substitute:

In this example the templates extension have been changed to .dat but this is not necessary to have the behaviour depicted.


I know very well this configuration. One may be likely to think that with the .ldr extension and 0 !LDRAW_ORG Unofficial_Model meta, the template is a model but, in fact, if you look at the source you will see it is also declared as a part with the meta 0 UNOFFICIAL PART; hence, why it automatically shows up in the LPub3D PLI.

I have been asking Roland for some time to consider allowing users the option to save a template with all the attributes of a part (i.e. .dat extension, 0 !LDRAW_ORG Unofficial_Part) but I understand this would conflict with the LDraw rules of 'unofficial' parts being parts that have not yet been approved. I can understand this position, even if I don't like it, so I have adapted LPub3D to recognize the 0 UNOFFICIAL PART meta; therefore, recognizing LDCad templates as parts (versus models) which they almost always are.

I could not reproduce your behaviour when I tested with 0 !LPUB PLI BEGIN SUB <part> <colour>/!LPUB PLI END metas. For me the behaviour was as expected.



Cheers,

I had a feeling it might work that way, but my concern is that if I want to use the same template more than once I will be forced to rename the second and so substitution won't work.

Anyway, my concern wasn't so much with the substitution. I added that because I thought it odd the unofficial part did show up in the PLI if inside a template, but not if used directly. My real "problem" is that unofficial parts are not included in the PLI and I'm trying to figure out why (mainly because I really want them to show up).

I tried with a few more unofficial parts that weren't WeDo 2.0 related to see if it made any difference, but none show up in the PLI or BOM.

For now I guess I'll just dump the unofficial parts in the official parts folder to circumvent the issue...

---------------------------

I placed the "offending" parts in the official library and got no results. Now I am really lost.

I searched around a little more and checked out the refresh options in the Tools menu. Those allow you to download the latest version of the complete ldraw library or a specialised LPub version of the unofficial files (lbupdldrawunf.zip) which are then stored in C:/user/<username>/Appdata/Local/LPub3D Software/Lpub3D/libraries. However, under Configuration > Preferences the path to the LDraw root directory is selected as a different location (C:\Users\Public\Documents\LDraw). 

Could this be the source of the conflict? Is LPub not looking where I told it to (and where my unofficial parts are included in both the unofficial and official libraries)?

Jetro,

I had a feeling it might work that way, but my concern is that if I want to use the same template more than once I will be forced to rename the second and so substitution won't work.

You don't have to rename anything unless you want the PLI representation to somehow change every time you use the template - this would be very unusual because normally, the PLI representation should be a static view of the part across all PLIs/BOM etc...

Don't add any unofficial parts to your official library - archive or disc. If you want to consolidate, add them to your unofficial/parts directory instead. Keep in mind the archive libraries (complete.zip, lpub3dldrawunf.zip) are used exclusively by the 3D Viewer. Renderers use the disc library files.

Your behaviour is really unusual because normally if the part is rendered in the CSI then there should be a PLI representation. In the LPub3D directory created in the directory where you host your model file, you can check in the LPub3D/parts directory and see if the PLI parts are being rendered. If they are not, you can then check in the LPub3D/tmp directory to see if the PLI files are being generated for your custom parts. It's very easy to see all the CSI part files, if you have set LDView w/multiple files single call rendering - in such case each PLI file will be created with a file name starting with the part name. Open the PLI file with LDView to check if all is ok with the file. If the PLI files exist but no part images generated, you can also check to see if your naming convention for your custom parts is consistent.

Cheers,

Let's separate this into two parts:

1) missing PLI images

I am not using any custom parts. I have simply downloaded all the new WeDo 2.0 parts Philo created that are on the tracker and added them to my unofficial parts folder. These parts work fine when viewing a model in LDView or for building steps in LDPub3D. For some strange reason no PLI images are generated. I have checked the LDPub3D/Parts directory and the unofficial parts are not there. I have tried with a new ldr file that includes a number of different unofficial parts and the same thing happens: the build turns up, but the PLI is not generated.

I'm attaching an example file that includes some unofficial parts that don't generate a PLI and on the last page a template onverted to subfile that does display the very same motor that is not displayed earlier.

2) templates and substitution

When you include a template in an MPD file LDCad converts it to an independent submodel and requires you to provide a name for that ldr file. If you use the template a second time you need to provide a second, different name. In the case of the LPF2 M Motor for example the proposed file name is powerFunc2MotorM-1.ldr. If I need a second motor+cable assembly I would name it something like powerFunc2MotorM-2.ldr. I could of course add powerFunc2MotorM-[1-9].ldr to all change to 21980.dat...

When you include a template in an MPD file LDCad converts it to an independent submodel and requires you to provide a name for that ldr file. If you use the template a second time you need to provide a second, different name. In the case of the LPF2 M Motor for example the proposed file name is powerFunc2MotorM-1.ldr. If I need a second motor+cable assembly I would name it something like powerFunc2MotorM-2.ldr. I could of course add powerFunc2MotorM-[1-9].ldr to all change to 21980.dat...

Precisely ! Or you could use the LPub metas - either way you'll have to address each unique occurrence but, for me, the substitution list is easier to configure and maintain.

I'm attaching an example file that includes some unofficial parts that don't generate a PLI and on the last page a template onverted to subfile that does display the very same motor that is not displayed earlier.

Ok - I'll take a look. Can you send a zipped copy of your unofficial library (with those WeDo parts you mentioned)  by email ? My address is in the About dialog at Feedback:

Cheers,

[Jetro de Château]

I'm attaching an example file that includes some unofficial parts that don't generate a PLI and on the last page a template converted to subfile that does display the very same motor that is not displayed earlier.

Ok - I'll take a look. Can you send a zipped copy of your unofficial library (with those WeDo parts you mentioned)  by email ? My address is in the About dialog at Feedback:

Cheers,

Sent.

[Trevor Sandy]

I'm attaching an example file that includes some unofficial parts that don't generate a PLI and on the last page a template converted to subfile that does display the very same motor that is not displayed earlier.

Ok - I'll take a look. Can you send a zipped copy of your unofficial library (with those WeDo parts you mentioned)  by email ? My address is in the About dialog at Feedback:

Cheers,

Sent.

All - seems ok on my system Win10/LPub3D 2.0.8 x64. Here's a video.

And the instructions...

  test.pdf (Size: 757.68 KB / Downloads: 7)

Cheers,

[Philippe Hurbain]

Good to know... As I said I haven't really used the latest versions, clearly I should!

[Jetro de Château]

It looks like the error was somewhere in my system.
I uninstalled LPub3D and did a clean re-install and now everything works as expected

[Roland Melkert]

I was wondering about something similar....

Is it possible to set the amount of parts the substitute should show. This would be needed when using a LDCad generated chain or thread.

Someone asked about this and it made me wonder as I can't find info about this myself (besizes the basic pli add sub meta).

[Trevor Sandy]

I was wondering about something similar....

Is it possible to set the amount of parts the substitute should show. This would be needed when using a LDCad generated chain or thread.

Someone asked about this and it made me wonder as I can't find info about this myself (besizes the basic pli add sub meta).

This is a great question. 

Parts like chains should reflect the number of occurrences based on the standard part representation. For example, if the standard chain part has a length of 20 links, then the PLI should display a representation as such. If, for example, a model consumes 5 chain parts (i.e 100 links), then it should be modelled in such a way as to indicate 5 occurrences of the chain part were used. If there are different parts representing different lengths (e.g. 20 links, 50 links ...), then the use of each should follow as previously described. The same as above holds for the use of thread with the exception of the PLI representation depicting the actual length of the part. 

If you look at the BOM for LEGO Technic 42042, you can see a good example of how thread is represented. With LPub3D, when a model is configured as described above, the LPub3D results will be just as those in 42042.

Cheers,

[Jaco van der Molen]

I see I've missed some interesting posts while on vacation....