Hugo <hua### [at] post3teledk> wrote:
> I'll try again then. I was only talking about the reflection tricks without
> Megapov. Lets say you average 5 normals, using the bump pattern scaled very
> big. Then you have 5 normals, but their directions are random..

> Example: You apply the blur texture on a plane and put a white sphere above
> it, that is supposed to be reflected on the plane, and use a black
> background.. The result with 5 averaged normals is not 5 eqaul steps between
> black/white. Because the bump patterns have random values (psudo-random, to
> be precise).

  With 5 blur samples MegaPov would shoot 5 reflected rays to random
directions for each pixel. This doesn't give any better result (just an
extremely grainy one).
  You can simulate the same effect by scaling the normal very small in the
trick.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

In article <3d29bb77@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   A builtin version would also take a lot less memory and be a tiny bit 
>   faster.

Maybe more than a tiny bit faster in some situations...POV recomputes 
the pigment for each sample, when it only really needs to cast more 
reflection/refraction rays.


> However, it would be difficult to get the same versatility with a builtin
> version - it would have to be designed very carefully.

Right. Something similar to the existing blur patch with the added 
ability to use patterns offset in specific ways...random translation, 
rotation around an axis, etc.


>   Of course I have the feeling that we can forget that when we get pov4
> some time in the distant future. My guess is that it will most probably have
> some kind of way of specifying quite meticulously how a surface is colored
> (something extremely similar to renderman shaders). Making any kind of
> blurred reflection with that will probably be very easy.

The existing method of specifying parameters to hard-coded shading 
algorithms works pretty well for quickly creating textures and is not 
likely to be removed, and that is what I am discussing this 
for...something where you just plug in numbers into a texture definition 
similar to what already exists. For the shaders, there could be 
refraction and reflection functions that include these algorithms.

I'm thinking of a finish attribute:
finish {
    surface {BLUR_AMOUNT
        samples NUM_SAMPLES
        ...
    }
    surface {BLUR_PATTERN
        samples NUM_SAMPLES
        sample_displacement METHOD, AMOUNT
    }
}
Other options could be: recompute_pigment (to force the pigment to be 
computed for each sample, in case the pigment depends on the normal), 
and maybe options to selectively affect reflection, transparency, 
highlights, etc.

If a number is specified, it is treated as the blur amount of the 
existing blur patch. If it is a pattern, it is treated as an input for 
perturbing the normals for the sample rays.

An example might be:
surface {bozo
    samples 16
    sample_displacement translate < 10, 10, 10>
}

This would perturb the normal using the bozo pattern for 10 samples, 
each translated by something from < 0, 0, 0> to < 10, 10, 10>.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

Christopher James Huff <chr### [at] maccom> wrote:
> Right. Something similar to the existing blur patch with the added 
> ability to use patterns offset in specific ways...random translation, 
> rotation around an axis, etc.

  What about refraction?-)

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

In article <3d29bcf4$1@news.povray.org>, "Hugo" <hua### [at] post3teledk> 
wrote:

> I'll try again then. I was only talking about the reflection tricks without
> Megapov. Lets say you average 5 normals, using the bump pattern scaled very
> big. Then you have 5 normals, but their directions are random..

Right. It has to be that way, otherwise you wouldn't get blur. The 
problem is?


> Example: You apply the blur texture on a plane and put a white sphere above
> it, that is supposed to be reflected on the plane, and use a black
> background.. The result with 5 averaged normals is not 5 eqaul steps between
> black/white. Because the bump patterns have random values (psudo-random, to
> be precise).

That's why you need much more than 5 samples. The blur patch takes them 
at complete random in the sampling area, so you get a "noisy" result 
where the color of one pixel has little relation to the color of the 
next. With the "average texture trick", the sample directions change 
relatively slowly over space, so the contribution from a specific 
direction is taken into account over an area of the surface, and you get 
a "stepping" artifact instead of noise. The stepping effect is less 
noticeable, so you can often get away with fewer samples...a similar 
situation as with method 1 vs. method 2 or 3 media.

It doesn't look good with only a few samples because you need more 
samples...there isn't really any way around that. It might be possible 
to add a pretrace stage that precalculates the blurry reflection at 
various points and then interpolates that data, similar to radiosity, 
but that would be a major addition...and the existing blur patch doesn't 
do that.

The existing blur patch looks awful with 5 samples, why are you 
complaining about the number needed by the averaged texture technique? 
The current blur patch is not any better!

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

In article <3d29e350@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

> Christopher James Huff <chr### [at] maccom> wrote:
> > Right. Something similar to the existing blur patch with the added 
> > ability to use patterns offset in specific ways...random translation, 
> > rotation around an axis, etc.
> 
>   What about refraction?-)

The patch I have in mind would affect both reflection and refraction, 
and maybe optionally highlights and other normal-dependant features.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

>> Lets say you average 5 normals, using the bump pattern scaled
>> very big. Then you have 5 normals, but their directions are random.
>
>Right. It has to be that way, otherwise you wouldn't get blur. The
>problem is?

Well I'm not sure it has to be random.. I would think it's possible to use
the surface normal (of the object that's supposed to have blurred
reflection), as a starting point, and shoot rays in a circular pattern
around that surface normal.


> The existing blur patch looks awful with 5 samples, why are you
> complaining about the number needed by the averaged texture technique?
> The current blur patch is not any better!

I don't try to complain.  ;o)  I'm only pointing out some limitations.
Thanks for explaining the difference (or no difference) between the patch
and the averaged normals.


Regards,
Hugo

Post a reply to this message