Subject:
|
Re: Background color controls for constr and part list images
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Thu, 3 Apr 2003 16:48:50 GMT
|
Viewed:
|
678 times
|
| |
|
|
In lugnet.cad.dev, Jennifer Clark writes:
>
> "Kevin L. Clague" <kevin_clague@yahoo.com> wrote in message
> news:HCrxBz.1Bso@lugnet.com...
> >
> > Let me try to restate this by example:
> >
> > Step N adds three LDraw parts, plus a sub-model. You want the part list
> > image for Step N to include the three added parts, plus all the parts • needed to
> > create the sub-model. Right?
>
> Yes, and the same for the included sub-sub-models as well.
The BOM information is recursive to include all levels of sub-models, so I
think we're talking the same thing.
>
> It would be good to have a control for doing this or not for each step
> including a sub-model, as there as some sub-models which are too complex to
> include in steps in this way, and therefore need their own pages in the
> instructions.
So we are rapidly running into one of the *major* enhancement areas of LPub:
page layout
I see two different issues here:
The ability to generate the images you *might* use in page layout.
The ability to use some of the images in page layout.
So far we've got BOMs per model/sub-model level of the file, where the BOM is
all inclusive of all the parts used to create the sub-model, and any sub-models
needed for that model.
We currently have Part List Images (PLI) for each step/rotstep in each
sub-model/model in the design. In the case where a sub-model is added in the
step, we can have the image of the sub-model included in the PLI or not (this
not part was added yesterday).
I've added PLI=BOM parts of sub-models + parts added during step (per
Jennifer's request) to the list of possible PLI formats. It will be added
soon.
Creating these images is very quick once the individual part images is
rendered, so I envision that both of these PLI types would be created for steps
that include sub-models.
Once these images are rendered it is up to page layout (currently human) to
decide which images are used.
When I get rid of the minor requests, I really want to work on page layout.
Some sub-models are so large that they need to be treated the way LPub
currently does, but some sub-models are small enough that they are perfect as
inserts for the given step. These kind of inserts could have a BOM type image
showing the parts needed to create the insert, and the individual step images
for the insert tiled together into one image. I envision width constrainted,
with max columns per row, or height constrained with max rows per column. At
this point you might as well throw in the background color overrides in case
you want to override the default color for this sub-model reference.
LPub could create a BOM for this sub-model which could be placed next to the
tiled insert, or the page layout could use the PLI=submodel-BOM + added parts
method requested by Jennifer.
>
> So, for example, we have the step as described previously with sub-model and
> sub-submodel included in a single top level step - would "sub model
> inlining" be an appropriate term for this? :-
>
> [1] http://library.brickshelf.com/scans/8000/8460/8460-015.html
>
> Some sub-models are too large or complex for this, however. In the same
> instructions there is also a sub-model representing the crane superstructure
> which is done in the standard way, the way LPub currently does it :-
>
> [2] http://library.brickshelf.com/scans/8000/8460/8460-028.html
>
> Of course, things are not that simple! Case [2] shows a sub-model, but there
> are sub-models in this sub-model which are of course sub-sub-models, and
> those are rendered on a yellow background. Now in the case [1], with the
> sub-model and sub-sub-models directly included in the top level step, the
> equivalent level model is on a pink background.
Boy, this parts in parts in parts stuff is kind of a write-only communication
:^(
>
> In other words, the colour of the background of a model, sub-model and
> sub-sub-model depends not only on the its explicit place in the model
> hierarchy, but also on the context. I think it goes like this:
>
> - If doing a step where there are sub-models explicitly included in that
> page such as [1], then do the background colours according to the normal
> hierarchy of inclusion.
>
> - If doing a submodel which is not explicitly included as part of a step,
> such as [2], then the hierarchy must be promoted up one level, such that the
> sub-model is rendered in the same way as the top level model, and so on.
>
> My apologies for the obscureness of this, I wish I could put it more
> succintly!
I think that the flattened sub-models in an insert where you explicitly state
the color that you want as the background is the trick to all of the above.
Once we can get LPub to create all the different image styles needed, we can
then work on the next level of issue of describing how to merge all these
wonderful images into a given page.
I've got adding TCL to LPub for user defined pre and post processing steps at
each processing phase on the list. I've also got templatized web page
generation on the list which I think should be implemented using TCL so we can
create advanced page layout mechanisms easily and flexibly.
In thinking through all of the above, I've decided that Willy T's request for
image masks to support transparency will be a *huge* help (previously I thought
it was a bit extreme (blush)). It can be used to reduce the POV renderings of
individual parts, because we can have a given part in front of a given
background color without re-rendering the part each time. This might also undo
the need for model specific image caching stuff.
Boy, I can hardly wait for that LPub guy to get all this done so I can use it
;-)
>
> Jennifer
Kevin
|
|
Message has 1 Reply:
Message is in Reply To:
17 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
|
|
|
|
