Baseplate 48x48 not rendered by LDGLite in LPub3D, LDView crash

[Jaco van der Molen]

Hi all,

Back from vacation I started a big project of 32000+ bricks.
The model is on 10 baseplates 48x48, so yes, it is bing.
I was able to model it though in LDCad (and turing to good old MLCad sometimes ;-)

Alas, LDView crashes very often when used as a renderer in LPub3D, so I turned to LDGLite for a change.
Works flawless, however the 4186 baseplate 48x48 does not render in the PLI.


What could this be?

LDView is able to render the whole model in LDView itself (although it takes a looooong time).
Getting to page 40 or so in the instructions in LPub3D, it starts to crash.
Anything to do about that? Or is it just a to big a model?

[Roland Melkert]

Alas, LDView crashes very often when used as a renderer in LPub3D, so I turned to LDGLite for a change.

Are you sure LPub is calling the 64 bit version of LDView. The 32 bit version might run out of memory on the larger brick count steps.

[Travis Cobbs]

Alas, LDView crashes very often when used as a renderer in LPub3D, so I turned to LDGLite for a change.

Are you sure LPub is calling the 64 bit version of LDView. The 32 bit version might run out of memory on the larger brick count steps.

A few other things to check. LPub3D recently added support for sending renders to LDView in batches, so LDView can render multiple steps in a row without running a separate instance of LDView for each step. This can greatly improve performance, but might be a contributor to it using more memory and thus crashing. If it's possible to disable that functionality in LPub3D's UI, you might try doing so. Also, LDView has three separate settings for "Memory Usage": low, medium, and high. Setting that to low for the renders might help.

[Merlijn Wissink]

It is indeed possible to turn it off in LPub3D: Preferences -> Rendereing -> Use multiple files single call rendering

[Jaco van der Molen]

Alas, LDView crashes very often when used as a renderer in LPub3D, so I turned to LDGLite for a change.

Are you sure LPub is calling the 64 bit version of LDView. The 32 bit version might run out of memory on the larger brick count steps.

I am pretty sure, for in LPub3D settings it says where LDView is: C:\Program Files\LDView\LDView64.exe
Though my PC is doing a better job than my laptop, it still crashes at some point.
It crashes too when it is trying to generate thumbnails in the explorer.

[Jaco van der Molen]

Are you sure LPub is calling the 64 bit version of LDView. The 32 bit version might run out of memory on the larger brick count steps.

A few other things to check. LPub3D recently added support for sending renders to LDView in batches, so LDView can render multiple steps in a row without running a separate instance of LDView for each step. This can greatly improve performance, but might be a contributor to it using more memory and thus crashing. If it's possible to disable that functionality in LPub3D's UI, you might try doing so. Also, LDView has three separate settings for "Memory Usage": low, medium, and high. Setting that to low for the renders might help.

OK, I'll tweak and try some settings.
What does the Process timeout do in the Render preference? It was set to -1.

[Jaco van der Molen]

It is indeed possible to turn it off in LPub3D: Preferences -> Rendereing -> Use multiple files single call rendering

No difference. Crash at the same point (page 40 of my instructions).

[Travis Cobbs]

Are you sure LPub is calling the 64 bit version of LDView. The 32 bit version might run out of memory on the larger brick count steps.

I am pretty sure, for in LPub3D settings it says where LDView is: C:\Program Files\LDView\LDView64.exe
Though my PC is doing a better job than my laptop, it still crashes at some point.
It crashes too when it is trying to generate thumbnails in the explorer.

It seems like memory issues are causing the crash, but I guess that's not guaranteed. If you're willing to send me the model at the LDView email address, I could at least investigate.

[Jaco van der Molen]

I am pretty sure, for in LPub3D settings it says where LDView is: C:\Program Files\LDView\LDView64.exe
Though my PC is doing a better job than my laptop, it still crashes at some point.
It crashes too when it is trying to generate thumbnails in the explorer.

It seems like memory issues are causing the crash, but I guess that's not guaranteed. If you're willing to send me the model at the LDView email address, I could at least investigate.

There are not that much bricks per step. I'll sent you the file. Thanks.

[Don Heyse]

So ldglite renders the 48x48 in the model images, but not in the PLI?  I'll have to try it with a simple model (48x48 and a 2x4) and see what happens.  Maybe the different orientation of the PLI images is making ldglite crash on the 48x48 for some reason.

[Jaco van der Molen]

So ldglite renders the 48x48 in the model images, but not in the PLI?  I'll have to try it with a simple model (48x48 and a 2x4) and see what happens.  Maybe the different orientation of the PLI images is making ldglite crash on the 48x48 for some reason.

Yes. Exactly.
I have tested too with one baseplate and one brick that renders just fine in both assembly and PLI.
Rendering my large model which has 10 baseplates LDGLite crashes too.
Must be a memory problem?

[Don Heyse]

It's almost certainly a memory problem.  How much do you have? 

It'd be interesting to monitor it in Task Manager and see how much each process is using.  I have no idea how much LPub3D uses, but I suspect quit a bit since it's built with a modern toolkit.  Ldglite is pretty frugal with the memory, but I've only tried a few really large models in it.  Anyhow, if LPub3D eats all the memory there's not much hope that either ldglite or LDView will be able to render.

[Jaco van der Molen]

It's almost certainly a memory problem.  How much do you have? 

It'd be interesting to monitor it in Task Manager and see how much each process is using.  I have no idea how much LPub3D uses, but I suspect quit a bit since it's built with a modern toolkit.  Ldglite is pretty frugal with the memory, but I've only tried a few really large models in it.  Anyhow, if LPub3D eats all the memory there's not much hope that either ldglite or LDView will be able to render.

I have "only" 8 Gb. Not much then.
Working with LPub eats a lot of memory and processor time I see.

I have split the model after a certain amount of steps and layers now and making instructions in parts.
Also, I have replaces chunks of brick build bricks with the box primitive. It helps.

Thanks to all who thought with me. I'll continue to experiment and struggle ;-)

[Roland Melkert]

I have "only" 8 Gb. Not much then.

You should be able to load models using millions of parts

I suspect this is not a memory shortage problem but a memory fragmentation problem. That's more of a 32 bit program problem though so are all the used tools 64 bit (lpub , lglite etc)

[Travis Cobbs]

I have "only" 8 Gb. Not much then.

You should be able to load models using millions of parts

I suspect this is not a memory shortage problem but a memory fragmentation problem. That's more of a 32 bit program problem though so are all the used tools 64 bit (lpub , lglite etc)

I think something else is going on, but haven't had time to try to track down what. LDView on my Mac only uses 120MB with the model loaded. That's a factor of 66 less than 8GB. And Jaco already indicated he was using the 64bit version of LDView for Windows.