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

In article <Xns### [at] 204213191226>,
 "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:

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

Well, yes, it does look wierd at first. The point is that it is far more 
flexible...a pigment is just a function that returns an RGB color 
vector, a color map is just a vector spline, which is also a function. 
If you want interpolation in a different color space, just convert back 
to RGB for the final value. If you want your own custom function instead 
of a color map, no problem. It can express any existing POV texture, and 
much more, without being much longer if at all.
Adding a special color map feature just adds bulk to an already 
redundant feature.

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

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

[...]

> Adding a special color map feature just adds bulk to an already 
> redundant feature.

I can't agree, in same way we can say that sphere,box,etc are redunant 
versions of i.e. isosurface.
I alsow realy like SDL, but if we will continue to implement everything 
possible in SDL istead of C we will end with parse-times longer then 
renders ;-/ and with straaange syntax.

My sugesstion(s) : (PS. I think that some of this realy can be usefull 
maybe for a change try to find something good instead of criticize each-
other's ideas :)

pigment {
  bozo
  color_map { 
    [0 rgb x]  // #1 blend to next entry using global blend type
    [0.1 rgb y blend_rgb] // #2 blend to next entry  RGB
    [0.2 rgb z] // #3 blend to next entry using global blend type 
    [1 rgb x+y] // #4 blend to next entry using global blend type
    blend_hsv // set global entry (used for 1,3,4)
    precalc {4096} // precaluate 4096 RGB values to optimize speed
  }
}

---Explanation step by step---
typical rgb colormap:
  color_map {[0 rgb x][1 rgb x+y]}

hsv blend colormap:
  color_map {[0 rgb x][1 rgb x+y] blend_hsv}
  <1,0,0> - <1,1,0> will be interpolated as HSV

hsv blend colormap with more entries
  color_map {
     [0 rgb x][0.1 rgb y][0.2 rgb z][1 rgb x+z] blend_hsv }
  }
  <0,0,0>-<0,1,0> interpolate as global (set here to HSV by blend_hsv)
  <0,1,0>-<0,0,1> interpolate as global (set here to HSV by blend_hsv)
  <0,0,1>-<1,1,0> interpolate as global (set here to HSV by blend_hsv)
  <1,1,1>-<0,0,0> interpolate as global (set here to HSV by blend_hsv)

hsv blend colormap with more entries and exception
  color_map {
     [0 rgb x][0.1 rgb y blend_rgb][0.2 rgb z][1 rgb x+z] blend_hsv }
  }
  <0,0,0>-<0,1,0> interpolate as global (set here to HSV by blend_hsv)
  <0,1,0>-<0,0,1> interpolate as RGB (set only here by blend_rgb)
  <0,0,1>-<1,1,0> interpolate as global (set here to HSV by blend_hsv)
  <0,0,1>-<1,1,0> interpolate as global (set here to HSV by blend_hsv)

same, with precalcuate 
  color_map { ...
    precalc{4096}
  }


-- 
#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-
15F### [at] netplexaussieorg

[...]

And btw. no offence but - Christopher, how about implementing photons using 
trace() that runned in recursive loop will create an big union of very 
small spheres with filter (that will look like photon dots) and remove at 
least this bulky and redunant Photnos{} blocks ;) ? Syntax will be very 
nice, someting like :
  ADD_PHOTON_OBJ( box{...}, 1,1) // 1=reflection 1=refraction
  SHOOT_SDL_PHOTONS(50000) // 50000=count = please come back tomorrow 

;)

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

In article <Xns### [at] 204213191226>,
 "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:

> I can't agree, in same way we can say that sphere,box,etc are redunant 
> versions of i.e. isosurface.

No, you can't...the isosurface object uses a completely different way to 
solve for the shape, takes a different kind of input, etc. A color map 
is a linear spline with some limitations...it can only take color 
values, and can only have 256 elements. Instead of removing the 
limitations and adding features, my suggestion is to replace it with the 
existing spline feature and add features to *that*. Instead of a color 
map with options for things like cubic blending, just have a color 
spline with the same syntax as any other spline.

The other stuff, the color space functions and pigment-as-function, were 
just a much more flexible and more consistent way of accomplishing the 
same result, interpolating in a different color space, as well as much, 
much more.


> I alsow realy like SDL, but if we will continue to implement everything 
> possible in SDL istead of C we will end with parse-times longer then 
> renders ;-/ and with straaange syntax.

This wouldn't have any impact on parse time. It might slightly slow 
render time, but it would be more capable than a vast array of 
hard-coded features.


> pigment {
>   bozo
>   color_map { 
>     [0 rgb x]  // #1 blend to next entry using global blend type
>     [0.1 rgb y blend_rgb] // #2 blend to next entry  RGB
>     [0.2 rgb z] // #3 blend to next entry using global blend type 
>     [1 rgb x+y] // #4 blend to next entry using global blend type
>     blend_hsv // set global entry (used for 1,3,4)
>     precalc {4096} // precaluate 4096 RGB values to optimize speed
>   }
> }

This is really crying for the old (and currently deprecated) blend 
syntax, which gave each end of a range as well as the color of each end:
pigment {bozo
  color_map {
    blend_hsv
    [0.0, 0.1 rgb x, rgb y]
    [0.1, 0.2 rgb y, rgb z blend_rgb]
    [0.2, 1.0 rgb z, rgb x+y]
    precalc 4096
  }
}

But I still don't think this syntax is necessary...that function syntax 
I proposed would handle it just fine for those cases where it is needed.
That precalc idea...I don't think I like it. For one thing, it would 
only help a few cases, and would hurt a lot of others. It would be 
required so rarely that it could easily be coded as a loop instead. And 
the differences between per-range and per-map blending modes would 
complicate things unnecessarily and cause confusion, its main advantage 
would be reducing typing.

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

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

> No, you can't...the isosurface object uses a completely different way to 
> solve for the shape, takes a different kind of input, etc. A color map 
> is a linear spline with some limitations...it can only take color 
> values, and can only have 256 elements. Instead of removing the 
> limitations and adding features, my suggestion is to replace it with the 
> existing spline feature and add features to *that*. Instead of a color 
> map with options for things like cubic blending, just have a color 
> spline with the same syntax as any other spline.

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

>> I alsow realy like SDL, but if we will continue to implement everything 
>> possible in SDL istead of C we will end with parse-times longer then 
>> renders ;-/ and with straaange syntax.
> This wouldn't have any impact on parse time. It might slightly slow 
> render time, but it would be more capable than a vast array of 
> hard-coded features.

I was talking in generaly about Your's approach "why hard code while we can 
do it in SDL"
 
> This is really crying for the old (and currently deprecated) blend 
> syntax, which gave each end of a range as well as the color of each end:
> pigment {bozo
>   color_map {
>     blend_hsv
>     [0.0, 0.1 rgb x, rgb y]
>     [0.1, 0.2 rgb y, rgb z blend_rgb]
>     [0.2, 1.0 rgb z, rgb x+y]
>     precalc 4096
>   }
> }
> But I still don't think this syntax is necessary...that function syntax 

You realy doesn't like changes ;) IMHO :
a) users that don't use it - will not notice it
b) users with do use it - will appriciate this possibility.

Btw. it can be used along with Yours spline idea (if I understand it 
correctly).

> That precalc idea...I don't think I like it. For one thing, it would 
> only help a few cases, and would hurt a lot of others. It would be 
> required so rarely that it could easily be coded as a loop instead. 

only if we add function color_map_value_at(float,COLOR_MAP)
but hmm I do agree :) maybe just code this function instead.
Hmm in fact this is where I woulud agree alsow that using SDL is good.

#macro color_map_at_value(_v,_cmap) - make function i.e. gradient x at 
return it's color at <_v,0,0> 
hmm what was full syntax for it ?

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

In article <Xns### [at] 204213191226>,
 "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:

> And btw. no offence but - Christopher, how about implementing photons using 
> trace() that runned in recursive loop will create an big union of very 
> small spheres with filter (that will look like photon dots) and remove at 
> least this bulky and redunant Photnos{} blocks ;) ? Syntax will be very 
> nice, someting like :
>   ADD_PHOTON_OBJ( box{...}, 1,1) // 1=reflection 1=refraction
>   SHOOT_SDL_PHOTONS(50000) // 50000=count = please come back tomorrow 

That is a rediculous analogy. I suggest you look into how photons really 
work...

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

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

>> Syntax will be very nice, someting like :
>>   ADD_PHOTON_OBJ( box{...}, 1,1) // 1=reflection 1=refraction
>>   SHOOT_SDL_PHOTONS(50000) // 50000=count = please come back tomorrow
> I suggest you look into how photons really work...

I did that already... and ? Yes to make it work SDL should be informed 
about lights, and about ALL scene objects that might block photons.
But this is only a joke :)

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

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