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