This may not be a bug, but it is certainly confusing me (easier to do these
days)...

This is using POV-Ray 3.7 RC4 on Mac, but is likely a language issue on all
platforms.  I have poked through the docs and POV-Wiki to no avail.

I'm starting to play with pre-creating arrays of texture elements, and writing
macros to help pre-build color-maps for them.  I've done this successfully with
certain elements (for example "pigment").  But I cannot do the same construct
for the "color_map" element.  Here's a boiled down scene file that will cause a
syntax error:

// POV-Ray 3.7 file that gives a syntax error when using a macro to init an
array element
#version 3.7
// define a Macro that creates a color_map
#macro ColorMapMacro(lineColor)
color_map
{
 [ 0.0 color rgb 0 ]
 [ 0.5 color rgb lineColor  ]
 [ 1.0 color rgb 0  ]
}
#end

// create a local color_map variable from the macro, this works fine
#local localCM= ColorMapMacro(<1,1,1>);

// declare an array of color_maps
#local ColorMapArray1 = array[3];
// now MANUALLY initialize each element in 3 different ways

#local ColorMapArray1[0] =  color_map
 {
 [ 0.0 color rgb 0 ]
 [ 0.5 color rgb 1  ]
 [ 1.0 color rgb 0  ]
 };

#local ColorMapArray1[1] =  localCM;

#local ColorMapArray1[2] =  ColorMapMacro(<1,1,1>);

// Do the same thing, but this time use the inline array initializer syntax
#local ColorMapArray2 = array[3]
{

 color_map
 {
 [ 0.0 color rgb 0 ]
 [ 0.5 color rgb 1  ]
 [ 1.0 color rgb 0  ]
 },

 localCM,

// "Parse Error: Attempted to redefine colour map identifier as object
identifier."
 ColorMapMacro(<1,1,1>)
}

What part of the POV-Ray language syntax am I missing here?  Can't an array
element be initialized from a macro?  Isn't it just magically injecting a
color_map declaration there?

I am poised with my hand hovering over my forehead, for the upcoming slap. :-)

ttfn,
Eduard


--------------------
POV-Ray Mac Developer - Emeritus
www.schwansongs.com

Post a reply to this message

On 01.03.12 23:09, Drakonis wrote:
> // Do the same thing, but this time use the inline array initializer syntax
> #local ColorMapArray2 = array[3]
> {

>   color_map
>   {
>   [ 0.0 color rgb 0 ]
>   [ 0.5 color rgb 1  ]
>   [ 1.0 color rgb 0  ]
>   },

>   localCM,

> // "Parse Error: Attempted to redefine colour map identifier as object
> identifier."
>   ColorMapMacro(<1,1,1>)
> }
>
> What part of the POV-Ray language syntax am I missing here?  Can't an array
> element be initialized from a macro?  Isn't it just magically injecting a
> color_map declaration there?
>
> I am poised with my hand hovering over my forehead, for the upcoming slap. :-)

Hello Eduard!

The error message is really funny, isn't it?  The reason is as trivial as 
the explanation Chris Young wrote for the docs: "POV-Ray macros are a 
strange mix of macros and functions." in 
<http://www.povray.org/documentation/view/3.6.1/243/#s02_02_02_08_03> .

And you happen to catch the macro in a case where the macros behaves like a 
function. It returns an object identifier of type "color_map", but too bad 
for you, it isn't a scene-level object, but one of those special cases that 
isn't really an object internally. As the docs (knowing this was written by 
Chris Young) say "When the body of a macro consists of statements that 
create an entire item such as an object, texture, etc. then the macro acts 
like a function which returns a single value." So when you try to assign it 
to the array, the code thinks you are assigning a (scene-level) object to 
the array of the special type of color_map" objects. It would need to do 
more inspection here, but that isn't happening.

Honestly, I didn't even know (!!!) it was possible to assign color_map 
objects to arrays before looking into the code, but it is also pretty clear 
that fixing the color_map assignment might not be trivial (though I haven't 
stepped through the code just yet). Especially given color_map code tends to 
leak so quickly and in so many unusual cases.

Of course, this does not solve the problem at hand, but: You might try to 
declare the return value of the macro locally, and then return that value. 
This might work...

As for fixing this in 3.7, it probably isn't a good idea to mess with the 
parser at this stage and on this level. But filing a bug report might be a 
good idea ;-)

Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:

> > I am poised with my hand hovering over my forehead, for the upcoming slap. :-)
>
> Hello Eduard!
>
> The error message is really funny, isn't it?  The reason is as trivial as
> the explanation Chris Young wrote for the docs: "POV-Ray macros are a
> strange mix of macros and functions." in
> <http://www.povray.org/documentation/view/3.6.1/243/#s02_02_02_08_03> .
>
> And you happen to catch the macro in a case where the macros behaves like a
> function. It returns an object identifier of type "color_map", but too bad
> for you, it isn't a scene-level object, but one of those special cases that
> isn't really an object internally. As the docs (knowing this was written by
> Chris Young) say "When the body of a macro consists of statements that
> create an entire item such as an object, texture, etc. then the macro acts
> like a function which returns a single value." So when you try to assign it
> to the array, the code thinks you are assigning a (scene-level) object to
> the array of the special type of color_map" objects. It would need to do
> more inspection here, but that isn't happening.
>
> Honestly, I didn't even know (!!!) it was possible to assign color_map
> objects to arrays before looking into the code, but it is also pretty clear
> that fixing the color_map assignment might not be trivial (though I haven't
> stepped through the code just yet). Especially given color_map code tends to
> leak so quickly and in so many unusual cases.
>
> Of course, this does not solve the problem at hand, but: You might try to
> declare the return value of the macro locally, and then return that value.
> This might work...
>
> As for fixing this in 3.7, it probably isn't a good idea to mess with the
> parser at this stage and on this level. But filing a bug report might be a
> good idea ;-)
>
> Thorsten

Hi there Thorsten!

I had read and re-read that macro section, and tried altering the macro in a
number of ways before giving up and writing this plea for help :-)  Chris's
general paragraph there has hints, but I was still not sure if this could be
considered a bug... so I was not ready to write a bug report (and definitely not
for a 3.7 fix!)

On the other hand, I cannot see an easy way to get what I want... that is, a way
to create an array of color_maps, and an array of pigments without color_maps,
so that I can choose a random color_map from the array to inject into a random
pigment from another array in my scene.

I did know that arrays of pigment{} will work, so I thought I could instead
pre-create the pigment statement I want (without a color map) and pass that into
the macro as a parameter, and the macro could ADD a new color_map and wrap the
whole thing in a new pigment element... but that doesn't let me mix and match
pigments and different color-maps.

I will ponder this more.  But thank you for responding and explaining that
color_map is not the same first-class scene-object-citizen that pigment is.
That makes sense in my programmer brain, but not in my end-user brain :-)


Eduard

Post a reply to this message

Drakonis <dra### [at] gmailcom> wrote:
> I will ponder this more.  But thank you for responding and explaining that
> color_map is not the same first-class scene-object-citizen that pigment is.
> That makes sense in my programmer brain, but not in my end-user brain :-)

  Did you try what Thorsten suggested, ie. declaring a local identifier
and "returning" it from the macro? In other words, like:

#macro ColorMapMacro(lineColor)
  #local ColorMap =
    color_map
    {
      [ 0.0 color rgb 0 ]
      [ 0.5 color rgb lineColor  ]
      [ 1.0 color rgb 0  ]
    };
  ColorMap
#end

  (Haven't tested it myself to see if it works...)

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   Did you try what Thorsten suggested, ie. declaring a local identifier
> and "returning" it from the macro? In other words, like:
>
> #macro ColorMapMacro(lineColor)
>   #local ColorMap =
>     color_map
>     {
>       [ 0.0 color rgb 0 ]
>       [ 0.5 color rgb lineColor  ]
>       [ 1.0 color rgb 0  ]
>     };
>   ColorMap
> #end
>
>   (Haven't tested it myself to see if it works...)

Sorry about the delay, real life keeps interrupting my render sessions!  Yes, I
tried it and it did NOT fix the problem.

However, I have found a slightly less-pretty workaround, so I will be using that
for now.  That is as I mentioned above, for some reason if I use explicit
initialization of each array element, it works.  It is just the
auto-initialization that fails... but that means I'll have to write it this way:

// define a Macro that creates a color_map
#macro ColorMapMacro(lineColor)
color_map
{
 [ 0.0 color rgb 0 ]
 [ 0.5 color rgb lineColor  ]
 [ 1.0 color rgb 0  ]
}
#end

// declare an array of color_maps
#local ColorMapArray1 = array[3];

// now MANUALLY initialize each element

maintain :-)
#local ColorMapArray1[0] =  ColorMapMacro(<1,1,0>);
#local ColorMapArray1[1] =  ColorMapMacro(<1,0,1>);
#local ColorMapArray1[2] =  ColorMapMacro(<0,1,1>);

But, this gets me back on my way.  Thank you both for your clarifying help.
ttfn,
Eduard

Post a reply to this message

Drakonis wrote:

> #local ColorMapArray1[0] =  ColorMapMacro(<1,1,0>);
> #local ColorMapArray1[1] =  ColorMapMacro(<1,0,1>);
> #local ColorMapArray1[2] =  ColorMapMacro(<0,1,1>);

How about calling this in a loop based on a vector or color array?

Post a reply to this message