> 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