POV-Ray : Newsgroups : povray.beta-test : bug in sphere_sweep for removing parts of an object Server Time
18 Apr 2024 14:00:10 EDT (-0400)
  bug in sphere_sweep for removing parts of an object (Message 1 to 6 of 6)  
From: Andrel C  Linnenbank
Subject: bug in sphere_sweep for removing parts of an object
Date: 14 Dec 2001 15:09:24
Message: <3C1A5D47.EA38F6E5@amc.uva.nl>
I am not entirely sure if this has been reported before.
I used  povray v3.5b8 on a 750MHz PIII, windows 98

When using sphere_sweep to generate a hollow tube there are 
some problems in rendering the inside of the tube.

Strange bands of discontinuous normals seem to appear in areas where

the spheres make a bend.



Below is a 'small' example that shows the problem.



Second point is that I used a parameterization for the sizes

of the spheres that depended on the clock to generate an animation.

It was a rather complex formula. I now use a different method where 

I generate an different include file for every frame. The reason 

is that this seems to be much faster. Apparently the formula 

is computed for every pixel in stead of ones per frame. I

think some caching may improve the speed of rendering. 



	Andrel



----

#version 3.5;



#include "colors.inc"



global_settings {

  assumed_gamma 1.0

}



// ----------------------------------------



camera {

  location  <0.0, 0.5, -4.0>

  direction 1.5*z

  right     x*image_width/image_height

  look_at   <0.0, 0.0,  0.0>

}



sky_sphere {

  pigment {

    gradient y

    color_map {

      [0.0 rgb <0.6,0.7,1.0>]

      [0.7 rgb <0.0,0.1,0.8>]

    }

  }

}



light_source {

  <0, 0, 0>            // light's position (translated below)

  color rgb <1, 1, 1>  // light's color

  translate <-0, 5, -10>

}



// ----------------------------------------



plane {

  y, -1

  pigment { color rgb <0.3,0.7,0.3> }

}





intersection{

sphere_sweep {

 catmull_rom_spline

 11,

 <-0.785398,0.000000,0.000000>,0.684887,

 <-0.392699,0.000000,0.000000>,0.747715,

 <0.000000,0.000000,0.000000>,0.779126,

 <0.342020,0.060307,0.000000>,0.792240,

 <0.642788,0.233956,0.000000>,0.797142,

 <0.866025,0.500000,0.000000>,0.798889,

 <0.984808,0.826352,0.000000>,0.799517,

 <0.984808,1.173648,0.000000>,0.799752,

 <0.866025,1.500000,0.000000>,0.799843,

 <0.642788,1.766044,0.000000>,0.799875,

 <0.342020,1.939693,0.000000>,0.799871

}// end sphere_sweep

sphere_sweep {

 catmull_rom_spline

 11,

 <-0.785398,0.000000,0.000000>,0.479132,

 <-0.392699,0.000000,0.000000>,0.545101,

 <0.000000,0.000000,0.000000>,0.578083,

 <0.342020,0.060307,0.000000>,0.591852,

 <0.642788,0.233956,0.000000>,0.596999,

 <0.866025,0.500000,0.000000>,0.598833,

 <0.984808,0.826352,0.000000>,0.599492,

 <0.984808,1.173648,0.000000>,0.599739,

 <0.866025,1.500000,0.000000>,0.599835,

 <0.642788,1.766044,0.000000>,0.599868,

 <0.342020,1.939693,0.000000>,0.599865



inverse }// end sphere_sweep

box{<-3.141593,-1,-.15><2,3,1>}

bounded_by{box{<-3.141593,-1,-.15><2.284808,3.3,1>}}

  translate x*2.5+y*-3+z*-3

  scale .5           

  rotate x*45+y*40

  pigment { color rgb <1,0.2,0.0> } 

  finish{specular .3} 

}// end difference


Post a reply to this message

From: Mike Williams
Subject: Re: bug in sphere_sweep for removing parts of an object
Date: 15 Dec 2001 02:37:00
Message: <sQycrBAaQrG8EwNH@econym.demon.co.uk>
Wasn't it Andrel C. Linnenbank who wrote:
>I am not entirely sure if this has been reported before.
>I used  povray v3.5b8 on a 750MHz PIII, windows 98
>
>When using sphere_sweep to generate a hollow tube there are 
>some problems in rendering the inside of the tube.
>
>Strange bands of discontinuous normals seem to appear in areas where
>the spheres make a bend.

I confirm this. The effect seems to happen with any inverse
sphere_sweep, or any difference {something, sphere_sweep}. The normals
in the inverse sphere_sweep are not the inverse of the normals of the
sphere_sweep.

>Second point is that I used a parameterization for the sizes
>of the spheres that depended on the clock to generate an animation.
>It was a rather complex formula. I now use a different method where 
>I generate an different include file for every frame. The reason 
>is that this seems to be much faster. Apparently the formula 
>is computed for every pixel in stead of ones per frame. I
>think some caching may improve the speed of rendering. 

I can't reproduce that with simple formulae that use the clock.
You're not using functions by any chance are you?

-- 
Mike Williams
Gentleman of Leisure


Post a reply to this message

From: Thorsten Froehlich
Subject: Re: bug in sphere_sweep for removing parts of an object
Date: 15 Dec 2001 05:24:49
Message: <3c1b24f1@news.povray.org>
In article <sQy### [at] econymdemoncouk> , Mike Williams 
<mik### [at] nospamplease>  wrote:

> I confirm this. The effect seems to happen with any inverse
> sphere_sweep, or any difference {something, sphere_sweep}. The normals
> in the inverse sphere_sweep are not the inverse of the normals of the
> sphere_sweep.

This suggests the normals are not inverted (at all?) because a difference is
simply an intersection with the inverted object and thus the cause of both
problems is identical.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org


Post a reply to this message

From: Andrel C  Linnenbank
Subject: Re: bug in sphere_sweep for removing parts of an object
Date: 15 Dec 2001 08:25:29
Message: <3C1B5008.7EBEAEDA@amc.uva.nl>
> 
> >Second point is that I used a parameterization for the sizes
> >of the spheres that depended on the clock to generate an animation.
> >It was a rather complex formula. I now use a different method where
> >I generate an different include file for every frame. The reason
> >is that this seems to be much faster. Apparently the formula
> >is computed for every pixel in stead of ones per frame. I
> >think some caching may improve the speed of rendering.
> 
> I can't reproduce that with simple formulae that use the clock.
> You're not using functions by any chance are you?

I meant that I used things like 

sphere_sweep {
 catmull_rom_spline
 11,
 <-0.785398,0.000000,0.000000>,1-(exp(-(2-sin((clock)*2*pi))*4)*25),
.
.
.

(or worse) does that count as using functions?


	Andrel


Post a reply to this message

From: Mike Williams
Subject: Re: bug in sphere_sweep for removing parts of an object
Date: 15 Dec 2001 09:15:31
Message: <WeTy4NAfp1G8EwLx@econym.demon.co.uk>
Wasn't it Andrel C. Linnenbank who wrote:
>> 
>> >Second point is that I used a parameterization for the sizes
>> >of the spheres that depended on the clock to generate an animation.
>> >It was a rather complex formula. I now use a different method where
>> >I generate an different include file for every frame. The reason
>> >is that this seems to be much faster. Apparently the formula
>> >is computed for every pixel in stead of ones per frame. I
>> >think some caching may improve the speed of rendering.
>> 
>> I can't reproduce that with simple formulae that use the clock.
>> You're not using functions by any chance are you?
>
>I meant that I used things like 
>
>sphere_sweep {
> catmull_rom_spline
> 11,
> <-0.785398,0.000000,0.000000>,1-(exp(-(2-sin((clock)*2*pi))*4)*25),
>.
>.
>.
>
>(or worse) does that count as using functions?

No. All that stuff gets evaluated at parse time. It doesn't affect the
speed of the rendering. 

The various frames take different amounts of time to render, but only
because the object varies in size. In particular, on my machine, the
time to render a frame with clock=0 containing lots of things like
  <-0.785398,0.000000,0.000000>,1-(exp(-(2-sin((clock)*2*pi))*4)*25),

renders in exactly the same time as one containing things like 
  <-0.785398,0.000000,0>,0.991613,

-- 
Mike Williams
Gentleman of Leisure


Post a reply to this message

From: Andrel C  Linnenbank
Subject: Re: bug in sphere_sweep for removing parts of an object
Date: 15 Dec 2001 10:10:14
Message: <3C1B68A9.6743B7FF@amc.uva.nl>
Mike Williams wrote:
> 
> Wasn't it Andrel C. Linnenbank who wrote:
> >>
> >> >Second point is that I used a parameterization for the sizes
> >> >of the spheres that depended on the clock to generate an animation.
> >> >It was a rather complex formula. I now use a different method where
> >> >I generate an different include file for every frame. The reason
> >> >is that this seems to be much faster. Apparently the formula
> >> >is computed for every pixel in stead of ones per frame. I
> >> >think some caching may improve the speed of rendering.
> >>
> >> I can't reproduce that with simple formulae that use the clock.
> >> You're not using functions by any chance are you?
> >
> >I meant that I used things like
> >
> >sphere_sweep {
> > catmull_rom_spline
> > 11,
> > <-0.785398,0.000000,0.000000>,1-(exp(-(2-sin((clock)*2*pi))*4)*25),
> >.
> >.
> >.
> >
> >(or worse) does that count as using functions?
> 
> No. All that stuff gets evaluated at parse time. It doesn't affect the
> speed of the rendering.
I would expect so.

> The various frames take different amounts of time to render, but only
> because the object varies in size. In particular, on my machine, the
> time to render a frame with clock=0 containing lots of things like
>   <-0.785398,0.000000,0.000000>,1-(exp(-(2-sin((clock)*2*pi))*4)*25),
> 
> renders in exactly the same time as one containing things like
>   <-0.785398,0.000000,0>,0.991613,
> 
mmm, I will try to recreate what I did. Consider this solved (category:
not a bug after all) I will repost if I can recreate the problem and 
have some measurements. Thanks for looking into it.

	Andrel


Post a reply to this message

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