POV 3.5 b 10, win

I play with HF_* macros from shapes.inc.

In macro HF_Square there are two parameters MnExt and MxExt. They are described
as corners of box containing heighfield. Afaik that's not true. Only x and z
components are considered. Somehow height of this heighfield is always 1.
The problem imo is here:

         #local A = A + y*Function(A.x, A.y, A.z);
         #local B = B + y*Function(B.x, B.y, B.z);
         #local C = C + y*Function(C.x, C.y, C.z);
         #local D = D + y*Function(D.x, D.y, D.z);

should be probably:

         #local A = A + y*Function(A.x, A.y, A.z)*(MxExt - MnExt).y;
         #local B = B + y*Function(B.x, B.y, B.z)*(MxExt - MnExt).y;
         #local C = C + y*Function(C.x, C.y, C.z)*(MxExt - MnExt).y;
         #local D = D + y*Function(D.x, D.y, D.z)*(MxExt - MnExt).y;

Also expression (MxExt - MnExt) is used many times inside loop and inside
another loop. Why not make it faster with additional local variables ?.

Also I wonder why points are not stored inside arrays. It could be 4 times
faster imo.

Also I have general doubt connected with hf_* macros. IMO Typical thinking of
mapping is connected with putting image/function on square <0,0> <1,1> and
making conversion of coordinates from 2D to 3D (or 3D to 2D other way). Typical
heighfield works this way. Mapping of images works this way. Afaik warps works
this way. But hf_macros use different strategy on this subject. They not
translated 3D (object space) to 2D (mapped function). This makes little harder
thinking about mapping image via function on cylinder. It is not impossible but
I feel hard for some people. Of course it is feature request so don't read
above... ;)

ABX

Post a reply to this message