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 / 10655
10654  |  10656
Subject: 
Re: Another question about LPub PLIs
Newsgroups: 
lugnet.cad
Date: 
Tue, 7 Oct 2003 21:13:01 GMT
Viewed: 
933 times
  
In lugnet.cad, Kevin L. Clague wrote:
In lugnet.cad, Joel Hoornbeek wrote:
<snip>

Hello again,
I've come up with something else that I thought I'd mention.  I ran my file
through LPub last night, with the minimum distance for the steps set at 100000
(which, by the way, seems to be about what I need to fix my scale problems), and
the minimum distance for the parts images was set to 75000.  However, the parts
images came out much smaller than the pictures of the parts in the model.  I
started re-rendering them this morning at a lesser m.d., and realized that the
parts images seem to be rendered in a window that's either 640x480 or 800x600.
This isn't a problem, since I don't really want/need the parts images for my
project to be the same size as the parts in the step images.  I just thought I'd
mention it as something you may want to look at.

What is it that you think is an issue here?  At print resolution I think I use
800x600.  At screen resolution I think I use 640x480.

Are you seeing it switch back and forth while jus staying in screen resolution?

I'm rendering at 2048x1536, so the size that the step images end up at when the
minimum distance is 75000 is different to that of the parts images when they are
rendered at 640x480 and a minimum distance of 75000.  No, I am not seeing it
switch back and forth.  I'm just pointing out the difference in size between
parts and steps even when the same minimum distance is used.


Also, as I was reviewing the images from last night's rendering, I noticed some
unexpected behavior with the BI BEGIN GREYED command.  I have been using it in
conjunction with ML-cad's Buffer Exchange, and I have one step where only the
parts inside the BI BEGIN and BI END pair are greyed out; all other parts
(including parts added in previous steps) are their normal, unshaded colors.
The steps before and after are both shaded correctly.  I then have another step
farther on in the model where I use that command, and all parts for that step
and all following steps are shaded.
Are there any problems with nesting LPub meta-statements?  I usually use the BI
statements inside a PLIST BEGIN IGN/PLIST END pair.  Have you ever encountered
situations like either of these two?

PLIST BEGIN/END pair should not contain a step, rotstep or buffer exchange.

I'm sorry; I was not clear in what I said.  I'm using a buffer exchange, and
then calling the PLIST BEGIN IGN and BI BEGIN GREYED pairs after I call the
buffer retrieve statement.  I'm at work right now, so I don't have my file in
front of me to get the exact order.  I do know that I'm not calling any buffer
exchange commands inside of any LPub command pairs.



Thanks again.


-Joel


Kevin



Message has 1 Reply:
  Re: Another question about LPub PLIs
 
snip (...) snip I've done some more investigating since I wrote the above. It seems that the LPub meta statements don't have anything to do with the behavior I described. I've uploaded a (URL) sample .ldr file> and the (URL) LPub config file> that I (...) (21 years ago, 8-Oct-03, to lugnet.cad, FTX)

Message is in Reply To:
  Re: Another question about LPub PLIs
 
(...) What is it that you think is an issue here? At print resolution I think I use 800x600. At screen resolution I think I use 640x480. Are you seeing it switch back and forth while jus staying in screen resolution? (...) PLIST BEGIN/END pair (...) (21 years ago, 7-Oct-03, to lugnet.cad)

22 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
    

Custom Search

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