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

wrote:
> POV 3.5 b 10, win

Oh, I forgot.

Connect_Spheres() and Round_Cone2() macros duplicate code. But this can be
intentional.

ABX

Post a reply to this message

In article <15vd4u4qec0o7j3jht8qbscmt7tmvpp6bk@4ax.com>,


> Connect_Spheres() and Round_Cone2() macros duplicate code. But this can be
> intentional.

Speed. These macros could be called thousands of times in a scene (for 
tree/plant branches, for example), and macros are quite slow.

-- 
 -- 
Christopher James Huff <chr### [at] maccom>

Post a reply to this message

In article <1dtd4ug8htn1ns9md3vp9i1mbcq5qf10sb@4ax.com>,
 W?odzimierz ABX Skiba <abx### [at] babilonorg> wrote:

>          #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;

The ".y" part is unnecessary (you are already multiplying by y), but you 
are correct, that is a bug and this looks like the fix.


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

I never completed these macros...I originally thought the function 
syntax was going to allow functions to be passed to macros, these macros 
were intended to take functions directly, not strings. Someone else 
patched them up to be useable.


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

I think I left some comments about this possibility...but like above, I 
never got the macros working, so I didn't bother to optimize them.


> 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... ;)

This was to make it possible to get seamless spheres and cylinders. You 
can easily use warps to map an image to the height field, but you can't 
"unwarp" a function to get a seamless result with procedural functions. 
A little more complex for the special case of using images to control 
displacement, but I think it's worth it.

-- 
 -- 
Christopher James Huff <chr### [at] maccom>

Post a reply to this message