POV-Ray : Newsgroups : povray.unofficial.patches : MegaPOV 1.0 suggestion Server Time
3 Jul 2024 05:02:38 EDT (-0400)
  MegaPOV 1.0 suggestion (Message 1 to 10 of 20)  
Goto Latest 10 Messages Next 10 Messages >>>
From: ceggi
Subject: MegaPOV 1.0 suggestion
Date: 1 Jan 2003 07:41:01
Message: <3e12e1dd@news.povray.org>
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

From: Christopher James Huff
Subject: Re: MegaPOV 1.0 suggestion
Date: 1 Jan 2003 10:07:22
Message: <cjameshuff-82ED8A.10030601012003@netplex.aussie.org>
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

From: Hugo Asm
Subject: Re: MegaPOV 1.0 suggestion
Date: 1 Jan 2003 12:11:03
Message: <3e132127@news.povray.org>
> 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

From: Christopher James Huff
Subject: Re: MegaPOV 1.0 suggestion
Date: 1 Jan 2003 12:49:49
Message: <cjameshuff-A3488D.12453601012003@netplex.aussie.org>
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

From: Hugo Asm
Subject: Re: MegaPOV 1.0 suggestion
Date: 1 Jan 2003 13:44:44
Message: <3e13371c@news.povray.org>
> 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

From: Warp
Subject: Re: MegaPOV 1.0 suggestion
Date: 1 Jan 2003 14:25:25
Message: <3e1340a5@news.povray.org>
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

From: Hugo Asm
Subject: Re: MegaPOV 1.0 suggestion
Date: 1 Jan 2003 15:12:21
Message: <3e134ba5@news.povray.org>
> 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

From: Christopher James Huff
Subject: Re: MegaPOV 1.0 suggestion
Date: 1 Jan 2003 15:55:15
Message: <cjameshuff-DD4062.15510301012003@netplex.aussie.org>
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

From: Hugo Asm
Subject: Re: MegaPOV 1.0 suggestion
Date: 1 Jan 2003 18:04:20
Message: <3e1373f4@news.povray.org>
> 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

From: Warp
Subject: Re: MegaPOV 1.0 suggestion
Date: 1 Jan 2003 18:12:48
Message: <3e1375f0@news.povray.org>
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

Goto Latest 10 Messages Next 10 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.