OK, this is weird...
This macro seems to exhibit a strange bug: when the random number seed is set to 1322
or 1342 (as far as I've discovered) the 3rd segment of the "worm" gets misaligned. The
misalignment grows with the total number of segments. I can't find any errors in my
code...
Could sb. try it out and tell me if I'm just being stupid or is this a genuine bug?

Thanx
Margus

//BEGIN SCENE

camera {orthographic
        location <0,10,2>
        up 10*.75*y
        right 10*x
        look_at z*2}
        
light_source {<20,60,-10> color 1}
#include "colors.inc"

//Generates random "Worm"
//LenStart      length of first segment
//LenEnd        length of last segment
//NumSegm       number of segments
//ExpL          segment length falloff (1-linear; 2-squared etc)
//RadStart      worm start radius
//RadEnd        worm end radius
//ExpW          worm radius falloff
//Random        randomness in X,Y and Z directions (vector expression)
//Seed          random number seed

#macro Interpolate(GC,GS,GE,PS,PE,EXP)
        (PS+(PE-PS)*pow((GC-GS)/(GE-GS),EXP))
#end
#declare PointStart = <0,0,0>;
#macro Worm(LenStart, LenEnd, NumSegm, ExpL, RadStart, RadEnd, ExpW, Random, Seed)
        #declare CurSegm = 0;
        #declare PointEnd = <0,0,LenStart>;
        #declare RadConst = RadStart;
        #declare RadAspect = RadEnd/RadStart;
        #declare LenAspect = LenEnd/LenStart;
        #declare MaxTwist = 90;
        #declare R1 = seed(Seed);
        union {
        #while (CurSegm < NumSegm)
                #declare
RadEnd=RadConst*Interpolate(CurSegm+1,0,NumSegm,1,RadAspect,ExpW);
                cone {PointStart, RadStart, PointEnd, RadEnd}
               #declare
PointNew=PointEnd+vrotate(LenStart*vnormalize(PointEnd-PointStart)*Interpolate(CurSegm+1,0,NumSegm,1,LenAspect,ExpL)*1.00001,<0+Random.x*(MaxTwist*rand(R1)-MaxTwist/2),0+Random.y*(MaxTwist*rand(R1)-MaxTwist/2),0+Random.z*(MaxTwist*rand(R1)-MaxTwist/2)>);
                #declare PointStart=PointEnd;
                #declare PointEnd=PointNew;
                #declare RadStart=RadEnd;
                #declare CurSegm=CurSegm+1;
        #end}
#end

object {Worm(.3,0,50,2,.3,0,2,<0,.1,0>,1342) pigment{Red} finish{ambient .3}}

Post a reply to this message

Hi Margus,

    You're right, something very strange is going on here. I think it is a
bug. Even more odd is this. I inserted the following:

#render concat( "PS: <",
 str( PointStart.x, 2, 4 ), ", ",
 str( PointStart.y, 2, 4 ), ", ",
 str( PointStart.z, 2, 4 ), ">  ",
 "   PE:",
 str( PointEnd.x, 2, 4 ), ", ",
 str( PointEnd.y, 2, 4 ), ", ",
 str( PointEnd.z, 2, 4 ), ">  CS:",
 str( CurSegm, 2, 0 ), "\n" )

just inside your #while loop. If you check the output none of the number in
the X axis are off as show up in the picture. It very much appears to me
that the data displayed by the output from above is correct but the render
is wrong.

I also tried in your cone statement changing it to:

   cone {
    PointStart * <2,1,1> + <0,0,0.05>,
    RadStart,
    PointEnd  * <2,1,1>,
    RadEnd
    pigment { rgb <CurSegm / 5, 1, 1> }
   }

This seperates the segments a bit more for visibility and also amplifys the
phenomena. The VERY interesting thing is that if your change the X
amplification to a number much about 2, say 4, then it entirely disapears.
At 2 it is more visible than at 1 but at 4 it is gone entirely.

Further, I tried change the end #declare to this:

   #declare PointStart = PointEnd + <0,0, 0.05>;

When I did the the phenomena went away again. I'd tell the POV team. I have
no idea what is causing the bug. It is very hard to pin down where is comes
from. I don't think it is related to rand or seed after all.

Good luck,


--Rainer



Margus Ramst wrote in message <364B73CD.942FCB99@peak.edu.ee>...
>OK, this is weird...
>This macro seems to exhibit a strange bug: when the random number seed is
set to 1322 or 1342 (as far as I've discovered) the 3rd segment of the
"worm" gets misaligned. The misalignment grows with the total number of
segments. I can't find any errors in my code...
>Could sb. try it out and tell me if I'm just being stupid or is this a
genuine bug?
>
>Thanx
>Margus

Post a reply to this message

Rainer Mager wrote:
>
> When I did the the phenomena went away again. I'd tell the POV team. I have
> no idea what is causing the bug. It is very hard to pin down where is comes
> from. I don't think it is related to rand or seed after all.

I'd recommend simplifying the example file, though.  There's a lot
of stuff there -- I suspect it could be chopped down 60% to something
simple which demonstrates the same problem.

I know that I like taking a stab at reported problems like this,
but I don't like wading through long, complex examples like yours.
I suspect the debugging team feels similarly.

Dan

-- 
http://www.flash.net/~djconnel/

Post a reply to this message

Margus Ramst wrote:
> 
> OK, this is weird...
> This macro seems to exhibit a strange bug: when the random number seed is set to
1322 or 1342 (as far as I've discovered) the 3rd segment of the "worm" gets
misaligned. The misalignment grows with the total number of segments. I can't find any
errors in my code...
> Could sb. try it out and tell me if I'm just being stupid or is this a genuine bug?
> 
[buggy scene snipped]

Yes, the problem certainly is strange, and no - there are no problems in
your code.  A little testing reveals that the problem is related to the
cones you are trying to render, and in particular a cone with similar
values to these:

   cone {<-0.020957, 0, 0>, 0.299520, <-0.021942, 0, 1>, 0.298920}

which can be reduced to:

   cone {<0, 0, 0>, 100, <4, 0, 1000>, 99}

Rendering this cone reveals a shift in the -x direction that should
definitely not be there.  Making the start and end radii equal (so that
POV-Ray converts the cone into a cylinder) removes the problem, but
otherwise the smaller the difference between the two values, the greater
the shift.  Also, increasing the offset of the start and end points
beyond a certain value will remove the problem (a factor of about 4/1000
in any direction seems to give the maximum shift).  The problem affects
POV-Ray 3.1a, 3.1, and 3.00e, so you can probably feel quite jusitified
in reporting it as a bug...

Post a reply to this message

Chris Colefax wrote:

> cone {<-0.020957, 0, 0>, 0.299520, <-0.021942, 0, 1>, 0.298920}
>
> which can be reduced to:
> 
>    cone {<0, 0, 0>, 100, <4, 0, 1000>, 99}


I wonder if this is a problem related to the W95 code's high value
of epsilon, similar to the sphere problem.  If so it should not show
up in the UNIX and Mac versions, bothe of which have lower values.

The W95 version has EPSILON of 1e-5, quite a high value.  Then
the code has a line of the form, in cones.c :

  {
    /* Solve intersections with a cone */

    a = D[X] * D[X] + D[Y] * D[Y] - D[Z] * D[Z];

    b = D[X] * P[X] + D[Y] * P[Y] - D[Z] * P[Z];

    c = P[X] * P[X] + P[Y] * P[Y] - P[Z] * P[Z];

    if (fabs(a) < EPSILON)
    {
      if (fabs(b) > EPSILON)
      {
        /* One intersection */


It isn't hard to see how this coule encounter problems with
differences in radius of 10^-3.

I strongly suspect this is another problem with the large epsilon value,
similar to the ellipsoid route problem already reported in 
news://news.povray.org/povray.bugreports .

Dan
-- 
http://www.flash.net/~djconnel/

Post a reply to this message

I already reported the problem in .bugreports, along with a few observations.
The problem persisted under DOS, so unless DOS also has a high epsilon value,
this is not the answer.

Margus

Dan Connelly wrote:
> 
> Chris Colefax wrote:
> 
> > cone {<-0.020957, 0, 0>, 0.299520, <-0.021942, 0, 1>, 0.298920}
> >
> > which can be reduced to:
> >
> >    cone {<0, 0, 0>, 100, <4, 0, 1000>, 99}
> 
> I wonder if this is a problem related to the W95 code's high value
> of epsilon, similar to the sphere problem.  If so it should not show
> up in the UNIX and Mac versions, bothe of which have lower values.
> 
> The W95 version has EPSILON of 1e-5, quite a high value.  Then
> the code has a line of the form, in cones.c :
> 
>   {
>     /* Solve intersections with a cone */
> 
>     a = D[X] * D[X] + D[Y] * D[Y] - D[Z] * D[Z];
> 
>     b = D[X] * P[X] + D[Y] * P[Y] - D[Z] * P[Z];
> 
>     c = P[X] * P[X] + P[Y] * P[Y] - P[Z] * P[Z];
> 
>     if (fabs(a) < EPSILON)
>     {
>       if (fabs(b) > EPSILON)
>       {
>         /* One intersection */
> 
> It isn't hard to see how this coule encounter problems with
> differences in radius of 10^-3.
> 
> I strongly suspect this is another problem with the large epsilon value,
> similar to the ellipsoid route problem already reported in
> news://news.povray.org/povray.bugreports .
> 
> Dan
> --
> http://www.flash.net/~djconnel/

Post a reply to this message

Margus Ramst wrote:
> 
> I already reported the problem in .bugreports, along with a few observations.
> The problem persisted under DOS, so unless DOS also has a high epsilon value,
> this is not the answer.

DOS has the same EPSILON as Win..

Dan

-- 
http://www.flash.net/~djconnel/

Post a reply to this message