Hello,

the following code renders "Strange Attractors", its derived from Paul Bourkes
scc entry. Has anybody got an idea how to reduce memory usage or parsing
times on that?

Thank you,
Manuel Kasten




//------------------------------------------------------------------------
//Quality 0: Preview            ~2.5 min @ Athlon XP 1900+ 512 MB Ram
//+w1024 +h1024 +a0.0 +r5 +fn       Memory use: ~30MB

//Quality 1: Final              ~15 min @ Athlon XP 1900+ 512 MB Ram
//+w1024 +h1024 +a0.0 +r5 +fn     Memory use: ~400MB

//Quality 2: Bigfinal           ~35 min @ Athlon XP 1900+ 512 MB Ram
//+w5000 +h5000 +a0.0 +r5 +fn     Memory use: ~400MB

#declare quality=0;

#declare a=1.5;
#declare b=1.84;
#declare c=-2;
#declare d=-1.8;




camera { right x }
#declare x1=0;
#declare y1=0;
#declare nul=1000;
#if(quality=0)
  #declare i=100000;   //Preview
#else
  #declare i=2000000;  //Final
#end


#while(nul>0)
   #declare x1=sin(a*y1)-cos(b*x1);
   #declare y1=sin(c*x1)-cos(d*y1);
   #declare nul=nul-1;
#end


union {

   #while(i>0)
      #declare x2=sin(a*y1)-cos(b*x1);
      #declare y2=sin(c*x1)-cos(d*y1);
      #if(quality=0)
         sphere{<x2,y2,4.3>, 0.002}     //Preview
      #else if(quality=1)
         sphere{<x2,y2,4.3>, 0.001}     //Final
      #else if(quality=2)
         sphere{<x2,y2,4.3>, 0.0005}    //Bigfinal
      #end
      #declare x1 = x2 ;
      #declare y1 = y2 ;
      #declare i  = i-1;
   #end

pigment { rgb 1 }
finish { ambient 1 }

}

Post a reply to this message

Whoops, should have mentioned that times and memory usage is with POV 3.6b1
under WinXP.

With POV 3.5 memory usage is a bit higher, but parsing times are lower.
(at least for "preview", I haven't tested the other two with POV 3.5)


Manuel Kasten

Post a reply to this message

Wasn't it Manuel Kasten who wrote:
>Whoops, should have mentioned that times and memory usage is with POV 3.6b1
>under WinXP.
>
>With POV 3.5 memory usage is a bit higher, but parsing times are lower.
>(at least for "preview", I haven't tested the other two with POV 3.5)

Look like the syntax of "#else if" has changed in 3.6.
3.5 doesn't like that space.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

> Look like the syntax of "#else if" has changed in 3.6.
> 3.5 doesn't like that space.

No, that's my fault. I changed the code just before posting
and didn't test the higher quality settings...

Now THAT'S right:

      #if(quality=0)
         sphere{<x2,y2,4.3>, 0.002}     //Preview
      #else
         #if(quality=1)
            sphere{<x2,y2,4.3>, 0.001}     //Final
         #else
            #if(quality=2)
               sphere{<x2,y2,4.3>, 0.0005}    //Bigfinal
            #end
         #end
      #end

Post a reply to this message

Manuel Kasten wrote:
> Whoops, should have mentioned that times and memory usage is with POV 3.6b1
> under WinXP.
> 
> With POV 3.5 memory usage is a bit higher, but parsing times are lower.
> (at least for "preview", I haven't tested the other two with POV 3.5)
> 
> 
> Manuel Kasten
> 
> 

My system is a Athlon XP 2400+ with a gigabyte of memory
Using POVRay 3.5 under linux my render times were
Quality 0 - 52 seconds (thats 19 seconds to parse 33 seconds to trace)
Quality 1 - 629 seconds (420 seconds to parse 209 seconds to trace)

Memory use was higher as you noted for POVRay 3.5
Quality 0 - about 32 MBytes
Quality 1 - about 500 MBytes

I don't understand why my render times were that much lower than yours. 
  It shouldn't have been over twice as fast even when allowing for 
POVRay being CPU bound and counting the 20% speed difference directly (I 
usually use sqrt(CPU speed) as a rule of thumb).  I wouldn't think 
Windows XP versus Linux would be that big a difference either (I would 
have guessed no more than 10%).  When you said parsing times were lower 
in POVRay 3.5, how much lower were they.

I suspect the memory usage may be due to the space used in the internal 
data representation used by POVRay.  For the quality 1 case, you are 
representing 2 million spheres so if it takes over a hundred bytes per 
object to store a sphere internally in POVRay, thats where your memory went.

Richard Kline

Post a reply to this message

> My system is a Athlon XP 2400+ with a gigabyte of memory
> Using POVRay 3.5 under linux my render times were
> Quality 0 - 52 seconds (thats 19 seconds to parse 33 seconds to trace)
> Quality 1 - 629 seconds (420 seconds to parse 209 seconds to trace)
>
> Memory use was higher as you noted for POVRay 3.5
> Quality 0 - about 32 MBytes
> Quality 1 - about 500 MBytes
(...)
> When you said parsing times were lower
> in POVRay 3.5, how much lower were they.


Ok, my system was freaked up. After a reboot I got following times and Memory uses:
Quality 0:
POV 3.6   63 sec ( 23 sec parse / 40 sec render )  27.5 MB
POV 3.5   51 sec ( 12 sec parse / 39 sec render )  31.0 MB

I can't test Quality 1 because of heavy swapping it will take hours to complete.
The 500 MB are right. My 400 MB were from an previous attractor. I thought
2.000.000 spheres are 2.000.000 spheres, but I was wrong.


> I suspect the memory usage may be due to the space used in the internal
> data representation used by POVRay.  For the quality 1 case, you are
> representing 2 million spheres so if it takes over a hundred bytes per
> object to store a sphere internally in POVRay, thats where your memory went.


I have rendered different attractors with 2.000.000 spheres and the memory
usage is not equal each time...


Manuel Kasten

Post a reply to this message

Manuel Kasten wrote:
> Hello,
>
> the following code renders "Strange Attractors", its derived from
> Paul Bourkes scc entry. Has anybody got an idea how to reduce memory
> usage or parsing times on that?

Try to render the following as an animation with between 10 and 99
frames, depending on how much you want to reduce the memory use (more
frames = less memory). The catch is that the render time is longer,
since there are more frames. Parsing time does not increase with the
number of frames though.

//----------------------------------------------------------------------
--
//Quality 0: Preview            ~2.5 min @ Athlon XP 1900+ 512 MB Ram
//+w1024 +h1024 +a0.0 +r5 +fn +kff20      Memory use: ~30MB

//Quality 1: Final              ~15 min @ Athlon XP 1900+ 512 MB Ram
//+w1024 +h1024 +a0.0 +r5 +fn +kff20     Memory use: ~400MB

//Quality 2: Bigfinal           ~35 min @ Athlon XP 1900+ 512 MB Ram
//+w5000 +h5000 +a0.0 +r5 +fn +kff20     Memory use: ~400MB


#declare quality=1;

#declare a=1.5;
#declare b=1.84;
#declare c=-2;
#declare d=-1.8;

camera { right x }

#if(quality=0)
  #declare i=100000/final_frame;   //Preview
#else
  #declare i=2000000/final_frame;  //Final
#end

#if (frame_number=1)
   #declare x1=0;
   #declare y1=0;
   #declare nul=1000;
   #while(nul>0)
      #declare x1=sin(a*y1)-cos(b*x1);
      #declare y1=sin(c*x1)-cos(d*y1);
      #declare nul=nul-1;
   #end
#else
   #include "attractor.data"
   plane {
      -z, -1
      pigment {
         image_map {
            png concat("attractors",str(frame_number-1,-2,0),".png")
         }
         translate -0.5
      }
      finish {ambient 1 diffuse 0}
      scale 10
   }
#end

union {
   #if(quality=0)
      #declare R = 0.002;     //Preview
   #end #if(quality=1)
      #declare R = 0.001;     //Final
   #end #if(quality=2)
      #declare R = 0.0005;    //Bigfinal
   #end
   #while(i>0)
      #declare x2=sin(a*y1)-cos(b*x1);
      #declare y2=sin(c*x1)-cos(d*y1);
      sphere{
         <x2,y2,4.3>, R
         pigment {rgb 1}
         finish {ambient 1}
      }
      #declare x1 = x2 ;
      #declare y1 = y2 ;
      #declare i  = i-1;
   #end
}

#fopen data concat("attractor.data") write
#write (data,"#declare x1 = ",x1,";")
#write (data,"#declare y1 = ",y1,";")
#fclose data

Post a reply to this message

Hmm, actually, if you use my approach you might want to use tga images
instead of png, since POV-Ray does some odd gamma-correction to png
image_maps making them darker than they should be.

Also, the applied antialiasing in each iteration may blur the final
result slightly, though very little I think. However, if it's a problem,
you can always render the whole thing without antialiasing in a higher
resolution and then just scale the whole thing down afterwards.

Rune
--
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com **updated Mar 9**
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

Image in povray.binaries.images...

Rune
--
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com **updated Mar 9**
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

"Richard Kline" <rkl### [at] earthlinknet> wrote in message
news:40537c14@news.povray.org...
> Manuel Kasten wrote:
> > Whoops, should have mentioned that times and memory usage is with POV
3.6b1
> > under WinXP.
> >
> > With POV 3.5 memory usage is a bit higher, but parsing times are lower.
> > (at least for "preview", I haven't tested the other two with POV 3.5)
> >
> >
> > Manuel Kasten
> >
> >
>
> My system is a Athlon XP 2400+ with a gigabyte of memory
> Using POVRay 3.5 under linux my render times were
> Quality 0 - 52 seconds (thats 19 seconds to parse 33 seconds to trace)
> Quality 1 - 629 seconds (420 seconds to parse 209 seconds to trace)
>
> Memory use was higher as you noted for POVRay 3.5
> Quality 0 - about 32 MBytes
> Quality 1 - about 500 MBytes
>
> I don't understand why my render times were that much lower than yours.
>   It shouldn't have been over twice as fast even when allowing for
> POVRay being CPU bound and counting the 20% speed difference directly (I
> usually use sqrt(CPU speed) as a rule of thumb).  I wouldn't think
> Windows XP versus Linux would be that big a difference either (I would
> have guessed no more than 10%).  When you said parsing times were lower
> in POVRay 3.5, how much lower were they.
>
> I suspect the memory usage may be due to the space used in the internal
> data representation used by POVRay.  For the quality 1 case, you are
> representing 2 million spheres so if it takes over a hundred bytes per
> object to store a sphere internally in POVRay, thats where your memory
went.
>
> Richard Kline
>
>

Unfamiliar with pov internals, but having heard something like meshes can be
copied without an increase in memory usage, would it ease memory consumption
to use a small mesh sphere instead of a sphere primitive?

just curious,
ross

Post a reply to this message