To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.cadOpen lugnet.cad in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 CAD / 9063
9062  |  9064
Subject: 
Re: Large LDraw/MPD Files?
Newsgroups: 
lugnet.cad, lugnet.cad.dev
Followup-To: 
lugnet.cad.dev
Date: 
Sat, 21 Dec 2002 01:21:53 GMT
Viewed: 
493 times
  
In lugnet.cad, Don Heyse writes:
In lugnet.cad, Travis Cobbs writes:
I'm not sure what you mean by this.  Ldglite only creates one structure
in memory per part file.  It's quite frugal with the memory when you
use the L3 Parser.  Thanks, Lars.  I think I've displayed datsville in
ldglite on a PC with as little as 64MB, perhaps less.

I meant basically what you just said.  Ldglite doesn't create a new copy of
the part each time it is used; LDView does.  I do this for various reasons,
but I believe that when I go back and revisit those reasons now with the
advantage of hindsight that most if not all of them are not actually necessary.


I suspect the problem with LDView is the large display lists.  The first
test I'd do is try rendering without them to see how much memory that
takes.  Display lists use more memory than a C structure, and I don't
think you want them to grow too large.  Making them larger than the
amount of video memory is probably really bad.  You might be better off
with a separate display list for each line in the main model file, or
abanoning them altogether when they exceed a certain number of triangles.

The display list itself definitely uses a large amount of memory (I have a
single display list for the entire model).  However, in my testing with
datsville and other much smaller models, I determined that my data
structures use a very large amount of memory before the display list is
created.  The latest version of LDView should use a little less memory on
certain models, but it still uses too much.

What I hope to do is just to have a separate display list for each dat file
loaded, and then make the lists themselves heirarchical.  I'll probably have
to flatten parts themselves and lose their internal heirarchy in order to
continue to support seams and smoothed edges.  This still shouldn't use all
THAT much memory.

I think (but don't know for sure) that this will cause the display lists to
also not use too much memory.  In order to do this, I'll actually need two
display lists for parts that use highlight color (ie for edge lines).  One
list will first draw all default color items, then all other color items.
The other list would just do the highlight color items.  The parent list
will set the color prior to drawing the child lists.  This is necessary
because you can't have any logic in the code that draws during the display
list creation.

I think all this will work fine, significantly reduce memory usage, and
hopefully not have much (if any) negative impact on performance.  However,
it will require a lot of modification to my code.  I want to significantly
clean up the model loading/parsing code while I'm at it.  The
loading/parsing code is currently too closely tied to the OpenGL drawing
code, and I think that's also bad.

--Travis Cobbs (tcobbs@REMOVE.halibut.com)



Message is in Reply To:
  Re: Large LDraw/MPD Files?
 
(...) I'm not sure what you mean by this. Ldglite only creates one structure in memory per part file. It's quite frugal with the memory when you use the L3 Parser. Thanks, Lars. I think I've displayed datsville in ldglite on a PC with as little as (...) (22 years ago, 20-Dec-02, to lugnet.cad)

17 Messages in This Thread:







Entire Thread on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR