Came up with it today (Dec. 29). I know it's not a significant improvement,
but at least it shouldn't hurt. With the current implementation, it takes 10
multiplications and 3 additions/subtractions. My version shaves 3
multiplications off the process... not to mention that it eliminates a bunch
of temporaries, which I believe were only there for self-documentation, when
instead you could simply spell it out in the comments.

DBL quilt_cubic(DBL t, DBL p1, DBL p2)
{
 DBL it = 1.0 - t;

 return (t * (t*t + 3.0*it*(it*p1 + t*p2) ) * INV_SQRT_3_4);
}

--
Anthony Bennett

Post a reply to this message

In article <3e0faee1@news.povray.org>, "Tony[B]" <ben### [at] catholicorg> 
wrote:

> Came up with it today (Dec. 29). I know it's not a significant improvement,
> but at least it shouldn't hurt. With the current implementation, it takes 10
> multiplications and 3 additions/subtractions. My version shaves 3
> multiplications off the process... not to mention that it eliminates a bunch
> of temporaries, which I believe were only there for self-documentation, when
> instead you could simply spell it out in the comments.

A lot of the patterns are like that...I think they were there to help 
old compilers optimize somehow. They don't make much sense otherwise, my 
favorite example:
static DBL onion_pattern (VECTOR EPoint)
{
  /* The variable noise is not used as noise in this function */

  register DBL noise;

Writing a 50-some character comment instead of changing a 5 character 
variable name...I hope there was a really good reason to use the name 
"noise".
Some others are to prevent duplicated calculations when passed to macros 
like Sqr().

There are also inconsistencies and inefficiencies in the range 
clipping...the pattern code could be greatly improved.

While you are at it, the wood pattern takes the 3D length of a vector 
where 2D would suffice...you could save a multiplication and addition. 
There are "bigger fish to fry" though...making these patterns as fast as 
possible will only speed POV a little. An algorithm improvement 
elsewhere (like transparency calculation) could accomplish much more.

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

> A lot of the patterns are like that...I think they were there to help
> old compilers optimize somehow.

I know what you mean. And then there are comments such as this one:

  /* This form didn't work with Zortech 386 compiler */
  /* value = Sqr((sin(x)+sin(y)+sin(z))/3); */
  /* So we break it down. */

I think we can move past this now... right?

> There are also inconsistencies and inefficiencies in the range
> clipping...the pattern code could be greatly improved.

I hope to slowly work my way through it and find more to fix.

> There are "bigger fish to fry" though...making these patterns as fast as
> possible will only speed POV a little. An algorithm improvement
> elsewhere (like transparency calculation) could accomplish much more.

Yes, that's true, I admit it. The sad part is that since I have trouble
comprehending other parts of the code, this is about as big a contribution
as I can make. :(

--
Anthony Bennett

Post a reply to this message

Tony[B] wrote:
> I know what you mean. And then there are comments such as this one:
>
>   /* This form didn't work with Zortech 386 compiler */
>   /* value = Sqr((sin(x)+sin(y)+sin(z))/3); */
>   /* So we break it down. */
>
> I think we can move past this now... right?

Noooo!

Don't you dare render my Zortech 386 obsolete!
-- 

Rick

Kitty5 NewMedia http://Kitty5.co.uk
POV-Ray News & Resources http://Povray.co.uk
TEL : +44 (01270) 501101 - FAX : +44 (01270) 251105 - ICQ : 15776037

PGP Public Key
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x231E1CEA



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.434 / Virus Database: 243 - Release Date: 25/12/2002

Post a reply to this message

Christopher James Huff <chr### [at] maccom> wrote:
> There are "bigger fish to fry" though...making these patterns as fast as 
> possible will only speed POV a little. An algorithm improvement 
> elsewhere (like transparency calculation) could accomplish much more.

  On the other hand, if someone has the free time and is willing to do it,
then why not?
  A 0.1% speed improvement is better than a 0% speed improvement. :)

  (Of course we have to remember that if these things are going to be in
the official POV-Ray, they will have to be carefully studies by a pov-team
member, who might not have that much time and willingness.)

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

>   On the other hand, if someone has the free time and is willing to do it,
> then why not?
>   A 0.1% speed improvement is better than a 0% speed improvement. :)

Hear-hear! :)

>   (Of course we have to remember that if these things are going to be in
> the official POV-Ray, they will have to be carefully studies by a pov-team
> member, who might not have that much time and willingness.)

I have a simple solution to that: make me a POV-Team member. ^_^

--
Anthony Bennett

Post a reply to this message