 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tag povrayorg> wrote in news:3d9b0160@news.povray.org
>> Just for couriosity I will modify it's code to work as
>> clip(0,1,x)
> Why don't you just make another function which does that instead of
> modifying the standard function?
just for a moment, before I learn how to add own function to syntax parser
>> in with file should I look ?
> I said "math.inc", didn't I?
source code
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rafal 'Raf256' Maj <raf### [at] raf256com> wrote:
>> I said "math.inc", didn't I?
> source code
It will be hard to modify the clip() function in the source code, as
it's in defined in math.inc, not in the source code. :)
--
#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:3d9b06f0@news.povray.org
>> source code
> It will be hard to modify the clip() function in the source code, as
> it's in defined in math.inc, not in the source code. :)
#declare clip = function (V, Mn, Mx) {min(Mx, max(V, Mn))}
woooow... this must be terrible slow in compare to hard-coded function.
With function takes 3 float argumetns, return float and is a real function
(not #decare/#macro) ?
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rafal 'Raf256' Maj <raf### [at] raf256com> wrote:
> #declare clip = function (V, Mn, Mx) {min(Mx, max(V, Mn))}
> woooow... this must be terrible slow in compare to hard-coded function.
Do you want me to preach again about the advantages of using a macro or
function compared to a hard-coded feature?
I can't imagine a scene where the speed-difference would be noticeable.
(Of course you could invent rather artificial examples, but I'm talking
about practical scenes.)
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote in news:3d9b0a4f@news.povray.org
> I can't imagine a scene where the speed-difference would be noticeable.
> (Of course you could invent rather artificial examples, but I'm talking
> about practical scenes.)
Maybe isosurface using only one clip() in it's pattern ?
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Rafal 'Raf256' Maj" <raf### [at] raf256com> schrieb im Newsbeitrag
news:Xns### [at] 204213191226...
> "Marc-Hendrik Bremer" <Mar### [at] t-onlinede> wrote in
> news:3d9aec64@news.povray.org
>
> > There is really no need to build in everythink in the
> > Pov-Code.
>
> speed ?
> We have i.e. 1 room (inverted box) inside with we have camera, lightsource
> and i.e. white sphere.
> Box is covered with function with 1-3 constructions like
> max(0,min(1,x+y...))
>
I don't understand what you want to do here (covered? with a pigment, a
normal? an isosurface)? If a color_map of some sort is used, then there's no
need to use a clipping function at all.
> And now we add radiosity - fo reach pixel formula min(max(... must be
> counted about 10..50 times depending on radiosity setting - that can
> probably give 5-15% of render time lost. Hmm I guess I should just add
this
> minmax() function and see is speed improvment notacible :)
The speed increase will strongly depend on the other thinks you use in the
scene. A quick 'n dirty test gave me 0,0000073 seconds for one function call
parsed and evaluated. I don't think, that pov will have to parse the
function for every ray if you use it in a pattern or even an isosurface
(don't know for sure though).
Implement your minmax()-function, if you want to, but if you need only one
day to do it, you will have to use your function quite a lot to get your
time back :-) I'm no programmer at all, so I'm happy about everything that
makes "my life" easier - but if the parser takes longer and longer to parse
even a simple scene, because there are too many keywords to check, it
doesn't make my life easier but harder.
Greetings,
Marc-Hendrik
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <Xns### [at] 204213191226>,
"Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:
> Maybe isosurface using only one clip() in it's pattern ?
It'd either be so fast it wouldn't matter or the clip would take such a
small fraction of total evaluation time you wouldn't notice a difference.
You really seem to have no idea how optimization is done...you optimize
slow parts, not simple parts. The clip() function is likely to take only
a very tiny amount of total rendering time, and then in only a small
percentage of scenes. It would be a waste of time to implement it
internally, the time would be better spent with other optimizations,
maybe something like allowing inlining of functions, where POV would
expand a clip() call to the min/max() calls. Or more powerful macros.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 02 Oct 2002 09:05:24 -0400, Rafal 'Raf256' Maj quoth:
> "Marc-Hendrik Bremer" <Mar### [at] t-onlinede> wrote in
> news:3d9aec64@news.povray.org
>
>> There is really no need to build in everythink in the Pov-Code.
>
> speed ?
> We have i.e. 1 room (inverted box) inside with we have camera,
> lightsource and i.e. white sphere.
> Box is covered with function with 1-3 constructions like
> max(0,min(1,x+y...))
>
> And now we add radiosity - fo reach pixel formula min(max(... must be
> counted about 10..50 times depending on radiosity setting - that can
> probably give 5-15% of render time lost. Hmm I guess I should just add
> this minmax() function and see is speed improvment notacible :)
You won't gain much speed. For example, I once converted a complicated
isosurface function for clouds to an internal pattern, and only got a
speedup of about 10%. For a simple function such as clip(), you probably
won't be able to measure the speedup.
--
Mark
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff <chr### [at] maccom> wrote in news:chrishuff-
386### [at] netplexaussieorg
>> Maybe isosurface using only one clip() in it's pattern ?
> It'd either be so fast it wouldn't matter or the clip would take such a
> small fraction of total evaluation time you wouldn't notice a difference.
So therefore I don't expect any medal of honor from POV-Team for writting
it ;) but this change would prouce a little bit better, or worse POV code ?
It would be same fast, or little bit faster AFAIK ?
> You really seem to have no idea how optimization is done...
And I want to get an idea i.e. by doing some (little) optimization myself.
> a very tiny amount of total rendering time, and then in only a small
> percentage of scenes. It would be a waste of time to implement it
> internally, the time would be better spent with other optimizations,
It's my time so I think I will decide with optimization I want to
implement, ok :) ?
> maybe something like allowing inlining of functions, where POV would
> expand a clip() call to the min/max() calls. Or more powerful macros.
Ok, but I do NOT want to code it ok ? I think I will implement a clip() for
a "warm-up" and to get better along with pov's sources. Maybe inlining
alsow - someday... :)
With files (and best - function names/lines) :
* have formulas for some literal functions like pow(a,b) ? (I want to see
how it's done)
* now what should I do to add my own function (real-function) like i.e.
my_function(a,b) and I want it's formula to be i.e. (a+b) for tests
reasons. I quess I will have to change parser code, and functions code ?
* now I want to add function like my_function(a,b,c) - it should be very
simmilar probably ?
TIA
--
#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:
> Ok, but I do NOT want to code it ok ? I think I will implement a clip() for
> a "warm-up" and to get better along with pov's sources. Maybe inlining
> alsow - someday... :)
Never with the current code, I am sure...
> With files (and best - function names/lines) :
>
> * have formulas for some literal functions like pow(a,b) ? (I want to see
> how it's done)
>
> * now what should I do to add my own function (real-function) like i.e.
> my_function(a,b) and I want it's formula to be i.e. (a+b) for tests
> reasons. I quess I will have to change parser code, and functions code ?
>
> * now I want to add function like my_function(a,b,c) - it should be very
> simmilar probably ?
<http://www.abx.art.pl/pov/patches/f_triangle.php>
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
