Hi - some time ago i gathered some .pov files from various places (i.e. the
web) in order to benchmark povray, after upgrading to v3.6.1 one of the
files renders a different picture than previously.. The code (which i did
not write) along with a picture can be found here:
http://members.jcom.home.ne.jp/tom3d/pov43/ilpov43e.htm
the first heave (and others) give totally different results in 3.6.1 vs.
3.50c
(v3.50c renders a version similar to the picture on that page, while v3.6.1
does not)

Im quite sure I didnt optimize too much (sloppy math). I can reproduce the
(buggy) result by a standard compilated (./configure && make) version of
povray. I noticed there was a bug previously i smooth_triangle - so the
scene might rely on that bug - since the scene is marked v3.1.

As a side remark - things (several different scenes - previously mentioned)
seem to render slower in v3.6.1 (gcc and icc) compared to v3.50c. Not that
I really care - but i'd like to know if others experienced a drop in
performance.

And finally: am I the only one missing float support for df3 files?

Post a reply to this message

Jakob Hunsballe wrote:
> Hi - some time ago i gathered some .pov files from various places (i.e. the
> web) in order to benchmark povray, after upgrading to v3.6.1 one of the
> files renders a different picture than previously.

Go figure - it is a different version so changes are to be expected. 
There are various changes from 3.5 to 3.6 as well as from 3.6 to 3.6.1 
that can lead to quite significant differences.

> As a side remark - things (several different scenes - previously mentioned)
> seem to render slower in v3.6.1 (gcc and icc) compared to v3.50c. Not that
> I really care - but i'd like to know if others experienced a drop in
> performance.

It is surely possible to design a scene that renders slower in 3.6 than 
in 3.5 with the same render settings.  To draw broad conclusions from 
this like you did is not a good idea.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 23 Sep. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

Jakob Hunsballe <nomail@nomail> wrote:
> Hi - some time ago i gathered some .pov files from various places (i.e. the
> web) in order to benchmark povray, after upgrading to v3.6.1 one of the
> files renders a different picture than previously..

  Most probably caused by either the change in default noise generator or
the change in default normal accuracy (my guess is the latter when
looking at the scene file).
  Try adding a small 'accuracy' value to the normal block of the texture
to see what happens. If the problem is in the noise generator, you can
try "global_settings { noise_generator 1 }" at the beginning of the scene.

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

Wasn't it Jakob Hunsballe who wrote:
>Hi - some time ago i gathered some .pov files from various places (i.e. the
>web) in order to benchmark povray, after upgrading to v3.6.1 one of the
>files renders a different picture than previously.. The code (which i did
>not write) along with a picture can be found here:
>http://members.jcom.home.ne.jp/tom3d/pov43/ilpov43e.htm
>the first heave (and others) give totally different results in 3.6.1 vs.
>3.50c
>(v3.50c renders a version similar to the picture on that page, while v3.6.1
>does not)

I've had a look at the top scene on that page.

What's happening is that in 3.5 the "Wave" macro always returns the
calculated result, but in 3.6 the calculated values occasionally fail to
be returned from the macro.

The code of the macro is:

#macro Wave (Xo, Yo, Zo, To, Lo)
  #declare Yo = 40*sin(1.5*To/pi+pi*0.8+0.3*pi*Lo)/(0.3+0.1*To)*sin(0.2*
Lo+0.02*To);
  #declare Xo = 10*To+20*cos(1.5*To/pi+pi*1)/(0.3+0.1*To)-1*Yo;
  #declare Zo = 100*(Lo-2);
  #declare Lxz = sqrt(Xo*Xo*4+Zo*Zo);
  #declare Yo = Yo-Lxz*sin(asin(Lo/2/300));
#end

And it's called like this

#declare Cp = array[Tmax][Lmax][3]
#declare T = 0; #while (T<Tmax)
  #declare L = 0; #while (L<Lmax)
    #declare M = 0; #while (M<3)
      #declare Cp[T][L][M] = 0;
    #declare M = M+1; #end
    Wave (Cp[T][L][0], Cp[T][L][1], Cp[T][L][2], T+Ncase, L)
  #declare L = L+1; #end
#declare T = T+1; #end

The macro gets called 30000 times, and about 29965 of those times the
calculated values get returned into the Cp array, but on 35 of those
calls one of the calculated values doesn't get returned. The value in
the control point array is whatever the array was preloaded with (in
this case 0). So about 35 of the 30000 control points of the mesh are
incorrectly positioned, producing ugly spikes in the surface.

Changes to other parts of the scene (e.g. adding the debugging code that
I used to determine what was going on) cause the errors to appear at
different points of the surface.

I've so far failed to reproduce the effect in a minimal scene.


A dirty workround is to return the values from Wave() in simple
variables which are not reset between calls. When the macro fails to
return a calculated value, the variable retains the value calculated for
the previous point which is only slightly out of place and the resulting
errors in the surface are not noticeable.

    Wave (XX, YY, ZZ, T+Ncase, L)
    #declare Cp[T][L][0] = XX;
    #declare Cp[T][L][1] = YY;
    #declare Cp[T][L][2] = ZZ;

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

> The macro gets called 30000 times, and about 29965 of those times the
> calculated values get returned into the Cp array, but on 35 of those
> calls one of the calculated values doesn't get returned. The value in
> the control point array is whatever the array was preloaded with (in
> this case 0). So about 35 of the 30000 control points of the mesh are
> incorrectly positioned, producing ugly spikes in the surface.
>
> Changes to other parts of the scene (e.g. adding the debugging code that
> I used to determine what was going on) cause the errors to appear at
> different points of the surface.
>
> I've so far failed to reproduce the effect in a minimal scene.

Oh, wow. I've seen this exact same behavior recently in my POVCOMP WIP.
Passing variables by reference (and changing their values within the macro)
fails *very* occasionally for no apparent reason. Changing the code (even
just the number of tokens in code that's never actually executed) changes
the results. I was going to try to find the problem in the POV-Ray source,
but I'm not familiar enough with that part of the code to do it in a
reasonable amount of time. And as you said, it's incredibly difficult to
reproduce the effect on purpose, so I couldn't make a minimal scene to do a
bug report.

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

Wasn't it Slime who wrote:
>> The macro gets called 30000 times, and about 29965 of those times the
>> calculated values get returned into the Cp array, but on 35 of those
>> calls one of the calculated values doesn't get returned. The value in
>> the control point array is whatever the array was preloaded with (in
>> this case 0). So about 35 of the 30000 control points of the mesh are
>> incorrectly positioned, producing ugly spikes in the surface.
>>
>> Changes to other parts of the scene (e.g. adding the debugging code that
>> I used to determine what was going on) cause the errors to appear at
>> different points of the surface.
>>
>> I've so far failed to reproduce the effect in a minimal scene.
>
>Oh, wow. I've seen this exact same behavior recently in my POVCOMP WIP.
>Passing variables by reference (and changing their values within the macro)
>fails *very* occasionally for no apparent reason. Changing the code (even
>just the number of tokens in code that's never actually executed) changes
>the results. I was going to try to find the problem in the POV-Ray source,
>but I'm not familiar enough with that part of the code to do it in a
>reasonable amount of time. And as you said, it's incredibly difficult to
>reproduce the effect on purpose, so I couldn't make a minimal scene to do a
>bug report.

I've now produced a minimal scene. Under 3.5 the macro always returns
with X=1, but under 3.6 it returns with X=123 about one time in a
thousand.

POV 3.6.0.icl8.win32 under Windows 98SE on a Celeron II with 376Mb RAM.


#macro Wave (Xo)
  #declare Xo = 1;
#end

#declare N=0;
#while (N<10000)
  #declare X=123;
  Wave(X)
  #if (X != 1)
    #debug concat("N = ", str(N,0,0), " X = ",str(X,0,0),"\n")
  #end
  #declare N=N+1;
#end


-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

> I've now produced a minimal scene. Under 3.5 the macro always returns
> with X=1, but under 3.6 it returns with X=123 about one time in a
> thousand.

Nice. I didn't think such simple code would actually reproduce it.

The code produces the effect on my machine, running Windows XP, version
3.6.1.icl8.win32.

Anything else necessary to make this a complete bug report? =)

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

Mike Williams wrote:
> 
> #macro Wave (Xo)
>   #declare Xo = 1;
> #end
> 
> #declare N=0;
> #while (N<10000)
>   #declare X=123;
>   Wave(X)
>   #if (X != 1)
>     #debug concat("N = ", str(N,0,0), " X = ",str(X,0,0),"\n")
>   #end
>   #declare N=N+1;
> #end

Interesting.  I don't use this kind of construction when coding scenes 
so i never came across this problem (it works without trouble when 
passing array identifiers BTW).

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 23 Sep. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

Mike Williams <nos### [at] econymdemoncouk> wrote:
> #macro Wave (Xo)
>   #declare Xo = 1;
> #end
>
> #declare N=0;
> #while (N<10000)
>   #declare X=123;
>   Wave(X)
>   #if (X != 1)
>     #debug concat("N = ", str(N,0,0), " X = ",str(X,0,0),"n")
>   #end
>   #declare N=N+1;
> #end

Hmm same thing here (Linux v.3.6.1 athlon-xp) I get bug's at:
2462,3347,4232,5117,6002,6887,7772,8657,9542 exactly 885 apart - peridic
thing.

Post a reply to this message

In article <41a558b9$1@news.povray.org> , "Slime" <fak### [at] emailaddress> 
wrote:

> just the number of tokens

The cause is an interaction of Parse_RValue's Temp_Count with a turnaround
of token_count in Get_Token.  If you change the last declare in the given
example to "#declare N=N+1-1+1;" you will see that the first such
coincidence occurs at N=72 with a period of 290.  If you break in the reset
of token_count in Get_Token you can follow the cause.

    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