|
 |
Warp nous apporta ses lumieres en ce 2007/11/06 16:32:
> Trevor G Quayle <Tin### [at] hotmail com> wrote:
>> Unfortuneately image_map can't be declared explicitly like:
>> #declare A=image_map{jpg "MyImage.jpg"} so using it this way would require it to
>> be applied to something (mind you it could be just a dummy pigment, but this
>> seems un-neat to me).
>
> It's perfectly possible and in fact quite easy to do something like this:
>
> #declare Im = pigment { image_map { jpg "MyImage" } };
> #declare R = max_extent(Im);
>
> and then R.x would be the width of the image and R.y the height.
>
> (I actually went ahead and implemented this just to see if it would work,
> and it worked like a charm.)
>
> The only question is whether max_extent() is the suitable function for
> this.
>
> It has been suggested that image_width, when used as a function (and given
> the image map pigment identifier as parameter) would return the width of the
> image, and likewise image_height the height, but I'm not completely sure how
> trivial this is to implement in the parser because these keywords are already
> used as float identifiers. It would mean that when parsing these keywords the
> parser would have to look for an optional opening parenthesis after it, and
> if it appears, behave differently. I haven't yet looked, but my past
> experience in trying this "check for an optional syntax element" with the
> current parser has been daunting. (More precisely, I tried to implement
> concatenation of strings using the + operator. I hit a wall.)
>
> (max_extent() doesn't have this problem because it's already a vector
> function, and thus it's simply a question of checking the type of the
> parameter. This is very trivial to implement in the parser.)
>
It looks like using max_extent() would be a beter option than the one I
proposed. Easier to implement and use, at least, it look like it's so.
--
Alain
-------------------------------------------------
Did you know that SATAN is an anagram for SANTA?
Post a reply to this message
|
|
