Is it possible to use a string construction of some kind to generate a VARIABLE
NAME (or identifier, as POV-Ray calls it) that can be used after a #declare?

So that, instead of
#declare my_value = 12345;
I could do this...
#declare --generated string name-- = 12345;

So far, I have had no luck. (Maybe I'm forgetting something basic??)

As a more practical example, say I want to create 100 different arrays inside of
a #while loop-- each with a different #declared name of course-- but without
having to manually name each and every array. Creating the different names
themselves is no problem when using strings (assume that AC is a #while loop
counter, simple up-counting integers)...

#declare array_name = concat("my_array",str(AC,1,0))

The generated string changes as AC changes, and array_name becomes my_array1,
my_array2, etc. But these are just names-as-strings, with no arrays 'attached'
yet. When I then try to create the arrays themselves...

#declare array_name = array[100]

......array_name is just #re-declared at every count of the while loop (it
doesn't substitute my_array1 for it, then my_array2 etc) which defeats the idea;
the end result is a *single* array that's simply re-declared over and over
again.

Trying to simplify the idea to this rather strange construction doesn't work
either (it produces a fatal error)...

#declare concat("my_array",str(AC,1,0)) = array[100]

So, if not with strings, is there another way to do this kind of automated
identifier creation?

------
While I'm on this subject: I see that I cannot substitute a string for one of
POV-Ray's built-in keywords-- like rgb or whatever. For example:

#declare color_vector_type = "rgb"

which I could then use in a pigment statement...

pigment{color_vector_type <.3,.6,.9>}

I would have assumed that this was possible, simply because... 'text is text':
When I type the letters rgb on the keyboard, its just text. (But then, of
course, POV-Ray recognizes what I've typed, and substitutes a keyword for it.)
So... what are the essential differences between typing r-g-b, the string "rgb",
and the keyword rgb? Perhaps it's a very naive question! (Maybe one that would
require a textbook in C-programming to explain??)

Post a reply to this message

> Is it possible to use a string construction of some kind to generate a VARIABLE
> NAME (or identifier, as POV-Ray calls it) that can be used after a #declare?
>
> So that, instead of
> #declare my_value = 12345;
> I could do this...
> #declare --generated string name-- = 12345;
>
> So far, I have had no luck. (Maybe I'm forgetting something basic??)
>
> As a more practical example, say I want to create 100 different arrays inside of
> a #while loop-- each with a different #declared name of course-- but without
> having to manually name each and every array. Creating the different names
> themselves is no problem when using strings (assume that AC is a #while loop
> counter, simple up-counting integers)...
>
> #declare array_name = concat("my_array",str(AC,1,0))
>
> The generated string changes as AC changes, and array_name becomes my_array1,
> my_array2, etc. But these are just names-as-strings, with no arrays 'attached'
> yet. When I then try to create the arrays themselves...
>
> #declare array_name = array[100]
>
> ......array_name is just #re-declared at every count of the while loop (it
> doesn't substitute my_array1 for it, then my_array2 etc) which defeats the idea;
> the end result is a *single* array that's simply re-declared over and over
> again.
>
> Trying to simplify the idea to this rather strange construction doesn't work
> either (it produces a fatal error)...
>
> #declare concat("my_array",str(AC,1,0)) = array[100]
>
> So, if not with strings, is there another way to do this kind of automated
> identifier creation?
>
> ------
> While I'm on this subject: I see that I cannot substitute a string for one of
> POV-Ray's built-in keywords-- like rgb or whatever. For example:
>
> #declare color_vector_type = "rgb"
>
> which I could then use in a pigment statement...
>
> pigment{color_vector_type <.3,.6,.9>}
>
> I would have assumed that this was possible, simply because... 'text is text':
> When I type the letters rgb on the keyboard, its just text. (But then, of
> course, POV-Ray recognizes what I've typed, and substitutes a keyword for it.)
> So... what are the essential differences between typing r-g-b, the string "rgb",
> and the keyword rgb? Perhaps it's a very naive question! (Maybe one that would
> require a textbook in C-programming to explain??)
>
>
>
>

Write the generated names to an inc file. The generated files need to 
contain ONLY the name of a single array.

Next, whenever you need to use one of the generated names, #include the 
corresponding file.


For the second question, no, text is not always text. It depends on the 
context.
For POV-Ray, "This_is_some_text" IS text while #declare 
This_is_some_text is a user defined identifier.
If you want to use color_vector_typ as a substitute for rgb=, you need 
to define a macro.

#macro color_vector_type()  rgb= #end
pigment{color_vector_type() <.3,.6,.9>}

The empty parentheses are mandatory.



Alain

Post a reply to this message

Sorry for the delay in responding; I was giving some thought to your
suggestions.

Alain wrote:
>
> Write the generated names to an inc file. The generated files need to
> contain ONLY the name of a single array.
>
> Next, whenever you need to use one of the generated names, #include the
> corresponding file.

Yes, a nice idea; I didn't think of #writing the files. I see how this would
work; and I could then create an automated way of #read-ing back the #include
files (which I've done before.) Of course, I was *hoping* that all of the
automated identifier-naming could be done totally within my SDL scene-- just to
be more 'elegant' and self-contained. But that's a minor consideration.

Thanks!

>
> If you want to use color_vector_type as a substitute for rgb=, you need
> to define a macro.
>
> #macro color_vector_type()  rgb= #end
> pigment{color_vector_type() <.3,.6,.9>}

YES, that works; I tried it. (Actually just rgb, not rgb= ) That came as a
surprise; I have never used a macro in quite this way. In fact, it gives me
ideas on how to improve some of my old scenes.

Very helpful, and very much appreciated!

(IMO, something should be added to the documentation that describes this kind of
macro use. The idea of using a macro to insert a KEYWORD is not obvious there,
and it seems to be a rather powerful feature; it's the only way I know of at
present to do such a thing, since using a string doesn't work. *Maybe* it could
also be done by using a #read block, reading in a simple #written rgb, for
example. Just a guess.)

Post a reply to this message

On 25-2-2014 1:15, Kenneth wrote:
>> #macro color_vector_type()  rgb= #end
>> pigment{color_vector_type() <.3,.6,.9>}
>
> YES, that works; I tried it. (Actually just rgb, not rgb= ) That came as a
> surprise; I have never used a macro in quite this way. In fact, it gives me
> ideas on how to improve some of my old scenes.
>
> Very helpful, and very much appreciated!
>
> (IMO, something should be added to the documentation that describes this kind of
> macro use. The idea of using a macro to insert a KEYWORD is not obvious there,
> and it seems to be a rather powerful feature; it's the only way I know of at
> present to do such a thing, since using a string doesn't work. *Maybe* it could
> also be done by using a #read block, reading in a simple #written rgb, for
> example. Just a guess.)
>

Just out of curiosity, what would the advantage be of this trick? I 
assume that calling such a macro would increase parsing time, even if by 
only a tiny, tiny bit ;-)

Thomas

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:

>
> Just out of curiosity, what would the advantage be of this trick? I
> assume that calling such a macro would increase parsing time, even if by
> only a tiny, tiny bit ;-)
>

When I was designing my 'animation blurring' scheme several years ago (i.e.,
averaging 10 or more frames to create motion blur), I was trying to come up with
a way to easily tell my code what type of image files I was going to use (.bmp,
..png, .jpeg), without having to do that in the body of the code (in the pigment
statement itself) but rather at the beginning of the scene. That's where I like
to add all of my 'switches,' to set up parameters, turn things on and off, etc.
So I worked out a scheme that uses strings for *part* of what I wanted to do,
but not all. Here's an example code snippet, buried way down in my code:

image_map{jpeg "my_image" once} // inside a #while loop, using a pigment_map
// to average lots of images together to get blur

For the 'my_image' part, I built a string construction that automatically takes
the 'real' image name (along with its included number in the animation
sequence), adds a period, then adds 'jpeg' after it, then it is all #declared as
my_image. (Same for the other file types, using a rather ugly #switch
statement.) So it's mostly automatic; all I have to do at the beginning of the
file is to specify what the real file name is, and the file type-- both as
#declared strings.

But I didn't know how to likewise create the 'file type' that comes immediately
after image_map{   as it's a KEYWORD. I've basically been looking for a more
'elegant' way of doing that. ;-) So now, with Alain's #macro idea, I can
automate that small bit of the process as well!

In a bigger context, it seems to me that this particular kind of macro use might
be a way to #declare things that are not normally declare-able. Keywords might
be just *one* example-- although I can't think of any others right now.

Post a reply to this message

On 25-2-2014 10:30, Kenneth wrote:
> In a bigger context, it seems to me that this particular kind of macro use might
> be a way to #declare things that are not normally declare-able. Keywords might
> be just *one* example-- although I can't think of any others right now.
>

It is an interesting use, and Alain's trick is also new to me. I am 
doing that kind of thing in my POV-tree test scene:

#local TreeName = "MyName";
....
#local IncName = concat(TreeName, "_mesh.inc")
#include IncName
....

That way, I only have to change the tree's generic name in order to 
include another tree. I also have a switch that enables me to choose 
between POV-tree blobs or meshes, Arbaro meshes, or Xfrog meshes.

Thomas

Post a reply to this message

> Thomas de Groot <tho### [at] degrootorg> wrote:
>
>>
>> Just out of curiosity, what would the advantage be of this trick? I
>> assume that calling such a macro would increase parsing time, even if by
>> only a tiny, tiny bit ;-)
>>
>
> When I was designing my 'animation blurring' scheme several years ago (i.e.,
> averaging 10 or more frames to create motion blur), I was trying to come up with
> a way to easily tell my code what type of image files I was going to use (.bmp,
> ..png, .jpeg), without having to do that in the body of the code (in the pigment
> statement itself) but rather at the beginning of the scene. That's where I like
> to add all of my 'switches,' to set up parameters, turn things on and off, etc.
> So I worked out a scheme that uses strings for *part* of what I wanted to do,
> but not all. Here's an example code snippet, buried way down in my code:
>
> image_map{jpeg "my_image" once} // inside a #while loop, using a pigment_map
> // to average lots of images together to get blur
>
> For the 'my_image' part, I built a string construction that automatically takes
> the 'real' image name (along with its included number in the animation
> sequence), adds a period, then adds 'jpeg' after it, then it is all #declared as
> my_image. (Same for the other file types, using a rather ugly #switch
> statement.) So it's mostly automatic; all I have to do at the beginning of the
> file is to specify what the real file name is, and the file type-- both as
> #declared strings.
>
> But I didn't know how to likewise create the 'file type' that comes immediately
> after image_map{   as it's a KEYWORD. I've basically been looking for a more
> 'elegant' way of doing that. ;-) So now, with Alain's #macro idea, I can
> automate that small bit of the process as well!
>
> In a bigger context, it seems to me that this particular kind of macro use might
> be a way to #declare things that are not normally declare-able. Keywords might
> be just *one* example-- although I can't think of any others right now.
>
>
>
>
>
>
For the task of motion blur, you should try the experimental uberpov 
"blink" feature.
It does the averaging for you using only a single rendering step.

Post a reply to this message

Alain <kua### [at] videotronca> wrote:

> >
> For the task of motion blur, you should try the experimental uberpov
> "blink" feature.
> It does the averaging for you using only a single rendering step.

What?? Very cool! Clipka is working overtime! :-P

Can you post the link to the Windows version of uberPOV? I haven't been keeping
up with the newsgroup news as much as I should.

Post a reply to this message

> Alain <kua### [at] videotronca> wrote:
>
>>>
>> For the task of motion blur, you should try the experimental uberpov
>> "blink" feature.
>> It does the averaging for you using only a single rendering step.
>
> What?? Very cool! Clipka is working overtime! :-P
>
> Can you post the link to the Windows version of uberPOV? I haven't been keeping
> up with the newsgroup news as much as I should.
>
>
>
>
>

The blured reflection is another nice feature.
You may also try the stochastic antialiasing, using am3. Great to get 

There are alson some other nice features that I did not try... yet.


Here goes:
https://github.com/UberPOV/UberPOV/tree/master/doc/html

You'll find a windows version, as well as the source code for Linux and 
Windows.



Alain

Post a reply to this message

Alain <kua### [at] videotronca> wrote:

>
> Here goes:
> https://github.com/UberPOV/UberPOV/tree/master/doc/html
>

Hmm, that looks like HTML documents instead.

I found a better link, in the 'unofficial patches' newsgroup posts...
https://github.com/UberPOV/UberPOV/releases/tag/v1.37.0.0-beta.4

(I should have looked there first myself, but was too excited by the news... or
too lazy....  :-O  )

Post a reply to this message