 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <Xns### [at] 204 213191226>,
"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
|
|
| |
| |
|
|
|
|
| |
|
|
