Subject:
|
Re: Proposed solution for Building Instruction scale issue
|
Newsgroups:
|
lugnet.cad
|
Date:
|
Thu, 16 Jan 2003 18:05:13 GMT
|
Viewed:
|
807 times
|
| |
|
|
-sc... I figured there was something technically stopping you, I wonder if a
quick prescan of the sub model that reveals no rot steps could lead to a
differnt render path etc... but that's a different topic.
Back to the scaling. BTW I am thinking of the context of printing but I'm
pretty sure that it also applies to screen images as well.
It's all a matter of the destination scale consistancey, what I mean is that
all instruction steps are typically the same scale. If you have a 64x64
baseplate footprint than you got yourself a big book or the individual
elements are tiny or you make a layout decision that all the instruction
steps are *not* the same scale. I would tend to choose the later if working
on a big project, obeying some basic layout design criteria such as: not
every step is a different scale or conversely only use 2 or maybe 3 scales
depending on the magnitude of the project. And with that I would then
re-render the appropriate steps at a certain target destination resolution.
If you indivually scale each images you would first drive the layout guy
crazy by making him try match scales from image to image (which in most
cases would be yourself, and this happened the other night to me :) ) and
your image quality of each step would vary causing a very unprofessional look.
With all that said I think that the LDU per pixel should be constant for all
steps in all the sub models.
In lugnet.cad, Kevin Clague writes:
> Steve,
> On the stepclock topic. L3P<->POV-Ray stepclock mechanism does not take
> rotation steps into account, so I cannot use it.
>
> I assume you are proposing that I use the same scale across the entire set of
> building instructions, right?
>
> I chose to examine/control scale on a per DAT basis, not on a per-entire
> design process. This is because for large projects (my largest sits on 4 32x32
> baseplates), the scale must be big, too big for when you are describing
> individual sub-assemblies.
>
> In lugnet.cad, Steve Barile writes:
> > I just ran into this problem a couple nights ago when I was rendering steps
> > for a train set. Why not jump right in and determine the LDU per pixel ratio
> > for the largest camera radius and apply that number to scale all the images.
>
> > Each image size should be unique if you create a .POV for each step.
>
> I don't know what you mean in this last sentence
>
> Kevin
>
> >
> > Which leads me to another question which is about your approach. Why aren't
> > you taking advantage of the "StepClock" (-sc) function of POVRay? It would
> > reduce/eliminate parsing times etc. and would eliminate this scaling issue.
> > Perhaps I'm overlooking something more fundamental here.
> >
> > SteveB
> >
> > In lugnet.cad, Kevin Clague writes:
> > > As LPub is creating building instructions for your LDraw files, it makes
> > > sure that there is consistant scale for the building steps in a given
> > > user-defined DAT file. The scale is determined by running each step's DAT
> > > (subset of original DAT with only parts up to a given step), through L3P and
> > > determining the largest camera radius. LPub then post processes all the POV
> > > files for the sequence of steps, and modifies them to have the largest
> > > camera radius.
> > >
> > > This works quite well, but presents a problem of scale between user defined
> > > DATs. LPub depends on L3P's automatic framing capabilities for determining
> > > largest camera radius. For large models, this automatic framing capability
> > > and largest camera radius technique works pretty well.
> > >
> > > For small models that involve only a few pieces, it starts to look kind of
> > > rediculous, because the size of the individual parts on the screen get
> > > *huge*. It looks especially comical if you are reading steps that have
> > > small scale (huge parts) building steps, followed by large scale building • steps.
> > >
> > > One solution to this problem would be to have LPub implement a "minimum
> > > camera radius". If the "largest camera radius" derived with L3P's help is
> > > smaller than LPub's "minimum camera radius", the "minimum camera radius"
> > > would be used, this limiting how small a scale would be acheived.
> > >
> > > A more advanced solution would to provide a list of increasingly larger
> > > "minimum camera radiai (sp?)" so that there were a fixed number of scales
> > > that could be used, and LPub would map the scale determined using L3P's help
> > > would get mapped to one of a small list of possible scales.
> > >
> > > I like this last concept, because I think it closely matches what LEGO does
> > > in their building instructions.
> > >
> > > I'm open to input on how to solve the variable scale issue, if others have
> > > ideas.
> > >
> > > Kevin
|
|
Message has 1 Reply:
 | | Re: Proposed solution for Building Instruction scale issue
|
| (...) Rather have a single solution path unless there is a *really* compelling reason to do otherwise. LPub is quite quick with its part of the job, but there is overhead in running L3P so many times. (...) Scale changing within a given sequence of (...) (22 years ago, 16-Jan-03, to lugnet.cad)
|
Message is in Reply To:
| | Re: Proposed solution for Building Instruction scale issue
|
| Steve, On the stepclock topic. L3P<->POV-Ray stepclock mechanism does not take rotation steps into account, so I cannot use it. I assume you are proposing that I use the same scale across the entire set of building instructions, right? I chose to (...) (22 years ago, 16-Jan-03, to lugnet.cad)
|
11 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
|
|
|
|
