POV-Ray : Newsgroups : povray.beta-test : Additional (?) blob bug Server Time
30 Jun 2022 13:00:39 EDT (-0400)
  Additional (?) blob bug (Message 1 to 5 of 5)  
From: QQ
Subject: Additional (?) blob bug
Date: 7 Sep 2001 18:12:13
Message: <Xns9115B92CF7D8ACQ@204.213.191.226>
I've encountered a problem with the blob primative where blob components 
above a certain size disappear completely.  The code below demonstrates the 
problem.  With D=1, the scene renders correctly; with D=2 (blob size == 
400), Pov generates a blank image.

#local D = 2;
blob
{
    threshold 0.75
    sphere {<0,0,0>, 200*D, 1}
    pigment {rgb 1}
    sturm  //makes no difference
}

camera {location <0,0,750>*D look_at 0}
light_source {<0,0,750>*D color rgb 1}



HW: Win2K running on a Celeron 400 CPU with 128MB ram.


Post a reply to this message

From: Thomas Lake
Subject: Re: Additional (?) blob bug
Date: 8 Sep 2001 02:01:16
Message: <3b99b42c@news.povray.org>
I'm really not the one to answer but could it be because when you switch D
to 2 not only does the sphere get bigger, but the camera moves back to 1500
units. When D is 1 there is 500 units separating them when D is 2 where is
1100 units. Also you could try <0,0,750*D>, I thought there was something
about 3.5 not handling vectors or some such thing, don't ask me:-)

"QQ" <now### [at] nowhereno> wrote in message
news:Xns### [at] 204213191226...
>
> I've encountered a problem with the blob primative where blob components
> above a certain size disappear completely.  The code below demonstrates
the
> problem.  With D=1, the scene renders correctly; with D=2 (blob size ==
> 400), Pov generates a blank image.
>
> #local D = 2;
> blob
> {
>     threshold 0.75
>     sphere {<0,0,0>, 200*D, 1}
>     pigment {rgb 1}
>     sturm  //makes no difference
> }
>
> camera {location <0,0,750>*D look_at 0}
> light_source {<0,0,750>*D color rgb 1}
>
>
>
> HW: Win2K running on a Celeron 400 CPU with 128MB ram.


Post a reply to this message

From: KalleK
Subject: Re: Additional (?) blob bug
Date: 8 Sep 2001 02:44:02
Message: <3b99be32$1@news.povray.org>
I can reacreate the bug.
don't use sturm, but D = 1.58113883008418,
to get to the limit between visible and unvisible.

Athlon 1,4GHz, 512MB DDR RAM Win98

cukk


Post a reply to this message

From: QQ
Subject: Re: Additional (?) blob bug
Date: 8 Sep 2001 14:29:59
Message: <Xns9116937F683B1CQ@204.213.191.226>
"Thomas Lake" <tla### [at] homecom> wrote in news:3b99b42c@news.povray.org:

> I'm really not the one to answer but could it be because when you
> switch D to 2 not only does the sphere get bigger, but the camera moves
> back to 1500 units.

Doubling D doubles both the size of the blob component and the distance 
between the blob and the camera.  A object of radius R at distance D will 
appear to be the same radius as an object of radius R*2 at distance D*2.  
The image should look the same for any value of D.

Try it with a non-blob sphere if you don't believe me.


Post a reply to this message

From: Jérôme Grimbert
Subject: Re: Additional (?) blob bug
Date: 9 Sep 2001 11:01:44
Message: <3B9B830D.B377150D@free.fr>
KalleK wrote:
> 
> I can reacreate the bug.
> don't use sturm, but D = 1.58113883008418,
> to get to the limit between visible and unvisible.
> 
> Athlon 1,4GHz, 512MB DDR RAM Win98
> 
> cukk

Playing with the scene file and 3.1g (it happen here too!),
the bug can be push away when playing with the
SMALL_ENOUGH constant in polysolv.c 
(Going from xE-10 to xE-30 give the correct picture for D=2)

The reason seems to be that the root solver decide to reduce
the order of the equation (normaly 4) when the first
coefficient is small enough (when D > 1.58.., it try
to resolve an order 3 equation.). 
Preventing that behavior by bursting the value of SMALL_ENOUGH
is one way to resolve that bug. 
Another way could also be to normalise the computed coefficients
of the blob so that the size of the interval always be the
same order of magnitude, instead of using always a unit vector.
But It might be difficult to correctly perform that modification,
and it may impact the precision of the blob intersection.
(because, back from the root solver, it will be needed to transform
back the intersection in the original space).

I wonder if there is really a need for automatically reducing the order of the
equation,
excepted for speed on nearly trivial case ?


Post a reply to this message

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