MS and MSTTY News
@8/10/89: Color space conversion routines
-----------------------------------------
Several routines are now included in the MS library for converting
colors between hsv and rgb. Several of these routines previously
existed but were undocumented and one has changed name.
hsv_to_rgb(h, s, v, r, g, b)
float h, s, v;
float *r, *g, *b;
Converts HSV to RGB. h is given in degrees, s and v are 0-1
shsv_to_rgb(h, s, v, r, g, b)
char *h;
float s, v;
float *r, *g, *b;
Like above except h is a string which may be either a color
name, e.g. "yellow", or contain a numeric specication of degrees,
e.g. "120.0".
rgb_to_hsv(r, g, b, h, s, v)
float r, g, b;
float *h, *s, *v;
Convert RGB to HSV. h is returned in degrees.
@8/10/89: Bug fix in "rainbow" color mapping
--------------------------------------------
"rainbow" color mapping now works correctly.
@8/10/89: Transparency supported in raytraced rendering
-------------------------------------------------------
Ray traced objects may now be translucent. The translucency of an
object is controlled by the property "xmitt" which may take on
values in the range 0.0 (opaque) to 1.0 (transparent). Further
enhancement (controlled via additional properties) in translucent
object rendering are planned.
@8/10/89: Phong shading and Vertex coloring
-------------------------------------------
Phong shading may now be combined with vertex colors to produced
smooth, vertex shaded polygonal surfaces. Remeber to turn "sheet"
on and "cull" off when rendering open objects (surface sheets)
(C/MS: ms_putprp(obj, "sheet", 1); ms_putprp(obj, "cull", 0);
MSTTY: sheet on; cull off)
@7/5/89: SGI Device Driver and "hardware" rendering mode
--------------------------------------------------------
A device driver for SGI workstations is under development. Although
this driver is not complete it is being distributed with the current
release. Under the current implementation only one MS SGI window may
exist and this window may not be moved or resized. These restrictions
will, of course, be lifted in the final version. The MS device name
of the window is "SGI". The multiwindow version will be similar to
the X window and SunView drivers in that it will use device
names SGI0, SGI1, etc. The SGI device options "kill" and "nokill"
are supported and have the same meaning as for X and SUN windows.
The MS device SGI may be used just like any other MS device, e.g.
it may be attached to a Camera and images may be copied to and from
it. However, in addition, MS now supports a new rendering mode for
high performance devices such as the SGI. This rendering mode, called
"hardware", tells MS to bypass the normal software rendering process
and to use whatever 3D graphics hardware mechanisms are provided by
the device. (Currently, the SGI is the only device which supports
this mode.) As an example, the following MSTTY commands will render
an image using the SGI hardware:
* Attach the SGI to Camera "CAM0"
attach =CAM0 SGI
* Use hardware rendering mode
display =CAM0 hardware
* Create an image
render
* Now use normal software shading
display =CAM0 scan
render
When rendering in the "hardware" mode, the image produced may be
either a line drawing or a shaded (scan converted) image depending
on the device's hardware. Since the SGI can perform both types of
rendering in hardware, two device options are supplied: "wire" and
"shade". Continuing the example,
* Use hardware shading
display =CAM0 hardware
option SGI shade
render
Shaded drawings produced by device hardware may not be identical
to those produced by the normal MS software rendering modes. Many
MS features, e.g. color mapping, translucent particles, mathematical
surfaces etc., may simply not be supported by the device hardware and
may be approximated, as in the case of curved surfaces or ignored,
as in the case of color mapping. Also, in general, hardware
rendering may produce a lower quality image. The tradeoff is, of
course, speed. Hardware rendering on the SGI tends to be at least
an order of magnitude faster than software rendering.
The speed of hardware rendering may be substantially increased by
using the MS routine ms_normals() (MSTTY command: "normals") to
precomputed surface normals. This command should be issued for
each polygonal object which is to be rendered.
Known bugs and limitations:
1. Multiprocessing raytracing (NPROC>1) will not work directly
to the SGI. Use a virtual frame buffer and copy.
2. Particles and Screens don't rendering in "hardware" mode.
3. Hardware rendering will occassionally produce a "singular matrix"
error message from the SGI.
4. The SGI window may not be moved or resized.
5. Double buffering is not yet implemented.
@7/3/89: More on MAP properties
-------------------------------
MS_DUMP and MS_RESTORE will now remove/ignore both color and
texture map properties (e.g. as set by set_cmap or the MSTTY command
map).
@7/2/89: Raytracing messages
----------------------------
Setting the MS error level to 0 will cause a "blip" of the form
"Raster n" to be printed out during raytracing and a variety of
statistics to be printed out when the rendering is completed.
Any higher error level will suppress these messages.
@7/2/89: X Windows device option
--------------------------------
A new option allowing you to set the display/server from within MS
is now supported. This option is specified using a string of the
form "display=host:d" where "display" is typed verbatim, 'host' is
the name of the server and 'd' is the display id (usually 0). For
example, in MSTTY to set device X3 to display on host 'guinness'
one would issue the command:
option X3 display=guinness:0
@6/30/89: MSTTY =obj syntax
---------------------------
The parsing of the MSTTY =obj syntax has been modified so that white
space between the '=' and the 'object' name is permitted.
@6/20/89: Raytraced CONES
-------------------------
Objects of class "cone" now raytrace correctly.
@6/15/89: Raytracing on SGI
---------------------------
The raytracer on the SGIs will now use multiple processors. The number
of processors used may be controlled using the environment variable
NPROC. For example, issuing the CSH command "setenv NPROC 3", will
force the raytracer to start 3 processes. The number of processors
specified should be no more than the number of physical processors
for best results. If NPROC is not set MS will use all available
processors. This default may change to all but one of the available
processors in the near future.
@4/10/89: updates
-----------------
dump removes "cmap" property
@4/1/89: updates
----------------
New property "fastshade".
New functions ms_normals(), ms_defnorm(obj, x, y, z).
Bug fix for "hull" rendering of quadrics.
New raster op "random n" where n is the % of pixels to be copied.
Change/fix to raster op "tint percentage"
0.0 => transparent, 1.0 => opaque (was reversed)
Bug fix in "odd raster line" poly scan code
Speed improvements in polygon shading
ms_rdimg(...) uses size of receiving device when file is headerless.
This was always the case but the message printed was incorrect.
ms_rdimg(file, dev, opts) opts = "noclose" will continue to read
from same file
@3/15/89: DV_TRAK routine
-------------------------
A new device subsystem routine for tracking input pointer motion:
dv_trak(dev, fnc, x, y).
DEVICE *dev;
int (*fnc)();
float *x, *y;
XYINput is read from "dev" and "fnc" is called with that input value
until a key/the stylus is pressed. The position of the press is
returned in *x, *y.
The dv_trak is supported in the X device driver.
New X options related to dv_trak support: wait/nowait, last/all.
wait - wait for new input before calling "fnc".
nowait - call "fnc" immediately even if new input is not available.
last - call "fnc" with only the last xy input value.
all - call "fnc" once for every xy input value received.
@3/12/89: update
----------------
New routine ms_project(obj, 1.0/dist)
@3/1/89: X11R3 device driver
----------------------------
Device X now X11. Uses XW library.
device options: stdcolor, kill/nokill.
standard color options for all colormap devices:
color, monochrome, bw, rv, primary, red7, green7, blue7,
@12/5/88: Dither improvements
-----------------------------
Dither routines produce fewer artifacts.
@11/21/88: SUN device enhancements
----------------------------------
Changes to SUN driver. Now supports color, read and write, resizing.
@11/11/88: Property routine patches
-----------------------------------
ms_putprp(obj, prop, float) and ms_getprp(obj, prop, &float) now work
correctly. Further changes anticipated.
@6/1/88: Vertex color shading
-----------------------------
Vertex shading. ms_defvcol(v, color) now supported (gouraud or flat
shading modes only, i.e. not phong)
New polygon property "sheet" flips surface normals on back faces.
Use properties "sheet", 1 and "cull", 0 to shade open objects(sheets)
Gouraud shading now supported with property "gouraud".
@1/1/88: Particle object class
-------------------------------
New object class "particle". Relevant properties: "size" (default 0.1)
and "density" (default 0.5)
@11/28/87: XFER (ms_movobj)
---------------------------
Moving/transferring an object now places the newly transferred
object at the end of parent object's child list. Previously the newly
created object was postioned at the beginning of the list. The new
behavior is more consistent with the behaviour of child creation (ms_bgnobj).
This should not effect any existing programs.
@10/01/87: Color Dither
-----------------------
A second version of dithering has been added to MS. This version
dithers a full color image into an 8 bit color mapped image. The color
mapping scheme used is the 3-3-2 encoding used for 8 bit displays (device
option "color"). The new command in MSTTY is:
cdither from_image to_image
where "from_image" should be a full color image/device and "to_image"
may be either a full color (32 bit) or color mapped (8 bit) image/device.
(Note: It is expected that the functionality of cdither and dither will be
subsumed by a single command with optional parameters)
@09/25/87: New options for RASTER (Raster Technologies) device driver
---------------------------------------------------------------------
A new device option has been added for device RASTER (Raster
Technologies Model 1/xx displays) which allows the device to be used
both as a normal terminal (controlling tty) and as the attached graphics
device. The device options "tty" and "notty" turn this feature on and off,
.e.g. in MSTTY the command "option RASTER tty" enables tty handling. This
option MUST be enabled in MSTTY whenever the device is attached via /dev/tty,
i.e. whenever a "setenv RASTER /dev/tty, .." is in effect.
@8/30/87: Bug Fix
-----------------
A bug which would occasionally caused MSTTY to die (drop core/abend) when
a macro was deleted (macdelete and macedit) has been fixed.
@5/23/87: Dither command
------------------------
A new command 'dither' has been added to MSTTY. Dither takes a color image
and converts it to a black and white only image using a "half-toning"
technique. The format of the command is:
dither from_image to_image
This command is particular useful for displaying images on laser printers
and 1 bit displays, e.g. Sun workstations.
(This is the same command that was previously available only in GBMS but
optimized for slow floating point machines, i.e. 4x speed-up on Suns)
@5/23/87: New raster operator
-----------------------------
A new option/raster operation 'tint' has been added to the copy and rastop
commands. This new operation 'tint' causes the new image to be copied into
the old image with a variable degree of "translucency". The resulting image
is an interpolation of the two images. The amount of transulence is specified
by supplying an additional argument which ranges from 0.0 (fully transparent)
to 1.0 (fully opaque). For example, to copy with 60% translucence one
would issue the command:
copy from_image to_image tint 0.60
Similarly, to apply a 30% blue (0.0 0.0 1.0) tint to an image one would say:
rastop tint image 0.0 0.0 1.0 0.30
The equivalent MS C library call versions of thef these two examples would be:
ms_copdev(from_image, to_image, "tint", 0.60);
ms_aopdev(image, RGB(0.0,0.0,1.0), "tint", 0.30);
The additional numeric argument to the these commands is ignored for all
raster operations other than 'tint', although it is expected that new raster
operations may be added in the future which will also may use of this value.
@3/16/87: News Command
----------------------
Typing 'news' in mstty will list this file, which, from time to time,
will document new features in both mstty and the ms library. This file
may also be viewed by listing the file /usr/local/doc/ms.news.
@3/16/87: New MSTTY Commands
----------------------------
Several new commands have been added to mstty.
NEws > list the news file
IF value command > execute command if value is not 0.0
IFN value command > execute command if value is 0.0
XCOPy {=obj | obj} obj2 > copy transformation to obj2
XCONcat {=obj | obj} obj2 > concatenate trasformation onto obj2
SHEar {=obj} axis1 axis2 value > shear in axis1 by value on axis2
@3/16/87: Macros
----------------
MSTTY now also suports "macro" functions. A macro is much like a script file,
i.e., an 'execute' file. Macros are created using the 'macbegin' and 'macend'
commands. Commands entered between 'macbegin' and 'macend' are not executed
but become part of the macro defintion. The macro is invoked, that is, the
commands which comprise its defintion are executed, by typing the macro name,
just as if it was a built-in command. Macros may take arguments and these
are specified as optional variable names in the 'macbegin' command. Note that
the argument list variables are NOT preceded by an & in the 'macbegin' command.
Within the body of the macro the actual values passed may be reference by
using &argument. As with script file, the variable &0 is set to the currently
invoked macro or script file name and &NARGS is set to the actual number of
arguments passed. Missing arguments are initialized to an empty string ("").
As with execute files, local variables may be declared with the command 'local'.
As an example, the following macro take two arguments an object and an angle,
pivots the object about the X axis by the given angle and then renders the
object (the indentation is for illustration purposes only and is not required):
macbegin rotx obj angle
rotate =&obj x &angle
render =&obj
macend
This macro could then be executed by typing, for example,
rotx mycube 45.0
To indicate that a macro is being defined, mstty changes the prompt
message from:
Command (objectname):
to:
Macro (macroname):
Note that although a macro itself may contain a macbegin command it is
not possible to include a macend command, thus, this feature of limited
use. Macro defintions my be typed in directly or may be created by executing
a script file. Additional commands, as summerized below, allow macros to be
listed, edited, and saved into a script file.
MACBegin name {arg1 ... argn} > begin macro defintion
MACENd > end macro defintion
MACDel name > delete macro
MACEDit name > invoke editor on macro defintion
MACList > list all defined macro names
MACList name1 {name2 ... namen} > list defintion of named macros
MACSave file > write all macros to file
MACSave file {name1 ... namen} > write named macros to file
IFMac name command > excute command if macro 'name' exists
IFNMac name command > excute command if macro doesn't exist
@03/13/87: TCONE object class
-----------------------------
MS V2.1 and MSTTY support a new object class "tcone". A tcone, or truncated
cone, is simply a cone with its point chopped off. A default "cone" has
its base at y = -1.0 and its apex at y =1.0. A default tcone is truncated
at y = 0.0. The truncation value may be changed using the the ms call:
ms_define(tconeobj, "truncat", value);
or the mstty command:
truncate {=obj} value.
Tcones will color and texture map identically with cones.
@3/12/87: Improved sphere and cone shading
------------------------------------------
Shading on objects of class sphere and cone rendered with scan convesion has
been improved. Previously, these object did not shade correctly under extreme
distortions, e.g. large stretch values. Execution time for sphere shading has
also been improved by about 10%.