LDView Bug


LDView Bug
#1
I recognized, that if I use the primitive substitution option with models that have xxxxh.DAT baseplates in them the whole program does crash.
With xxxxh.DAT I mean the baseplate with detailed underside studs - only for the case these get renamed.....

Is this error known ?
Will it be fixed?
Reply
Re: LDView Bug
#2
I am unable to reproduce the issue as of version 4.1 (latest that I am aware of) on mac.

The part:
[Image: zpVsX.png]

A model using the part:
[Image: cm4xz.png]

It did take a little while to load the first time because it tried to find an update for the part and a few subparts (some are still unofficial) and during that time the interface did become unresponsive for a few seconds, but it loaded just fine. Please elaborate on "crash" and please tell us what version/system you are running on, and what part, specifically, you have issues with.
Reply
Re: LDView Bug
#3
Where can I find the h versions of the baseplates?
Reply
Re: LDView Bug
#6
Chris Dee Wrote:Only on the Parts Tracker - e.g. her. I'm not yet convinced this is a good idea, or sure how we should implement it in the Parts Library.

I split off Chris' reply due to veer in the conversation

http://forums.ldraw.org/showthread.php?tid=3095

Tim
Reply
Re: LDView Bug
#4
It doesn't crash on my Mac either, but it does use a fair bit of memory. Loading just the 50x50 baseplate with underside in LDView causes LDView to use about 228MB, while loading the standard one causes LDView to use about 66MB. I'll have to test on my Windows machine to see if it crashes there, but I don't see any particular reason why it should.

Also, check the "Curve quality" slider setting on the Primitives page of LDView's preferences. The default for that slider is the second notch, and anything above that will have a huge impact on memory usage of the baseplate with underside, with a much lower impact on the memory usage of the standard baseplate. For example, bumping the slider from the second notch to the third caused memory usage for the standard one to go from 66MB to 74MB, while the one with underside went from 228MB to 409MB.

For reference, the h version uses 643MB on the fourth notch, and that's just the one part. Also, no matter how much memory you have, LDView is a 32-bit app, so it will crash if it ever needs more than 2GB (or perhaps 3GB, but I don't think so).
Reply
Re: LDView Bug
#5
The 50x50 baseplate with underside loaded without any problem for me in Windows also (and used quite a bit less memory than on my Mac; memory usage in LDView is very dependend on video card drivers, though). Based on your original post, it seems you're having the problem with all the XXXXh.dat baseplates, but if the 50x50 (which I chose because it is the largest) loads for you, please give me a specific example of one that causes a crash.
Reply
Re: LDView Bug
#7
The problems begin with the 16 x 16 baseplates- first it needs a huge amount of time to get the parsing done then I get this error messages:
[Image: gEuLG]

All xxxxh.DAT baseplates which are bigger are even worse and they all crash with that error message.

Currently I run LDView on Windows XP 64 Profesional SP2

I have a 2,3 GHz Intel Dualcore, ATI RAdion HD graphic card with 512 MB RAM, and 4 GB DDR2 RAM-

hope you can tell me what goes wrong....
Reply
Re: LDView Bug
#8
I'm not 100% sure, but the error you're seeing appears to be due to LDView running out of memory. I have no idea why this would happen to you with a 16x32 baseplate, unless you have the curve quality set (way) above the second notch. Make sure that's set to the second notch, and if it is, try setting the Memory usage setting to Medium or Low in the General tab of LDView's preferences.
Reply
Re: LDView Bug
#9
yes that was the error - I tried a model with 2 16x16 and one 16x32 baseplate and it does crash when I set the curve quality above the 6 notch (seen from left)....
Reply
Re: LDView Bug
#10
can you please post the file here, so it is available for playing around?
Reply
Re: LDView Bug
#12
Chris Dee provided a link to the 16x24 baseplate with underside details on the parts tracker. To see any of the others, simply click on the Stud Underside Baseplate subfile link on that page (or here). to get a list of all the baseplates on the tracker with underside detail.
Reply
Re: LDView Bug
#13
uh, yes, I know, I had just simply wanted the handful of lines from the model file to quickly fire up LDView with it
Reply
Re: LDView Bug
#15
It wasn't only some simple test model. I tested it with some larger model- It is the official 6080 King's Castle....
Right now I've modled many of my models with these underside stud baseplates, because I like to look in 3D on them from all the sides.
It's right that almost nobody makes a pov-ray (or other raytracing) shot, where you can the these underside stud besides I modeld some advanced building model and used the baseplates in another way.
But in LDView the model seems to float in midair and so it happens easily that you look from beneath at it - and there I like it to see these details,which are much easier to see than the stud underside of a brick.

I attached the model


Attached Files
.l3b   sr.L3B (Size: 40.6 KB / Downloads: 0)
Reply
Re: LDView Bug
#11
I may be able to implement something so that LDView gives you a dialog saying it ran out of memory before exiting, but I'm not going to ever be making the problem go away entirely. These models simply use to much memory when you have LDView set to super-high curve quality and High memory usage. There's nothing that can be done about that.

Also, as a general rule, LDView's default curve quality setting (second notch) is good for displaying models. Going above that doesn't really have a huge impact except when zoomed in quite close, and memory usage goes up dramatically.
Reply
Re: LDView Bug
#14
Quote:Also, as a general rule, LDView's default curve quality setting (second notch) is good for displaying models. Going above that doesn't really have a huge impact except when zoomed in quite close, and memory usage goes up dramatically.
Another point is that intersection lines (say between two cylinders in random position) or junctions between round primitives and triangle/quads assume that normal resolution round primitives are 16-sided, so any curve quality setting other than second notch may result in wrong looking parts.
Reply
« Next Oldest | Next Newest »



Forum Jump:


Users browsing this thread: 1 Guest(s)