| |
Well, it's been more than a year since the last official L3P release.
Mainly because I have spent more time on L3Lab. But nevertheless several
nice features have been added during that time.
So here it is:
STUDS flag in POV file
----------------------
Turn off studs to substantially speed up test renderings.
TRANSLATE, ROTATE, SCALE, TRANSFORM meta commands
-------------------------------------------------
L3P now handles these meta commands suggested by Paul Gyugyi and used in
e.g. Minifig Modeller in Steve Bliss's LDAO.
-c=<color Default Part Color
----------------------------
Normally the model contains colored references to parts, but if you only
want to render a single part, the part typically uses the color 16 for
its subparts and primitives, and the part would just be rendered in the
default gray color (7). You would have to create a dummy model file with
just one line, like
. 1 4 0 0 0 1 0 0 0 1 0 0 0 1 3001.dat
to render the part 3001 in red (4).
However, this option lets you specify the default part color for color 16
references, and you can simply start L3P like this:
l3p -c4 3001
LDRAWDIR or ldraw.ini
---------------------
It is no longer necessary to set the environment variable LDRAWDIR if you
are using LDAO or LDLite. If LDRAWDIR is not set, L3P looks for ldraw.ini
in C:\Windows (or the directory specified by the environment variable WINDIR).
If found, L3P uses the BaseDirectory setting in the [LDraw] section.
Extended colors (direct colors)
-------------------------------
The LDraw colors are 0-15, 32-47, 256-511 (and of course 16 and 24).
Paul Gyugyi defined some more colors for LDLite: 17-23, 25, 57 and
"Direct Colors" in the range 0x04000000-0x07FFFFFF.
As MLCad also supports these colors, L3P does too.
However, Gyugyi packed two RGB's (for dithering) into each Direct Color
leaving only 12 bits to each RGB, e.g. 0x04RGBRGB. Some L3P and L3Lab users
have asked for the possibility to specify "true colors" (24 bit RGB's),
so I have defined the range 0x02000000-0x03FFFFFF for this.
0x02RRGGBB for solid colors and 0x03RRGGBB for transparent.
I will support, but not require, hex notation for colors (0x/0X prefix).
You are welcome to specify the color value in decimal ;-)
The following description is partly taken from the LDLite documentation:
3. Direct colors
LDLITE defines the color values from 0x4000000 to 0x7ffffff. These represent
two 12-bit colors which are dithered together, and cannot be redefined.
They are intended to be used in converting meshes from other 3D formats.
While you can use decimal numbers, the hex representation makes the structure
clear. The edge color for all direct colors is pure black.
The first (leftmost, most significant) hex digit defines whether the color
will be transparent. "4" is an opaque color. "5" or "6" create transparent
colors. "7" will create an invisible color which will not be drawn at all.
You can interpret the two least significant bits of this digit as inverted
alpha values.
The second, third and fourth digits are the red, green and blue intensities
of the first dithered color. These digits are ignored for colors in the
range 0x6000000 to 0x7ffffff.
The fifth, sixth and seventh digits are the red, green and blue intensities
of the second dithered color. For pure colors, set these to the same as the
second, third and fourth digits. These digits are ignored for colors in the
ranges 0x5000000 to 0x5ffffff and 0x7000000 to 0x7ffffff.
Note that this is the correct description! Paul Gyugyi has swapped the
hex ranges in the last two paragraphs in his LDLITE documentation!
Valid colors
------------
L3P now knows these colors (apart from 16 and 24):
0-15, 17-23, 25-28, 32-47, 57, 256-511, 0x02000000-0x07FFFFFF.
Color 256 is used for black rubber.
I haven't spent any time adjusting the new LDraw colors, they were just
added from the FAQ. But I'll play a little with POV again to make some
better colors. Most importantly the transparent colors should not
necessarily be based on the corresponding non-transparent color, but may
have their own RGB values.
Please make any suggestions.
In the POV file an "#ifndef ColorXX" / "#end" pair is now put around L3P's
color definitions. This makes it easier to use your own definitions.
Unlimited number of colors
--------------------------
The number of simultaneous colors was in version 1.1 limited to 200 for
my programming convenience. Now you can have as many as you like.
I haven't heard about anybody reaching the limit yet, but with the
introduction of extended colors, the number of different possible colors
is now huge.
14 new primitives
-----------------
Additional POV equivalents for primitive substitution:
1-4cyls.dat, 1-4cyls2.dat, 2-4cyls.dat, 3-8cyls.dat, 2-4ring1.dat,
1-8disc.dat, 4-4con1.dat, 1-4con1.dat, 1-4con2.dat, 1-4con10.dat,
1-4ring1.dat, 1-4ring3.dat, 1-4rin10.dat, 1-4rin14.dat
Support for hi-res primitives
-----------------------------
Primitives in P\48 and future numeric subdirectories of P are also
supported. L3P skips any digit-only directory before attempting
primitive substitution, and thus treats e.g. 48\1-4cyli.dat exactly
like the ordinary 1-4cyli.dat
More checks
-----------
L3P now detects recursion, i.e. subparts referring each other in a ring.
Many parts actually have identical lines. Probably because of copy'n'paste
blunders by the author, or because the same line or suface was simply
coded twice in the file. Since this is a waste of rendering time,
L3P can now report such repeated lines. The DOS version of L3P just
reports that a given line has been seen before, the Win32 verson also
shows you the line number of the previous occurrence.
Another common mistake is to reference lines with color 16 instead of
color 24, so L3P now warns about this. The only legitimate example I
have seen is in PARTS\S\973p46a.dat.DAT "~Subpart Minifig Torso with
Forestman and Purse Pattern" by Chris Dee where he used color 16
linetype 2 to make sure an outline is visible at low resolution,
see also http://www.lugnet.com/cad/dev/?n=4161 and
http://www.lugnet.com/cad/dev/?n=4248.
A clever but questionable technique because it makes some assumptions
about the renderer. All other examples I have seen are errors,
and that justifies the "Lines should not use color 16" warning.
Ill-formatted lines like "01 ..." are also noticed.
Bad lines before first valid commands are now allowed. You should now
be able to directly render e.g. a DAT or MPD file sent by mail without
complaints about the mail header.
L3P -check now checks (recursively) if all subfile references can be found.
-stdout Redirect stderr to stdout
----------------------------------
Normally error messages goes to stderr, but you can have them redirected
to stdout by placing this option as the very first argument after l3p.
Mainly of interest for other programs which call L3P.
L3P will exit with 0 after a normal and successful run.
L3P will return a non-zero exit code in case of errors.
That's it, please enjoy
http://www.netby.net/Nord/Mandelvej/Hassing/l3p.html
/Lars
PS. Tim, will you update http://www.ldraw.org/download/software/l3p
|
|
Message has 2 Replies:
 | | Re: L3P v1.2 20000602
|
| About color definitions: The only thing that seems wrong to me in the otherwise excellent L3P v1.2 is the definition of color 0. As in the vesion 1.1 black is defined as rgb <0.301961,0.301961,0.301961>. This produces a dark grey color and not (...) (24 years ago, 3-Jun-00, to lugnet.cad)
|
4 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
