Hi,

Has this been already discussed? I didn't find anything relevant.

When using non-integer "frequency" value in "color_map" (or "pigment_map" or
whatever) with "gradient", there's a behavior change at the origin.
Consider this almost minimal example:

----------------------------------
camera { location -10*z look_at 0 }
light_source { 20*<-1, 1, -1>, color rgb 1.5 }
box { -4, 4
  pigment { gradient y
    color_map {
      [0.0 color rgb <1, 0, 1>]
      [1.0 color rgb <0, 1, 1>]
    }
    // see the difference between the positive and negative zones
    // it looks fine with integer values
    // it looks "funny" with non-integer values
    frequency 0.5
  }
  scale 0.8
}
----------------------------------

Below the y=0 plane, the gradient looks OK, with a period twice as large as
normal. Above the plane, the period is still 1 unit, but the colour range
has been stretched and clipped. A similar things happens with other
non-integer values, try 1.5, for example. It looks like the positive part
is forced to have a period of 1 unit "superimposed" on whatever other
period there might be.

I've only tested this with "gradient" (only with "gradient y", to be true),
but it happens with all waveforms (sine_wave, triangle_wave...)

-- 
light_source{9+9*x,1}camera{orthographic look_at(1-y)/4angle 30location
9/4-z*4}light_source{-9*z,1}union{box{.9-z.1+x clipped_by{plane{2+y-4*x
0}}}box{z-y-.1.1+z}box{-.1.1+x}box{.1z-.1}pigment{rgb<.8.2,1>}}//Jellby

Post a reply to this message

Among other things, myself wrote:

> It looks like the positive part
> is forced to have a period of 1 unit "superimposed" on whatever other
> period there might be.

That's exactly what's happening. In the source file pattern.cpp we find this
piece of code:

============================
static DBL gradient_pattern (VECTOR EPoint, TPATTERN *TPat)
{
  DBL Result;
  VDot( Result, EPoint, TPat->Vals.Gradient );

  /* Mod to keep within [0.0,1.0] range */
  return ((Result > 1.0) ? fmod(Result, 1.0) : Result);
}
============================

Replacing the last line with "return Result;" fixes the bug with my scene
file.

What's the purpose of this restriction to [0.0 1.0]? Isn't that the job of
the Evaluate_TPat routine (which has another fmod instruction)?
If this further enforcing is needed, shouldn't it be applied to negative
numbers too?

From my limited knowledge of povray innards, this looks to me like a genuine
bug. Is it?

-- 
light_source{9+9*x,1}camera{orthographic look_at(1-y)/4angle 30location
9/4-z*4}light_source{-9*z,1}union{box{.9-z.1+x clipped_by{plane{2+y-4*x
0}}}box{z-y-.1.1+z}box{-.1.1+x}box{.1z-.1}pigment{rgb<.8.2,1>}}//Jellby

Post a reply to this message

Among other things, myself wrote:

> From my limited knowledge of povray innards, this looks to me like a
> genuine bug. Is it?

Comments? Confirmations? Should I post this to p.bugreports?

-- 
light_source{9+9*x,1}camera{orthographic look_at(1-y)/4angle 30location
9/4-z*4}light_source{-9*z,1}union{box{.9-z.1+x clipped_by{plane{2+y-4*x
0}}}box{z-y-.1.1+z}box{-.1.1+x}box{.1z-.1}pigment{rgb<.8.2,1>}}//Jellby

Post a reply to this message

In article <41e1408f@news.povray.org>, Jellby <jel### [at] yahoocom> wrote:

> Among other things, myself wrote:
> 
> > From my limited knowledge of povray innards, this looks to me like a
> > genuine bug. Is it?
> 
> Comments? Confirmations? Should I post this to p.bugreports?

I think this is a bug. I "fixed" it in a patch which I've just moved 
over to MegaPOV, however, I haven't verified that it works properly.

I'm kind of busy starting school again now, but I'll hopefully have my 
patches documented and released in a couple weeks. Included are a "no 
waveform" patch (which fixes this issue and allows direct use of the 
pattern values), crackle optimizatons, 2D crackle, the voronoi pattern, 
a faster proximity pattern, blob2 object, and few other updates and new 
patches.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

Among other things, Christopher James Huff saw fit to write:

> I think this is a bug. I "fixed" it in a patch which I've just moved
> over to MegaPOV, however, I haven't verified that it works properly.

Great. Does that mean a post to bugreports is not needed?

-- 
light_source{9+9*x,1}camera{orthographic look_at(1-y)/4angle 30location
9/4-z*4}light_source{-9*z,1}union{box{.9-z.1+x clipped_by{plane{2+y-4*x
0}}}box{z-y-.1.1+z}box{-.1.1+x}box{.1z-.1}pigment{rgb<.8.2,1>}}//Jellby

Post a reply to this message

In article <41ee715d@news.povray.org>, Jellby <me### [at] privacynet> wrote:

> > I think this is a bug. I "fixed" it in a patch which I've just moved
> > over to MegaPOV, however, I haven't verified that it works properly.
> 
> Great. Does that mean a post to bugreports is not needed?

No. If you can come up with a good example, post it. This is just a 
third party patch.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message