POV-Ray : Newsgroups : povray.beta-test : Solid crackle query Server Time
29 Jul 2024 20:27:03 EDT (-0400)
  Solid crackle query (Message 1 to 2 of 2)  
From: Coridon Henshaw
Subject: Solid crackle query
Date: 17 Feb 2002 14:50:53
Message: <Xns91B8970AE1D90CQ@204.213.191.226>
I've noticed that the offset and form keywords have no effect on the shape 
and color map shift of the cells in solid crackle patterns.  Is this by 
design or is it a bug?

Example:


plane
{
    z,0
    pigment
    {
        crackle
        solid
        form z       //Ignored when solid is present
        offset 5     //Ignored when solid is present
        metric 10    //Works fine
        color_map
        {
            [0 rgb 1]
            [1 rgb 0]
        }
    }
}

camera {location <0,0,10> look_at 0} light_source {1e6 1}


Post a reply to this message

From: Ron Parker
Subject: Re: Solid crackle query
Date: 19 Feb 2002 13:23:03
Message: <slrna7560m.cbi.ron.parker@fwi.com>
On 17 Feb 2002 14:50:53 -0500, Coridon Henshaw wrote:
> 
> I've noticed that the offset and form keywords have no effect on the shape 
> and color map shift of the cells in solid crackle patterns.  Is this by 
> design or is it a bug?

By design.  Offset and form both determine the value the pattern will take at a 
particular location.  Solid also determines the value the pattern will take 
at a particular location.  The only thing that affects the actual shape of 
the cells is metric.  Thus, the fact that the shape remains unchanged is not
a bug.[1]  Whether offset should apply when solid is specified is an interesting
question, and I'm not sure of the answer.  It could be argued either way, I
think, but if we do allow it to apply then we suddenly realize that it should
probably also apply to every other pattern, and worse yet, we should also be
able to specify a slope for every other pattern.

The truth is, there are actually already ways to handle what offset does in
the crackle pattern that are available to any pattern: color maps and pattern
functions.  Offset is only there to account for the fact that lots of 
interesting forms have a tendency to push the final pattern value out of the
allowed range of 0..1, and I needed to have a way to push it back before 
clipping takes place.  This doesn't really apply to solid, since it takes
its values from an underlying noise function that is already limited to the
0..1 range.

[1] I noticed when rereading this prior to posting that there might be some
confusion about what the "cells" are, especially with things like form <1,0,0>
that disguise the actual cell boundaries and form <0,1,0> that redefines the
notion of "cell" entirely.  Solid always uses a definition of "cell" that goes
like this: The cell associated with a given lattice point is the set of points 
for it is the closest lattice point.  You could stretch the definition a little
for weird forms like <0,1,0> to say it's the set of all points for which it's
the second-closest lattice point, but I can't come up with a reasonable 
definition for form <.6,.3,0>.  I think ultimately this falls under the heading
of "feature request" but it's definitely worth some thought.

--
#macro R(L P)sphere{L __}cylinder{L P __}#end#macro P(_1)union{R(z+_ z)R(-z _-z)
R(_-z*3_+z)torus{1__ clipped_by{plane{_ 0}}}translate z+_1}#end#macro S(_)9-(_1-
_)*(_1-_)#end#macro Z(_1 _ __)union{P(_)P(-_)R(y-z-1_)translate.1*_1-y*8pigment{
rgb<S(7)S(5)S(3)>}}#if(_1)Z(_1-__,_,__)#end#end Z(10x*-2,.2)camera{rotate x*90}


Post a reply to this message

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