 | | | | | |
In lugnet.cad.dev.mac, Jon Palmer wrote:
| |
I’m trying to do the old find_edges renders with the current version of
MacMegaPov and they aren’t working. Reading through here, it sounds like the
0.7 version of the program works fine for this.
I’ve googled up and down but can’t find 0.7 anywhere.
Can somone out there point me to the file online or send me a copy?
You are awesome if you can.
|
I have a copy sitting here:
http://bricksmith.sourceforge.net/files/MacMegaPov0.7.zip
I got it by e-mailing the maintainers of MacMegaPOV several years ago. In later
correspondence, they also told me the edge-tracer in the newer version of
MacMegaPOV had not been optimized by its author. The result is that edge-tracing
renders take 5 minutes in 0.7 and over an hour in 1.1+. Obviously I recommend
avoiding newer versions like the plague. Even running under Rosetta I bet the
old 0.7 runs circles around the newer one. (But I haven’t tested it yet.)
MacMegaPOV 0.7 is very difficult-to-find software. I’ve quietly hosted it for
quite a while, pointing people toward it when they ask the scary question of how
to make good instructions on the Mac. It all screams out for a detailed
tutorial, but I’ve never gotten around to it, partly because I’m embarrased by
how complex a process it is.
Allen
| | | | | | | | | | | | | | | |
In lugnet.cad.dev.mac, Allen Smith wrote:
| |
MacMegaPOV 0.7 is very difficult-to-find software. I’ve quietly hosted it
for quite a while, pointing people toward it when they ask the scary question
of how to make good instructions on the Mac. It all screams out for a
detailed tutorial, but I’ve never gotten around to it, partly because I’m
embarrased by how complex a process it is.
|
Establishing a consistent way to create quality instructions from LDraw models
on the Mac is of great interest to me, personally and on behalf of the general
Mac LDraw community. If a detailed tutorial is not practical, I would still be
interested in a summary of your process. I am interested in developing or
collaborating on any tools that would be useful to streamline the procedure:
well-formed MPD in, good instruction material out.
What are the key advantages of MacMegaPOV 0.7 compared with, say, the command
line version of POV-Ray 3.6?
Jim
| | | | | | | | | | | | | | | | |
In lugnet.cad.dev.mac, Allen Smith wrote:
| |
In lugnet.cad.dev.mac, Jon Palmer wrote:
| |
I’m trying to do the old find_edges renders with the current version of
MacMegaPov and they aren’t working. Reading through here, it sounds like
the 0.7 version of the program works fine for this.
I’ve googled up and down but can’t find 0.7 anywhere.
Can somone out there point me to the file online or send me a copy?
You are awesome if you can.
|
I have a copy sitting here:
http://bricksmith.sourceforge.net/files/MacMegaPov0.7.zip
|
You can find a command-line Intel Mac compile of MegaPOV 0.7 here:
http://www.halibut.com/~tcobbs/ldraw/private/megapov.bz2
I tested it with the following command line:
megapov +IBRICKS.pov
I used BRICKS.pov from the above zip, and it generated the following two PNG
files in under 2 seconds:
I then modified the output of L3P for LDView’s sample model m6459.ldr, and it
generated this in 3 seconds:
The above was all on an original 2GHz MacBook.
--Travis
| | | | | | | | | | | | | | | | | |
I realized that in my previous message, I never actually mentioned that I built
the executable that I link to. I built it from the MegaPOV 0.7 source using
(mostly) the Unix settings from the regular POV source. I set it to output PNG
files by default (which seemed the most reasonable). Since it’s using Unix
settings, it should look for povray.ini in the following locations at run-time:
$POVINI
./povray.ini
$HOME/.povrayrc
/usr/local/lib/povray31/povray.ini
I could probably easily change the search path if people have suggestions for
other ones.
I haven’t really tested the above, although I copied povray.ini from the Unix
source distrib for POV-Ray 3.1g into the current directory when doing my tests.
--Travis
| | | | | | | | | | | | | | | | | |
In lugnet.cad.dev.mac, Travis Cobbs wrote:
Travis,
This is a valuable resource to have. I’m glad to see this software isn’t doomed
to the dustbin of history. Thank you!
Allen
| | | | | | | | | | | | | | | | |
In lugnet.cad.dev.mac, Allen Smith wrote:
| |
In lugnet.cad.dev.mac, Travis Cobbs wrote:
Travis,
This is a valuable resource to have. I’m glad to see this software isn’t
doomed to the dustbin of history. Thank you!
|
You’re welcome. I think we need to get both my Intel-only version and your
PPC-only version put together somewhere. It also might be good to do a Mac OSX
PPC build, since I believe that yours requires Classic, which isn’t exactly
optimal. Mine might be more confusing to users though, since it’s done as a
Unix command. (I have no idea how yours work, since it won’t run on my machine;
I don’t have Classic.)
Note that I tried a Universal build, but it failed due to my lack of a Universal
build of libpng. If someone can send me instructions on getting libpng to build
as a Univeral binary, I’d really appreciate it. It’s actually holding up
another project of mine. I spent a little time trying to get it to build, but
stopped before investing all that much time. Alternatively, if someone can send
me a PPC build of libpng, I think it can be merged with my Intel build into a
Universal binary.
Thoughts?
--Travis
| | | | | | | | | | | | | | | | | |
In lugnet.cad.dev.mac, Travis Cobbs wrote:
| |
Note that I tried a Universal build, but it failed due to my lack of a
Universal build of libpng. If someone can send me instructions on getting
libpng to build as a Univeral binary, I’d really appreciate it. It’s
actually holding up another project of mine. I spent a little time trying to
get it to build, but stopped before investing all that much time.
Alternatively, if someone can send me a PPC build of libpng, I think it can
be merged with my Intel build into a Universal binary.
|
Actually, I need a Universal binary version of the static libpng library, since
I don’t want to have to distribute libpng along with the executable. Now that I
think about it, I’m pretty sure the megapov executable I already posted is
dynamically linked against libpng; I’ll have to fix that.
--Travis
| | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev.mac, Travis Cobbs wrote:
| |
Note that I tried a Universal build, but it failed due to my lack of a
Universal build of libpng. If someone can send me instructions on getting
libpng to build as a Univeral binary, I’d really appreciate it. It’s
actually holding up another project of mine. I spent a little time trying to
get it to build, but stopped before investing all that much time.
Alternatively, if someone can send me a PPC build of libpng, I think it can
be merged with my Intel build into a Universal binary.
|
I see there is universal build of libpng 1.2.17
here, but I have not
tested it. From the installer notes:
“Installs static (.a) and dynamic (.dylib) universal binaries of libpng, as
provided by the official libpng reference release:
http://www.libpng.org/pub/png/libpng.html
The libraries will be installed into /usr/local/lib, and the header files into
/usr/local/include.”
I’m not sure if it’s much help in the long run without notes on how it was
actually built, but maybe it’ll provide a few leads.
Jim
| | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev.mac, Jim DeVona wrote:
| |
I see there is universal build of libpng 1.2.17
here, but I have
not tested it. From the installer notes:
“Installs static (.a) and dynamic (.dylib) universal binaries of libpng, as
provided by the official libpng reference release:
http://www.libpng.org/pub/png/libpng.html
The libraries will be installed into /usr/local/lib, and the header files
into /usr/local/include.”
I’m not sure if it’s much help in the long run without notes on how it was
actually built, but maybe it’ll provide a few leads.
|
Thanks. I eventually figured out how to get it to build. The trick was to
build the two versions separately (ppc and i386), and then use lipo to join
them. Building for both architectures at once just gave an error that some of
the gcc command line arguments weren’t compatible with having multiple -arch
arguments (which seems really stupid).
So I built libpng 1.2.18, then rebuilt megapov in universal mode with a static
libpng and replaced my original upload. I’d really appreciate it if someone
with a PPC Mac would test it.
You can download a test POV file here:
http://www.halibut.com/~tcobbs/ldraw/private/m6459.pov
Once again the MegaPOV 0.7 build is here:
http://www.halibut.com/~tcobbs/ldraw/private/megapov.bz2
Once you have both of those in a directory together, use the following command
lines from that directory:
bunzip2 megapov.bz2
chmod 755 megapov
./megapov +im6459.pov
open m6450PP.png
That should show you the render.
--Travis
| | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev.mac, Travis Cobbs wrote:
| |
So I built libpng 1.2.18, then rebuilt megapov in universal mode with a
static libpng and replaced my original upload. I’d really appreciate it if
someone with a PPC Mac would test it.
|
I dusted off my old G3, now a bone stock 10.4 system, and it runs fine (as it
does on my MacBook).
Jim
| | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev.mac, Jim DeVona wrote:
| |
I’m not sure if it’s much help in the long run without notes on how it was
actually built, but maybe it’ll provide a few leads.
|
For reference, here is a script that builds a static univeral libpng library,
and then copies it into /usr/local/lib with a u appended to the filename
(libpng12u.a):
http://www.halibut.com/~tcobbs/ldraw/private/buildpngu.sh
In order for it to work, png.h has to be modified. In 1.2.18, line 497 needs to
be changed like so:
Old:
#ifdef PNG_USE_PNGGCRD
New:
#if defined(PNG_USE_PNGGCCRD) && defined(PNG_HAVE_MMX_COMBINE_ROW)
Run buildpngu.sh while in the main directory of the libpng source distribution.
I used it with 1.2.18; hopefully it will continue to work.
--Travis
| | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev.mac, Travis Cobbs wrote:
| |
You’re welcome. I think we need to get both my Intel-only version and your
PPC-only version put together somewhere. It also might be good to do a Mac
OSX PPC build, since I believe that yours requires Classic, which isn’t
exactly optimal. Mine might be more confusing to users though, since it’s
done as a Unix command. (I have no idea how yours work, since it won’t run
on my machine; I don’t have Classic.)
|
The version I posted does not require Classic. It’s an old CFM Carbon program
(not Mach-O) that can run natively under both OS 8/9 and OS X. It is PowerPC
though, so on an Intel Mac, it gets emulated via Rosetta. (But I suspect it runs
faster there than it does on my Powerbook G4!)
The only caveat for those who try it: make sure you choose an output image type
on the Image & Quality tab; otherwise the edge-tracing post-process will
cryptically fail.
It would be good to get these programs hosted together too, given their rarity.
They’re both quite useful. I tend to be one of those people who reflexively use
GUIs. However, a command-line tool will be best for automated
instruction-generation.
Allen
| | | | | | | | | | | | | | | | |
In lugnet.cad.dev.mac, Allen Smith wrote:
| |
The version I posted does not require Classic. It’s an old CFM Carbon program
(not Mach-O) that can run natively under both OS 8/9 and OS X. It is PowerPC
though, so on an Intel Mac, it gets emulated via Rosetta. (But I suspect it
runs faster there than it does on my Powerbook G4!)
|
Sorry. I used the command line unzip (on my Macbook) to unzip the file, and
that toasted the contents. Apparently the resource fork didn’t extract
properly. Using a different unzipper solved the problem.
--Travis
| | | | | | | | | | | | | | | | |
In lugnet.cad.dev.mac, Travis Cobbs wrote:
| |
In lugnet.cad.dev.mac, Allen Smith wrote:
| |
The version I posted does not require Classic. It’s an old CFM Carbon
program (not Mach-O) that can run natively under both OS 8/9 and OS X. It is
PowerPC though, so on an Intel Mac, it gets emulated via Rosetta. (But I
suspect it runs faster there than it does on my Powerbook G4!)
|
Sorry. I used the command line unzip (on my Macbook) to unzip the file, and
that toasted the contents. Apparently the resource fork didn’t extract
properly. Using a different unzipper solved the problem.
|
For comparison, I rendered m6459.png (picture posted in earlier post) at
640x480, and the times were as follows (all on an original MacBook 2GHz).
Intel (command line-only) compile:
Time For Trace: 0 hours 0 minutes 2.0 seconds (2 seconds)
Time For Post: 0 hours 0 minutes 1.0 seconds (1 seconds)
Total Time: 0 hours 0 minutes 3.0 seconds (3 seconds)
|
|
Your PPC (Carbon with UI) compile:
Time For Trace: 0 hours 0 minutes 8.0 seconds (8 seconds)
Time For Post: 0 hours 0 minutes 5.0 seconds (5 seconds)
Total Time: 0 hours 0 minutes 13.0 seconds (13 seconds)
|
|
My PPC (command line-only) compile (different compiler, and no UI):
Time For Trace: 0 hours 0 minutes 8.0 seconds (8 seconds)
Time For Post: 0 hours 0 minutes 2.0 seconds (2 seconds)
Total Time: 0 hours 0 minutes 10.0 seconds (10 seconds)
|
|
Not sure why all the times are rounded (truncated?) to the nearest second, but
there is a noticeable difference between all three versions. Your compile has
the huge advantage of an actual UI, though. It’s very odd that only the
post-processing step took longer on yours, and not the trace. My guess is that
there is something in there that the current GCC optimizes better than whatever
compiler compiled yours (at least when running under Rosetta).
--Travis
| | | | | | |
