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