(in Windows)
I had done this kind of thing years ago, but lost the code; so I came up with
something very similar to Stephen's idea.

My particular video app outputs the .png frame sequence like this...
my_image0001
my_image0002
my_image0003
--etc.--

These are placed in a folder location that I added to POV-Ray's 'master
POVRAY.INI' file-- i.e., Library_Path= ... So I didn't need to add a C: ...
library path to the concat(...) string, as Stephen did. POV-Ray will
automatically locate the images.

#declare AA = array[20]; // for 20 images
#for(i,0,19) // because arrays start with 'location' zero
#declare AA[i] = concat("my_image",str(i+1,-4,0),".png");
#end

then...
box{0, <1,1,0> // a box can be made zero-thickness
pigment{image_map{png AA[frame_number - 1] once interpolate 2}}
finish{ambient 1 emission 0 diffuse 0}
scale <...whatever...>
     }

However, I don't see the need for the array (unless you have a specific reason
to use one.) During your 'new' animation render, the array will be filled with
all 20 images during each animation frame, which isn't very efficient. I would
instead use Stephen's approach, calling each .png image as needed, with no
array. My own particular set-up would be...

box{0, <1,1,0>
pigment{
image_map{png concat("my_image",str(frame_number,-4,0),".png")
once interpolate 2
         }
       }
     finish{ambient 1 emission 0 diffuse 0}
scale...
}

Post a reply to this message

On 02/12/2018 16:26, Kenneth wrote:
> I would
> instead use Stephen's approach, calling each .png image as needed, with no
> array. 

I did this sort of thing regularly but with animated meshes made in Poser.
Several winters ago. Tim Cook IIRC, made a TV where the image files were 
stored in a df3. The frames were selected by intersecting the df3 with a 
thin box. The result was monochromatic. But if you used jr's tga2df3 to 
create the df3 (actually 3 df3s one for each RGB channel.). Then you can 
have the image in colour, if you use 3 media in the material. *Not* that 
I am suggesting Phil uses that method. That would just be showing off. ;)


My own particular set-up would be...
> 
> box{0, <1,1,0>
> pigment{
> image_map{png concat("my_image",str(frame_number,-4,0),".png")

I'll just point out, again. That the BITMAP_TYPE should not be included 
in the concat function. When I tried that earlier, Pov threw a wobbly 
and complained that the first letter of the file path was an undeclared 
variable "C". Also #debug would not output the result of: 
image_map{concat("png  ","my_image",str(frame_number,-4,0),".png")
That made me feel that I was losing my marbles for a while.




-- 

Regards
     Stephen

Post a reply to this message

Am 02.12.2018 um 07:25 schrieb Phil:

>                          #declare thisfilename = magik_cube[X][Y][Z][F]
>                          paint_tile(thisfilename)
...
> File 'initialise_cube.mac' line 163: Parse Error: Cannot assign uninitialized
>   identifier.

It is good practice to end each and every `#declare` with a semicolon, 
even in cases where it is entirely optional.

The requirement for a semicolon at some variants of `#declare` is not 
arbitrary: It is required everywhere there is a possibility that the 
right-hand side expression might continue. If POV-Ray comes across a 
macro invocation in such a case, POV-Ray presumes that the macro 
invocation is still part of the right-hand side expression of the 
`#declare`, so `paint_tile(thisfilename)` will take the old value of 
`thisfilename`.


Totally unreleated: It is highly recommend to NOT use all-lowercase 
identifiers, as these may conflict with keywords in future versions.

Post a reply to this message

Stephen <mca### [at] aolcom> wrote:
> On 02/12/2018 16:26, Kenneth wrote:
> >
> > My own particular set-up would be...
> >
> > box{0, <1,1,0>
> > pigment{
> > image_map{png concat("my_image",str(frame_number,-4,0),".png")
>
> I'll just point out, again. That the BITMAP_TYPE should not be included
> in the concat function. When I tried that earlier, Pov threw a wobbly
> and complained that the first letter of the file path was an undeclared
> variable "C".

Yes-- BITMAP_TYPE being the *first* .png in the code line. I ran into the same
problem years ago, even without the use of a C: library path as in your example.
That 'png' is a keyword (or sort of like one), and I could never figure out a
way to get a string construction to 'create' a POV-Ray keyword. I assume it
can't be done-- but it would be an interesting feature to add in the future (if
possible!)  ;-)

> Also #debug would not output the result of:
> image_map{concat("png  ","my_image",str(frame_number,-4,0),".png")
> That made me feel that I was losing my marbles for a while.
>

This works for me...
#debug concat ("\n","my_image",str(frame_number,-4,0),".png","\n")

I think the "\n" line feeds are necessary to even see the #debugged message;
there is an older post about how the absence of them causes the message pane to
ignore #debug...sometimes ;-) The details were somewhat complicated, IIRC.

When using the C: path method instead, I came across some info in the built-in
documentation at   3.3.1.9 Strings   about backslashes, that might be of
interest...
---
Windows users need to be especially wary about this as the backslash is also the
windows path separator. For example, the following code does not produce the
intended result:
#declare DisplayFont = "c:\windows\fonts\lucon.ttf"
  text { ttf DisplayFont "Hello", 2,0 translate y*1.50 }

New users might expect this to create a text object using the font
c:\windows\fonts\lucon.ttf. Instead, it will give an error message saying that
it cannot find the font file c:windowsontslucon.ttf.

The correct form of the above code is as follows:
#declare DisplayFont = "c:\\windows\\fonts\\lucon.ttf"
  text { ttf DisplayFont "Hello", 2,0 translate y*1.50 }

However, as POV-Ray for Windows also supports forward slashes as path separator,
it is recommended to use the following form: #declare DisplayFont =
"c:/windows/fonts/lucon.ttf"

Note: Up to (and including) version 3.7.0, contrary to the documentation (and on
all platforms) backslashes lost their special meaning where a file name is
expected, except when preceding a double quote. For backward compatibility, this
behaviour is still retained for scenes specifying a #version of 3.70 or lower,
but a warning will be issued.

---

The only remaining mystery for me is whether or not a line feed "\n" should use
a forward slash as well; I don't see that distinction in the docs.

Post a reply to this message

Tired, starting new job tomorrow, (yay)

But I thought I'd dig this up to see if it's any help:

http://news.povray.org/5ba3b5f9%241%40news.povray.org

The entire thread's a good read (for me, anyway)

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Tired, starting new job tomorrow, (yay)
>
> But I thought I'd dig this up to see if it's any help:
>
> http://news.povray.org/5ba3b5f9%241%40news.povray.org
>
> The entire thread's a good read (for me, anyway)

Good point! I should have remembered that piece of info. The BITMAP_TYPE isn't
even required, apparently.

Post a reply to this message

Am 03.12.2018 um 02:06 schrieb Kenneth:

> That 'png' is a keyword (or sort of like one), and I could never figure out a
> way to get a string construction to 'create' a POV-Ray keyword. I assume it
> can't be done-- but it would be an interesting feature to add in the future (if
> possible!)  ;-)

See `Parse_String` macro in `strings.inc`.

Post a reply to this message

On 03/12/2018 01:06, Kenneth wrote:
> Stephen <mca### [at] aolcom> wrote:
>> On 02/12/2018 16:26, Kenneth wrote:
>>>
>>> My own particular set-up would be...
>>>
>>> box{0, <1,1,0>
>>> pigment{
>>> image_map{png concat("my_image",str(frame_number,-4,0),".png")
>>
>> I'll just point out, again. That the BITMAP_TYPE should not be included
>> in the concat function. When I tried that earlier, Pov threw a wobbly
>> and complained that the first letter of the file path was an undeclared
>> variable "C".
> 
> Yes-- BITMAP_TYPE being the *first* .png in the code line. I ran into the same
> problem years ago, even without the use of a C: library path as in your example.
> That 'png' is a keyword (or sort of like one), and I could never figure out a
> way to get a string construction to 'create' a POV-Ray keyword. I assume it
> can't be done-- but it would be an interesting feature to add in the future (if
> possible!)  ;-)
> 
>> Also #debug would not output the result of:
>> image_map{concat("png  ","my_image",str(frame_number,-4,0),".png")
>> That made me feel that I was losing my marbles for a while.
>>
> 
> This works for me...
> #debug concat ("\n","my_image",str(frame_number,-4,0),".png","\n")
>

My problem was when I tried to include the *first* .png in the code 
line. Although when I used #warning. The message was displayed. Then the 
render failed.

> I think the "\n" line feeds are necessary to even see the #debugged message;
> there is an older post about how the absence of them causes the message pane to
> ignore #debug...sometimes ;-) The details were somewhat complicated, IIRC.
> 
I've not noticed that. I have noticed that if you don't add new lines. 
The message can get lost in the message tab.
I try to keep things simple and generally add a newline before and after.

#debug "\n"
#debug concat ("my_image",str(frame_number,-4,0),".png")
#debug "\n"

> When using the C: path method instead, I came across some info in the built-in
> documentation at   3.3.1.9 Strings   about backslashes, that might be of
> interest...

Yes, a couple of years ago clipka explained that. And since my modelling 
program exports the SDL with single "\". So I manually have to add the 
double backslash.

> ---
> Windows users need to be especially wary about this as the backslash is also the
> windows path separator. For example, the following code does not produce the
> intended result:
> #declare DisplayFont = "c:\windows\fonts\lucon.ttf"
>    text { ttf DisplayFont "Hello", 2,0 translate y*1.50 }
> 
> New users might expect this to create a text object using the font
> c:\windows\fonts\lucon.ttf. Instead, it will give an error message saying that
> it cannot find the font file c:windowsontslucon.ttf.
> 
> The correct form of the above code is as follows:
> #declare DisplayFont = "c:\\windows\\fonts\\lucon.ttf"
>    text { ttf DisplayFont "Hello", 2,0 translate y*1.50 }
> 
> However, as POV-Ray for Windows also supports forward slashes as path separator,
> it is recommended to use the following form: #declare DisplayFont =
> "c:/windows/fonts/lucon.ttf"
> 

I remember clipka saying that.

> Note: Up to (and including) version 3.7.0, contrary to the documentation (and on
> all platforms) backslashes lost their special meaning where a file name is
> expected, except when preceding a double quote. For backward compatibility, this
> behaviour is still retained for scenes specifying a #version of 3.70 or lower,
> but a warning will be issued.
> 
I must admit that I have seen that warning. :)

> ---
> 
> The only remaining mystery for me is whether or not a line feed "\n" should use
> a forward slash as well; I don't see that distinction in the docs.
> 
> 
> 

Have you tried? ;)


-- 

Regards
     Stephen

Post a reply to this message

On 3-12-2018 2:06, Kenneth wrote:
> ---
> 
> The only remaining mystery for me is whether or not a line feed "\n" should use
> a forward slash as well; I don't see that distinction in the docs.
> 
> 

If I am correct, the / instead of \ has only been introduced in the case 
of folder boundaries, in particular to distinguish them from the other 
language uses, like \n.

-- 
Thomas

Post a reply to this message

Stephen <mca### [at] aolcom> wrote:
> On 03/12/2018 01:06, Kenneth wrote:
> >
> > The only remaining mystery for me is whether or not a line
> > feed "\n" should use a forward slash as well; I don't see that
> > distinction in the docs.
> >
>
> Have you tried? ;)
>

I just did!  :-P

#debug concat ("/n","my_image",str(frame_number,-4,0),".png","/n")

....and no debug message shows up. So I guess line feeds can't use the forward
slash after all. (I'm guessing that line feeds are 'different animals' than
library-path separators.)

Post a reply to this message