POV-Ray : Newsgroups : povray.general : Colour-flip bug? Server Time
5 Aug 2024 04:19:30 EDT (-0400)
  Colour-flip bug? (Message 7 to 16 of 16)  
<<< Previous 6 Messages Goto Initial 10 Messages
From: Tom & Lu Melly
Subject: Re: Colour-flip bug?
Date: 16 Jan 2003 14:42:16
Message: <3e270b18@news.povray.org>
"Slime" <slm### [at] slimelandcom> wrote in message
news:3e26fa99@news.povray.org...

> this, the pattern is pre-translated internally by y*-0.001. Normally that
> fixes it. However, that is *exactly* where you set the surface of your
> plane, so you're reintroducing the original floating point innacuracies.

Ah - that makes sense (as in now you've explained, rather than, doh, why
didn't I think of that). As a suggestion, it might make more sense to
translate by, say, -0.273 (less likely to be picked than 0.001).

Weird all the same.


Post a reply to this message

From: Julien Gourdon
Subject: Re: Colour-flip bug?
Date: 16 Jan 2003 15:26:36
Message: <3E2716B5.7050402@cnedra.org>
ABX wrote:

> I'm not sure how you have recognize that this is a horizontal plane and not
> vertical ... ;-)

y normal ? Was not this supposed to be horizontal ? :)

-- 
Jul### [at] cnedraorg
http://www.cnedra.org


Post a reply to this message

From: hughes, b 
Subject: Re: Colour-flip bug?
Date: 16 Jan 2003 16:01:22
Message: <3e271da2@news.povray.org>
"Tom & Lu Melly" <all### [at] tomandlucouk> wrote in message
news:3e270b18@news.povray.org...
>
> "Slime" <slm### [at] slimelandcom> wrote in message
> news:3e26fa99@news.povray.org...
>
> > this, the pattern is pre-translated internally by y*-0.001. Normally
that
> > fixes it. However, that is *exactly* where you set the surface of your
> > plane, so you're reintroducing the original floating point innacuracies.
>
> Ah - that makes sense (as in now you've explained, rather than, doh, why
> didn't I think of that). As a suggestion, it might make more sense to
> translate by, say, -0.273 (less likely to be picked than 0.001).

Admittedly, it probably isn't the ultimate perfect solution. For this to be
okay the surface placement needs to begin at 0, such as plane {y,0 material
{...} translate XYZ} so that translate would be used for moving the whole
thing to prevent erroneous happenings. If textures could dynamically
readjust maybe that would be perfect. Maybe not  :-)

0.001 was picked arbitrarily, as I recall. Or maybe because it was already a
value used in the source code, but I'd be speculating about that. I looked
it up and it is not y*-0.001, it's used on all three axes and is positive
not negative. That is if I'm reading the source code correctly. That part is
rather simple though, you can find the checker pattern in pigment.cpp and
the Small_Tolerance used on it in frame.h.

The problem encountered would happen at some user offset no matter what, I
think, and the 0.001 isn't at 0.0 at least where the most common occurances
of surfaces would align. Of course, a smaller number would become ever less
likely to intersect. Just also becomes a little more obscure.

Someone else might know this. There might be very good reasons to not go to
a smaller value for Small_Tolerance in the first place since it is a factor
for the ray tracing itself I guess.


Post a reply to this message

From: Slime
Subject: Re: Colour-flip bug?
Date: 16 Jan 2003 16:12:37
Message: <3e272045$1@news.povray.org>
> I can't believe it ! Someone assumed that the checker patern was much
> more used with a horizontal plane than with a vertical one ?


My mistake. The texture is actually internally translated by
<-0.001,-0.001,-0.001>. Some of those may be positive, I don't know for
sure.

> I find it rather strange that this correction is internaly code, since
> we (users) are used to do corrections ourselves (in case of intersection
>   between objects, things like that). Is this documented somewhere ? I
> guess we all assumed cubes went from 0 to 1, and so on...

Thing is, if they didn't do it, hundreds of new users trying out their first
simple reflective-sphere-on-checkered-plane scene would complain to them,
saying it was a bug.

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


Post a reply to this message

From: Slime
Subject: Re: Colour-flip bug?
Date: 16 Jan 2003 16:15:04
Message: <3e2720d8$1@news.povray.org>
> Someone else might know this. There might be very good reasons to not go
to
> a smaller value for Small_Tolerance in the first place since it is a
factor
> for the ray tracing itself I guess.

For some objects defined by high-order equations, .001 is as low as you can
safely go.

However, I wouldn't think that'd be the case with most objects that have
flat edges... I'd expect a smaller tolerance to be used. *shrug*

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


Post a reply to this message

From: Vadim Sytnikov
Subject: Re: Colour-flip bug?
Date: 16 Jan 2003 16:29:50
Message: <3e27244e$1@news.povray.org>
"Julien Gourdon" <jul### [at] cnedraorg> wrote:
>
> y normal ? Was not this supposed to be horizontal ? :)

For those of us belonging to "CAD school" (like yours truly), the answer is
DEFINITELY NO! :-)


Post a reply to this message

From: Warp
Subject: Re: Colour-flip bug?
Date: 16 Jan 2003 18:15:35
Message: <3e273d17@news.povray.org>
hughes, b. <omn### [at] charternet> wrote:
> 0.001 was picked arbitrarily, as I recall.

  Since it's arbitrary, I agree that it should be a value which is much
less likely to be used by anyone by chance. 0.001 is such a value that it's
extremely likely that someone will use some day. However, if it was
something like 0.00139263205, then the odds are practically nonexistent.

-- 
#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: Slime
Subject: Re: Colour-flip bug?
Date: 16 Jan 2003 18:22:23
Message: <3e273eaf$1@news.povray.org>
>   Since it's arbitrary, I agree that it should be a value which is much
> less likely to be used by anyone by chance. 0.001 is such a value that
it's
> extremely likely that someone will use some day. However, if it was
> something like 0.00139263205, then the odds are practically nonexistent.


Oh, you know how it is. *Some* jerk would find it and complain. ;)

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


Post a reply to this message

From: ABX
Subject: Re: Colour-flip bug?
Date: 17 Jan 2003 01:49:16
Message: <959f2v001lqpg6cqhplq9ojnk87ftd4el0@4ax.com>
On Thu, 16 Jan 2003 21:31:49 +0100, Julien Gourdon <jul### [at] cnedraorg> wrote:
> > I'm not sure how you have recognize that this is a horizontal plane and not
> > vertical ... ;-)
>
> y normal ? Was not this supposed to be horizontal ? :)

When you lie in bed and your view is rotated about 90 degrees, horizont is
still at the same place, not rotated. The appearance of view by itself does
not define horizontal and vertical things. Meaning of 'horizontal' is relative
and is influenced by assumptions about envirionment. More accurate thinking is
probably something like: "it is horizontal plane becouse 'sky' keyword in
camera statement was not changed and therefore default sky can be reached
going along y. the plane normal is also y but has nothing to do with this."
:-)

ABX


Post a reply to this message

From: Tom Melly
Subject: Re: Colour-flip bug?
Date: 17 Jan 2003 04:49:12
Message: <3e27d198$1@news.povray.org>
"Slime" <slm### [at] slimelandcom> wrote in message news:3e273eaf$1@news.povray.org...
>
> Oh, you know how it is. *Some* jerk would find it and complain. ;)
>

Arguably, it's better to have it rare, but not too rare - of course you could
make it pow(-1,0.5) ;)


Post a reply to this message

<<< Previous 6 Messages Goto Initial 10 Messages

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