I forgot to mention that in the Qsc() macro, you should
enclose the returned expression in parentheses.


Like this:


#macro Qsc(Q)

  (Q.x*Q.x + Q.y*Q.y + Q.z*Q.z + Q.t*Q.t)

#end // macro Qsc


Tor Olav

Post a reply to this message

Tor Olav Kristensen <tor_olav_kCURLYAhotmail.com> wrote in 
news:Xns### [at] 204213191226:

> [...]
> Note that in this expression:
> [...]

Wow, thanks for the great advice and explanations.  I did figure out that 
the (c?a:b) was evaluating both expressions and the AxAn() divide error, 
sorry to have you go through my code as well, I should have just taken a 
moment to figured those out earlier.

Thanks for your other suggestions (variables, epsilon, code, etc.), much 
appreciated,  I will use most of them.  I'm adding a few more rotation 
macros and will revise all of my variables names.

As for the log() in the Qln(), it's operating on the scalar, and I'm pretty 
sure that's what it should be, but don't make me explain quaternions I 
still don't quite understand them.

Post a reply to this message

Tor Olav Kristensen <tor_olav_kCURLYAhotmail.com> wrote in 
news:Xns### [at] 204213191226:

>   #local R = f_r(Q.x, Q.y, Q.z);

Is "f_fr(x,y,z)" much faster than "sqrt( x*x + y*y + z*z )"?  I'm wondering 
because I don't find it reads better and perhaps the overhead of including 
"functions.inc" (if one wasn't using it in the first place) might not make 
it that beneficial?

Post a reply to this message

None <Non### [at] onca> wrote in news:Xns### [at] 204213191226:

> Tor Olav Kristensen <tor_olav_kCURLYAhotmail.com> wrote in 
> news:Xns### [at] 204213191226:
> 
>> [...]
>> Note that in this expression:
>> [...]
> 
> Wow, thanks for the great advice and explanations.  I did figure out
> that the (c?a:b) was evaluating both expressions and the AxAn() divide
> error, sorry to have you go through my code as well, I should have
> just taken a moment to figured those out earlier.
>
> Thanks for your other suggestions (variables, epsilon, code, etc.),
> much appreciated,  I will use most of them.  I'm adding a few more
> rotation macros and will revise all of my variables names.

I'm glad that I could help you  =)


> As for the log() in the Qln(), it's operating on the scalar, and I'm
> pretty sure that's what it should be, but don't make me explain
> quaternions I still don't quite understand them.

Hmmmm... I hope that you are aware that in POV-Ray v3.5 log()
is no longer the natural logarithm function. (It is now the
base 10 logarithm.)

To get the natural logarithm in POV-Ray v3.5, simply use the
ln() function.

See:
http://www.povray.org/documentation/view/24/


Tor Olav

Post a reply to this message

None <Non### [at] onca> wrote in news:Xns### [at] 204213191226:

> Tor Olav Kristensen <tor_olav_kCURLYAhotmail.com> wrote in 
> news:Xns### [at] 204213191226:
> 
>>   #local R = f_r(Q.x, Q.y, Q.z);
> 
> Is "f_fr(x,y,z)" much faster than "sqrt( x*x + y*y + z*z )"?  I'm
> wondering because I don't find it reads better and perhaps the
> overhead of including "functions.inc" (if one wasn't using it in the
> first place) might not make it that beneficial?

Since f_r() is a built in function in POV-Ray, it should be a
little bit faster. But I doubt that you will be able to measure
any significant speed increase with it in your macros.

Here is how it is declared in functions.inc:

#declare f_r = function { internal(57) }

I just suggested using it because _I_ find it easy to read.
Maybe this comes from my extensive use of it within the
functions for my isosurfaces...

(Note that it isn't much overhead for POV-Ray to include
functions.inc.)



Tor Olav

Post a reply to this message

Tor Olav Kristensen <tor_olav_kCURLYAhotmail.com> wrote in 
news:Xns### [at] 204213191226:

> Hmmmm... I hope that you are aware that in POV-Ray v3.5 log()
> is no longer the natural logarithm function. (It is now the
> base 10 logarithm.)
> 
> To get the natural logarithm in POV-Ray v3.5, simply use the
> ln() function.
> 
> See:
> http://www.povray.org/documentation/view/24/


OMG, I don't know what I was smoking yesterday, yikes.  I did assume log() 
was the natural logarithm, I was thinking C math.h.  I don't know why it 
didn't click when you mentionned ln(), sorry.

Thanks for pointing that out (again), wow I feel silly.

Post a reply to this message

Tor Olav Kristensen <tor_olav_kCURLYAhotmail.com> wrote in 
news:Xns### [at] 204213191226:

> Since f_r() is a built in function in POV-Ray, it should be a
> little bit faster. But I doubt that you will be able to measure
> any significant speed increase with it in your macros.
> [...]

Thanks for clearing that.  Oh, and just in case you may think I'm not 
reading your suggestions (after that ln() thing), I feel I need to 
explain why I opted not to use some of your suggestions:

Let's take for example:
  #if (R > 0)
    #local S = sin(R)/R;
  #else
    #local S = 0;
  #end // if

  (Et*<S*Q.x, S*Q.y, S*Q.z, cos(R)>)

I've decided to leave it as:
  #if (R > 0)
    #local S = ET*sin(R)/R;
  #else
    #local S = 0;
  #end
  <S*Q.x,S*Q.y,S*Q.z,ET*cos(R)>

Simply for performance issues.  I realize it's not much, but the first 
one will have two more multiplications if R>0 and will have three more 
multiplications if R <= 0.  And perhaps, it's simply a coding style as 
well.

But I do appreciate any and all input, it helps.

Post a reply to this message

None <Non### [at] onca> wrote in news:Xns### [at] 204213191226:

> Tor Olav Kristensen <tor_olav_kCURLYAhotmail.com> wrote in 
> news:Xns### [at] 204213191226:
> 
>> Since f_r() is a built in function in POV-Ray, it should be a
>> little bit faster. But I doubt that you will be able to measure
>> any significant speed increase with it in your macros.
>> [...]
> 
> Thanks for clearing that.  Oh, and just in case you may think I'm not 
> reading your suggestions (after that ln() thing), I feel I need to 
> explain why I opted not to use some of your suggestions:
> 
> Let's take for example:
>   #if (R > 0)
>     #local S = sin(R)/R;
>   #else
>     #local S = 0;
>   #end // if
> 
>   (Et*<S*Q.x, S*Q.y, S*Q.z, cos(R)>)
> 
> I've decided to leave it as:
>   #if (R > 0)
>     #local S = ET*sin(R)/R;
>   #else
>     #local S = 0;
>   #end
>   <S*Q.x,S*Q.y,S*Q.z,ET*cos(R)>
> 
> Simply for performance issues.  I realize it's not much, but the first 
> one will have two more multiplications if R>0 and will have three more 
> multiplications if R <= 0.  And perhaps, it's simply a coding style as 
> well.
> 
> But I do appreciate any and all input, it helps.

I see what you mean. - But I have experienced that
the number of mathematical operations within POV-
Ray macros is not necessarily a good measure for
how fast or slow the macros will be. (Maybe this is
because it is a parsed languge ;-)

While coding I sometimes tend to sacrifice a little
performance in attempts to get more elegant code.

(If the problem is very complex I always go for
readability and elegance. This makes it easy to
discover bugs. Although this often makes the code
grow for a while, it makes it easy for me in the
later stages to see how it can be simplified and
shaved down to a minimum.)


Tor Olav

Post a reply to this message