Hi,

I'm having a go at embedding video in my animations by splitting video files up
into .png's and then calling them using image_map command with an array
identifier that stores the file names for the images.

Here is some of the code:

box { <0.00, 0.00, 0.00>,< 1.00, 1.00, 1.000>
       texture {
                pigment{
                        #declare thisfilename = magik_cube[X][Y][Z][F]
                        paint_tile(thisfilename)
                        }
               } // end of texture
       scale <0.9 0.9,0.001> rotate<0,0,0> translate <-0.45,-0.45,-0.501> rotate
x*0
      } // end of box --------------------------------------
   #end

.... but I keep getting the following error:

File 'initialise_cube.mac' line 163: Parse Error: Cannot assign uninitialized
 identifier.
Fatal error in parser: Cannot parse input.
Render failed

Can anyone give me a lead ??

This is my first post to the forum.

Thanking you in advance.

Phil.

Post a reply to this message

On 02/12/2018 06:25, Phil wrote:
> Hi,
> 
> I'm having a go at embedding video in my animations by splitting video files up
> into .png's and then calling them using image_map command with an array
> identifier that stores the file names for the images.
> 
> Here is some of the code:
> 
> box { <0.00, 0.00, 0.00>,< 1.00, 1.00, 1.000>
>         texture {
>                  pigment{
>                          #declare thisfilename = magik_cube[X][Y][Z][F]
>                          paint_tile(thisfilename)
>                          }
>                 } // end of texture
>         scale <0.9 0.9,0.001> rotate<0,0,0> translate <-0.45,-0.45,-0.501> rotate
> x*0
>        } // end of box --------------------------------------
>     #end
> 
> .... but I keep getting the following error:
> 
> File 'initialise_cube.mac' line 163: Parse Error: Cannot assign uninitialized
>   identifier.
> Fatal error in parser: Cannot parse input.
> Render failed
> 
> Can anyone give me a lead ??
> 
> This is my first post to the forum.
> 
> Thanking you in advance.
> 
> Phil.
> 
> 

Hi Phil and welcome

Is the bit of code close to line 163?
Did you declare paint_tile and the array magik_cube before the box code?
When Pov fails and highlights a line of code. It is not necessarily that 
line which is the problem.


-- 

Regards
     Stephen

Post a reply to this message

On 02/12/2018 07:12, Stephen wrote:
> box { <0.00, 0.00, 0.00>,< 1.00, 1.00, 1.000>
>          texture {
>                   pigment{
>                           #declare thisfilename =
magik_cube[X][Y][Z][F]
>                           paint_tile(thisfilename)
>                           }
>                  } // end of texture
>          scale <0.9 0.9,0.001> rotate<0,0,0> translate 
> <-0.45,-0.45,-0.501> rotate
> x*0
>         } // end of box --------------------------------------
>      #end

I have been thinking about this as I did something similar a while ago.

Not knowing what you have in magik_cube[X][Y][Z][F] or 
paint_tile(thisfilename). I did a test with a series of files 0001 ... 
0120 in the directory C:\tmp

This works using concat and frame_number.
Note that the BITMAP_TYPE should not be included in the concat function

#declare Non_Patterned_Texture =
texture {
   pigment {
     image_map{

         png  concat ("C:\\tmp\\", str(frame_number, -4, 0),  ".png")

       map_type 0
       once
     }
     translate <-0.500,-0.500,-0.500>
   }

   finish {
     ambient     rgb <0.100,0.100,0.100>*5.000
     brilliance  1.000
     crand       0.000
     diffuse     0.600
     metallic    0.000
     phong       0.000
     phong_size  40.000
     specular    0.000
     roughness   0.050
   }

}



-- 

Regards
     Stephen

Post a reply to this message

Hi Phil, as Stephen points out, one of the tricky bits of working with POV-Ray's
command-line SDL is that where the parser finally decides to throw an error is
not necessarily where the real problem lies.

But in this case, I think you've highlighted the bit of code that POV-Ray
correctly declares is the problem.

First, I think it would help if
#declare thisfilename = magik_cube[X][Y][Z][F]
were terminated by a semicolon
#declare thisfilename = magik_cube[X][Y][Z][F];

Second, and central to your problem, is that it looks as if you are trying to
get the filename to interpreted as a pigment using (what appears to be a macro
called) "paint_tile".

so, either you need to keep things simple and just use

pigment {image_map {png thisfilename}}
instead of
paint_tile(thisfilename)

or you need to check out your macro earlier in the scene (and this is where
Stephen's point may actually be the case) and see what your macro is doing.

I'm envisioning it to be this simple, although the above direct use of the
filename in a pigment statement _without_ a macro is simpler still.

#macro paint_tile(_FN)
pigment {image_map {png _FN}}
#end

You may also consider testing for the existence of the element
magik_cube[X][Y][Z][F], using #ifdef(magik_cube[X][Y][Z][F]), and sending a
debug message to the output stream so you can verify what POV-Ray has stored in
magik_cube[X][Y][Z][F] and is trying to use as a filename.

I'd be tempted to rewrite the box definition to avoid the sequence of scaling
and translation - simply because it's easier to debug, and I often find myself
catching would-be errors before I set them down in code.

All this code is straight off the top of my head, untested, and you're getting
it before I've even had my first coffee - so some of the finer elements of the
proper syntax may be wrong/missing.

Welcome!
Good luck.
I hope to see the progress of your project   :)

Bill

Post a reply to this message

(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

hi,

"Kenneth" <kdw### [at] gmailcom> wrote:
> 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.)

your "guess" is good.  see 3.3.2.7.2 "Text Formatting" for the list of "escape
sequences".  the path separator is just a "normal" character, albeit different
for each (it seems) os.


regards, jr.

Post a reply to this message

On 03/12/2018 12:03, Kenneth wrote:
> 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.)
> 
> 
> 
As Thomas and jr said. :)
But I think that you are showing your age calling them line feeds. o_O

I remember the time when you had to type CR+LF because if you typed 
LF+CR your Teletype 33 would not return the carriage to the beginning of 
the line before the machine would start printing the next character.

-- 

Regards
     Stephen

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> 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...
>
> See `Parse_String` macro in `strings.inc`.

Hey, that does work beautifully!

#include "Strings.inc"
image_map{
Parse_String("png") concat("my_image",str(frame_number - 1,-4,0),".png")

(although, I probably wouldn't use it in this *particular* context, as the
keyword   png   would simply be easier; but it's a great way to generate
keywords in general.) Thanks for the hint!

The macro is a nice one: It simply #writes the string to a file, then
immediately #includes that file back into the SDL code line.

But what baffles me at the moment is why it DOES work, when
     image_map{concat("png ","my_image",str(frame_number - 1,-4,0),".png")
does not-- since both constructions involve strings, in what *appears* to be a
similar way.

SO... I'm thinking that the  concat  keyword is the problem-- not specifically
concat, but that the initial image_map{  expression expects the BITMAP_TYPE to
be the first thing it sees, not some other 'thing'.  Not even  str("png")

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:

> But what baffles me at the moment is why it DOES work, when
>      image_map{concat("png ","my_image",str(frame_number - 1,-4,0),".png")
> does not-- since both constructions involve strings, in what *appears* to be a
> similar way.

When you do it the cancat way - POV-Ray sees it as a string.
When you do it the #include way - it parses it as a keyword.

Maybe something handy would be to have something like

keyword (my_keyword) so the whole write/read/parse sequence could be avoided

in the far far future   ;)

Post a reply to this message

On 03/12/2018 20:27, Bald Eagle wrote:
> in the far far future;)

Made me smile. :D


-- 

Regards
     Stephen

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:

>
> When you do it the cancat way - POV-Ray sees it as a string.
> When you do it the #include way - it parses it as a keyword.

Apparently so. In some miraculous and secretive way, known only to the Gods :-P
>
> Maybe something handy would be to have something like
>
> keyword (my_keyword) so the whole write/read/parse sequence could be avoided
>

What interests me about the Parse_String macro is that it does two seemingly
separate operations simultaneously (well, one after the other)-- #write and
#include. For some strange reason, I thought that the parsing/processing of a
macro would have to go past its #end statement, before anything actually
happened (with the result that an error would be encountered at the #include
line);  but that's not the case. It's a happy (if late) new discovery for me.
;-)

That macro construction looks like a compact 'shorthand' way to avoid coding
separate #write/#read statements (doing away with #read altogether), while
producing the same results (?). Pasting that short macro *into* scene code would
do away with #include as well.

Post a reply to this message

Am 04.12.2018 um 03:57 schrieb Kenneth:

> That macro construction looks like a compact 'shorthand' way to avoid coding
> separate #write/#read statements (doing away with #read altogether), while
> producing the same results (?). Pasting that short macro *into* scene code would
> do away with #include as well.

The macro is /not/ a shorthand for a `#read`/`#write` combination - the 
`#include` is indispensable. You can put it directly into the scene, but 
you can't do without it.

The primary trick here is that e.g. instead of writing the keyword `png` 
verbatim in your scene, you can instead include a file that contains the 
keyword (and nothing but the keyword).

The secondary trick is that you can create such a file with arbitrary 
content "on the fly" using `#write`.

Wrapping it all in a single macro is just a matter of convenience.

Post a reply to this message

Am 03.12.2018 um 02:06 schrieb Kenneth:

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

In a first approximation, the details are actually quite simple:

- Any `#debug` statement that does not end in a `\n` will be 
concatenated with the next one.

- Any `#debug` output after the last `\n` may be truncated.


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

No, the "use forward slashes instead" rule only applies to filenames; 
the change was made /specifically/ so that `\n` is always interpreted as 
a line feed (as opposed to a path separator followed by the lowercase 
letter `n`).

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 04.12.2018 um 03:57 schrieb Kenneth:
>
> > ...Pasting that short macro *into* scene code would
> > do away with #include as well.
>
> The macro is /not/ a shorthand for a `#read`/`#write` combination - the
> `#include` is indispensable. You can put it directly into the scene, but
> you can't do without it.
>
Oops, I see now that my sentence wasn't clear; sorry. What I meant was, by
pasting the macro itself directly into a scene file, the   #include
"Strings.inc"  line could be eliminated from the scene (NOT the #include line
that's *in* the macro.)

I.e., just...

#macro Parse_String(String)
    #fopen FOut "parse_string.tmp" write
    #write(FOut,String)
    #fclose FOut
    #include "parse_string.tmp"
#end

(then the macro invocation(s) later)

It's also a *little* faster to parse this way-- the entire "Strings.inc" file
doesn't have to be pulled from disc or processed.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> Stephen <mca### [at] aolcom> wrote:
> > On 02/12/2018 16:26, Kenneth wrote:

> 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!)  ;-)
>
Have you tried parse_string?
It is slow if you have lot to do.

Post a reply to this message