|
|
In article <Xns### [at] 204213191226>,
"Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:
> Hmm ok... but I don't understand, how can I use this spline to get HSV
> blend beetwen :
> [0 rgb <1,1,0>]
> [.5 rgb <1,0,0>]
> [1 rgb <.3,1,.3>]
> ?
hsv2rgb(spline {
[0.0 rgb2hsv(< 1, 1, 0>)]
[0.5 rgb2hsv(< 1, 0, 0>)]
[1.0 rgb2hsv(< 0.3, 1, 0.3>)]
}(tVal))
It is just basically a spline function declared at the time it is used:
spline {ENTRIES} (T-VALUE)
The same would exist for things like transform or pattern functions,
just a way to use them in-line without having to declare them.
This approach is infinitely flexible, here's a "color map" that always
results in a color with a length equal to 1:
declare Foo = function (t){vnormalize(spline {...}(t))}
And here's one that always results in a color where the maximum
component is equal to 1: (function variable syntax still being worked
out)
declare Bar =
function (t) {
def col = spline {...}(t);
col/max(col.red, col.green, col.blue)
}
pigment Foo(bozo(x, y, z))
pigment Bar(radial(x, y, z))
It reflects the actual arrangement of things: the color map is a
function with the pattern result as input, and gives you great control
over computation.
> I was talking in generaly about Your's approach "why hard code while we can
> do it in SDL"
In general, hard coding is bad because it increases complexity and
reduces flexibility, but there are times it is necessary. In this case,
it is more "why add one specific feature when adding a more general
feature does the same thing and more".
> Btw. it can be used along with Yours spline idea (if I understand it
> correctly).
Right, the syntax is distinct enough that the parser can easily
determine what is desired. I just don't think it would be required often
enough.
> only if we add function color_map_value_at(float,COLOR_MAP)
No reason for that. We don't have or need "array_value_at()" or
"spline_value_at()".
I haven't covered what I want to do to the other blend types...there
would be an "associative array" or "map" data type, splines and blends
would be based off of this. "MyTextureMap[3]" would return the third
element, "MyTextureMap(0.3)" would evaluate the textures and return the
blended result (I haven't figured out how the intersection information
would be handled, maybe a new intersection type that would be passed
along).
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|