Last February, Sam Benge introduced a very cool technique and some great images,
created by iterative mapping of images onto discs:

http://news.povray.org/povray.binaries.images/thread/%3C47bf6f44%40news.povray.org%3E/?ttop=275374&toff=100

He also provided the code:

http://news.povray.org/povray.binaries.scene-files/thread/%3C47bfbb8e%40news.povray.org%3E/

This technique can also be used to produce "normal" (Iterated Function System)
fractals, using the condensation set method (repeated shrinking, moving and
pasting), as opposed to the more familiar "chaos-game" bouncing dot method.

Just to make sure I was understanding what was going on, I rendered the same
fractal using Povray and Iterative Imaging (the first picture), and then using
the chaos-game approach, with Apophysis ( http://www.apophysis.org ).

Because the condensation set method involves repeated shrinking, round-off
errors quickly accumulate, unless you render the image very large.  I made this
one 3200 x 3200.  I've included a close-up of the actual size, also.

Since rendering this, I thought of a way to eliminate the "cut-off" where the
fractal goes off the edge of the box.  I now use planes, and just shrink and
map the pigments on the planes.  Also, when the fractal overlaps itself, you
need to choose which plane goes on top -- this leads to slightly different
images, even though the actual attractors are the same.

Post a reply to this message

Attachments:
Download 'spiral7_99.jpg' (127 KB)

Preview of image 'spiral7_99.jpg'

Here's the Apophysis picture

Post a reply to this message

Attachments:
Download 'spiral7_apophysis.jpg' (115 KB)

Preview of image 'spiral7_apophysis.jpg'

And here's a close-up of the POVRay image

Post a reply to this message

Attachments:
Download 'spiral7_99closeup.jpg' (120 KB)

Preview of image 'spiral7_99closeup.jpg'

Dave Matthews wrote:
> Last February, Sam Benge introduced a very cool technique and some great images,
> created by iterative mapping of images onto discs:
> 
> Since rendering this, I thought of a way to eliminate the "cut-off" where the
> fractal goes off the edge of the box.  I now use planes, and just shrink and
> map the pigments on the planes.  Also, when the fractal overlaps itself, you
> need to choose which plane goes on top -- this leads to slightly different
> images, even though the actual attractors are the same.

Cool image.

I'm not sure I understand your exact method, but I'm sure it helps. Why 
is the POV-Ray render hard-edged, while the Apophysis image looks soft? 
You could probably get a smoother result by fiddling with the pigment.

It would be nice to generate these images in POV without also generating 
a long sequence of animation frames. If there was a way to rename the 
output image in POV without using an external application to do so, I 
would be pretty happy about it :) Maybe I'll raise a question in p.a-u. 
I was actually thinking of this earlier, but found no solution in the 
documentation. I found no working solution short of calling an external 
program to rename the file, anyway. I don't know how to make C++ rename 
a file, so I'm sort of stuck.

Sam

Post a reply to this message

stbenge wrote:

> It would be nice to generate these images in POV without also generating 
> a long sequence of animation frames. If there was a way to rename the 
> output image in POV without using an external application to do so, 

I don't think there is - unless one of the supported output formats
were both ASCII based and comma-separated suitable for #fopen, but I
think even with PPM it would not work ;)

However, if the intention is to use the previous image as input
for the next render, it seems that the output image is not yet
destroyed during the SDL parse phase. At least the below test
scene worked for me (3.6.1, Windows). Save as "reuse.pov",
render once with FIRST = 1 then again with FIRST = 0:

#declare FIRST = 1;

camera
{
   location  <0.0, 1.0, -5.0>
   look_at   <0.0, 1.0,  0.0>
   angle 90
}

light_source {< -10,  10, -10> color rgb 1}

#if (FIRST)
   sphere {y,1 pigment {color rgb 1}}
#else
   plane {z,0 pigment {image_map {sys "reuse.bmp"}}}
#end

Post a reply to this message

Christian Froeschlin wrote:

> However, if the intention is to use the previous image as input
> for the next render, it seems that the output image is not yet
> destroyed during the SDL parse phase. At least the below test
> scene worked for me (3.6.1, Windows). Save as "reuse.pov",
> render once with FIRST = 1 then again with FIRST = 0:

Sure, it works once, but you have to manually render the scene again and 
again to see how it changes. I was hoping for a way to make the scene 
more automated.

Sam

Post a reply to this message

stbenge wrote:

> Sure, it works once, but you have to manually render the scene again and 
> again to see how it changes. I was hoping for a way to make the scene 
> more automated.

Hmm ... you can add the same file multiple times to the render queue ;)

Also, you wouldn't really need an "external application" to automate
this, simple command line scripting would suffice. Assuming Windows,
create the following two files (3 lines total):

render.bat

   pvengine -D /EXIT testreuse.pov Declare=FIRST=%1

testreuse.bat

   call render 1
   for /l %t in (1,1,10) do call render 0

and run testreuse.bat to render 11 iterations. Of course, you should
remove the #declare FIRST from the SDL, also, you actually no longer
need to reuse the same image because you can copy, rename and delete
files as you wish with this approach.

The reason for having two scripts files is really just that I
didn't find another way to get the loop call to block (rendering
sequentially instead of spawning 10 POV instances at once - which
incidentally also causes an exception in the core backend).

Post a reply to this message

stbenge <stb### [at] hotmailcom> wrote:
> Cool image.

Thanks.

> I'm not sure I understand your exact method, but I'm sure it helps. Why
> is the POV-Ray render hard-edged, while the Apophysis image looks soft?
> You could probably get a smoother result by fiddling with the pigment.

There are 2 reasons why the Apophysis image looks softer.  The first is that it
is made by tracking a bouncing dot around the plane, while the condensation
method is made by repeatedly projecting images onto the plane, so that you keep
seeing the edges of the (smaller and smaller) images.

The other reason is that Apophysis has a rendering option that lets you
oversample, and then it interpolates the results.


> It would be nice to generate these images in POV without also generating
> a long sequence of animation frames. If there was a way to rename the
> output image in POV without using an external application to do so, I
> would be pretty happy about it :) Maybe I'll raise a question in p.a-u.
> I was actually thinking of this earlier, but found no solution in the
> documentation. I found no working solution short of calling an external
> program to rename the file, anyway. I don't know how to make C++ rename
> a file, so I'm sort of stuck.
>
> Sam

I'm trying to follow Christian's suggestions, but they are a bit beyond me, so,
for now, I don't really mind going back and dumping a bunch of intermediate
images.  Also, sometimes the final frame isn't the best image, so it's nice to
look back up and see which one "works."

Here's the code, as I adapted it.  I'm working on fixing it up a bit more.
Also, by adding different backgrounds, and messing with the transparencies, you
can get some pretty neat effects -- I'll share a few and you can probably come
up with better ideas (you usually do!)

*****************

// Condensation IFS adapted from S. Benge
// final_frame will determine the number of iterations.
// Make sure that file_name, below, matches your name for the file!

global_settings{
 assumed_gamma 1.0
}

camera{
 orthographic
 right x*2 up y*2
 location <0, 0, -20>
}

#default{ finish{ambient 1 } }

#declare file_name = "CondIFS2";

#declare Number_Of_Transforms = 3;

#declare T_array = array[Number_Of_Transforms];

// The last transform in the array will be on the plane that is closest to
// the camera.

#declare T_array[0] = transform {scale <-0.5, 0.6, 1>
  translate <0.3, -0.1, -0.07> };

#declare T_array[1] = transform { scale <0.9, 0.9, 1>  rotate 30*z
   translate <.04, 0.13, -0.1> };

#declare T_array[2] = transform { scale <0.26, 0.26, 1>
   translate <-0.72, -0.72, -0.15>  };

#macro M2(T_,n_o_t_)

union {

#local J = 0;
#while (J < n_o_t_)

plane { -z, 0.05*(J+1)
      pigment { pigm
      transform { T_[J]} } }
#local J = J + 1;
#end }

#end

#macro scene_elements()

#declare FIN = function { pigment { image_map { png file_name once} } };

#declare pigm=
 pigment { function{FIN(x,y,z).gray} pigment_map { [0.0   color rgbt <0,0,0,1>]
 [0.01   color rgbt <0,0,0,1>]
 [0.01  image_map {png file_name once}    ] } scale 2 translate <-1, -1, 0>};

M2(T_array, Number_Of_Transforms)


#end


#declare fn = frame_number;

#if(fn>1)

 #if(fn<11)
  #declare file_name=concat(file_name,"0",str(fn-1,0,0),".png");
  #else
  #declare file_name=concat(file_name,str(fn-1,0,0),".png");
 #end

 scene_elements()


#else

  plane{z,1
  pigment {  rgb <0.5, 0.7, 0.9> } }

#end

Post a reply to this message

"Dave Matthews" <dav### [at] mnwestedu> wrote:

> Since rendering this, I thought of a way to eliminate the "cut-off" where the
> fractal goes off the edge of the box.  I now use planes, and just shrink and
> map the pigments on the planes.

Actually, the "solution" eliminates one "cut-off" error, the one that occurs
when the fractal goes off the edge of the box (the discs in Sam's method), but
there's no way that I know of to eliminate the other "cut-off" error, the one
that occurs when a piece of the fractal goes out of the camera's view, since
all that gets mapped back is what the camera sees.

Post a reply to this message

"Dave Matthews" <dav### [at] mnwestedu> wrote:
> Here's the code, as I adapted it.  I'm working on fixing it up a bit more.
> Also, by adding different backgrounds, and messing with the transparencies, you
> can get some pretty neat effects -- I'll share a few and you can probably come
> up with better ideas (you usually do!)
>
> *****************

One thing you can do, of course, is change the initial image from a boring blue
plane.

(This also helps show how the IFS is generated, I think.)

Post a reply to this message

Attachments:
Download 'condensationmona02.jpg' (178 KB)

Preview of image 'condensationmona02.jpg'