William F Pokorny <ano### [at] anonymousorg> wrote:

> height_field { //+++++++++++++++++***  <------- Need this
>    function 500, 500 { somb(x*20, (1-y)*20) }

I was playing with something similar last night wi the y-subtraction.

> Yes. Functions as used in height_fields never see called x,y values
> outside the [0-1] range.

All I can say at this point is that it takes a lot of wrangling to get some
things to behave properly, and at the moment, I can't say that I've got it all
straightened out.

The height_field definitely needs to be tailored to use either user-defined
functions or pigment functions, and there are definitely more complications than
just that.

I was able to get most of the issues sorted out in one scene, but they remain in
another.  for whatever reason, pigment {onion} really throws thing off compared
to other things.

At the moment, I'm comparing isosurface and height_field, so maybe somehow those
get to be like comparing apples to oranges, due to the values and how they need
to be handled (y-function for an isosurface}

I did not see the y-shift that yesbird is seeing.

(Sergey:  scaling scales EVERYTHING.   If the hf is 1 unit away from the origin,
then it will scale that offset vector as well.  So, you can take a sphere
cenetered at the origin and scale it, and it will give the expected results, but
if you translate it first, then it will scale the translation as well, and it's
center will wind up farther away from the origin.)


It might be worth having a few people independently test out their own methods
of constructing a function and function {pigment} hf, and compare results, then
we can maybe make a macro that has a solution to reliably  making a hf in the xz
plane.   I spent WAY longer sorting this out than I should have, and I'm still
not satisfied that I fully understand all of the intricacies.

Post a reply to this message