Happy New Year to Everybody.

You made a great job, but i think that if
you include a reflection-blur and a hdr(mlpov)
patches it's perfect.
Is there anyone who knows how to do it?

Ceggi.

Post a reply to this message

In article <3e12e1dd@news.povray.org>, "ceggi" <ceg### [at] tiscalinetit> 
wrote:

> You made a great job, but i think that if you include a 
> reflection-blur and a hdr(mlpov) patches it's perfect.
> Is there anyone who knows how to do it?

Anyone could do the old reflection blur patch, but it isn't needed: 
there are better, more flexible ways of doing it already, without any 
patch.

A patch could implement the average texture method and both eliminate 
some of the overhead and make it easier to use. The pigment only needs 
to be evaluated once in most cases, it rarely depends on the normal and 
blurring it isn't always desired when it does. Same for things like 
highlights, iridescence, etc...they should all be optionally excluded 
from the blur.

-- 
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

> Anyone could do the old reflection blur patch,
> but it isn't needed

Agree.

> A patch could implement the average texture method

I've tried both the 'averaging' method and the 'microfacet' method, and I
clearly prefer the microfacets. So again, a patch is not needed. But it's
possible that even the microfacets could be speed up, by evaluating the rest
of the texture only once. To avoid confusion let me note, what I mean by
microfacets: One normal, scaled very small, but evaluated many times due to
HQ anti-alias.

Regards,
Hugo

Post a reply to this message

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

> I've tried both the 'averaging' method and the 'microfacet' method, and I
> clearly prefer the microfacets. So again, a patch is not needed. But it's
> possible that even the microfacets could be speed up, by evaluating the rest
> of the texture only once. To avoid confusion let me note, what I mean by
> microfacets: One normal, scaled very small, but evaluated many times due to
> HQ anti-alias.

That has practically the same result as using the average texture method 
with a small-scaled normal, only slower and less efficient. You seem to 
misunderstand things: the average texture method simulates microfacets 
too, it just keeps the supersampling to the blurry surface.

-- 
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

> the average texture method simulates microfacets
> too, it just keeps the supersampling
> to the blurry surface.

I was thinking about averaging normals scaled very BIG, and that looks
horrible. It even seems slower than my method unless I use .. only 10
normals, and that looks plain wrong. But I see your point, and will try to
average just a few normals, scaled very small.

Some speed optimations could be done with radiosity and reflections. The
"bolts and plugs" picture I just posted, was rendered in 2 passes: First
radiosity without AA, without area_light, and with a low max_trace_level..
Second pass loads the radiosity data, and has the above mentioned features
activated. The result looks just as good, and only takes 1/4 of the render
time. But the 2-pass method is cumbersome, at least for animations.

Regards,
Hugo

Post a reply to this message

Hugo Asm <hua### [at] post3teledk> wrote:
> I was thinking about averaging normals scaled very BIG, and that looks
> horrible. It even seems slower than my method unless I use .. only 10
> normals, and that looks plain wrong.

  In my experience scaling the normals big gives you a very smooth result,
which scaling the very small gives you a very grainy result. Personally
I like more the smooth one.
  Naturally you need a rather high amount of samples in order to get a
good-looking result with normals scaled big. When scaled small, the result
looks grainy no matter how many samples you use (even though a larger
amount of samples still gives a visually better result).
  It really depends on how you like grainy reflections. I usually don't
like them (unless it's a very rough surface where you are expecting a
grainy reflection).

  In any case, you can get both worlds with the same trick, just changing
one number.

-- 
#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

> scaling the normals big gives you a very smooth
> result, ... Naturally you need a rather high amount
> of samples in order to get a good-looking result
> with normals scaled big.

Yes, and so many samples are too slow. With just a few samples, the normals
are pointing in all kinds of wrong directions considering the true surface.

> When scaled small, the result looks grainy no matter
> how many samples you use (even though a larger
> amount of samples still gives a visually better result).

In theory yes, sure. But as you said, more samples gives a smooth result. I
just did an experiment based on Chris Huff's explanation: I'm rendering the
"bolts and plugs" scene again, this time I changed the reflective textures
to have 3 averaged normals instead of one with HQ anti-alias over the entire
scene.. It was good at first, faster, but now it hangs at the bottom of the
picture... This part still render and it will break the 2-hour limit
(compared to my posted picture).

It must be because adc_bailout and max_trace_level doesn't come and save the
day.. Now there are 3 normals to average no matter what.. The ping-pong goes
on inside the metal for the red plug... My old method also had ping-pong,
but there was only 1 normal to evaluate, so adc_bailout had more effect, so
to say.

The visual result is almost the same, but a tad worse because there are some
white spots, so for now I think my old method was the best one.

Regards,
Hugo

Post a reply to this message

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

> Yes, and so many samples are too slow. With just a few samples, the normals
> are pointing in all kinds of wrong directions considering the true surface.

You get that no matter what. There is no way to get accurate blur with 
only a few samples.


> In theory yes, sure.

In practice. In theory, you could take enough samples to get smooth 
results with random/small scale normals, in practice you can't without 
taking huge amounts of processing power. The recommended method uses 
large scale normals, it is easier to get smooth looking results with 
fewer samples.


> But as you said, more samples gives a smooth result. I
> just did an experiment based on Chris Huff's explanation: I'm rendering the
> "bolts and plugs" scene again, this time I changed the reflective textures
> to have 3 averaged normals instead of one with HQ anti-alias over the entire
> scene.. It was good at first, faster, but now it hangs at the bottom of the
> picture... This part still render and it will break the 2-hour limit
> (compared to my posted picture).

You *don't need* the high-quality AA to get a blur with this technique, 
and 3 samples are far too few. You are simply doing it wrong.

-- 
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

> You *don't need* the high-quality AA to get
> a blur with this technique, and 3 samples are far
> too few.

I know, and I was not using high-quality AA on the render with 3 averaged
normals, just a decent AA so the rest of the scene looks ok: +AM2 +A0.1
+R2 -J.

Now I tried to increase the amount of averaged normals. I started a render
with 64 samples and another one with 32 samples. Both of them are actually
incredibly slow, with or without AA. My original approch was definitely the
fastest, and looks smooth. Will you be willing to accept that?

Friendly greeting,
Hugo

Post a reply to this message

Hugo Asm <hua### [at] post3teledk> wrote:
> Now I tried to increase the amount of averaged normals. I started a render
> with 64 samples and another one with 32 samples. Both of them are actually
> incredibly slow, with or without AA. My original approch was definitely the
> fastest, and looks smooth. Will you be willing to accept that?

  It probably depends on the scene. In some scenes the grainy approach
is best, while in others the smooth one. You can't simply dump one of
the approaches because in a particular scene the other one works better.

-- 
#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

> It probably depends on the scene.
> In some scenes the grainy approach
> is best, while in others the smooth one.

Yes, and now I've got proof in my hand. I've setup a simple scene (I will
post the source in p.b.s-f) and tried my own "one normal with HQ- AA" method
versus the common method you are suggesting "many normals averaged" and the
results speak loud. When there are more than one reflective object and the
rays go ping-pong, my method is best:

1 normal and HQ AA:  2 minutes, 34 seconds.
32 averaged normals, without AA: 13 minutes, 0 seconds.

The results look pretty much the same, except I got my AA and ... your
method was measured without AA.. But when the scene doesn't have objects
where the rays go ping-pong, your method are more than twice as fast as
mine.


Regards,
Hugo

Post a reply to this message

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

> The results look pretty much the same, except I got my AA and ... your
> method was measured without AA.. But when the scene doesn't have objects
> where the rays go ping-pong, your method are more than twice as fast as
> mine.

This is pretty irrelevant to a patch though: you could reduce the number 
of samples with depth, cut blurred rays off after a smaller number of 
trace levels, etc...

-- 
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

"Hugo Asm" <hua### [at] post3teledk> ha scritto nel messaggio
news:3e138d3a$1@news.povray.org...

> Yes, and now I've got proof in my hand. I've setup a simple scene (I will
> post the source in p.b.s-f) and tried my own "one normal with HQ- AA"
method
> versus the common method you are suggesting "many normals averaged" and
the
> results speak loud. When there are more than one reflective object and the
> rays go ping-pong, my method is best:
>
> 1 normal and HQ AA:  2 minutes, 34 seconds.
> 32 averaged normals, without AA: 13 minutes, 0 seconds.
>
> The results look pretty much the same, except I got my AA and ... your
> method was measured without AA.. But when the scene doesn't have objects
> where the rays go ping-pong, your method are more than twice as fast as
> mine.

I disagree with you; i think that the method of old megaPOV is better for
the speed and the realism.
I tried to render blurred_reflection_test scene with mPOV 0.7:
reflection_blur 0.05
reflection_samples 35
no normal
+AM2 +A0.2 +R2 -J( it's enough) 800x600
2 minutes, 43 seconds on my PIII 733 Win98 system;
see and judge you the result of image posted in p.b.i..

I've a more remarks:
if you examine a metallic object, you can observe that it behaves
like a lens which blur the distant objects;
i think that we need a algorithm to simulate this like focal_blur of
a camera, but i'm not a programmer...

Regards,
Ceggi.

Post a reply to this message

Hugo Asm <hua### [at] post3teledk> wrote:
> your method was measured without AA..

  Btw, it's not "my" method. I think it was Ron Parker who came up with
the trick originally.

-- 
#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 <3e143797@news.povray.org>, "ceggi" <ceg### [at] tiscalinetit> 
wrote:

> I disagree with you; i think that the method of old megaPOV is better for
> the speed and the realism.

Well, you are allowed to believe what you wish. It is no better at 
realism, that is a simple fact. And in the experience of myself and many 
others, it is much slower.


> I've a more remarks:
> if you examine a metallic object, you can observe that it behaves
> like a lens which blur the distant objects;
> i think that we need a algorithm to simulate this like focal_blur of
> a camera, but i'm not a programmer...

It doesn't behave anything like a lens, you are on a wild goose chase.
Any surface is at least slightly blurry, and a curved surface can spread 
out light, smearing something like a lightbulb over an area of its 
surface. Regular raytracing only samples points, you need to track the 
ray "footprint" (by casting at least two slightly separated rays) and 
dim down rays that spread out a lot or use more samples for them.

-- 
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

I was actually going to back out from this discussion. There were some
"nerves" involved, and I don't wish to blame anyone, and I won't argue about
what caused it. I hope we can put it aside. Lets just sum up what we've got
so far:

We talked about 3 methods. They all seem to perform well in terms of the
visual result. The speed is different, and while it may be true, that the
best way depends on the scene, it seems valid to say that Ron Parkers method
(the averaged normals) is slow when rays go ping-pong between surfaces.
Currently I'm not aware of any way around that limitation.

The 2 other methods are simpler to use: Either MegaPOV0.7's patch, or my
method (I think it was inspired by Jaime Viwes Piquires). This method I'm
using however demands the whole scene to be rendered with high-quality
anti-alias. In some cases (perhaps many cases?) this will be slower than the
MegaPOV0.7 patch.

Ceggi tested my scene with MegaPOV0.7 and it's a clear winner in terms of
speed. Apparently it doesn't have the handicap of being slower than a snail
in cases of ping-pong, and it doesn't need anti-alias to work.

I'm not aware of instabilities with the MegaPOV patch, please let me know if
there are any.. While the patch may not seem the best answer to all scenes,
and certainly less flexible, I think it would be alright to include it with
upcoming MegaPOV versions; Chris says it won't be a big deal to technically
include.

I'm not to decide, I just lay out the facts as I currently see them, based
on my tests with real scenes, where it behaves different than scenes with
spheres on a plane... I have not followed every discussion around here about
the blurring though.. I don't claim to know all facts.

If there's anything you'd like to add or correct, I'll be listetning. Thanks
for all you peoples work so far regarding POV.

Regards,
Hugo

Post a reply to this message

Warp wrote:
>   Btw, it's not "my" method. I think it was Ron Parker
> who came up with the trick originally.

It was when he came up with it that it became popular anyway. Except for
the little trick of scaling the bumps large instead of small, which was
suggested by someone else... ;)

Rune
--
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com (updated Oct 19)
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

> It was when he came up with it that it became
> popular anyway. Except for the little trick of scaling
> the bumps large instead of small, which was
> suggested by someone else... ;)

By you.. Yes, I do remember.  :o)

Godnat Rune.
I better go to sleep, it's late.

Hugo

Post a reply to this message

"Hugo Asm" <hua### [at] post3teledk> ha scritto nel messaggio
news:3e146e45@news.povray.org...
> I was actually going to back out from this discussion. There were some
> "nerves" involved, and I don't wish to blame anyone, and I won't argue
about
> what caused it. I hope we can put it aside.


I'm sorry, i did not mean to hurt your feelings,
it's only a my devising because i tried several method again and again ...
I think  too that the Ron Parker trick is the right way, but it's too slow
if we use a complex object, while for the normal method we need of HQ AA.
I'd like only to know why many renderers (Lightwave, Cinema4d, Brazil,
FinalRender,
MentalRay, VirtualLight etc.) have the reflection_blur while no POV.

Ciao.
Ceggi.

Post a reply to this message

> I'm sorry, i did not mean to hurt your feelings,

You didn't, you are completely without guilt.
You weren't driving this conversation.

> I'd like only to know why many renderers
> (Lightwave, Cinema4d, Brazil, FinalRender,
> MentalRay, VirtualLight etc.) have the reflection_blur
> while no POV.

Because POV is able to do it within SDL (the Scene Description Language) and
doesn't actually need an internal code for it. Besides, the patch from
MegaPOV has some limits, one being that you can't stretch the blur in any
direction, but I'm not sure this is a good reason to exclude it.. Another
reason is that, apparently it's not until now that Ron Parkers trick is
releaved to have a speed problem.


Hugo

Post a reply to this message