See the thread in povray.programming for an explanation.

 - Slime
[ http://www.slimeland.com/ ]

Post a reply to this message

Attachments:
Download 'smoothhfartifact.jpg' (39 KB) Download 'smoothhfclean.jpg' (31 KB)

Preview of image 'smoothhfartifact.jpg'

Preview of image 'smoothhfclean.jpg'

This is great! Magnificient!
I still remember all those long discussions about
reworking the entire code etc... I guess it was just
in the nature of the bug that everyone assumed it
to be working correctly, and that some calculation
discrepancies were the cause, and checking these
would surely mean that the code would have to be
redone in an entire different way...

I mean, think about: Calculate the normals, normalize
them, done... Who would expect that there's a mistake
in that assumption?

Very good job. Everyone's slapping their heads,
telling themselves: Why didn't I come up with that?

I don't blame anyone. Its just good that we get a
fix for this.

So, will this make it into POV-Ray 3.5a or 3.51?
:-)


--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html
Email: Tim### [at] gmxde

Post a reply to this message

"Tim Nikias" <tim### [at] gmxde> wrote in news:3da34c3b$1@news.povray.org

> So, will this make it into POV-Ray 3.5a or 3.51?
>:-)

Maybe 3.51 along with 4d noise ?
If we wait about a week I should finish path that in some common situations 
speeds up photons calculations.

-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message

> This is great! Magnificient!


Hee hee, thanks =) I was *very* glad to find the solution after 2 days of
frustration.

> I still remember all those long discussions about
> reworking the entire code etc... I guess it was just
> in the nature of the bug that everyone assumed it
> to be working correctly, and that some calculation
> discrepancies were the cause, and checking these
> would surely mean that the code would have to be
> redone in an entire different way...

I guess that conversation was back during 3.1, I wasn't here for it...

> I mean, think about: Calculate the normals, normalize
> them, done... Who would expect that there's a mistake
> in that assumption?

Yeah, and in fact, there isn't really anything wrong with it. The reason for
the artifact is that interpolating normals isn't really an exact science. It
just happens to create a nice effect when done linearly. The transformation
after interpolation was causing it to be nonlinear, sorta, but it was still
interpolated. Just not quite like we wanted it to be. It's one of those
cases where the algorithm is doing exactly what you intend it to, but the
final result isn't exactly what you expected.

At first I thought it was a problem with the loss of data when typecasting
from double to short, but it turns out that that's hardly noticeable.
(however, since most of the normals tend to have a Y value that's extremely
small, it's not entirely unnoticeable, and I'm going to look for a way to
store the data differently so that there's no visible difference between
doubles and shorts. The screenshot I showed used doubles to store the normal
vectors.)

> So, will this make it into POV-Ray 3.5a or 3.51?
> :-)

Heh, well, I'm not a member of the POV team, so of course I don't know, but
if anyone desparately needs this fix for their IRTC entry, I'm willing to
hand out the code. In the meantime, I'm working on other things too, and I
plan to release a small patch of some sort with this, the normal accuracy
bugfix that I mentioned in povray.programming, 4D noise, and a couple other
things that I'm working on.

 - Slime
[ http://www.slimeland.com/ ]

Post a reply to this message

> > So, will this make it into POV-Ray 3.5a or 3.51?
> >:-)
>
> Maybe 3.51 along with 4d noise ?


Well, 4D noise is unlikely to get into an official release, since it sort of
would need some beta testing. New features aren't something you want to just
throw into a program.

> If we wait about a week I should finish path that in some common
situations
> speeds up photons calculations.

"Patch" =)

 - Slime
[ http://www.slimeland.com/ ]

Post a reply to this message

"Tim Nikias" <tim### [at] gmxde> wrote in news:3da34c3b$1@news.povray.org:

> So, will this make it into POV-Ray 3.5a or 3.51?
>:-)

3.51? Where are gone the versions 3.6 to 3.50?
I hate when version numbers are taken as floating values... I know MS did 
that when going from Win 3.1 to Win 3.11, but yet. What if they released 
3.2, ..., 3.9, 3.10? And after?
This logic disappears when using three or four values for version number, 
eg. 3.5.1.

-- 
--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist
http://jove.prohosting.com/~philho/

Post a reply to this message