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