POV-Ray : Newsgroups : povray.programming : ANNOUNCE: POV Superpatch for version 3.1 public beta Server Time
29 Jul 2024 12:24:55 EDT (-0400)
  ANNOUNCE: POV Superpatch for version 3.1 public beta (Message 1 to 5 of 5)  
From: Ron Parker
Subject: ANNOUNCE: POV Superpatch for version 3.1 public beta
Date: 15 Oct 1998 10:56:09
Message: <3625fef9.0@news.povray.org>
The first public beta of the POV Superpatch for version 3.1 is now available
at http://twysted.net/patchstation .  Currently, only a Win32 binary is 
available.  Source is not yet generally available because it has not been 
finalized, but I would be happy to email it to interested parties, particularly
those who would like to build and contribute versions for DOS, Unix, or Mac.

The following patches by other authors have been included in this version
of the superpatch:

o Ryoichi Suzuki, Daniel Skarda, Thomas Bily, and Nathan Kopp's collected
  isosurface patches, including isosurfaces of arbitrary data, parametric
  and implicit functions, UV-mapping of images on bezier patches (map_type 8),
  and textures based on mathematical functions of location.  Daniel Skarda's
  #macro patch, while included in the isosurface package, has been removed
  from this patch in favor of the official version 3.1 #macro syntax.

o Nathan Kopp's rational bezier surface patch.

o Wolfgang Ortmann's spline patch.

o Jochen Lippert's sphere-sweeps patch

o Nathan Kopp's UV mapping, image transparency, and mesh patches.

o Wyzard's variable and blurred reflectance patches.

o Hans-Detlev Fink's and Michael C. Andrews' slope-dependent texture patch.

o Dan Connelly's #system patch.

o Ron Parker's object bounds patch.

The following new patches are also in the superpatch:

----------------------
trace
----------------------

Vector-valued function.  Traces a ray beginning at <start vector> in the
direction of <direction vector>.  If it hits the specified #declared object,
this function returns the coordinate where the ray intersected the object.
If not, it returns <0,0,0>.  If a #declared vector is provided, the normal
of the object at the intersection point (not including any normal 
perturbations due to textures) is stored into that vector.  If no 
intersection was found, that vector is reset to <0,0,0>.   Checking the
normal vector for <0,0,0> is the only reliable way to determine whether an
intersection has been found, as valid intersections can and do occur
anywhere, including at <0,0,0>.

syntax: trace( <declared object> <start vector> <direction vector>
        [<declared normal>] )

----------------------
facets
----------------------

Normal texture.  The facets texture, like bumps or wrinkles, is not suitable
for use as a pigment.  There are two forms of the facets texture.  One is
most suited for use with rounded surfaces, and one is most suited for use
with flat surfaces.

syntax: {facets [coords <scale value> | size <factor>] }

if coords is specified, the facets function creates facets with a size on the
same order as the specified scale value.  This version of facets is most
suited for use with flat surfaces, but will also work with curved surfaces.
The boundaries of the facets coincide with the boundaries of the cells in 
the standard crackle texture.

If size is specified, the facets function uses a different function that
creates facets only on curved surfaces.  The factor determines how many
facets are created, with smaller values creating more facets, but it is 
not directly related to any real-world measurement.  The same factor will
create the same pattern of facets on a sphere of any size.

----------------------
crackle changes
----------------------

These keywords are modifiers for the crackle pattern.  They may be specified
anywhere within the pattern declaration.

solid: Causes the same value to be generated for every point within a 
specific cell.  This has practical applications in making easy stained-glass
windows or flagstones.  There is no provision for mortar, but mortar may be
created by layering or texture-mapping a standard crackle texture with a
solid one.  The default for this parameter is off.

metric: Changing the metric changes the function used to determine which
cell center is closer, for purposes of determining which cell a particular
point falls in.  The standard Euclidean distance function has a metric of 
2.  Changing the metric value changes the boundaries of the cells.  
A metric value of 3, for example, causes the boundaries to curve, while
a very large metric constrains the boundaries to the xy, xz, and yz planes.
The default for metric is 2, as used by the standard crackle texture.
Metrics other than 1 or 2 can lead to substantially longer render times.

form <vector>: Form determines the linear combination of distances used to 
create the texture.  Form is a vector.  The first component determines the 
multiple of the distance to the closest point to be used in determining the 
value of the pattern at a particular point.  The second component determines 
the coefficient applied to the second-closest distance, and the third 
component corresponds to the third-closest distance.  The standard form 
is <-1,1,0>.  Another commonly-used form is <1,0,0>, which produces a 
pattern that looks roughly like a random collection of intersecting spheres 
or cells.  The default for form is the standard <-1,1,0>.  Other forms can
create very interesting effects, but it's best to keep the sum of the 
coefficients low.  If the final computed value is too low or too high, the
resultant pigment will be saturated with the color at the low or high end of
the color_map.  In this case, try multiplying the form vector by a constant.

offset: The offset is used to displace the texture from the standard xyz 
space along a fourth dimension.  It can be used to round off the "pointy"
parts of a cellular normal texture or procedural heightfield.  The default 
offset is zero.  This parameter is included for completeness, as the same
effect can usually be obtained with an appropriate slope or color map.

----------------------
pattern
----------------------

This keyword defines a new image type.  The pixels of the image can be 
derived from any standard pigment.  This image may be used wherever a tga
image may be used.  Some uses include creating heightfields from procedural
textures or wrapping a 2d texture such as hexagons around a cylinder.

syntax: pattern <width>, <height> { <pigment body> } may be used wherever
an image specifier like tga or png may be used.  Width and height specify 
the resolution of the resulting bitmap image.  The pigment body may contain
transformations.  If present, they apply only to the pigment and not to the 
object as a whole.  This image type currently ignores any filter or 
transparency that may be present in the pigment.


Post a reply to this message

From: Ron Parker
Subject: Re: ANNOUNCE: POV Superpatch for version 3.1 public beta
Date: 15 Oct 1998 12:11:56
Message: <362610bc.0@news.povray.org>
On 15 Oct 1998 09:56:09 -0500, Ron Parker <par### [at] my-dejanewscom> wrote:
>o Nathan Kopp's rational bezier surface patch.

Whoops, I attributed this one wrong.  This patch is actually by
Daniel Skarda (0rfelyus).  If I offended anyone, I apologize.


Post a reply to this message

From: Dan Connelly
Subject: Re: ANNOUNCE: POV Superpatch for version 3.1 public beta
Date: 15 Oct 1998 20:25:16
Message: <3626843A.F5ABE066@flash.net>
This is an amazing contribution!!!

Thanks to Ron for the time and effort he put into
this (I am proud to have my name associated it
for my one-liner system patch :)).... I look forward to
giving it a workout, but with all the features it may
take awhile.....

Dan
-- 
http://www.flash.net/~djconnel/


Post a reply to this message

From: Thomas Willhalm
Subject: Re: ANNOUNCE: POV Superpatch for version 3.1 public beta
Date: 15 Oct 1998 11:37:01
Message: <qqm90ih7uyb.fsf@goldach.fmi.uni-konstanz.de>
par### [at] my-dejanewscom (Ron Parker) writes:

> The first public beta of the POV Superpatch for version 3.1 is now available
> at http://twysted.net/patchstation .  Currently, only a Win32 binary is 
> available.  Source is not yet generally available because it has not been 
> finalized, but I would be happy to email it to interested parties, 
> particularly those who would like to build and contribute versions for DOS, 
> Unix, or Mac.
[impressive list of patches snipped]

Yeah! I would be interested in compiling a Sun Solaris version. If in your
opinion the code is ready for such an attempt, send me the code or a pointer 
to its location.

Thomas

-- 
http://www.fmi.uni-konstanz.de/~willhalm


Post a reply to this message

From: Michael Andrews
Subject: Re: ANNOUNCE: POV Superpatch for version 3.1 public beta
Date: 15 Oct 1998 14:00:15
Message: <362629FB.5A907509@remove-this.reading.ac.uk>
Hi Ron,
    I'm downloading the binary as I type, salivating copiously at the thought of
getting it home and installed ... isosurface bounded media clouds over a
procedural, slope textured heightfield landscape [drool, drool]! Oh, my!
    Ahem, pardon me. My emotions overcame me for a moment.

    Seriously Ron, this is a great job. If the source is stable I'd like to try
building a DJGPP dos port, possibly a win32 console with mingw32 version if I can
adapt what I read of how the *n*x ports are being done from the dos source ...

    Thanks for the hard work,
        Mike Andrews.

Ron Parker wrote:

> The first public beta of the POV Superpatch for version 3.1 is now available
> at http://twysted.net/patchstation .  Currently, only a Win32 binary is
> available.  Source is not yet generally available because it has not been
> finalized, but I would be happy to email it to interested parties, particularly
> those who would like to build and contribute versions for DOS, Unix, or Mac.
>
> The following patches by other authors have been included in this version
> of the superpatch:
>

[ wonderful, huge list of patches and improvements snipped :-) ]


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.