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