LPub3D - Submodel not shown in main model

[Johann Eisner]

Hi guys
After a long break, I work once again on a new building instrution for a MOC from a friend.
When adding submodels to the mainmodels, they are not shown in the main model.
This problem is on LPub3d - 2.3.6
Have download now the version 2.2.1, there is no problem.
Have anyone an idea?

Version 2.2.1:
   

Version 2.3.6:
   

[Jaco van der Molen]

Hi guys
After a long break, I work once again on a new building instrution for a MOC from a friend.
When adding submodels to the mainmodels, they are not shown in the main model.
This problem is on LPub3d - 2.3.6
Have download now the version 2.2.1, there is no problem.
Have anyone an idea?

Version 2.2.1:


Version 2.3.6:

Hmm, strange. Can you PM me the LDraw file? I'll take a look.

[Johann Eisner]

Hmm, strange. Can you PM me the LDraw file? I'll take a look.

Hi Jaco
Can not send a file via PM.
File is not a big secret.
So I attached the file.


Regards Johann

[Jaco van der Molen]

Hi Jaco
Can not send a file via PM.
File is not a big secret.
So I attached the file.


Regards Johann

OK, I have a few versions of LPUb3D running. In all versions the model and all submodels renders just fine.
Taking a look at the structure and hierarchy of the model and its contents I cannot spot anything that could cause this problem.

You might want to try to clear all caches and make sure all folders and generated images and files are gone. I.e. delete the LPub3D folder manualy.
Using multiple versions of LPub3D sometimes causes files that cannot be found by the other version or are not overwritten.
Also, remove LPub3D formatting and start over and see what happens.

I'd advice you to use version 2.3.7

The only thing I can think now of is the use of spaces in file names that messes things up.
My experience sometimes shows that LPub3D cannot handle this too well in some cases.

[Jaco van der Molen]

   

You might want to consider turning the submodel 180 degrees too since now it is displayed the other way around compared to how you would attach it.

[Philippe Hurbain]

I'd advice you to use version 2.3.7

Is this relevant?

[Jaco van der Molen]

Is this relevant?

Hmm, yes. I encoutered the same problems GREG998 describes there.
Some of them I could solve (by doing things a bit different), some not.

The ones that I could not solve, I start reporting to Trevor via Github.

I would agree that 2.3.6 is more stable than 2.3.7. So, Johann: try 2.3.6.

About installing/updating/uninstalling: I ran into trouble installing and updating it through the installer in Program Files.
This keeps settings in C:\Users\[username]\AppData\Roaming which does not turn out that well some times.

So since a while now I "install" as portable. Download the relevant Zip from here:
https://sourceforge.net/projects/lpub3d/files/2.3.6/
Then unpack in a LEGO folder or something.

This way settings are stored locally in the (sub)folder(s) where LPub3D is installed. And can easily be copied to the new version and one can have multiple version running.
Installing in Program Files, you cannot since settings are overwritten and seem not compatible all the time with versions.

I work on 3 laptops/PC's so on either machine I have the same setup:

C:\LEGO\LDraw\ (with library and stuff)
C:\LEGO\LDCad\
C:\LEGO\LPub3D\

That is all I need.

Next to that I do have C:\LEGO\LPub3D 2.3.6 and C:\LEGO\LPub3D 2.3.4.
This because files edited with 2.3.4 do strange things in 2.3.6 and 2.3.7 does strange things with 2.3.6 files.

[Johann Eisner]

Hmm, yes. I encoutered the same problems GREG998 describes there.
Some of them I could solve (by doing things a bit different), some not.

The ones that I could not solve, I start reporting to Trevor via Github.

I would agree that 2.3.6 is more stable than 2.3.7. So, Johann: try 2.3.6.

About installing/updating/uninstalling: I ran into trouble installing and updating it through the installer in Program Files.
This keeps settings in C:\Users\[username]\AppData\Roaming which does not turn out that well some times.

So since a while now I "install" as portable. Download the relevant Zip from here:
https://sourceforge.net/projects/lpub3d/files/2.3.6/
Then unpack in a LEGO folder or something.

This way settings are stored locally in the (sub)folder(s) where LPub3D is installed. And can easily be copied to the new version and one can have multiple version running.
Installing in Program Files, you cannot since settings are overwritten and seem not compatible all the time with versions.

I work on 3 laptops/PC's so on either machine I have the same setup:

C:\LEGO\LDraw\ (with library and stuff)
C:\LEGO\LDCad\
C:\LEGO\LPub3D\

That is all I need.

Next to that I do have C:\LEGO\LPub3D 2.3.6 and C:\LEGO\LPub3D 2.3.4.
This because files edited with 2.3.4 do strange things in 2.3.6 and 2.3.7 does strange things with 2.3.6 files.

HI Philo, hi Jaco

First of all, thanks for the help.

I installed a new fresh version of the complete Ldraw (AIOI 2018-01) on my second notebook at work just in this time.
Here with version 2.3.6 the submodel is show.

At home I have also have a fresh installation, after AIOI 2018-01 was avilable.
So the problem must be on my main maschine at home.


Johann

[Johann Eisner]

You might want to consider turning the submodel 180 degrees too since now it is displayed the other way around compared to how you would attach it.

Did you do a second submodel?
So you get two callouts or is there a new feature in LPud3D?

[Jaco van der Molen]

Did you do a second submodel?
So you get two callouts or is there a new feature in LPud3D?

That is not new but needs manual editing. Been there since the beginning of LPub.
No new submodel, but just separately called out.
Like so:

0 !LPUB CALLOUT BEGIN
1 0 0 -40 90 1 0 0 0 1 0 0 0 1 mxxxx - sub1.ldr
0 !LPUB CALLOUT END
0 !LPUB CALLOUT BEGIN
1 0 0 40 90 1 0 0 0 1 0 0 0 1 mxxxx - sub1.ldr
0 !LPUB CALLOUT END

Without the pointers.

[Johann Eisner]

That is not new but needs manual editing. Been there since the beginning of LPub.
No new submodel, but just separately called out.
Like so:

0 !LPUB CALLOUT BEGIN
1 0 0 -40 90 1 0 0 0 1 0 0 0 1 mxxxx - sub1.ldr
0 !LPUB CALLOUT END
0 !LPUB CALLOUT BEGIN
1 0 0 40 90 1 0 0 0 1 0 0 0 1 mxxxx - sub1.ldr
0 !LPUB CALLOUT END

Without the pointers.

Ahhhh....
I understand now.
Thanks.

[Johann Eisner]

HI Philo, hi Jaco

First of all, thanks for the help.

I installed a new fresh version of the complete Ldraw (AIOI 2018-01) on my second notebook at work just in this time.
Here with version 2.3.6 the submodel is show.

At home I have also have a fresh installation, after AIOI 2018-01 was avilable.
So the problem must be on my main maschine at home.


Johann

Delete the half computer...
Install the AIOI new....
Now it works fine.  

The error must have been in LDview, LDGlite rendered correctly.

[Jaco van der Molen]

Ahhhh....
I understand now.
Thanks.

Good!
Just choose Convert to Callout when the submodels are encountered and then manually edit the metacommands.
LPub converts 2 or more of the same submodel right after each other to one callout with x times used indication.
The behavior is similar to where you would use the same submodel in later steps in the model.

The only thing that you cannot do is display the callout in different ways, i.e. with rotation steps.
Since you work in the same submodel of course.

[Johann Eisner]

Hi guys
After a long break, ....

After the whole thing has not worked again, the thing is a bit overblown.
I reinstalled the AIOI twice, it still did not work.
Then I wanted to reset my system, which meant that Windows did not start anymore.
Windows reinstalled, AIOI reinstalled, bugs still there.

After I had almost given up, I tried to open the file on my tablet, no problem, everything is working properly.
Submodels are displayed. File sent a friend -> no problems. 
Cause research operated, almost desperate, computer almost thrown out the window, made coffee, gone into me, brainstorm ....
File copied to another directory ... tataaaa ..... no more problem.
And now the simple solution: As soon as the file is in a directory that contains an umlaut (ä, ö, ü) the submodels are not displayed.
Why wander into the distance when the solution is so close.
I could slap myself.

I hope I can help somebody in the future and spare him such a path of suffering.

Regards Johann

[Philippe Hurbain]

Ah... indeed... Using accentuated character in pathes or file names is something I generally avoid, as it often causes problems with programs written in countries where this situation doesn't occur and are thus not correctly tested. To a lesser degree, using space characters is to be avoided (very old programs were written in a time where space characters were not allowed!). Finally, I always configure my system to use '.' as decimal separator, it avoids me a lot of headaches too!

[Jaco van der Molen]

Ah... indeed... Using accentuated character in paths or file names is something I generally avoid, as it often causes problems with programs written in countries where this situation doesn't occur and are thus not correctly tested. To a lesser degree, using space characters is to be avoided (very old programs were written in a time where space characters were not allowed!). Finally, I always configure my system to use '.' as decimal separator, it avoids me a lot of headaches too!

Yes. Characters with accents and diacritical marks are a problem, as for spaces are too as Philo points out.
Dots in file names other than the dot that separates the file extension (.dat, .ldr or .mpd) is to be avoided too. Use a - or _ instead.
Although that can give problems since the files LPub3D produces are often with a lot underscores too. I always use capital letters in a certain way to name files. I.e. FrontDoorLeft.ldr or something, rather than "left front door.ldr"
Also, very long paths can be a problem too. There was a time once the path (including the file name) exceded 255 characters crashes could occur too.
I could go on with warnings and exceptions...

[Johann Eisner]

Yes. Characters with accents and diacritical marks are a problem, as for spaces are too as Philo points out.
Dots in file names other than the dot that separates the file extension (.dat, .ldr or .mpd) is to be avoided too. Use a - or _ instead.
Although that can give problems since the files LPub3D produces are often with a lot underscores too. I always use capital letters in a certain way to name files. I.e. FrontDoorLeft.ldr or something, rather than "left front door.ldr"
Also, very long paths can be a problem too. There was a time once the path (including the file name) exceded 255 characters crashes could occur too.
I could go on with warnings and exceptions...

Think it's just weird that it works in 2.2.1 and not in 2.3.6.

[Roland Melkert]

Also, very long paths can be a problem too. There was a time once the path (including the file name) exceded 255 characters crashes could occur too.

This is a filesystem and/or OS limitation, still shouldn't cause a crash though.

Also the special char problems might be OS depended too, as things are a minefield in the Windows low level file io api's regarding to character encoding.

[Travis Cobbs]

This is a filesystem and/or OS limitation, still shouldn't cause a crash though.

Also the special char problems might be OS depended too, as things are a minefield in the Windows low level file io api's regarding to character encoding.

Since LPub3D uses Qt, in theory this stuff should work as well as possible on all platforms. (When I say "as well as possible", I'm acknowledging that different platforms have different limits.) Obviously that's not the case.  Since it creates files and passes things like paths into commands running other programs (like LDView), it could be that the commands aren't properly handling UTF-8 special characters, and it could also be that the programs in question don't properly handle them. I know that in the past, LDView didn't work with arbitrary UTF-8 filenames. I'm pretty sure I fixed that, but I'm not sure if my fix has made it into a release yet, since I can't remember precisely when I fixed it.

[Johann Eisner]

Since LPub3D uses Qt, in theory this stuff should work as well as possible on all platforms. (When I say "as well as possible", I'm acknowledging that different platforms have different limits.) Obviously that's not the case.  Since it creates files and passes things like paths into commands running other programs (like LDView), it could be that the commands aren't properly handling UTF-8 special characters, and it could also be that the programs in question don't properly handle them. I know that in the past, LDView didn't work with arbitrary UTF-8 filenames. I'm pretty sure I fixed that, but I'm not sure if my fix has made it into a release yet, since I can't remember precisely when I fixed it.

The problem is caused by the LDView.exe installed with LPub3D. This is likely to be modified because it is version 4.4.0.1. Copying the official 4.3 in the 3rd party directory, you get error messages but it would work.