Results 1 – 5 of about 1800.
|
Search took 0.00 CPU seconds.
|
|
| |
In lugnet.cad, Jason Allemann wrote:
| |
For anyone stumbling on this thread, the beta for LDView 4.2 is now available
in 32 and 64 bit flavors. http://ldview.sourceforge.net/Downloads.html
I assume that future releases will continue this trend. I tried the 64 bit
version and it fixed the delays I was experiencing.
|
Sadly, the problem has resurfaced, but at least I was able to gather a lot of
new information for help in troubleshooting.
I’m on a Windows 7 machine with brand new installs of the LDraw library, LPub,
and the 64-bit build of LDView 4.2beta referenced above. I’ve done many
instructions with this setup already and had no problems whatsoever. Some of
the models were very large (over 1 Mb MPD files) and with hundreds of pages. No
problem. Then something changed.
I am working a new set of instructions and everything was going fine. Then I
get to Page 57 and for some reason everything just stopped. Data I’ve gathered:
- If I simply open the model in LDView 4.2b in the GUI, it takes about 30 seconds to load and display. No errors or problems.
- The above consumes about 250 Mb of RAM.
- When LPub calls LDView to make an image of this model (and keep in mind these are early steps so it is not even the whole model), LDView consumes on average 500 Mb of RAM.
- When LPub calls LDView to make a parts list image (single part), it only takes about a second. A view of the whole model takes about 30 seconds.
- As of page 57, a call to LDView initially consumes about 500 Mb of RAM up until the point that it should return the image, then it suddenly consumes 4.7 Gb of RAM (all available) and the hard drive light goes steady “ON” implying even more virtual memory is called.
- Entire computer locks (can’t even move mouse) until process completes. This takes 1-2 hours.
- There is nothing special about page 57. In fact, this is a submodel step with only 5 parts in it so it should take seconds.
- Subsequent pages after this have the same problem. Model and computer are completely unusable.
- No other model died at Page 57. No changes to computer configuration. This happened in the middle of working a model.
- Restart of the computer or LPub has no effect.
Questions:
- Why does LDView use more RAM when called from LPub than it does to open the entire model in GUI?
- Why does it consume 4.5 Gb of RAM on Page 57 when the whole model can be loaded for 250 Mb?
- How am I supposed to finish these instructions? ;-)
Any help would be greatly appreciated. I’m sure that tracking this down will be
no small task, but it seems like if this is solved it will reveal a lot that may
be of future value.
Eric Albrecht
|
|
|
| 
lpub
(score: 0.591)
|
|
| |
I'm using LPub v 2.4.8.0, and I've noticed that it completely omits POV-Ray
torus objects in the output images.
Any idea why this might be happening?
|
|
|
|
lpub
(score: 0.585)
|
|
| |
In lugnet.cad, Jaco van der Molen wrote:
> In lugnet.cad, Dave Schuler wrote:
> > I'm using LPub v 2.4.8.0, and I've noticed that it completely omits POV-Ray
> > torus objects in the output images.
> >
> > Any idea why this might be happening?
>
> Hi Dave,
>
> That is a really old version of LPub.
> I can imagine that you are using it for a reason, like you want to render with
> POV, but if that is not the case, I suggest you update LPub to version 4.0.0.11.
>
> It renders using LDView or LDGLite and does the job quicker and WYSIWYG.
>
> For more information cosult the Official Online LPub manual here:
>
> http://lpub.binarybricks.nl
Okay, I've downloaded the newest edition, and confess that I'm frustrated
because it loses some of the basic functionality of the earlier version, and
it's completely hobbled by errors that the older versions were able to
accommodate without even blinking.
LPub version 4.0.0.11 is brought to a standstill by the following:
===================
Runtime Error!
Program: C:\Program Files\LDView\LDView.exe
R6025
-pure virtual function call
===================
This popped up from a DAT file that rendered just fine on version 2.4.8.0 not
one minute before.
From a programming standpoint, what's the thinking behind making a newer version
*less* resilient than its predecessors?
For that matter, what the heck does that error message mean?
|
|
|
|
lpub
(score: 0.585)
|
|
| |
In lugnet.cad, Timothy Gould wrote:
> > Point taken. I'll give it a shot.
> >
> > The problem is that I've written somewhere upwards of 1,100 parts, and although
> > these do indeed conform to the pre-legalese LDraw format, they don't have the
> > elaborate file header now present in official elements. I'm not eager to
> > undertake any solution that requires re-writing an entire library, if that's
> > what it's going to take.
>
> The format is still the same and any software should render parts that conform
> to the original 0.1 format just as well as anything more recent. To do otherwise
> is a failure.
Well, here goes:
http://forums.ldraw.org/read.php?22,3930
|
|
|
|
lpub
(score: 0.585)
|
|
| |
In lugnet.cad, Timothy Gould wrote:
> > Hmm...
> >
> > I'm a bit apprehensive about the reception I'll get there. It's no secret that
> > I'm not exactly working with canonical material...
>
> There's plenty of people that work with LDraw outside the official library. So
> long as your parts are valid LDraw Format a problem with renderers is worth
> mentioning where others will actually see it.
>
> Or in short you can ask somewhere where an answer is likely to be forthcoming,
> or you can stick to here and hope that one day your problem may be noticed ;)
Point taken. I'll give it a shot.
The problem is that I've written somewhere upwards of 1,100 parts, and although
these do indeed conform to the pre-legalese LDraw format, they don't have the
elaborate file header now present in official elements. I'm not eager to
undertake any solution that requires re-writing an entire library, if that's
what it's going to take.
|
|
|
|
lpub
(score: 0.585)
|
More: Next Page >>
|
