 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
POV 3.5 RC1 Win installation
===========================================
HFComputeNormal()
===========================================
Not used but still (commented) in include file
===========================================
HFCreate_()
===========================================
1. Unused Type parameter in HFCreate_ macro.
2. Putting comment inside loop can slow down execution I think
3. First loop use two locals but can be realised with only one.
Here is my version of first loop with speed optimization
but without annoying #debug
#if (Smooth)
// CALCULATION OF NORMAL VECTOR
// We don't vnormalize the vectors from the current center point
// to its neightbor points because we want a weighted average
// where bigger areas contribute more. This also means that the
// center point can be left out completely of the calculations:
#local NArr = array[xRes][zRes]
#local J = 1;
#while (J<=xRes)
#local K = 1;
#while (K<=zRes)
#local VC =
vcross(vnormalize(PArr[J][K+1]-PArr[J][K-1]),vnormalize(PArr[J+1][K]-PArr[J-1][K]));
#declare NArr[J-1][K-1] = ( VC.gray=0 ? 333*x : vnormalize(VC) );
#declare K = K+1;
#end
#declare J = J+1;
#end
#end
===========================================
HF_Square(), HF_Sphere(), HF_Cylinder(), HF_Torus()
===========================================
I think that content of loop can be optimized. to remove jumping for conditions.
For example content for HS_Square could be:
CURRENTLY:
#local UV = <(J-1)/(xRes-1),0,(K-1)/(zRes-1)>;
#local P = (UV*Ext*<1,0,1> + MnExt);
#if (UVmap)
#local H = Function(UV.x, UV.z, 0);
#else
#local H = Function(P.x, P.y, P.z);
#end
#declare PArr[J][K] = P + H*Ext*y;
MY REPLACEMENT:
#local UV = <(J-1)/(xRes-1),0,(K-1)/(zRes-1)>;
#local P = (UV*Ext*<1,0,1> + MnExt);
#declare PArr[J][K] = P +
Function(UVmap?UV.x:P.x,UVmap?UV.z:P.y,UVmap?0:P.z)*Ext*y;
===========================================
scenes\incdemo\shapes.pov
===========================================
Example shows dark areas on edges of meshes.
It is probably result of low resolution (and direction of normals).
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> ===========================================
> HFComputeNormal()
> ===========================================
> Not used but still (commented) in include file
I'll delete it.
> ===========================================
> HFCreate_()
> ===========================================
> 1. Unused Type parameter in HFCreate_ macro.
It was supposed to be "FileName" instead of "Type", but I see now that no
parameter is needed.
> 2. Putting comment inside loop can slow down
> execution I think
A test shows that you're right, so I'll move the comments outside of the
loops. However, normally it's preferred that you test speed optimizations
yourself before you suggest them.
> 3. First loop use two locals but can be realised with only one.
> Here is my version of first loop with speed optimization
> but without annoying #debug
Whoops, the debug is a leftover from my tests. Don't know how it got
there...
Actually, the test to see if the vector has zero length is also a leftover
from the debugging. Currently the macro should never reach that part anyway,
so it can be removed completely. I will do so.
If you have actually seen the debug being used in some of your tests, then
it is due to an error, and then I would be very interested in that.
> ===========================================
> HF_Square(), HF_Sphere(), HF_Cylinder(), HF_Torus()
> ===========================================
> I think that content of loop can be optimized. to
> remove jumping for conditions.
I can't see any significant improvement with your version, and it's more
difficult to read.
> ===========================================
> scenes\incdemo\shapes.pov
> ===========================================
>
> Example shows dark areas on edges of meshes.
> It is probably result of low resolution (and
> direction of normals).
That's just how smooth triangles are. There's nothing I can do about it that
won't significantly increase the parse time of the demo scene.
Thanks for your input,
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated Mar 19)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Ring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 16 Apr 2002 21:27:42 +0200, "Rune" <run### [at] mobilixnet dk>
wrote:
> However, normally it's preferred that you test speed optimizations
> yourself before you suggest them.
I know, but it was difficoult in this case becouse I worked with printed
version of HF* macros :-)
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 16 Apr 2002 21:27:42 +0200, "Rune" <run### [at] mobilixnetdk>
wrote:
> > 3. First loop use two locals but can be realised with only one.
> > Here is my version of first loop with speed optimization
> > but without annoying #debug
>
> Whoops, the debug is a leftover from my tests. Don't know how it got
> there...
>
> Actually, the test to see if the vector has zero length is also a leftover
> from the debugging. Currently the macro should never reach that part anyway,
> so it can be removed completely. I will do so.
Your changes seems better now except AFAIK you not necessary normalize vector
before calculating cross product (you only inrease floating point error at
this moment) in HFCreate_() macro. Consider below example:
#include "strings"
#local A=<126,45,33>;
#local B=<63,12,7>/1000;
#declare C=vnormalize(vcross(vnormalize(A),vnormalize(B)));
#declare D=vnormalize(vcross(A,B));
#warning VStr(C)
#warning VStr(D)
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Your changes seems better now except AFAIK you not
> necessary normalize vector before calculating cross
> product
Sheesh, I knew that! How could I forget?
Thanks for the tip! :)
Anyway, I have rewritten the HF macros completely for the next beta.
They now work with mesh2 instead of mesh. Maybe you would like to have a
look at them?
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated Apr 14)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Ring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 22 Apr 2002 20:55:31 +0200, "Rune" <run### [at] mobilixnetdk>
wrote:
> W?odzimierz ABX Skiba wrote:
> > Your changes seems better now except AFAIK you not
> > necessary normalize vector before calculating cross
> > product
>
> Sheesh, I knew that! How could I forget?
> Anyway, I have rewritten the HF macros completely for the next beta.
> They now work with mesh2 instead of mesh. Maybe you would like to have a
> look at them?
Yes. I looked at this and ... You made exactly the same mistake as above. :)
And additional note to mesh2 creation process. You can remove condition inside
loops in HFCreate_(). Just don't close and don't open #write directive before
and after condition. Look for changed case of first loop of HFCreate_():
#if(WriteFile)
#fopen _HFMACRO_OUTPUT_FILE FileName write
#write(_HFMACRO_OUTPUT_FILE,"mesh2 {\nvertex_vectors {",xRes*zRes,",\n",
#else
mesh2 {vertex_vectors{xRes*zRes,
#end
#local J = 1;
#while (J<=xRes)
#local K = 1;
#while (K<=zRes)
PArr[J][K]
#declare K = K+1;
#end
#declare J = J+1;
#end
#if(WriteFile)
,"}\n")
#else
}
#end
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Yes. I looked at this and ... You made
> exactly the same mistake as above. :)
Sigh, I really must learn to remember this!
> And additional note to mesh2 creation process.
> You can remove condition inside loops in HFCreate_().
> Just don't close and don't open #write directive before
> and after condition.
Very clever! With this fixed four places, the speed increase is actually
noticeable. :)
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated Apr 14)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Ring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
