Index of /atarilibrary/atari_cd09/VISION/POVRAY/BIN
Name Last modified Size Description
![[DIR]](/icons/back.gif)
Parent Directory 11-May-2007 21:19 -
![[TXT]](/icons/text.gif)
POV22_ST.TTP 25-Nov-1995 06:03 363k
POV22_TT.TTP 25-Nov-1995 06:03 231k
![[ ]](/icons/unknown.gif)
POVINF.DOC 25-Nov-1995 06:03 11k
POVLEGAL.DOC 25-Nov-1995 06:03 12k
WHATSNEW.DOC 25-Nov-1995 06:03 3k
This is an improved version of POVRay 2.2. I compiled it with Pure C 1.1
and added some modifications to the original source. This version supports
no displaying but works very well with POVShell 1.3.
There are to different versions of POVRay 2.2:
pov22_st.ttp - this file is for plain Atari ST's without FPU.
pov22_tt.ttp - this file is especially done for use with at least
MC68030/40 and a FPU. It won't work without!
At the end of this file are parts of the original readme's. POVRay should
still work very well. If you have problems, please contact me. By request
you can get the original archives, too.
Send bug reports or improvements to:
address: Dirk Klemmt
Heimchenweg 41
D-65929 Frankfurt am Main (Germany)
(You can write in english)
voice: 069/30 72 25
EMAIL: klemmt@informatik.uni-frankfurt.de
Frankfurt, 30.03.1995
-------------------------------------------------------------------------------
Here are parts of the original readme's:
The following lines are taken from 'snowcode.c':
This is the patch code for a snow function for POV-Ray. It's a part of the
"frame", like fog. It has the following visual properties:
(1) Snowflake size is always 1 pixel.
(2) However, smaller snowflakes are simulated by 'antialiasing';
they are not completely snow-colored but share some background
color. If I say so myself as shouldn't, this looks good :-)
(3) The probability of a pixel being changed by a snowflake takes
into consideration that a pixel represents a cone which is more
likely to include a flake as it recedes. Strictly,the sqrt below
in the First_Flake computations ought to be a cube root, but it
doesn't seem to matter much. Change it if you like.
(4) You can declare distance (essentially number of flakes) and
flake_size independantly. Typical flake_size is 1.0 - 4.0.
(5) This, like crand, is random-number driven. It won't animate
worth a damn, but looks pretty good in stills.
(6) This is basically 'near-field' - it does the part of a cloud
of flakes that is visible as single flakes. You may wish to add fog
for the flakes that are too far away to see individually.
(7) Try using this for dustmotes, mosquitoes, etc... anything tiny
and in the air.
SYNTAX: snow{distance 10.0 flake_size 2.0 color White}
ACKNOWLEDGEMENTS: This little piece of code wouldn't run without the great
stuff written by the POV-Ray team. I am really grateful for the opportunity
to use the product of their efforts. If this code,or any part thereof, is
of any use to the POV-Ray team, they are welcome to use it in any way at
all.
The following lines are taken from 'dirmods.c':
These modifications to the POV-Ray 2.2 source code add a suite of
pigment and normal textures based on Dirichlet domains. They may be
used by anybody for private use; anybody with a good compiler (mine
is not - PC real mode only X-( ) who wants to make executables avail-
able to the public may do so. The POV-Ray team, of course, are
particularly welcome to use this code in any way that benefits the
project!
The harlequin taxi bug from the first release has been corrected;
and the mortar_colour modifier has been added to avoid the kludge of
using color 0.0 from the harlequin colormap for mortar.
The effects are:
harlequin color_map{[..]} wildness <...> mortar <...>
[is_2d] [taxi/euclid/fourth]
A sort of random tesselation with solid colors. By
default it is made up of irregular polygons; setting wildness
(see below) to 0 creates a randomly-colored checker texture.
Harlequin uses a color_map, from which colors are randomly
chosen. EG: {[0.0 color Red]
[0.5 color Red]
[0.5 color White]
[1.0 color Black]}
will make half the cells red, and the other half different shades
of gray ranging from white to black.
How it's done: Take all the integer lattice points in space.
Perturb them at random (the scale of this is called "wildness".
Call these "centers". Divide space into regions so that each
region contains the points closest to one specific center. Color
the whole "nearest-neighbour region" (aka "Dirichlet domain",
"Voronoi region", "Wigner-Seitz cell", etc...) one randomly-
selected color.
Uses: Coarse granite. Camouflage greens (with a bit of turb-
ulence.) Meadows (scale huge, use a greeny-brown color map and
low wildness) Crazy paving. Abstract murals. Rough-hewn stonework
(put a translucent layer with colors over a stone texture!)
Conglomerate stones and some fancy marble (use a bit of turbulence.)
Modifiers (with sample values)
wildness 0.5
The more wildness, the further from their
original cubical shape the cells are. Wildnesses over 1 may
cause strange 'splintered' shapes. Wildnesses near 0 give
near-cubical cells.
The wildness may also be a vector. wildness<1,0,1> would
give centers perturbed only in the x and z directions; thus
the cells would look something like the cells of an irregular
honeycomb, with vertical "walls" but random "roofs".
mortar 0.1
This puts a layer of "mortar" between the cells.
Parameter = width of layer: so mortar 0.03 is very narrow,
mortar 0.5 very wide. (Cells are of approximately unit size.)
Default is 0.
mortar_colour White
Chooses the color of the mortar. White is the default. In
a short-lived first release, color_map(0.0) was used - this was
not very satisfactory, and created occasional "mortared-over"
tiles.
is_2D
uses only distances in the XY plane. Looks like
an image map. Useful (a) because it runs faster, (b) because
if you want to avoid big areas of mortar on a _flat_ surface,
the 2d verson works better. No parameter.
taxi - Uses taxicab metric
d = |x1-y1| + |x2-y2| + |x3-y3|
instead of Euclidean distance to compute the cells. Instead
of boundaries at all angles, the cell boundaries are all
planes with orientation <i,j,k> where i,j,k are taken from
{-1,0,1}. The effect is zigzag boundaries. Try it...might look
good for frost or something!
fourth - Uses the fourth root of the sum of fourth powers
instead of Euclidean distance. It's somewhere in between the
effects of the other two metrics. Good for masonry.
euclid - This is the default metric - you don't need to
declare it. It's there just in case.
turbulence, scale, translate, etc: as usual!
millefiori color_map{[..]} wildness<...> [is_2d] [taxi/euclid/fourth].
Imagine getting a whole load of those gobstopper
candies with layers of different colored sugar, then squeezing
them together into a big solid mass. Or, to be less revolting,
imaging fusing together many glass balls with concentric spheres
of color. Now carve something out of the mass. Like spotted, but
more polygonal. Uses a color_map in a fairly conventional way.
How it's done: Do the Dirichlet domain calculation. Don't worry
about what the nearest center is. Rather, keep track of how much
nearer you are to the nearest neighbour than to the second-nearest.
Then use that as the index of a color-map.
Note that if you use the same modifiers you get the same cell
boundaries as in harlequin. Useful for layering textures.
Uses: Decorative "glass". Tortoise-shell. Convection cells in
a cup of coffee. Cracks in mud. Roads seen from the air. Stones with
"crazed" pattern. Snake scales.
Modifiers: Same as for harlequin, except for mortar, which has
no effect. If you want mortar, just leave a one-color band of the
desired width at the bottom end of the color_map:
color_map{[0.0 color Mortarcolor]
[0.1 color Mortarcolor]
[0.1 color Othercolor] ...}
scoops 0.75 mortar 0.2 wildness<...> [is_2d] [taxi/euclid/fourth]
This is a normal modifier based on the Dirichlet cells. If the
amount is positive, the middles of the cells appear to bulge out from
the surface, creating the appearance of a cluster of fused nodules
(or scoops of ice-cream!) If it's negative, the middles of the cells
are 'sucked in', making a surface that appears to have been chipped or
carved with an ice-cream scoop. [I'm indebted to my wife for finding a
name that describes both cases. Thanks, Bridget!]
The scoop curvature is added to the existing curvature. Thus, if
scoops -1/R is applied to a sphere of radius R, the scooping will
(to second order) cancel the curvature of the sphere and it will
appear faceted. However, most curved surfaces do not have uniform
umbilic curvature at all points - so it won't facet them.
All modifiers from above apply. The "mortar" is a band at the
edge of each cell which isn't scooped. Moreover, if the same set
of modifiers is used, the cell boundaries will coincide - allowing
colored bulges (stones?) in a flat mortar matrix.
Typical amounts are from 0.1 to 1. Values much greater than 1 get
rather unrealistic - but interesting. Sort of like a brain.
Uses: Mostly strange. Try it on a mirrored sphere.
Also, it ought to make a pretty realistic raspberry!
[With the wave-shaping that has been predicted for POV3,
maybe pineapples and strawberries too?]
facets 0.1 wildness<...>
This is a real faceting operation. I haven't implemented
variant metrics, though it could [should?] be done. It makes the
surface of any curved object appear to be broken up into small poly-
gonal facets. Think of mirror balls, or beaten copper. It works on
anything, not just spheres. The amount corresponds to the size of
the facets, proportional to the object. facets 0.01,on any size of
convex body, will break it into on the rough order of 10,000 facets.
facets 0.1 will produce around 100 facets. Near 1, it gets rather
unrealistic; larger values could crash.
How it works: The original normal is itself a vector,
lying on the unit sphere. Scale it by 1/amount - it's now on a big
sphere. Find the Dirichlet center nearest it, and normalize that,
to get the new normal. The effect is that all the points from a
region on the surface now have the same normal - so they form a
facet.
Uses: Beaten metal, irregular crystals, etc.