// The name of the pics is si101 to si200

  // They are all in the directory Temp3, where also the this fil is.
  // If I render just one pic, all works well
  // but something doesen't work, when I try to render the 100 pics.
  // Strange is, it worked, years ago, with an older pov Version
  // Can someone help me?


camera{   location -z*10.1    look_at  <0,0,0>
 }

light_source{ <20,20,50> rgb <1,1,1> }




 #declare Count = 0;
  #while (Count <= 9)

  #declare X = Count ;

    #declare anzahl = 200-(X*10);



   #declare Bount = 0;
  #while (Bount <=9)

  #declare Y = Bount ;

    #declare name = anzahl -Y ;



   box {<-1,-1,-.001>,<1,1,.001>

     // one pic to render
    //    pigment {image_map {png "Temp3\si100.png"   map_type 0 interpolate 2 }

    pigment {image_map {png concat ("Temp3\si",str(name,0,0),".png")   map_type
0 interpolate 2 }
        scale 2
       translate <1,1,0>      }


           finish {ambient 1 }

          scale <1.333,1,.1>
          scale <.47,.47,.1>
          translate <(4.5*1.333)-Y*1.333,X-4.5,0> }


  background {color rgb <.9,.9,.9>}


 #declare Bount = Bount + 1 ;
  #end

 #declare Count = Count + 1 ;
  #end

Post a reply to this message

On 1-12-2013 14:24, Rudi wrote:
>   // The name of the pics is si101 to si200
>
>    // They are all in the directory Temp3, where also the this fil is.
>    // If I render just one pic, all works well
>    // but something doesen't work, when I try to render the 100 pics.
>    // Strange is, it worked, years ago, with an older pov Version
>    // Can someone help me?
>
>
> camera{   location -z*10.1    look_at  <0,0,0>
>   }
>
> light_source{ <20,20,50> rgb <1,1,1> }
>
>
>
>
>   #declare Count = 0;
>    #while (Count <= 9)
>
>    #declare X = Count ;
>
>      #declare anzahl = 200-(X*10);
>
>
>
>     #declare Bount = 0;
>    #while (Bount <=9)
>
>    #declare Y = Bount ;
>
>      #declare name = anzahl -Y ;
>
>
>
>     box {<-1,-1,-.001>,<1,1,.001>
>
>       // one pic to render
>      //    pigment {image_map {png "Temp3\si100.png"   map_type 0 interpolate 2 }
>
>      pigment {image_map {png concat ("Temp3\si",str(name,0,0),".png")   map_type
> 0 interpolate 2 }
>          scale 2
>         translate <1,1,0>      }
>
>
>             finish {ambient 1 }
>
>            scale <1.333,1,.1>
>            scale <.47,.47,.1>
>            translate <(4.5*1.333)-Y*1.333,X-4.5,0> }
>
>
>    background {color rgb <.9,.9,.9>}
>
>
>   #declare Bount = Bount + 1 ;
>    #end
>
>   #declare Count = Count + 1 ;
>    #end
>

I think you should try this (double backslash):

       pigment {image_map {png concat ("Temp3\\si",str(name,0,0),".png") 
   map_type 0 interpolate 2 }

Thomas

Post a reply to this message

I had to think a bit deeply to find the /why/ of this; it has to do with 
the way string literals are interpreted. See the off-line docs section 
3.3.1.9.1 String Literals, or in the online wiki: 
http://wiki.povray.org/content/Reference:Strings#String_Literals

Thomas

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
> I had to think a bit deeply to find the /why/ of this; it has to do with
> the way string literals are interpreted. See the off-line docs section
> 3.3.1.9.1 String Literals, or in the online wiki:
> http://wiki.povray.org/content/Reference:Strings#String_Literals
>
> Thomas

This is a natural effect of using escaped characters in strings (special
characters like non-printing characters \t and \n or \b).  One of the dumber
things windows does is use back-slash instead of forward-slash in directory
paths, so you have to escape the backslash "\\" to get it to render properly in
a string.

Regards,
A.D.B.

Post a reply to this message

On 12/01/2013 12:22 PM, Anthony D. Baye wrote:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> I had to think a bit deeply to find the /why/ of this; it has to do with
>> the way string literals are interpreted. See the off-line docs section
>> 3.3.1.9.1 String Literals, or in the online wiki:
>> http://wiki.povray.org/content/Reference:Strings#String_Literals
>>
>> Thomas
>
> This is a natural effect of using escaped characters in strings (special
> characters like non-printing characters \t and \n or \b).  One of the dumber
> things windows does is use back-slash instead of forward-slash in directory
> paths, so you have to escape the backslash "\\" to get it to render properly in
> a string.
>
> Regards,
> A.D.B.
>
>
It seems that it's not well known, but Windows _does_ accept forward slashes in path
strings, 
when they come from a program.  It's the Windows command processor that only accepts
the back 
slashes -- that is, when you are typing a command directly in Windows.

When the string comes from a program and not directly from the keyboard, the command
processor 
is bypassed, and both forms are accepted.  Definitely saves the headaches of trying to
remember 
to double the backslashes in path strings in a source-code file.

      -=- Larry -=-

Post a reply to this message

Am 01.12.2013 22:23, schrieb Larry Hudson:

> It seems that it's not well known, but Windows _does_ accept forward
> slashes in path strings, when they come from a program.  It's the
> Windows command processor that only accepts the back slashes -- that is,
> when you are typing a command directly in Windows.

Better yet: Even the command processor (cmd.exe) is perfectly fine with 
forward slashes.

Post a reply to this message

On 12/01/2013 02:53 PM, clipka wrote:
> Am 01.12.2013 22:23, schrieb Larry Hudson:
>
>> It seems that it's not well known, but Windows _does_ accept forward
>> slashes in path strings, when they come from a program.  It's the
>> Windows command processor that only accepts the back slashes -- that is,
>> when you are typing a command directly in Windows.
>
> Better yet: Even the command processor (cmd.exe) is perfectly fine with forward
slashes.
>
 From my memory, it used to be that it did not.  But perhaps that was command.com in
DOS.  I 
have to confess I haven't checked this myself recently -- I currently use Linux only
and rarely 
use Windows.  But since I believe most people aren't aware of it, I did want to point
out that 
forward slashes are acceptable (and more convenient) in Windows.  Thanx for the
updated info.

      -=- Larry

Post a reply to this message

clipka wrote:

> Better yet: Even the command processor (cmd.exe) is perfectly fine with 
> forward slashes.

I'm not sure it works for all commands ... also for example
auto-completion does not seem to work if you type

cd aaa/b

and then hit tab to complete the name of directory bbb (Windows 7 x64).

Post a reply to this message

> Thomas de Groot <tho### [at] degrootorg> wrote:
>> I had to think a bit deeply to find the /why/ of this; it has to do with
>> the way string literals are interpreted. See the off-line docs section
>> 3.3.1.9.1 String Literals, or in the online wiki:
>> http://wiki.povray.org/content/Reference:Strings#String_Literals
>>
>> Thomas
>
> This is a natural effect of using escaped characters in strings (special
> characters like non-printing characters \t and \n or \b).  One of the dumber
> things windows does is use back-slash instead of forward-slash in directory
> paths, so you have to escape the backslash "\\" to get it to render properly in
> a string.
>
> Regards,
> A.D.B.
>
>
And windows use the back-slash because DOS 1.0, that did not support 
folders, used the slash as an option prefix while using a + or - would 
have been beter.
Remember dir /w...
dir -w or dir +w would have been preferable.

Post a reply to this message

Am 02.12.2013 20:30, schrieb Christian Froeschlin:
> clipka wrote:
>
>> Better yet: Even the command processor (cmd.exe) is perfectly fine
>> with forward slashes.
>
> I'm not sure it works for all commands ... also for example
> auto-completion does not seem to work if you type
>
> cd aaa/b
>
> and then hit tab to complete the name of directory bbb (Windows 7 x64).

Worked fine here when I tried.

Post a reply to this message