 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] nowhere no> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
