POV-Ray : Newsgroups : povray.general : Help changing background light intensity : Re: Help changing background light intensity Server Time
5 Aug 2024 16:12:32 EDT (-0400)
  Re: Help changing background light intensity  
From: Christopher James Huff
Date: 13 Oct 2002 12:47:59
Message: <chrishuff-993526.12422113102002@netplex.aussie.org>
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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.