Subject:
|
Re: Bricksmith 1.3: Here's Looking at You, Kid
|
Newsgroups:
|
lugnet.cad.dev.mac
|
Date:
|
Fri, 7 Apr 2006 06:33:59 GMT
|
Viewed:
|
5271 times
|
| |
|
|
In lugnet.cad.dev.mac, Allen Smith wrote:
| |
Travis,
Those images are very impressive! The lines are big and bold, instead of
disappearing into the surface they are supposed to be outlining. They are
instruction-grade. I will say, however, that MegaPOV does a better job doing
stud outlining on so on. (See http://news.lugnet.com/cad/dev/mac/?n=707)
For instance, the lines on the bottom of the studs in your image are not as
thick as the ones on top. That’s not a major quibble, though. Incidentally,
MegaPOV does outline walls bricks properly—just don’t ask me how. The
edge-tracing parameters I use are in the post linked above.
|
The lines do end up with different thicknesses at different places due to the
way they get drawn. As far as I know, thick lines in OpenGL are drawn such that
a section perpendicular to the line direction is all drawn at the same Z depth.
So when you draw that in a valley, some of the thickness goes away. The only
reason they look as good as they do is due to the use of glPolygonOffset. I use
this to move the solid polygons away from the camera by a little bit, so that
the lines show better.
| |
It also looks
like you have much better lighting than I have managed to achieve. I only
dabble in 3D graphics as a hobby, and my way-too-reflective surfaces prove
it.
|
You’re welcome to steal the lighting parameters I use in LDView. If you’re
interested, browse LDView’s CVS on sourceforge, and take a look at
LDrawModelViewer.cpp. Look for glLight* calls and glMaterial* calls. I think
all the lighting setup is in setupLights and setupMaterial.
| |
What I’m most amazed by is that you report drawing a Star Destroyer 12
times a second. I draw all parts in display lists, which improved drawing
speed by 60%, but it still takes about 2 seconds to draw the Star Destroyer
model on a 2.7 GHz G5. What in the world did you do to get 24 times that
speed?
|
There could be a number of factors, I guess. I have an GeForce 7800GT video
card, which obviously produces fairly fast geometry performance. My CPU is a
dual-core Athlon 3800+ (2GHz), but I suspect that the video card has a greater
impact on the performance than the CPU. I’m not sure what kind of video card
the G5 Mac has, since the single-core models don’t appear to be available from
Apple any more. However, the current Dual-core and Quad-core models don’t
appear to come with video cards that would be expected to have stunning geometry
performance.
Additionally, I use vertex arrays. When I first wrote LDView, I did everything
with standard geometry in display lists (glBegin(GL_QUADS), glVertex3f(...),
etc). LDView 3.0’s biggest feature from my point of view was a new rendering
engine that dropped those in favor of vertex arrays (still in display lists by
default). I’m not sure why that would make such a big difference, though.
Perhaps the video driver on the Mac doesn’t do a good job of optimizing display
lists?
After all, LDView 3 didn’t end up being that much faster than LDView 2 (maybe
twice as fast, best case, and usually nowhere near that big of a difference).
Since LDView doesn’t have to deal with editing, I am able to have a display list
for the whole model that calls out to all the part display lists. That doesn’t
seem to affect my performance much, though. I have three memory settings, one
of which uses no display lists at all, one of which uses display lists for each
part, but not for the model, and one of which uses display lists for the parts
and the model as a whole. When I turn display lists off completely it drops to
10FPS. (Note that the vertex arrays do help a lot when display lists aren’t
used. Immediate mode is well-known for being fairly slow.)
One thing I do is to flatten parts. In other words, if I decide a file is a
part, I promote all its sub-file geometry (and sub-sub-file, ad nauseum) to act
in LDView as if all the geometry was in the part file itself. This greatly
reduces the amount of tree traversal required during rendering, but if the part
itself is in a display list, there’s no tree traversal. I seem to remember that
having all those little display lists inside the part was detrimental to the
performance, though, so this could be the easiest way to gain performance.
(It’s a whole lot easier than switching to vertex arrays, trust me.)
Flattening parts increases the memory requirements, but the ISD uses just under
150MB in LDView when LDView’s memory setting is set to “high” (full display list
usage), and considering how large the file is, I consider this to be acceptable.
You might try downloading and compiling the original Cocoa LDView source code
from here:
http://www.raftis.net:16080/~alex/source.html
(If you do this, don’t forget to download the dependencies listed in the last
column on that page. They’re on the same page.)
That’s a really old version of LDView, but it uses standard OpenGL geometry
commands inside display lists. It might suck up a ton of memory though. LDView
2 flattens all the geometry in the entire model into one great big
non-heirarchical data structure, and then sticks that into a display list.
LDView 1.0 didn’t do that. I’m not sure what LDView version the Cocoa version
is based on. I loaded the file in LDView 2.1.01 in Windows, and it used about
750MB VM (although only around 200MB actual memory). I tried LDView 1.0, and it
only used about 200MB VM.
| |
I’m sorry I came across as sounding defensive; that wasn’t my
intention. I found what you said very interesting, not condescending. It
merely failed to mesh with my preconceived notions. Now I have been
enlightened!
|
Good to hear. I know that when I re-read it, I could definitely see how what I
wrote could have come across in a negative way. I’m glad it didn’t come across
that way to you.
--Travis
|
|
Message is in Reply To:
 | | Re: Bricksmith 1.3: Here's Looking at You, Kid
|
| Travis, Those images are very impressive! The lines are big and bold, instead of disappearing into the surface they are supposed to be outlining. They are instruction-grade. I will say, however, that MegaPOV does a better job doing stud outlining on (...) (19 years ago, 7-Apr-06, to lugnet.cad.dev.mac, FTX)
|
11 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
