I'm able to change the  intensity, but only if I also change the color.
Is there a way that I can change ONLY the intensity of the background?
Thank you for help ahead of time.

Post a reply to this message

Atchar Sudhyadhom <atc### [at] ufledu> wrote:
> I'm able to change the  intensity, but only if I also change the color.
> Is there a way that I can change ONLY the intensity of the background?

  You don't give enough information to give a proper answer.
  Are you talking about the background {} feature or the ambient_light
feature, or perhaps something else?

  Anyways, in order to change the intensity of a color, just multiply it
with a float.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote in news:3da610a5@news.povray.org

>   Anyways, in order to change the intensity of a color, just multiply it
> with a float.

or use hsv2rgb macro (is that correct spellig ?) 

btw.
how about ne future - types of colors interpolating :
colors_rgb
colors_hsv ?

i.e.

gradient color_map{[0 rgb <1,0,0>][1 rgb <0,1,0>] colors_rgb}
will give : red dirty-red dirty-yellow dirty-green green

gradient color_map{[0 rgb <1,0,0>][1 rgb <0,1,0>] colors_hsv}
will give : red red-yellow yellow yellow-green green

I will write try to implement this futre, do You think it would be usefull 
?

-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message

Atchar Sudhyadhom wrote:
>I'm able to change the  intensity, but only if I also change the color.
>Is there a way that I can change ONLY the intensity of the background?
>Thank you for help ahead of time.
>


Take a big sphere instaed of a background {...} or a sky_sphere.
Then you have a finish definition also to play with. But it is not possible
to rise the ambient level and to not change the background color impression
imho.


Norbert

Post a reply to this message

On 10 Oct 2002 20:04:16 -0400, "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:
> >   Anyways, in order to change the intensity of a color, just multiply it
> > with a float.
>
> or use hsv2rgb macro (is that correct spellig ?) 

CHSV2RGB(Color)

> btw.
> how about ne future - types of colors interpolating :
> colors_rgb
> colors_hsv ?

Why ? If it is easy possible with macro (already included in official package)
then no need to waste time for coding. There will be no difference between
macro and builded feature. It have to be always converted to rgb internally.

> I will write try to implement this futre, do You think it would be usefull 

No :-)

ABX

Post a reply to this message

Norbert Kern <nor### [at] t-onlinede> wrote:
> Take a big sphere instaed of a background {...} or a sky_sphere.

  Why? That just slows down the rendering...

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

In article <fgucqu4mhn13aldspfkk016iom072qtuf3@4ax.com>,
 ABX <abx### [at] abxartpl> wrote:

> Why ? If it is easy possible with macro (already included in official package)
> then no need to waste time for coding. There will be no difference between
> macro and builded feature. It have to be always converted to rgb internally.

I think he is talking about different blending methods...currently, 
color_maps do a linear interpolation of RGB colors, and will return < 
0.5, 0.5, 0> with a pattern value of 0.5 with that color map, the user 
might have expected < 1, 1, 0>. Doing a linear interpolation in HSV 
space would give a very different blend...it would make it possible to 
specify two colors with maximum brightness and saturation and get a 
rainbow of hues all of the same brightness.

However, it would be slower. Not by a lot, the conversion of the color 
entries could be done at parse time (assuming you will never want to 
access the color entries directly, with something like an array syntax), 
but it still has to convert back to RGB space. It may be faster to just 
use an RGB map with more entries.

I have considered doing something related to this, along with different 
interpolation types like cosine and cubic interpolation. Color maps are 
very similar to splines in some ways, I've been thinking it might be 
better to merge them into the spline feature.
Basically, all the *_map keywords would be replaced with "blend", the 
parser would be smart enough to figure out what kind of blend is needed. 
The color_map feature would be replaced with the spline feature. 
Pigments would be vector functions. Something like that code could be 
written as:

#declare colorSpline =
spline {
    [0, rgb2hsv(< 1, 0, 0>)]
    [1, rgb2hsv(< 1, 1, 0>)]
}

#declare theTexture =
texture {
    pigment hsv2rgb(colorSpline(bozo(x, y, z)))
}

Maybe an in-line syntax for splines too:
texture {
    pigment hsv2rgb(
        spline {//linear would be default
            [0, rgb2hsv(< 1, 0, 0>)]
            [1, rgb2hsv(< 0, 1, 0>)]
        }(bozo(x, y, z))
    )
}

Ok, that looks a bit wierd, but is much more flexible and could be 
backwards compatible, it doesn't have to replace the existing syntax.
One thing I don't like, you have to watch for the differences between 
code run at parse/scene setup time and code run at render time, but the 
same problem exists now and it doesn't cause much trouble.

-- 
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

ABX <abx### [at] abxartpl> wrote in
news:fgucqu4mhn13aldspfkk016iom072qtuf3@4ax.com 

>> btw.
>> how about ne future - types of colors interpolating :
>> colors_rgb
>> colors_hsv ?
> Why ? If it is easy possible with macro (already included in official
> package) then no need to waste time for coding. There will be no
> difference between macro and builded feature. It have to be always
> converted to rgb internally. 

As Christopher pointed out, I was talking about different blending method.

HSV and even splines color map doesn't need to be slower, IF we would 
optimize it - and i.e. precalculate 256 (with can be done even now - with 
macro), or 4096 (or more) colors.
bozo color_map{[...][...] hsv_blending precalculate {4096}}

I have some more ideas for it, I will do some tests and post full hmm CFF 
(Call For Feature ? maybe RFD ? is there some name for that documents :)
in near future :)



-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message

"Norbert Kern" <nor### [at] t-onlinede> wrote in
news:web.3da626df23ad0e644b26c9670@news.povray.org 

> Take a big sphere instaed of a background {...} or a sky_sphere.
> Then you have a finish definition also to play with. But it is not
> possible to rise the ambient level and to not change the background
> color impression imho.

no,
background rgb A
sky sphere rgbf <B,B,B,f>

is same (but slower) as :
background rgb A*(f)+b*(1-f)


-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message

Christopher James Huff <chr### [at] maccom> wrote in news:chrishuff-
7DF### [at] netplexaussieorg

>     pigment hsv2rgb(
>         spline {//linear would be default
>             [0, rgb2hsv(< 1, 0, 0>)]
>             [1, rgb2hsv(< 0, 1, 0>)]
>         }(bozo(x, y, z))
>     )

IMHO I think that this syntax is wierd [1], better would be to extend 
color_map by new keywords. 

[1] this time it's me who is criticizing :P no offence :)

-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message