LDraw.org Discussion Forums

Full Version: LPub3D Unofficial parts in PLI
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
(2016-08-05, 9:19)Jetro de Château Wrote: [ -> ]
(2016-08-05, 8:56)Trevor Sandy Wrote: [ -> ]
(2016-08-05, 7:45)Jetro de Château Wrote: [ -> ]
(2016-08-05, 0:58)Trevor Sandy Wrote: [ -> ]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,

Quote: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...

Quote: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.


Quote: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,
(2016-08-05, 9:31)Trevor Sandy Wrote: [ -> ]
Quote: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.
(2016-08-05, 9:38)Jetro de Château Wrote: [ -> ]
(2016-08-05, 9:31)Trevor Sandy Wrote: [ -> ]
Quote: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...
[attachment=2419]

Cheers,
Good to know... As I said I haven't really used the latest versions, clearly I should!
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
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).
(2016-08-10, 18:05)Roland Melkert Wrote: [ -> ]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,
I see I've missed some interesting posts while on vacation....
Pages: 1 2