|
![](/i/fill.gif) |
Hi folks,
While I was building my recent waterscapes, and in the clouds I'm still
working on, I hit a wall with standard blend maps. I simply could not
figure out how to produce an effect I wanted. I'd hit this problem
before, but this time I decided to do something about it ...
Rationale:
---------
Say I wanted to change from a granite pigment to a gradient, over
another gradient. Fine, you say, you can do this:
pigment {
gradient y
pigment_map {
[0 granite]
[0.5 gradient x]
}
}
OK, I say, but I want to colour_map this, say {[0.5 Red][0.5 Green][1
Blue]}.
Now, using:
pigment {
gradient y
pigment_map {
[0 granite colour_map {[0.5 Red][0.5 Green][1 Blue]}]
[0.5 gradient x colour_map {[0.5 Red][0.5 Green][1 Blue]}]
}
}
I get smeared mixtures of red, green and blue. What I really wanted to
do was apply the colour_map once to the whole pigment:
pigment {
gradient y
pigment_map {
[0 granite]
[0.5 gradient x]
}
colour_map {[0.5 Red][0.5 Green][1 Blue]}
}
but this, so far as I know, was impossible. So I decided to make this
effect possible, if not this exact syntax.
Result:
------
What I came up with was this syntax:
composite { PIGMENT_BODY }
eg
pigment {
composite {
gradient y
pigment_map {
[0 granite]
[0.5 gradient x]
}
}
colour_map {[0.5 Red][0.5 Green][1 Blue]}
}
The composite pattern takes the colour returned by the pigment body,
takes a simple average of the three colours and uses this value to index
the colour_map in this example. This composite pattern can (I believe -
I haven't stringently tested it yet) be used anywhere any other pattern
type can be used. I have tested it using colour_map, pigment_map,
texture_map and density. These all appear to work correctly. One thing
you do have to watch for are non-grayscale default colour_maps, eg
radial.
Hokay, I guess if anyone has persevered this far they want to know how
I did it.
The code changes surprised me with their simplicity - eight small code
additions through four files is all it took. I haven't produced a diff
file - the base code I was working with was an already altered version
of Ron's latest superpatch release code - but I hope it is clear from my
notes in the attached text file as to where the code snippets are to be
added. I've also attached an example PoV file which shows the composite
syntax compared to applying the blend maps on a pattern-by-pattern
basis, an image of which I posted on p.b.i.
As a final note, would the folks who have created similar patches
(Hans-Detlev, Ron and Nathan that I know of, anyone else?) please check
that I'm not doing any architypal Bad Things like not releasing acquired
memory? And, of course, if anyone can think of any changes that should
be made, or any comments on usefulness (or lack thereof) please make
them known, either here or by email.
Bye for now,
Mike Andrews.
Post a reply to this message
Attachments:
Download 'us-ascii' (3 KB)
Download 'composit.pov.txt' (5 KB)
|
![](/i/fill.gif) |