 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I am experimenting with using blurred reflections and am using the method
Warp lists in his PovQandT on his web site. But rendering with this
technique takes an extremely long time to render. What other proven
techniques are there to create blurred reflections (that are preferrably
faster to render)?
...too bad POV-Ray doesn't support blurred reflections like MegaPOV does
----------------
Here is the technique listed in the PovQandT:
#declare BlurAmount = .2; // How blurred the reflection should be
#declare BlurSamples = 40; // How many reflected rays to shoot
object
{ MyObject
texture
{ average texture_map
{ #declare Ind = 0;
#declare S = seed(0);
#while(Ind < BlurSamples)
[1 pigment { ObjectPigment } // The pigment of the object here
finish { ObjectFinish } // The finish; should have reflection
normal
{ bumps BlurAmount
translate <rand(S),rand(S),rand(S)>*10
scale 1000
}
]
#declare Ind = Ind+1;
#end
}
}
}
Here is how I used it (and rendering takes forever):
#declare BlurAmount = .2;
#declare BlurSamples = 20;
#declare Polished_Chrome =
material // Polished_Chrome
{
texture
{ average texture_map
{
#declare Ind = 0;
#declare S = seed(0);
#while( Ind < BlurSamples)
[1 pigment
{
color rgb <0.2, 0.2, 0.2>
}
finish
{
ambient 0.1
diffuse 0.7
brilliance 6.0
phong 0.8
phong_size 120.0
reflection 0.6
}
normal
{
bumps BlurAmount
translate <rand(S), rand(S), rand(S)>*10
scale 1000
}
]
#declare Ind = Ind + 1;
#end
}
}
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Paragon <use### [at] host com> wrote:
> ...too bad POV-Ray doesn't support blurred reflections like MegaPOV does
It wouldn't help much. MegaPov does basically the same thing, and it's
not any faster there.
Using this trick, however, you can do much more than MegaPov's blurred
reflection can.
--
#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 <3d275fb4@news.povray.org>, "Paragon" <use### [at] hostcom> wrote:
> I am experimenting with using blurred reflections and am using the method
> Warp lists in his PovQandT on his web site. But rendering with this
> technique takes an extremely long time to render. What other proven
> techniques are there to create blurred reflections (that are preferrably
> faster to render)?
>
> ...too bad POV-Ray doesn't support blurred reflections like MegaPOV does
MegaPOV uses the same basic technique, except that it just randomly
jitters the rays. The averaged texture method is slower if you compare
by the number of blur rays cast, but you usually don't need as many
samples because the rays aren't purely random, and it is much more
flexible: it can be used to simulate different shapes of bumps or ridges
on the surface. It might be possible to make a patch that has the same
flexibility but is as optimized as possible, it would be a bit more work
than the MegaPOV blur but it is possible.
--
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:
> It might be possible to make a patch that has the same
> flexibility but is as optimized as possible, it would be a bit more work
> than the MegaPOV blur but it is possible.
I would bet that in pov4 we will have some way of saying in a texture
(or whatever property of the surface) things like "shoot a ray in this
direction and return me the color", which can eventually be used to make
blur-reflecting textures or whatever we like.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> I would bet that in pov4 we will have some way of saying in a texture
> (or whatever property of the surface) things like "shoot a ray in this
> direction and return me the color", which can eventually be used to make
> blur-reflecting textures or whatever we like.
And I hope pov4 doesn't become just another programmers only toy.
--
Ken Tyler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> MegaPov does basically the same thing, and it's not any faster
Even when two blurred objects are close to each other and the rays ping
pong? That takes ages with the blur "trick" but the rendertime can be
considerably reduced with a low max_trace_level without any noticeable
difference.. Maybe MegaPOVs blurred reflection wouldn't change it's speed
with max_trace_level? It would be a better way then, because a scene may
have other objects that need a very high max_trace_level.
> you can do much more than MegaPov's blurred reflection can.
The best results are when the averaged normals are scaled very big, but then
the layers have a random value .. if you understand what I mean ... with
only a few layers, this does not always look good.. Besides it seems a very
big limitation that we can't apply both blur *and* an ordinary normal
pattern / image_map ... doing so does not mix well without MegaPOV.
Regards,
Hugo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hugo <hua### [at] post3teledk> wrote:
> Maybe MegaPOVs blurred reflection wouldn't change it's speed
> with max_trace_level?
It wouldn't make any sense if max_trace_level would not affect blurred
reflection.
> The best results are when the averaged normals are scaled very big, but then
> the layers have a random value .. if you understand what I mean ... with
> only a few layers, this does not always look good..
You can scale the normal very small, thus getting a similar result to
MegaPov's blurred reflection. It isn't very nice either (*really* grainy).
> Besides it seems a very
> big limitation that we can't apply both blur *and* an ordinary normal
> pattern / image_map ... doing so does not mix well without MegaPOV.
The Q&T tip describes how to use both the blurred reflection trick and a
regular normal pattern.
--
#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 <3d293a2e@news.povray.org>, "Hugo" <hua### [at] post3teledk>
wrote:
> Even when two blurred objects are close to each other and the rays ping
> pong?
The blur patch doesn't do anything special in that case. That can get
very slow with the blur patch as well, and you need more samples to get
fairly smooth results.
> That takes ages with the blur "trick" but the rendertime can be
> considerably reduced with a low max_trace_level without any
> noticeable difference.. Maybe MegaPOVs blurred reflection wouldn't
> change it's speed with max_trace_level? It would be a better way
> then, because a scene may have other objects that need a very high
> max_trace_level.
There isn't any special difference between ordinary reflection and
blurred reflection, max_trace_level behaves the same. A blur patch
*could* do something like that, but the existing one doesn't.
> The best results are when the averaged normals are scaled very big, but then
> the layers have a random value .. if you understand what I mean ... with
> only a few layers, this does not always look good..
I don't understand. The part about using large scale normals is what
makes the technique better than what the patch does, I don't know what
you mean by "the layers have a random value".
With only a few layers, it doesn't look good...and the blur patch
doesn't look good with only a few samples. Your point?
> Besides it seems a very big limitation that we can't apply both blur
> *and* an ordinary normal pattern / image_map ... doing so does not
> mix well without MegaPOV.
There aren't any problems with image_maps. You *can* mix normals and
blur, it does get tricky though...a built-in feature would be simpler to
use.
--
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:
> There aren't any problems with image_maps. You *can* mix normals and
> blur, it does get tricky though...a built-in feature would be simpler to
> use.
A builtin version would also take a lot less memory and be a tiny bit faster.
However, it would be difficult to get the same versatility with a builtin
version - it would have to be designed very carefully.
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.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > The best results are when the averaged normals are scaled very big, but
then
> > the layers have a random value .. if you understand what I mean ... with
> > only a few layers, this does not always look good..
>
> I don't understand. The part about using large scale normals is what
> makes the technique better than what the patch does, I don't know what
> you mean by "the layers have a random value".
> With only a few layers, it doesn't look good...and the blur patch
> doesn't look good with only a few samples. Your point?
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).
Regards,
Hugo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
