Subject:
|
Re: Need (working) program to generate instruction pictures
|
Newsgroups:
|
lugnet.cad.dev.mac
|
Date:
|
Sun, 4 Mar 2007 17:37:59 GMT
|
Reply-To:
|
CJMASI@*NOGARBAGEPLEASE*VERIZONsaynotospam.NET
|
Viewed:
|
4953 times
|
| |
|
|
Jim DeVona wrote:
> In lugnet.cad.dev.mac, Christopher Masi wrote:
>
> > > > I tried ldglite, but it just shows a white window, even after loading
> > > > a model. Do I need some addtional software? I am using OS X Tiger, Mac Mini
> > > > Intel duo core.
> > > ...
> > > I've observed the same problem with ldglite on my Intel Mac. However, I just
> > > realized that although there are display problems, [it works fine from the
> > > command line]! Based on the notes in the ldglite.txt readme, try something like
> > > this:
> > >
> > > | /path/to/ldglite.app/Contents/MacOS/ldglite -i2 -mS /path/to/model.ldr
> > >
> > > The |-i2| option generates PNGs with transparent backgrounds and |-mS| saves an
> > > image for every step without opening a window. Cool!
> > >
> > > Jim
> > Odd... one of the first things I did was check to see if LDGLite worked
> > on my MacBook, and it worked without a problem. My first guesses are
> > that your LDRAW dir didn't get copied over from your old computer,
> > and/or your .MacOSX/environment.plist file didn't get copied from your
> > old Mac. Remember, the double clickable version of LDGLite reads
> > ~/.MacOSX/environment.plist for the location of your LDRAW directory and
> > the command line version reads ~/.tcshrc (or whatever file you have set
> > up to tell the shell you use where to find stuff).
>
> Hmm. I'm curious how it works on your machine. There's not a problem with my
> LDraw directory or $LDRAWDIR definition; it's an environment variable,
> regardless of where it's defined.
>
> The problem isn't with the LDraw parts, its with the visible interface. It feels
> like maybe a GLUT problem - just the last step to the screen that's flaky. The
> screen is blank, and gets re-blanked whenever you try to rotate the display.
> Displaying a menu will paint whatever is underneath it, but it doesn't get
> repainted until obscured again. Screenshot with a model loaded:
> http://www.brickshelf.com/gallery/anoved/Examples/ldglite-display-glitch.jpg
>
> Showing the contextual menu reveals the background color behind it, but no
> model, so I'm not really sure where the problem lies. If you open the little
> settings panel, it remains visible after you close it - it's no longer
> "clickable," but just its image that hasn't been cleared.
>
> Anyway, this is with ldglite 1.0.18 on OS X 10.4.8. It'd be great if there's a
> ready fix.
>
> Jim
Jim,
I'm not a programmer, but as it was explained to me by Don Heyse, that
the only way for a double-clickable Mac application to get information
about unix-like environment variables is if that variable is specified
in a file called "environment.plist" which needs to have the following
location "~/.MacOSX/environment.plist". If that file isn't there, then
the Mac bundle will not be able to find the ldraw directory. On the
other hand, you are correct that the command line version of the program
has access to the environment variable regardless of whether you set
them manually, read them from .tcshrc or .login or what ever. This might
explain why the command line version will load a model but the Mac
bundle won't.
As for the display artifacts I fear that they will be associated with
the specific computer models and they won't get fixed. For example, my
Pismo had an 128bit ATi Rage Mobility Pro video card with 8MB of video
RAM and it did some weird things display-wise. With a small enough (but
still perfectly usable) window, my Pismo would use hardware acceleration
and the ATi driver to display the program's output. At high resolutions,
the OS would switch over to Apple's generic driver (which had it's own
idiosyncrasies). At intermediate resolutions, the program would display
garbage. Other computers with similar vintages but more powerful video
processing had no problems at all. Don never was able to figure out what
was going on at the intermediate resolutions, but he did fix the
problems that cropped up when the generic Apple driver was used.
I looked at the specs and the Mac mini, the base model iMac, and the
MacBooks (13.3" models) are share a common video card
"Intel GMA 950 graphics processor with 64MB of DDR2 SDRAM shared with
main memory(1)
1.Memory available to Mac OS X may vary depending on graphics needs.
Minimum graphics memory usage is 80MB, resulting in 432MB of system
memory available."
The the faster 17" and 20" iMacs use an ATi Radeon X1600 graphics
processor, and the 24" iMac uses a NVIDIA GeForce 7300 GT graphics
processor. The MacBook Pros use an ATI Mobility Radeon X1600 graphics
processor. I suspect that is why I don't have any display artifacts and
you do.
Chris
--
http://mysite.verizon.net/cjmasi/lego/
Learn about brittle bone disease
http://www.oif.org/
|
|
Message has 1 Reply:
Message is in Reply To:
12 Messages in This Thread:
  
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
