If my eval_pattern() function is added to MegaPov, I think it would also 
be a good idea to add it as an isosurface function. I have a feeling 
that evaluating the pattern directly could be much faster than 
evaluating the pigment, but I don't know the isosurface code well enough 
to add a function.

Another advantage could be the increased precision, aren't color_maps 
limited to 255 levels of color?

An alternative would be to add the ability to call the patterns as 
functions, this would require adding a function for each pattern, but 
Might be even faster. There probably isn't a significant difference in 
speed, though. And patterns which take parameters would have to have 
more than the normal 3(x, y, and z), so you couldn't use the usual 
pattern syntax. And some patterns(like my object pattern) have a syntax 
which would look pretty strange used as a function.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Chris Huff <chr### [at] yahoocom> wrote:
: Another advantage could be the increased precision, aren't color_maps 
: limited to 255 levels of color?

  Says who?

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <386c87de@news.povray.org>, Nieminen Juha 
<war### [at] punarastascstutfi> wrote:

> Chris Huff <chr### [at] yahoocom> wrote:
> : Another advantage could be the increased precision, aren't color_maps 
> : limited to 255 levels of color?
> 
>   Says who?

I don't know. Which is why I didn't state it as a fact. :-)
I know they are limited to 255 entries, but I don't know how much 
precision a float value derived from a color_map would have. I haven't 
taken a close look at that part of the code. But the patterns can return 
double precision values, and they don't have to interpret a color_map to 
do so. This makes slightly less flexibility, you can't alter the 
waveform with a color_map, but could be a lot faster.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

You could try this code segment.
#declare P=6; /* this is the number of decimal Places to display*/
#declare CapColor= color <1,.9999999,.2222222,0,0>;
#warning "Vector <"     #warning str(CapColor.red     ,0,P)
#warning ", "           #warning str(CapColor.green   ,0,P)
#warning ", "           #warning str(CapColor.blue    ,0,P)
#warning ", "           #warning str(CapColor.filter  ,0,P)
#warning ", "           #warning str(CapColor.transmit,0,P)
#warning "> "

This gives some fun results if you dont use the key word "color"

Chris Huff wrote:
> 
> I don't know. Which is why I didn't state it as a fact. :-)
> I know they are limited to 255 entries, but I don't know how much
> precision a float value derived from a color_map would have. I haven't
> taken a close look at that part of the code. But the patterns can return
> double precision values, and they don't have to interpret a color_map to
> do so. This makes slightly less flexibility, you can't alter the
> waveform with a color_map, but could be a lot faster.
> 
> --
> Chris Huff
> e-mail: chr### [at] yahoocom
> Web page: http://chrishuff.dhs.org/

Post a reply to this message

mr.art <mr.### [at] gcinet> wrote:
: #warning "Vector <"     #warning str(CapColor.red     ,0,P)
: #warning ", "           #warning str(CapColor.green   ,0,P)
: #warning ", "           #warning str(CapColor.blue    ,0,P)
: #warning ", "           #warning str(CapColor.filter  ,0,P)
: #warning ", "           #warning str(CapColor.transmit,0,P)
: #warning "> "

  Take a look at the 'concat' function of povray.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

As this wasn't my work,( I found it in another post) I haven't
adjusted it much. Just added the P variable.

Nieminen Juha wrote:
> 
> mr.art <mr.### [at] gcinet> wrote:
> : #warning "Vector <"     #warning str(CapColor.red     ,0,P)
> : #warning ", "           #warning str(CapColor.green   ,0,P)
> : #warning ", "           #warning str(CapColor.blue    ,0,P)
> : #warning ", "           #warning str(CapColor.filter  ,0,P)
> : #warning ", "           #warning str(CapColor.transmit,0,P)
> : #warning "> "
> 
>   Take a look at the 'concat' function of povray.
> 
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

First Thing, yes using patterns directly would be slightly faster
by removing per lookup approximately 

10 multipulcations / divisions
5 add/subs
2 compares
1 or 2 function calls

(this is done from my color conversion so you can use red/green hf
images, and blending of colors of evalpigment, this is off the top of my
head so 
for sake of argument lets triple these numbers)

How ever most patterns use noise which is a couple of magnitudes of more
adds and muls.

so depending on how much turbulence and which pattern you gain anywhere
from 0.01% to 50% gain, the 50% gain is if you use gradient with
no turbulence, might as well use y-floor(y) and possibly get an even
faster speed gain. but i would stay 99% of the functions the speed gain
would be less then %1

note on precision: colors do use floats, but some compilers reduce
doubles
to floats when they are told todo fast math, personally i compile
without fast math.

without the source in front of me i'm not sure if eval pattern does the
turbulence or not, however i don't see it a hard addition, just a
tedious
one. (as pattern in heightfields uses pigments too if i remember right
when i was trying to add a cap to 0..1 capability to use my fractal
terrains i haven't yet ben able to make sure it returns values between 0
and 1 .. i degress)

Chris Huff wrote:
> 
> In article <386c87de@news.povray.org>, Nieminen Juha
> <war### [at] punarastascstutfi> wrote:
> 
> > Chris Huff <chr### [at] yahoocom> wrote:
> > : Another advantage could be the increased precision, aren't color_maps
> > : limited to 255 levels of color?
> >
> >   Says who?
> 
> I don't know. Which is why I didn't state it as a fact. :-)
> I know they are limited to 255 entries, but I don't know how much
> precision a float value derived from a color_map would have. I haven't
> taken a close look at that part of the code. But the patterns can return
> double precision values, and they don't have to interpret a color_map to
> do so. This makes slightly less flexibility, you can't alter the
> waveform with a color_map, but could be a lot faster.
> 
> --
> Chris Huff
> e-mail: chr### [at] yahoocom
> Web page: http://chrishuff.dhs.org/

Post a reply to this message

In article <386E7D29.2BAD5F3B@xenoarch.com>, Matthew Corey Brown 
<mcb### [at] xenoarchcom> wrote:

> First Thing, yes using patterns directly would be slightly faster
> by removing per lookup approximately 
> 
> 10 multipulcations / divisions
> 5 add/subs
> 2 compares
> 1 or 2 function calls
> 
> (this is done from my color conversion so you can use red/green hf
> images, and blending of colors of evalpigment, this is off the top of my
> head so 
> for sake of argument lets triple these numbers)
> 
> How ever most patterns use noise which is a couple of magnitudes of more
> adds and muls.
> 
> so depending on how much turbulence and which pattern you gain anywhere
> from 0.01% to 50% gain, the 50% gain is if you use gradient with
> no turbulence, might as well use y-floor(y) and possibly get an even
> faster speed gain. but i would stay 99% of the functions the speed gain
> would be less then %1

Hmm, are you sure the numbers would be that small? Per call, perhaps, 
but how many times are those functions used? I suppose the only way to 
get a real answer would be to add the function and run some tests. Does 
anyone have some hints on adding an isosurface function?


> note on precision: colors do use floats, but some compilers reduce
> doubles
> to floats when they are told todo fast math, personally i compile
> without fast math.

Well, when I said that, I was thinking about the precision of the color 
blending code, which I don't understand at all.


> without the source in front of me i'm not sure if eval pattern does the
> turbulence or not

I am fairly certain it does, as well as the other warps and transforms.
As I remember, those are handled in Eval_TPat(), and my patch is 
basically an interface to this function.

I am having school break now, and just got back from checking out a 
possible new job(pulling traps at a target shooting range nearby), so I 
will have some free time. I will take a closer look at that color_map 
code, I have been putting that off long enough.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Chris Huff wrote:
> 
> In article <386E7D29.2BAD5F3B@xenoarch.com>, Matthew Corey Brown
> <mcb### [at] xenoarchcom> wrote:
> > so depending on how much turbulence and which pattern you gain 
> > anywhere
> > from 0.01% to 50% gain, the 50% gain is if you use gradient with
> > no turbulence, might as well use y-floor(y) and possibly get an even
> > faster speed gain. but i would stay 99% of the functions the speed
> > gain would be less then %1
> 
> Hmm, are you sure the numbers would be that small? Per call, perhaps,
> but how many times are those functions used? I suppose the only way to
> get a real answer would be to add the function and run some tests. Does
> anyone have some hints on adding an isosurface function?
> 
Not 100% sure but close, noise and especially turbulence has
over a hundred operands a piece (as turbulence calls noise a couple of
times)

yes there is an array in iso_func.c with a string and the function name,

the parse function calls a lookup function to put a pointer to the
function into the function data struct, do a search on isopigment of the
source, its been a year since i wrote it heh, maybe one of the other
patchers that have added more functions then I could correct me and add
the missing data.

> > note on precision: colors do use floats, but some compilers reduce
> > doubles
> > to floats when they are told todo fast math, personally i compile
> > without fast math.
> 
> Well, when I said that, I was thinking about the precision of the color
> blending code, which I don't understand at all.
> 
Basically it does this 
T=eval_pattern
CM[x] < T > CM[x+1] (finding x is fast if you have a color map with 2
entries ie {[0 rgb 0][1 rgb 1]} )

rat = (T-CM[x])/(CM[x+1]-CM[x])
then Color=Color[x]*(1-rat)+Color[x+1]*rat

umm i wish i could put it in english but it does a weighted average of
the colors, based on distance of T from the closest entries on the color
map.

A rule of thumb on precsion from basic science lab classes:
The precsion of your final value is the precsion of the coursest data
point.. ie in base 10
2.05 * 1.00000345 = 2.05

but floats are done in binary so its binarary precsion and not decimal
precsion as is done in science. So since the data uses floats or higher
and its all floating point code then the precsion is float.. the color
itself.

> --
> Chris Huff
> e-mail: chr### [at] yahoocom
> Web page: http://chrishuff.dhs.org/

Post a reply to this message

In article <386EA3D7.1A53D563@xenoarch.com>, Matthew Corey Brown - 
XenoArch <mcb### [at] xenoarchcom> wrote:

> yes there is an array in iso_func.c with a string and the function name,
> 
> the parse function calls a lookup function to put a pointer to the
> function into the function data struct, do a search on isopigment of the
> source, its been a year since i wrote it heh, maybe one of the other
> patchers that have added more functions then I could correct me and add
> the missing data.

Hmn, thanks for the help.


> > Well, when I said that, I was thinking about the precision of the color
> > blending code, which I don't understand at all.
> > 
> Basically it does this 
> T=eval_pattern
> CM[x] < T > CM[x+1] (finding x is fast if you have a color map with 2
> entries ie {[0 rgb 0][1 rgb 1]} )
> 
> rat = (T-CM[x])/(CM[x+1]-CM[x])
> then Color=Color[x]*(1-rat)+Color[x+1]*rat
> 
> umm i wish i could put it in english but it does a weighted average of
> the colors, based on distance of T from the closest entries on the color
> map.

Thanks, sounds somewhat similar to my z-buffer code.
If you put it into english, I probably couldn't understand it, no matter 
how well you phrased it. :-)
Not that I have problems with english, it is the only human language I 
know(although I can barely understand some written spanish, and can get 
the sense of some other languages that are related closely enough). I 
just find this type of explanation a lot easier to understand.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message