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 / 9243
9242  |  9244
Subject: 
Re: Proposed solution for Building Instruction scale issue
Newsgroups: 
lugnet.cad
Date: 
Thu, 16 Jan 2003 17:11:14 GMT
Viewed: 
740 times
  
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.

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
 
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)

Message is in Reply To:
  Proposed solution for Building Instruction scale issue
 
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 (...) (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
    

Custom Search

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