|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |