|
 |
RC4 for Win
Currently HF Macros works only when resolution <xRes,zRes> is specified with
xRes=zRes. For xRes<>zRes it stops parsing with error in face_indices. It is
becouse little but important mistake in last loop of HFCreate_() macro:
#local A = (J )+(K )*zRes;
#local B = (J+1)+(K )*zRes;
#local C = (J+1)+(K+1)*zRes;
#local D = (J )+(K+1)*zRes;
<A,B,C>,<A,C,D>,
should be:
#local A = (J )*zRes+(K );
#local B = (J+1)*zRes+(K );
#local C = (J+1)*zRes+(K+1);
#local D = (J )*zRes+(K+1);
<A,B,C>,<A,C,D>,
But since I was in this part I started to optimize this stuff. Note that
optimized part is exactly the same as:
#local A = (J )*zRes+(K );
#local B = A + zRes;
#local C = A + zRes + 1;
#local D = A + 1;
<A,B,C>,<A,C,D>,
But then it is exactly the same as:
#local A = J*zRes+K;
<A,A+zRes,A+zRes+1>,<A,A+zRes+1,A+1>,
But then it is exactly the same as:
#local A = J*zRes+K;
<0,zRes,zRes+1>+A,<0,zRes+1,1>+A,
But then it is exactly the same as (extending quoted part to whole loop):
#local F1=<0,zRes,zRes+1>;
#local F2=<0,zRes+1,1>;
#local J=0;
#while (J<xRes-1)
#local K=0;
#while (K<zRes-1)
#local A=J*zRes+K;
F1+A,F2+A,
#local K=K+1;
#end
#local J=J+1;
#end
But then A contains constant part J*zRes so why not move it before K-loop :
#local F1=<0,zRes,zRes+1>;
#local F2=<0,zRes+1,1>;
#local J = 0;
#while (J<xRes-1)
#local A = J*zRes;
#local K = 0;
#while (K<zRes-1)
F1+A,F2+A,
#local A = A+1;
#local K = K+1;
#end
#local J = J+1;
#end
But then do we really need two indexes A and K ?
#local F1=<0,zRes,zRes+1>;
#local F2=<0,zRes+1,1>;
#local J=0;
#while (J<xRes-1)
#local A=J*zRes;
#while (mod(A+1,zRes))
F1+A,F2+A,
#local A=A+1;
#end
#local J=J+1;
#end
Now it is little less readable but in my tests decreased parsing time from 36
seconds to 32 seconds. So let's look into two other loops in HFCreate_. Do we
really need to assign exported value to variable and then export it and forget
variable ? Can't we remove assigment ?
#local Nvect =
vnormalize(vcross(
PArr[J][K+1]-PArr[J][K-1],
PArr[J+1][K]-PArr[J-1][K]
));
Nvect,
could be just:
vnormalize(vcross(
PArr[J][K+1]-PArr[J][K-1],
PArr[J+1][K]-PArr[J-1][K]
)),
and
#local UVvect = <(J-1)/(xRes-1),(K-1)/(zRes-1)>;
UVvect,
could be just:
<(J-1)/(xRes-1),(K-1)/(zRes-1)>,
This change decreased parsing time for next 2 seconds. So alltogether I saved
~11% of parsing. I measured time of parsing scenes/incdemo/shapes.pov. I have
also little suggestion to this file. Perhaps could be good to additionaly
present UV-mapping on those macros. Just change apropriate parameter of macros
and change pigment{rgb1} to something like pigment{checker scale .1}.
ABX
Post a reply to this message
|
|
|
|
[About a bug, maybe he is right, I do not know]
> #local A = (J )*zRes+(K );
> #local B = (J+1)*zRes+(K );
> #local C = (J+1)*zRes+(K+1);
> #local D = (J )*zRes+(K+1);
> <A,B,C>,<A,C,D>,
> But since I was in this part I started to optimize this stuff. Note that
> optimized part is exactly the same as:
> #local A = (J )*zRes+(K );
> #local B = A + zRes;
> #local C = A + zRes + 1;
> #local D = A + 1;
> <A,B,C>,<A,C,D>,
I do not agree.
Mathematically, you are correct.
But Computationaly, you may end up with overlapping part and holes,
because the way you compute the coordinates are not always
exactly the same when you are iterating in the loop.
Maybe I'm just paranoid.
Post a reply to this message
|
|
com> wrote: