Subject:
|
Re: Proposed solution for Building Instruction scale issue
|
Newsgroups:
|
lugnet.cad
|
Date:
|
Thu, 16 Jan 2003 18:31:25 GMT
|
Viewed:
|
993 times
|
| |
|
|
In lugnet.cad, Steve Barile writes:
> -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.
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.
>
> 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.
Scale changing within a given sequence of steps for a sub-model is certainly
out. I made sure of that very early on.
I inisist on having the ability to have different scales for different
sub-assemblies, but was proposing some controls to limit those scales.
You can of course use those controls to force consistant scale across all
sub-assemblies. If we only had one "mininum camera distance" (one scale
control), *and* you set it to a scale large enough to encompass your entire
model, then all sub-models would be rendered at the same scale.
My question was "is it a good idea to allow a small set of scales, each with a
high bound". This would quantize scales to a few specific scales (zero or more
probably up to 8 I'd guess).
for each possible scale {
if the sub-model scale from L3P is less than scale upper bound {
set sub-model scale to this scale's upper bound
}
}
I think it is.
>
> With all that said I think that the LDU per pixel should be constant for all
> steps in all the sub models.
But this contradicts your previous paragraph, right?
I think the solution I propose lets you apply whatever technique you feel is
approriate for the situation. The scale controls would obviously be adjustable
by the user, not hardwired by LPub.
The part I'm not highly motivated to do is write code to figure out L3P's best
fit scale for the entire model, but hey what's a little recursion, file I/O and
CPU time amongst friends. That would be a different mechanism than the
quantized scale controls anyway.
Kevin
>
>
> 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
|
| Kevin, Overall, I think the more well thought out and defined controls there are the better the tool. And I wanted to take this oppertunity to thank you for having this open dialog, it is very reasuring and likely to produce a more robust tool in (...) (22 years ago, 16-Jan-03, to lugnet.cad)
|
Message is in Reply To:
| | Re: Proposed solution for Building Instruction scale issue
|
| -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 (...) (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
|
|
|
|
