| |
My latest update to Bricksmith for Macintosh is focused heavily on
viewing-related enhancements.
Bricksmith 1.3 adds the following
features:
- Multiple viewports
- Perspective in the 3D view
- Preset orthographic viewing angles (front, top, etc.)
- Speed improvements of up to 40% in a single viewport
- Select All works
- Added a Tutorial
- Use the mouse for zooming and scrolling! There’s both a “tool palette” and Photoshop-style hotkeys:
Zoom In:
| | space-command-click
|
| | Zoom Out:
| | space-option-click
|
| | Center:
| | command-click
|
| | Smooth zoom in/out:
| | command-drag
|
| | Pan-Scroll:
| | space-drag
|
It also fixes the following bugs:
- Fixed glitch whereby parts might rotate unexpectedly when moved
- Fixed crash when removing then adding certain toolbar items
Bricksmith 1.3 was something of a monumental undertaking for me, and there were
several times when I was pretty sure I’d bitten off more than I could chew.
Implementing perspective (a vanishing point) was by far the worst. However, I am
delighted that I finally grasped the concept, because the distortions caused by
an orthographic camera were extremely annoying.
Perhaps the Number One
request I’ve received for this program is to provide preset viewing angles, like
“Front” or “Left,” so I’m happy to fulfill that wish as well. Note, however,
that perspective is ill-suited to such head-on views, so the camera
automatically switches back to orthographic when you view a model that way.
This is probably the last time you’ll see enormous speed gains, as all parts are
now drawn via OpenGL display lists.
On a side note, Bricksmith has now been
downloaded over 16,000 times. I’m guessing the overwhelming majority of those
users are getting their first taste of LDraw. But I would also very much like to
hear the needs of the truly devoted.
Bricksmith requires Mac OS X 10.3 or
later, and may be download it at http://bricksmith.sourceforge.net/. It is not
yet Intel native, but I will try it out as soon as I get access to an Intel
Mac.
Sincerely,
Allen Smith
|
|
| |
In lugnet.announce, Allen Smith wrote:
| |
My latest update to Bricksmith for Macintosh is focused heavily on
viewing-related enhancements.
|
Just installed this and I think it’s great! I have a few questions. I was
looking for a way to save each step as an image and for how to save or export a
parts list to text. Are these features available?
Russell
BayLUG
|
|
| |
Thanks for sharing your enthusiasm and suggestions.
Unfortunately, Bricksmith does not have any native ability to export the images
it generates. Since they would be unsuitable for printing anyway, this feature
is not apt to ever appear. What I personally do is render each step individually
in MacMegaPOV, using the find_edges command to produce professional-quality
images. Bricksmith is optimized for onscreen drawing, so the renderings look
infinitely better than anything it could ever do itself.
But if you like what
you see onscreen, I suppose you can just take a screenshot.
Parts list
exporting is unavailable as well, but there is no reason it couldn’t be
implemented. Is there a standard file-format for exported part lists, from
Peeron, perhaps?
Allen
|
|
| |
In lugnet.cad.dev.mac, Allen Smith wrote:
| |
Unfortunately, Bricksmith does not have any native ability to export the
images it generates. Since they would be unsuitable for printing anyway, this
feature is not apt to ever appear. What I personally do is render each step
individually in MacMegaPOV, using the find_edges command to produce
professional-quality images. Bricksmith is optimized for onscreen drawing, so
the renderings look infinitely better than anything it could ever do itself.
|
I guess what I am asking about is that if I create a set of instructions, there
is no way to save or print to a .pdf file? Not a problem. I can just share the
.mpd file, but I figured I would ask.
| |
Parts list exporting is unavailable as well, but there is no
reason it couldn’t be implemented. Is there a standard file-format for
exported part lists, from Peeron, perhaps?
|
I don’t know about Peeron, but MLCAD saves a .txt file.
Russell
|
|
| |
In lugnet.cad.dev.mac, Russell Clark wrote:
| |
I guess what I am asking about is that if I create a set of instructions,
there is no way to save or print to a .pdf file? Not a problem. I can just
share the .mpd file, but I figured I would ask.
|
When I create a set of instructions, I use MacMegaPOV/POV-Ray to individually
render a super-high-quality image for each step. I then arrange them manually
with a page-layout program. My ultimate goal is always to print them. Of course,
producing print-quality images using a real-time onscreen design program like
Bricksmith just wouldn’t work out well; the images wouldn’t be a high-enough
resolution.
I’m sure there are ways to automate this process, but I doubt I
would ever be as satisfied with the results as I am with my labor-intensive
rendering method. Just look at MLCad’s image-exporting feature. It is useless
for instruction printouts.
| |
I don’t know about Peeron, but MLCAD saves a .txt file.
|
Yes, but does the data in that text file need to be arranged in a particular
way?
Allen
|
|
| |
In lugnet.cad.dev.mac, Allen Smith wrote:
| |
In lugnet.cad.dev.mac, Russell Clark wrote:
| |
I don’t know about Peeron, but MLCAD saves a .txt file.
|
Yes, but does the data in that text file need to be arranged in a particular
way?
|
I don’t think it has to be. My friend made me a parts list from MLCAD and it was
arranged alphabetically by part description. I think it would make the most
logical sense to sort a parts list by part number.
Russell
|
|
| |
In lugnet.cad.dev.mac, Allen Smith wrote:
| |
In lugnet.cad.dev.mac, Russell Clark wrote:
| |
I guess what I am asking about is that if I create a set of instructions,
there is no way to save or print to a .pdf file? Not a problem. I can just
share the .mpd file, but I figured I would ask.
|
When I create a set of instructions, I use MacMegaPOV/POV-Ray to individually
render a super-high-quality image for each step. I then arrange them manually
with a page-layout program. My ultimate goal is always to print them. Of
course, producing print-quality images using a real-time onscreen design
program like Bricksmith just wouldn’t work out well; the images wouldn’t be a
high-enough resolution.
|
The resolution argument actually doesn’t hold up. When I added printing support
to LDView in Windows, I made it generate an image using tiling that was at the
printer’s resolution (or maybe I maxed out at 300DPI; that was four years ago,
so I don’t really remember). LDView in Windows also supports snapshots at
arbitrary resolutions up to 9999x9999.
Mind you, the quality won’t match what you can get out of POV, but it’s
definitely possible to render something in OpenGL with a resolution that’s
sufficiently high to look good printed. And it’s a whole lot faster. Just to
check, I generated a 9999x9999 snapshot of Orion’s Imperial Star Destroyer model
based on the set. It took about 5 seconds to render the image, and another 20
seconds to convert it to PNG and save the file. I tried again with BMP, and it
took about 15 seconds to write the (285MB) BMP to the disk.
Of course, none of this helps you at the moment, because LDView doesn’t support
steps at all, and the QT verison of LDView that can run on a Mac doesn’t
currently support arbitrary snapshot sizes (although that should change in the
next release). But it does show that use of OpenGL for 3D rendering doesn’t
introduce any arbitrary constraints on rendered image size. Big images just
require a little extra work.
| |
I’m sure there are ways to automate this process,
but I doubt I would ever be as satisfied with the results as I am with my
labor-intensive rendering method. Just look at MLCad’s image-exporting
feature. It is useless for instruction printouts.
|
LPub in Windows can produce rather impressive results. I think that shows that
professional-quality results can be generated in an automated fashion. Once
again, this doesn’t help you on the Mac, since (as far as I know) LPub is
Windows-only.
--Travis Cobbs
|
|
| |
In lugnet.cad.dev.mac, Travis Cobbs wrote:
| |
In lugnet.cad.dev.mac, Allen Smith wrote:
| |
Of course, producing print-quality images using a real-time
onscreen design program like Bricksmith just wouldn’t work out well; the
images wouldn’t be a high-enough resolution.
|
The resolution argument actually doesn’t hold up. When I added printing
support to LDView in Windows, I made it generate an image using tiling that
was at the printer’s resolution (or maybe I maxed out at 300DPI; that was
four years ago, so I don’t really remember).
|
Okay, that puts me in my place. I hereby recant any prior suggestions about
crummy resolution! Now that we have established that OpenGL can produce
print-quality images, my question is: Can OpenGL produce instruction-quality
graphics? Even more germanely, can Bricksmith produce such graphics? I seriously
doubt it.
Usable instructions demand boldly-outlined edges around each part.
Bricksmith doesn’t do that, even more so because it doesn’t even draw
conditional lines. But even if it did, I don’t think part-outlining would begin
to approach what MegaPOV can do, which is to say that it would be well nigh
useless.
LPub, meanwhile, is based on POV-Ray/MegaPOV, so it has little
bearing on whether OpenGL viewers should have built-in image-exporting
abilities. LPub is essentially a way to automate the highly-labor-intensive
render-it-all-by-hand process I use for my own instructions, and can therefore
produce output I would deem acceptable. If you want easy and good instructions
on the Mac, recreate the LPub workflow! Unfortunately, I don’t have the time to
do that; my hands are full enough with an LDraw editor. But it would be
fantastic if someone could do it, because I’m the first to admit that my way
stinks.
Allen
|
|
| |
In lugnet.cad.dev.mac, Allen Smith wrote:
| |
In lugnet.cad.dev.mac, Travis Cobbs wrote:
| |
In lugnet.cad.dev.mac, Allen Smith wrote:
| |
Of course, producing print-quality images using a real-time
onscreen design program like Bricksmith just wouldn’t work out well; the
images wouldn’t be a high-enough resolution.
|
The resolution argument actually doesn’t hold up. When I added printing
support to LDView in Windows, I made it generate an image using tiling that
was at the printer’s resolution (or maybe I maxed out at 300DPI; that was
four years ago, so I don’t really remember).
|
Okay, that puts me in my place. I hereby recant any prior suggestions about
crummy resolution! Now that we have established that OpenGL can produce
print-quality images, my question is: Can OpenGL produce instruction-quality
graphics? Even more germanely, can Bricksmith produce such graphics? I
seriously doubt it.
|
For what it’s worth, I don’t think most people are aware that OpenGL can be used
to render images at arbitrary resolutions. Most video cards don’t support
rendering directly above 2048x2048. (Presumably the new cards that support
2560x1600 monitor resolution support higher.)
I’d say that OpenGL can be used to make fairly decent instructions. I won’t
claim that they can equal the quality of carefully created instructions
generated via MegaPOV, but I’d say that they can definitely be pretty good. I
uploaded a 5MB PNG file (designed for printing full-page at 600DPI) here:
http://www.halibut.com/~tcobbs/ldraw/private/10030ImperialStarDestroyer1.png
Note that it doesn’t look too great at 100% on your monitor, but it should look
pretty good printed. I also scaled the image down to screen resolution, and put
the (much smaller) file here:
http://www.halibut.com/~tcobbs/ldraw/private/10030ImperialStarDestroyer2.png
| |
Usable instructions demand boldly-outlined edges
around each part. Bricksmith doesn’t do that, even more so because it doesn’t
even draw conditional lines. But even if it did, I don’t think part-outlining
would begin to approach what MegaPOV can do, which is to say that it would be
well nigh useless.
|
I’m not sure why. Actually, I think programs that are LDraw-aware can do a
better job at outlining, because they can outline exactly what the part authors
decided needs to be outlined when the parts were created. The samples above
have outlining turned on. By the way, how do you get MegaPOV to draw lines
between parts that make up a wall? I thought it’s auto-outlining required
changes in depth between adjacent pixels in order to work.
Having said that, conditional lines are going to be slow to draw in an
OpenGL-accelerated editor, unless somebody figures out a way to put them into a
Vertex program. The above Star Destroyer gets about 12FPS on my computer in
LDView with edge lines enabled, but conditional lines disabled. It gets just
under 3FPS with conditional lines enabled along with edge lines. It gets 20FPS
with no edge lines at all.
In an editor, I think having the edges visible is a huge help to editing, but
conditional lines add a relatively minor improvement. Of course, if you’re
editing a small file, you can have edge lines and conditional lines, and still
get good performance. The Star Destroyer does have over 3000 pieces, remember.
| |
LPub, meanwhile, is based on POV-Ray/MegaPOV, so it has
little bearing on whether OpenGL viewers should have built-in image-exporting
|
I wasn’t trying to say that it does. I was responding to your point about it
not being feasible to automate your work-flow.
| |
abilities. LPub is essentially a way to automate the highly-labor-intensive
render-it-all-by-hand process I use for my own instructions, and can
therefore produce output I would deem acceptable. If you want easy and good
instructions on the Mac, recreate the LPub workflow! Unfortunately, I don’t
have the time to do that; my hands are full enough with an LDraw editor. But
it would be fantastic if someone could do it, because I’m the first to admit
that my way stinks.
|
Well, the source is available, but I think it’s in C++ Builder. I don’t know
much about C++ Builder, but I’m guessing there’s no easy way to get it up and
running outside Windows.
I don’t want to come across the wrong way here. My original comments were made
just as a statement that it’s perfectly reasonable to have decent print quality
out of an OpenGL app for creation of instructions. I don’t have access to a
Mac, so I haven’t been able to look at Bricksmith, but based on the screenshots
and the comments here, I think you’ve got yourself a great app. And since your
primary goal is to make a good editor, support for these kind of
instructions-generation features would just take away from your primary work on
the editor. And, to be perfectly honest, producing decent instructions would
definitely take a lot of work. I think my comments may have come across as
condescending, or implying that you should be taking action based on them. I
just want to say here that that wasn’t my intention at all, but reading what I
wrote, I can definitely see how it could have been interpreted that way.
Having said all that, if anyone would be interested in STEP support in LDView on
the Mac, by all means let me know. I’ve had requests for it on the PC, and it’s
on my “to-do” list, but I’ll be honest and admit that LPub’s ability to use
LDView as a renderer in Windows really decreased the priority of that feature
for me. Not having access to a Mac, I haven’t been the one that has compiled it
there lately, but there is a Mac version of the QT LDView. It’s not native, but
it should at least work. If I had a Mac, I’d update the Cocoa port of LDView,
but I don’t, and it’s not all that likely that I will any time soon.
--Travis
|
|
| |
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.
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.
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?
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!
Sincerely,
Allen
|
|
| |
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
|
|
|
