Just came from visualizing the strength of the magneric field in 
a cylindrical cavity when I wanted to do the final rendering 
without the no_shadow keywoard. (I am using it for speed's sake 
when testing). 

However, it turned out that the complete object gets black in that 
case. Is this a bug or a self-shadowing problem? 
What can I do against that?

(Quality setting was +Q9, of course...)

Wolfgang

Image (with no_shadow keywoard): 
http://www.cip.physik.uni-muenchen.de/~wwieser/cavity3.png

Code:
#include "functions.inc"

global_settings { assumed_gamma 2.2 }

light_source { <0,1,0>*20, rgb <2,2,2>/2 }
light_source { <0.2,1,-0.8>*20, rgb <2,2,2>/1.7 }

#declare f_besselJ = function { internal(81) }
#declare f_besselJD = function { internal(82) }
#declare f_CAVITY = function { internal(83) }

#declare m=3;
#declare param_obj = 
parametric {
        function { u*sin(v) }
        //function { 25*sqrt(pow(sin(m*v)*f_besselJ(u,0,0,m),2)+
        //      pow(cos(m*v)*m/u*f_besselJD(u,0,0,m),2)) }
        function { 25*f_CAVITY(u,v,0,m) }
        function { u*cos(v) }
        <0.00000001,0>, <15,2*pi>
        contained_by {  sphere { 0, 15 }  }
        precompute 16 x,y,z
        //no_shadow
        scale 0.2
}

object {
        param_obj
        texture { pigment { color rgb <0,1,0> } }
        rotate -20*y rotate -20*x scale 1.4 translate -0.2*y
}
plane { y,-3.2  pigment { rgb .6 } }
camera {  location <0,0.3,-1>*8.3 up y  look_at <0,0,0> }

Post a reply to this message

Wolfgang Wieser <wwi### [at] gmxde> wrote:
> #declare f_besselJ = function { internal(81) }
> #declare f_besselJD = function { internal(82) }
> #declare f_CAVITY = function { internal(83) }

  You should really use functions by their official names. The internal()
ID numbers are reserved and should not be used (because they can change
at any time with a new version, without any notice, and can break old
scenes).
  I tried this scene with POV-Ray 3.5 and it says

Parse Error: Function 'internal(81)' does not exist.

  Are you using some kind of patched version?

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Warp wrote:

> Wolfgang Wieser <wwi### [at] gmxde> wrote:
>> #declare f_besselJ = function { internal(81) }
>> #declare f_besselJD = function { internal(82) }
>> #declare f_CAVITY = function { internal(83) }
> 
>   You should really use functions by their official names. The internal()
> ID numbers are reserved and should not be used (because they can change
> at any time with a new version, without any notice, and can break old
> scenes).
>
The reason is just the same as the reason for the error below: 

>   I tried this scene with POV-Ray 3.5 and it says
> 
> Parse Error: Function 'internal(81)' does not exist.
> 
>   Are you using some kind of patched version?
> 
Correct. Because POVRay official version does not know the 
Bessel J function -- and if you saw that function, you know why I have 
to code it in C directly into POV source code...

Cheers,
Wolfgang

----------<fnintern.cpp>---------------
// Include GNU scientific library (GSL): 
#include "/usr/local/numerics/include/gsl/gsl_sf_bessel.h"

inline DBL _f_besselJ(DBL x,int m)
{
        return(gsl_sf_bessel_Jn(m,x));
}
inline DBL _f_besselJD(DBL x,int m)
{
        double eps=0.00001;
        double vA=gsl_sf_bessel_Jn(m,x-eps);
        double vB=gsl_sf_bessel_Jn(m,x+eps);
        return((vB-vA)/(2.0*eps));
}

DBL f_besselJ(DBL *ptr, unsigned int fn) // 81
{
        return(_f_besselJ(PARAM_X,int(PARAM(0)+0.5)));
}

DBL f_besselJD(DBL *ptr, unsigned int fn) // 81
{
        return(_f_besselJD(PARAM_X,int(PARAM(0)+0.5)));
}

DBL f_CAVITY(DBL *ptr, unsigned int fn) // 82
{
        int m=int(PARAM(0)+0.5);
        double tmpA=sin(m*PARAM_Y)*_f_besselJ(PARAM_X,m);
        double tmpB=cos(m*PARAM_Y)*m/PARAM_X*_f_besselJD(PARAM_X,m);
        return(hypot(tmpA,tmpB));
}
----------------------------------------

Post a reply to this message

Wolfgang Wieser <wwi### [at] gmxde> wrote:
> Correct. Because POVRay official version does not know the 
> Bessel J function -- and if you saw that function, you know why I have 
> to code it in C directly into POV source code...

  It's difficult to test your scene if it doesn't work in the official
version... :)

-- 
#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

Warp wrote:
>   It's difficult to test your scene if it doesn't work in the official
> version... :)
> 
Okay, so here is a version which can be rendered on official version. 
I replaced the Bessel functions with sin(): 

The problem is still there -- please have a look at it. 
Try using better accuracy and you may SIGSEGV POVRay...

Wolfgang

-----------------------------------------------------------
#include "functions.inc"

global_settings { assumed_gamma 2.2 }
light_source { <0,1,0>*20, rgb <2,2,2>/2 }
light_source { <0.2,1,-0.8>*20, rgb <2,2,2>/1.7 }

#declare m=3;
parametric {
        function { u*sin(v) }
        function { 15*sqrt(pow(sin(m*v)*sin(u/2)/3,2)+
                pow(cos(m*v)*m/u*sin(u/2)/3,2)) }
        function { u*cos(v) }
        <0.001,0>, <15,2*pi>
        contained_by {  sphere { 0, 15 }  }
        precompute 12 x,y,z
        accuracy 0.000001
        no_shadow  // <----------------- REMOVE THIS LINE
        scale 0.2
        pigment { color rgb <0,1,0> }
        rotate -20*y
        rotate -20*x
        scale 1.4
        translate -0.2*y
}

plane { y,-3.2 pigment { rgb .6 } }
camera {  location <0,0.3,-1>*8.3 up y  look_at <0,0,0> }

Post a reply to this message

Wolfgang Wieser wrote:

> Warp wrote:
>>   It's difficult to test your scene if it doesn't work in the official
>> version... :)
>> 
> Okay, so here is a version which can be rendered on official version.
> I replaced the Bessel functions with sin():
> 
> The problem is still there -- please have a look at it.
> Try using better accuracy and you may SIGSEGV POVRay...
> 
> ...
> accuracy 0.000001
> ...
>
Pardon, this accuracy is already too "good". To see the 
problem with the shape getting black, leave away "accuracy" and 
"no_shadow". 

Wolfgang

Post a reply to this message

Wolfgang Wieser <wwi### [at] gmxde> wrote:
> Try using better accuracy and you may SIGSEGV POVRay...

  This may be worth posting a bug report, as it happens to me as well.

  As for the problem, I don't really know what's going on, sorry.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

in news:3ef09caa@news.povray.org Wolfgang Wieser wrote:

> What can I do against that?
> 

It will not solve the parametric object problem, but may get you a working 
scene; param.inc at http://members.home.nl/seedseven/

Ingo

Post a reply to this message

Warp wrote:
> Wolfgang Wieser <wwi### [at] gmxde> wrote:
>> Try using better accuracy and you may SIGSEGV POVRay...
> 
>   This may be worth posting a bug report, as it happens to me as well.
> 
Yes...
As you can read on povray.programming, I also found out the cause 
of the bug last night. But I don't know the apropriate fix. 

>   As for the problem, I don't really know what's going on, sorry.
> 
Damn. Seems somehow, every point on the surface is considered 
to be in heavy shadow?

Wolfgang

Post a reply to this message

In article <3ef483f2@news.povray.org>, Wolfgang Wieser <wwi### [at] gmxde> 
wrote:

> >   As for the problem, I don't really know what's going on, sorry.
> > 
> Damn. Seems somehow, every point on the surface is considered 
> to be in heavy shadow?

Or the normal calculations are getting screwed up. I was getting this 
for a while with a patch I'm currently working on...zero length normal 
vectors don't normalize well.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message