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 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.