POV-Ray : Newsgroups : povray.advanced-users : isosurface: Does the order of multiple functions matter? : Re: isosurface: Does the order of multiple functions matter? Server Time
18 May 2024 22:31:03 EDT (-0400)
  Re: isosurface: Does the order of multiple functions matter?  
From: Bald Eagle
Date: 30 Jan 2023 07:10:00
Message: <web.63d7b2fe9b90547b1f9dae3025979125@news.povray.org>
With regard to your problems with :

isosurface{function{
1 - (OBJ_PATTERN_FUNC(
x + MAG*PIG_DISTORTION_FUNC (x,1-y,1-z).x - .5*MAG,
y + MAG*PIG_DISTORTION_FUNC (1-x,y,1-z).y - .5*MAG,
z + MAG*PIG_DISTORTION_FUNC (1-x,1-y,z).z - .5*MAG
     ).gray)
     } ...}

I don't think that the problem lies with any particular grayscale, color, or
pattern values, but with the way in which you are incorporating them into your
function call.

It's a bit hard to describe without diagrams or animations, but I think that you
ought to think about the coordinates of what you're passing into your function
as a mathematical form of translate <x, y, z>.

The ONLY thing you're doing when you change the values in the "slots" for x, y,
and z in your function calls is telling the function what value - what 3D point
in space (for a 3D pigment or pattern function) - to get its calculated value
from.

If you take a look at Mike Williams' Isosurface Tutorial, you'll see how he goes
about systematically manipulating small parts of any given function to achieve
specific results.  These are all based on very simple algebraic concepts that
you can readily find with a few clicks on the web.

When you take something like a parabola, y = x*x, or declare Parabola = function
(X) {pow (X, 2)}, then you have a specific, hard coded relationship between the
value of X and what the result of the calculation is.

The visual an often counterintuitive result of many mathematical manipulations
of that basic equation is that it moves in the opposite direction of what you
initially might expect.

If I subtract from the "X" that I _pass into_ the function call, then I'm moving
the function result to the left, because I'm decreasing X itself.   If I
subtract that same value from the X _inside the function_, then I shift it to
the right, because I'm taking the input value that's needed to achieve the
original result, and by subtracting from it, "increasing the value needed" to
get the same result - so I shift it to the right.

Now, I'm tired, and it's early, and I've only had half a coffee, so this may be
wrong or backwards - but the point is, all of the elements of what goes on are
right there for you to be aware of and experiment with.

find out what you have to do with any given function (I'd start with #declare
Test = function (X) {X} to get a straight line) to get it move exactly as much
as you think it should in any given direction.
Try a circle next (my onion example) and do the same, but now add scaling.

Always ask what is going in, how does that now get evaluated in the function's
equation, and what is required to achieve any target result value.


To get back to your original problem, I think that you are trying to modify your
x, y, and z input values, but you're comingling your terms by making your
distortion function for each term depend on the other 2 terms, rather than that
vector component alone. Your function that modifies x ought to have (x, 0, 0)
going into it, y should have (0, y, 0), and z should have (0, 0, z).

But without graphing the result and SEEING what the results of each function
evaluation are, I'm just speculating.   But I'm suspecting that you're adding
some sort of bias using all 3 vector components, which is consistent with an
overall shift/skew in the +/- <1, 1, 1> direction of any given magnitude.

Friedrich Lohmueller's site is down, but I'll bet you can use Wayback
(archive.org) to look at his geometric transformations section using matrix
transforms.   When you change around the values in the top 3 rows of the matrix,
you're multiplying what contribution that x, y, and z have on "where that axis
points" when you use functions in that redefined geometric space.  When you put
values into the bottom row, you add to those vectors, and do a translation.

So if I use <1, 1, 0> in my definition for "the y axis", then I achieve a skew
effect - because everything that used to be pointed straight up now points in
the direction of: <1, 1, 0>.   Which is at a 45 degree angle to the right.

Therefore if I use <1, 1, 1> * SomeScalingFactor, then I'd get a skew that's
forward and to the right by SomeScalingFactor.

Anyway, that's my early morning take, you breakfast food for thought, and you
math homework for the week.  :D

- The AntiTax Man


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.