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