fiducial sstt/watch_fiducial.jpg 80 52
translate 0 0 0
model sstt/model.3ds 0.26

fiducial sstt/watch_fiducial.jpg 80 52

translate 0 0 0

model sstt/model.3ds 0.26

cvs -d:pserver:anonymous@lpub4.cvs.sourceforge.net:/cvsroot/lpub4 login
cvs -z3 -d:pserver:anonymous@lpub4.cvs.sourceforge.net:/cvsroot/lpub4 co -P LPub4

cvs update

cd LPub4/LPub4
/usr/bin/qmake -spec /usr/local/Qt4.5/mkspecs/macx-g++ -macx -o Makefile LPub.pro
make

3005.dat
3004.dat
3003.dat
3001.dat

LDTrim 1.1
Usage: ldtrim                         Default:
    [-in FILE]  | [-in FILE FILE...]    stdin (use -ing to glob wildcards)
    [-out FILE] | [-out DIRECTORY]      stdout
    [-precision DIGITS]                 all significant digits preserved
    [-trim zeros|none]                  zeros (trims redundant trailing zeros)
    [-justify left|right|none]          none (alignment of values in field)
    [-invalid omit|keep]                omit (keep retains unrecognized lines)
    [-width CHARACTERS|max]             variable (minimum width of all fields)
    [-1..15 CHARACTERS]                 variable (override width for one field)
    [-h|--h|-help|--help]               display this usage summary

If multiple input files are specified without -out, they are modified in place.
If -out is given with multiple input files, output is saved to that directory.

The -precision option causes values to be rounded down and may append zeros to
reach the specified precision unless -trim zeros is explicitly specified.

Whitespace between fields is condensed to a single space.

The -width option pads values with spaces to reach the specified field width.
If -width max is given, the widest value is used as the width for all fields.
(Sub-part names are ignored for this comparison.) If a field value exists that
is wider than the requested width, that width is used as the field width.

Right justification is used if -width or -1..15 is specified without -justify.
If none of -width, -1..15, or -justify is specified, fields are unaligned.

If environment variable GATEWAY_INTERFACE is defined, LDTrim is a CGI script.

1 0 20.000000 0.000000 20.000000 0.000000 -1.000000 0.000000 1.000000 0.000000 0.000000 0.000000 0.000000 1.000000 4085c.dat 1 1 28.000000 7.000000 27.000000 0.000000 -1.000000 0.000000 0.500000 0.000000 -0.866025 0.866025 0.000000 0.500000 3023.dat 1 25 36.000000 -5.000000 11.000000 0.000000 -1.000000 0.000000 0.707106 0.000000 -0.707106 0.707106 0.000000 0.707106 2412b.dat 

1 0 20 0 20 0 -1 0 1 0 0 0 0 1 4085c.dat 1 1 28 7 27 0 -1 0 0.5 0 -0.866025 0.866025 0 0.5 3023.dat 1 25 36 -5 11 0 -1 0 0.707106 0 -0.707106 0.707106 0 0.707106 2412b.dat 

1 0 20.00 0.00 20.00 0.00 -1.00 0.00 1.00 0.00 0.00 0.00 0.00 1.00 4085c.dat 1 1 28.00 7.00 27.00 0.00 -1.00 0.00 0.50 0.00 -0.87 0.87 0.00 0.50 3023.dat 1 25 36.00 -5.00 11.00 0.00 -1.00 0.00 0.71 0.00 -0.71 0.71 0.00 0.71 2412b.dat 

ldtrim -in $LDRAWDIR/parts/*.dat -out /trimmed/parts/ 

Instruction Step Fading with PreL3P

By substituting different colors in different parts of a model, PreL3P can be used to create interesting effects such as the step-by-step highlighting seen here:

This page explains how this image was created. It is intended as a demonstration of what can be done with PreL3P, but other relevant topics are discussed. Windows users may be interested in LPub as a more convenient solution.

Color Preparation

Two sets of color code definitions are needed to achieve this effect. A set of modified colors is used first to give parts from previous steps a faded appearance. Then a set of normal colors is loaded to give new parts their vivid hue.

Here are the normal colors from ldconfig.ldr used to draw the current step and the final image:

0 normal.ldr
0 !COLOUR Green  CODE  2 VALUE #008C14 EDGE 0
0 !COLOUR Red    CODE  4 VALUE #C40026 EDGE 0
0 !COLOUR Yellow CODE 14 VALUE #FFDC00 EDGE 0

I used Hex Color Picker along with the standard HSB saturation slider to choose faded versions of these colors. You can use the color picker from any application to do this.

Of course, this approach is not practical for converting large numbers of colors. You’ll have to devise your own system for selecting and generating suitable substitute colors.

Here are the faded colors used for parts from previous steps:

0 faded.ldr
0 !COLOUR Green  CODE  2 VALUE #598952 EDGE 0
0 !COLOUR Red    CODE  4 VALUE #B26676 EDGE 0
0 !COLOUR Yellow CODE 14 VALUE #FBEC87 EDGE 0

Steps

The STEP meta command marks the end of each instruction step in an LDraw model. For example, here are the first three steps of the doghouse model pictured above:

1 2 0 0 0 1 0 0 0 1 0 0 0 1 41539.dat
0 STEP
1 14 50 -24 30 -1 0 0 0 1 0 0 0 -1 3005.dat
1 14 50 -24 -30 -1 0 0 0 1 0 0 0 -1 3005.dat
1 14 -50 -24 0 0 0 -1 0 1 0 1 0 0 3010.dat
0 STEP
1 14 0 -24 50 1 0 0 0 1 0 0 0 1 3009.dat
1 14 0 -24 -50 1 0 0 0 1 0 0 0 1 3009.dat
0 STEP

Most LDraw editors make it easy to create and organize steps. For instance, steps are always shown as part of the model hierarchy in Bricksmith’s “File Contents” drawer:

Once a model is complete, its constituent steps can be exported as a series of individual files that represent the model up to that point. In other words, each exported step model is essentially identical to the original model except that it is truncated after the corresponding step.

Rendering each of these partial models produces an image depicting each step in the instructions.

PreL3P Meta Commands

Before proceeding to render the step models, PreL3P meta commands are inserted at the beginning of the file and at the beginning of the most recent step to invoke the appropriate color substitution schemes. The -ldconfig option is used to load the faded.ldr and normal.ldr files prepared above. (PreL3P supports the notion of “LDraw configuration files”—files containing pertinent meta commands; if present, any visible linetypes are ignored.)

By default, PreL3P does not modify the basic color codes understood by L3P. To accomplish step fading, however, it may be necessary to do so. The +codes option tells PreL3P which color codes should be kept in their original form. The special parameter none causes all codes to be converted.

Here is the third step model with meta commands inserted:

0 !PREL3P +codes none
0 !PREL3P -ldconfig faded.ldr
1 2 0 0 0 1 0 0 0 1 0 0 0 1 41539.dat
0 STEP
1 14 50 -24 30 -1 0 0 0 1 0 0 0 -1 3005.dat
1 14 50 -24 -30 -1 0 0 0 1 0 0 0 -1 3005.dat
1 14 -50 -24 0 0 0 -1 0 1 0 1 0 0 3010.dat
0 STEP
0 !PREL3P -ldconfig normal.ldr
1 14 0 -24 50 1 0 0 0 1 0 0 0 1 3009.dat
1 14 0 -24 -50 1 0 0 0 1 0 0 0 1 3009.dat

For each successive step the -ldconfig normal.ldr line should be inserted later in the file. If your editor includes the STEP lines in exported step models, it is fairly easy to locate the beginning of the last step. The correct location can also be found by comparing each step model file to the previous step’s file; the new step starts where the files differ. This is the method used by Travis Cobbs’ shell script.

The first step is a special case since there are no previous steps that need to be faded. You may be able to render it without modification. For consistency, however, you could load the standard color set at the beginning of the file:

0 !PREL3P +codes none
0 !PREL3P -ldconfig normal.ldr
1 2 0 0 0 1 0 0 0 1 0 0 0 1 41539.dat

Note that the preparations are slightly more complex for MPD files. Another -ldconfig faded.ldr command would be needed at the end of the main model to draw submodels from previous steps in the faded colors. Any submodels included in the current step would need to use normal.ldr again. Submodels referenced by the previous step and the current step present a challenge that is left as an exercise for the reader.

Running PreL3P

Once the meta commands have been inserted, the step models can be processed with PreL3P. This replaces the original color codes with hexadecimal values that represent the exact shades defined in the color configuration files.

prel3p -in doghouse3.ldr -out doghouse3-faded.ldr

Rendering

Finally the faded step models are ready to be rendered. PreL3P’s name is a bit of a misnomer; the output works just as well with LDView (note, however, that these hexadecimal colors do not conform to the LDraw format specification, so don’t expect them to work with all LDraw software).

Currently, it is easiest to render a batch of images from the command line. If you save a bunch of command lines to a file named render, you can run them all with sh render (other automation methods may be forthcoming). Here’s what one command looks like:

ldview doghouse3.ldr -SaveSnapshot=doghouse03.png -AutoCrop=0 -SaveZoomToFit=0 -WindowWidth=1024 -WindowHeight=1024 -SaveActualSize=1 -cg30,45 -ModelCenter=0.0,-50,0.0 -ModelSize=250

With LDView 3.2 on Mac OS X, you might need to expand ldview to /Applications/LDView/LDView.App/Contents/MacOS/LDView. Only the first two arguments need to be changed from step to step; the rest specify the size of the output image and ensure that each image will be rendered at the same scale. I’m not particularly familiar with LDView’s command line syntax, so more succinct options may be possible.

Briefly, the -cg option specifies the “latitude and longitude” of the camera on a globe whose origin is specified in LDraw units by the -ModelCenter option. The -ModelSize option controls the distance from the camera to the center of the model. These options work together to ensure the same perspective is used to depict each step. Otherwise, the different dimensions of the individual steps might result in inconsistent default camera positions.

Posted on Friday, October 19th, 2007.

PreL3P

PreL3P preprocesses LDraw files for color compatibility with L3P, which converts LDraw models to POV-Ray format. The current version of L3P (1.3) only knows about some color codes, but it does support arbitrary colors via an extended color syntax. PreL3P replaces LDraw color codes unrecognized by L3P with hexadecimal “extended color” specifications based on the COLOUR definitions provided by your LDraw configuration file. No special material tags are honored besides ALPHA 128 (regular transparency). Color codes can also be mapped directly to other color codes.

PreL3P is a hack to allow models containing contemporary colors to be rendered with L3P and POV-Ray without touching any POV-Ray code. It is not intended to replace other, more expert, solutions to the color quandary; better results can arguably be had by manually including custom POV-Ray color definitions. Ideally, L3P and other programs like Bricksmith would support ldconfig.ldr themselves.

Usage

prel3p # Default: [-in FILE] # stdin [-out FILE] # stdout [-ldconfig FILE] # LDRAWDIR/ldconfig.ldr [+codes none|l3p|CODE[,...]] # l3p (keep codes known by L3P) [-codes none|l3p|CODE[,...]] # none (preprocess all others) [-map IN:OUT] # no mappings [-flag quiet] # not quiet (report completion) [-flag noglob] # glob expansion supported [FILE[,...]] # none (see Alternate Usage) 

Explicit option values override the defaults.

PreL3P can be used as a filter:

prel3p < input.ldr > output.ldr 

Output is not written until the input has been successfully parsed and processed, so files can be preprocessed in place:

prel3p -in model.ldr -out model.ldr 

The codes options permit custom substitution schemes to be specified. The + and - characters represent color codes which should be preserved and color codes which may be replaced, respectively.

prel3p +codes 0 # replace any code other than 0 (black) prel3p -codes 0,71,72 # replace codes 0, 71, and 72, but no others prel3p +codes l3p -codes 4 # preserve color codes known to L3P, except 4 prel3p +codes none # replace every color code (preserve none) 

Unspecified codes are handled according to the behavior implied by the type of the first codes option. +codes implies that other codes may be replaced; -codes implies that other codes should be preserved. Subsequent options of either type modify the initial set.

Color codes can be renumbered with the -map option. For instance, to replace instances of color code 7 with color 8, specify -map 7:8. Mapping occurs before substitution, so if -codes 8 is also specified and a !COLOUR definition for 8 is found, instances of 7 will ultimately be replaced by the hexadecimal equivalent of 8.

A message reporting how many colors were changed and how many lines contained changes is printed when processing is complete. Mappings and color substitutions both constitute color changes.

Color definitions are normally read from LDRAWDIR/ldconfig.ldr (LDRAWDIR is an environment variable assumed to contain the path to your LDraw directory). Different configuration files may be specified with the -ldconfig option. Multiple -ldconfig options may be given, in which case the last of multiple definitions for the same color code takes precedence.

With the exception of color codes, PreL3P’s output is identical to its input. Whitespace, capitalization, and decimal precision are not modified. Unrecognized lines are preserved, as are unrecognized color codes (those not identified by the ldconfig file).

Alternate Usage

If no -in or -out arguments are specified, PreL3P will interpret unrecognized arguments as paths to files to process.

prel3p model.ldr 

The original model.ldr is copied to model.ldr.bak and the processed version is saved in place as model.ldr.

In this context PreL3P understands glob wildcard characters. For instance, in a directory containing only the files model1.ldr, model2.ldr, and model3.ldr, the following commands are equivalent:

prel3p model*.ldr prel3p model?.ldr prel3p model[1-3].ldr prel3p model{1,2,3}.ldr prel3p model1.ldr model2.ldr model3.ldr 

This feature is intended primarily as a convenience for Windows command prompt users since this functionality is typically provided by the command line shell itself on other platforms (unless the argument is quoted). Wildcard expansion can be disabled with the -flag noglob option.

Meta Commands

In addition to the !COLOUR meta command, PreL3P understands unofficial meta commands which allow certain PreL3P command line options to be imbedded in models and configuration files.

The general form of these meta commands is:

0 !PREL3P OPTION VALUE 

where OPTION is one of -ldconfig, +codes, -codes, or -map and VALUE is formatted as the analogous command line parameter.

Options and !COLOUR definitions are read from the input model header after command line options are parsed. The model header is comprised of all input lines preceding the first instance of any LDraw type 1 through 5 lines. Configuration files specified by -ldconfig options in the model header are appended to the configuration file queue and override the default -ldconfig if no explicit value is given on the command line.

Configuration files are parsed sequentially after reading the model header. The entire configuration file is read; LDraw type 1 through 5 lines are ignored. Additional configuration files specified by -ldconfig meta commands within configuration files are parsed at the point they are encountered.

PreL3P meta commands in the model that are not in the model header are parsed and applied as they are encountered during processing. This allows different color substitution schemes to be used for different parts of the model.

Example

Here is a simple LDraw file, bricks.ldr. It uses color codes 89 (Royal Blue), 92 (Flesh), and 72 (Dark Stone Gray).

1 89 0 0 -20 1 0 0 0 1 0 0 0 1 3005.dat 1 92 0 0 0 1 0 0 0 1 0 0 0 1 3005.dat 1 72 0 0 20 1 0 0 0 1 0 0 0 1 3005.dat 

L3P doesn’t recognize these color codes, so it replaces them with the default color 7 (Gray). As a result, the initial rendering looks like this:

So, let’s use PreL3P to make a copy of the model with colors L3P can understand:

prel3p -in bricks.ldr -out prebricks.ldr 

The contents of prebricks.ldr:

1 0x029BB2EF 0 0 -20 1 0 0 0 1 0 0 0 1 3005.dat 1 0x02CC8E68 0 0 0 1 0 0 0 1 0 0 0 1 3005.dat 1 0x02635F61 0 0 20 1 0 0 0 1 0 0 0 1 3005.dat 

L3P converts this version of the model without complaint, and the final rendering looks like this:

Changes

1.1:

• Added “done” announcement and statistics with complementary -flag quiet option.
• Multiple -ldconfig FILE option pairs may be given.
• Added alternate usage syntax.

1.2:

• Added -map option to convert color codes directly to other codes.
• Added !PREL3P meta command versions of -ldconfig, +code, -codes, and -map.
• Added -help option to display brief usage summary.
• Tweaked alternate usage backup mechanism.

1.3:

• Meta commands may be used throughout models.

1.3.1:

• Properly report a few errors.
• Limit number of -ldconfig references to prevent circular references.

1.4:

• Added ability to process multiple files
• Added support for wildcard characters

Download

• prel3p-1.4-kit.zip 14 KB
  Platform independent Starkit. Requires a separate Tclkit (8.4.16 recommended).
• prel3p-1.4-mac.zip 1.9 MB
  Self-contained universal binary (x86 + PPC) for Mac OS X 10.4+.
• prel3p-1.4-mac-service.zip 2 MB
  Macintosh Starpack bundled as a service for filtering selected text. Install in ~/Library/Services/.
• prel3p-1.4-win.zip 559 KB
  Self-contained console binary for Windows.

The source code may be extracted from any version with SDX. An example localization file is available here.

Posted on Saturday, October 6th, 2007.