brlcad — BRL-CAD programs for solid modeling, raytracing, graphics, and image processing
The BRL-CAD Distribution contains many directories of materials (programs, man pages, documents, libraries, etc.). The major categories of programs are:
A multi-device interactive editor for constructing and updating combinatorial solid geometry (CSG) models. See mged(1), and see also Understanding the Preparation and Analysis of Solid Models by Michael John Muuss (enclosed, in the "paper" directory).
A library of functions suitable for interrogation of a CSG solid model, utilizing ray-tracing techniques. See librt(3).
A ray-tracing lighting model, for rendering pictures of mged(1) CSG models. See rt(1), rtray(1), rtpp(1).
Programs to convert mged(1) and pix(3) format binary files to a portable ASCII form, and back again. See asc2g(1), asc2pix(1), conv-vg2g(1), g2asc(1), pix2asc(1).
A "message-passing" interface layered on top of TCP network links, to ease construction of network-distributed applications.
A generic frame-buffer library which includes
support for a number of display devices,
as well as file, network, and debugging interfaces.
Most programs which use this library have the letters "fb"
in their names. To override your system default frame-buffer,
the environment variable
FB_FILE
can be set. In addition, some commands also support a
-F
framebuffer
option.
Note that the disk file format of
libfb
is that of
pix(5),
allowing "framebuffer" files to be later processed by
any of the "pix" family of programs.
See
libfb(3),
pix-fb(3),
pix(5),
etc.
TCP-based network server which implements remote frame-buffer services.
A library to handle terminal mode setting on both Berkeley or SystemV machines.
A public-domain version of the UNIX-Plot library which differs from that of the standard libplot(3), by the addition of 3-D primitives, color, floating point coordinate routines, and the use of a file pointer parameter. See libplot3(3), plot3(5).
A Run-Length-Encoding (RLE) library, providing functions originally from the University of Utah in a library package. Note that the current version of this library reads Edition-3 RLE files. See rle-fb(1), fb-rle(1), rle-pix(1), pix-rle(1), librle(3).
A collection of image-handling utilities, each constructed as individual tools intended to be used in combination. See ap-pix(1), bw-fb(1), bw-imp(1), bw-pix(1), bw3-pix(1), bwcrop(1), bwdiff(1), bwfilter(1), bwhist(1), bwmod(1), bwrect(1), bwrot(1), bwscale(1), bwstat(1), dunncolor(1), dunnsnap(1), fb-bw(1), fb-pix(1), fb-rle(1), fbanim(1), fbclear(1), fbcmap(1), fbcmrot(1), fbcolor(1), fbframe(1), fbgrid(1), fbpoint(1), fbzoom(1), gencolor(1), loop(1), pix-bw(1), pix-bw3(1), pix-fb(1), pixbackgnd(1), pixbustup(1), pixdiff(1), pixfilter(1), pixhist(1), pixhist3d-plot3(1), pixhist3d(1), pixinterp2x(1), pixrect(1), pixrot(1), pixscale(1), pixstat(1), pixtile(1), plot3-fb(1), pp-fb(1), rle-fb(1), rle-pix(1), wavelet(1), bw(5), pix(5), plot3(5).
An interactive, termcap-based frame-buffer image editor. See fbed(1).
A program to convert mged(1) models to gift(1) format card deck files. See vdeck(1).
Whenever a framebuffer is needed, and the
-F
option has not been specified, the environment variable
FB_FILE
is checked for the device to use. The format of this
variable is either
[hostname:]/dev/
device_name[num]
or
UNIX_path ,
the pathname of a disk file to be used as a "virtual framebuffer".
Hostname
is the name of a remote machine if the remote framebuffer interface
is being used.
When a local display device is being specified, the
hostname
should not be specified, for performance reasons; just the
special string
device_name
is used to select a particular type of framebuffer.
Num
is type dependent and can either mean a display number or select
some options for that type.
Note that for security reasons, it is not permitted to access a
disk file via the remote interface.
If
FB_FILE
is not set, the default for your system will be used.
The use of
/dev/
before the
device_name
is simply to distinguish them from filenames. See the end of the
libfb(3)
manual page for a list of the device names and the meanings of
any
num
parameters they may take, and for a more detailed discussion.
A convention exists for the options used on most of the utilities provided. Random options are usually lower case. Options which could specify either a screen or file size are, by convention, lower case for file information, and upper case for screen information. Here's a list of some of the common options you may encounter:
-i
Inverse flag. Pretend origin is in upper left corner of screen, for that good old-fashioned fourth-quadrant behavior.
-c
Various. Typically means clear the screen first.
-z
Various. Typically means zoom-in on current area of display.
-s
square_file_size
WARNING:
Behavior is undefined when the
-s
flag is used in conjunction with the
-w
or -n
flags.
-w
file_width
, -n
file_height
, -S
square_screen_size
WARNING:
Behavior is undefined when the
-S
flag is used in conjunction with the
-W
or -N
flags.
-W
screen_width
, -N
screen_height
, -x
file_x_offset
, -y
file_y_offset
, -X
screen_x_offset
, -Y
screen_y_offset
, -#
bytes_per_sample
specifies the number of bytes per sample, where the flag, where the # character is a literal "pound" or "sharp" sign character, typically found over the numeral "3" on ANSI keyboards. Several programs (like pixrect) can operate on data samples of arbitrary width. For example, a pix(5) format file can often be treated like a bw(5) format file with a width of three bytes per sample.
When dealing with large collections of images, as might be needed for making a movie, it frequently becomes desirable to deal with magnetic tapes. Some of the early pix(5) tools contained built-in knowledge of the tape format. While this aberrant early design has been corrected in favor of using tape-oriented programs such as dd(1) in pipelines with the image tools, our "standard" image format remains.
Regardless of image resolution, all tape records are 24k bytes long. If an image does not occupy an integral number of tape records, the last record is padded out. For example, NTSC images in 640x480 format use 37.5 records per image. The files-tape(1) utility is helpful in performing this function.
The capacity of an average 2400 foot reel of tape at 6250 is 6144 records of 24k bytes each. For the various combinations of density and image resolution, a convention for the number of frames/reel exists:
Density Resolution Frames/reel
6250 1k 48
6250 640x480 160
6250 512 192
1600 1k 12
1600 512 48