"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
> When you set some of the
> arguments to the PIG_DISTORTION_FUNC function to zero, you were
> either "sampling" this function in a plane, along a line or at a point.

Yes, the odd isosurface result looked kind of like 'cubes' joined together--
restricted to (or made up of) many x,y,z planes. The effect is actually hard to
describe.
>
> With pattern functions you can rewrite your isosurface function like
> this:
>
> function {
>     1 -
>     OBJECT_FUNC(
>         x + MAG*(DISTORTION_FUNC(    x, 1 - y, 1 - z) - 0.5),
>         y + MAG*(DISTORTION_FUNC(1 - x,     y, 1 - z) - 0.5),
>         z + MAG*(DISTORTION_FUNC(1 - x, 1 - y,     z) - 0.5)
>     )
> }

Originally, I did use -0.5 for the 'bias' (but unfortunately without the
additional parentheses you've added.) As the MAG multiplier value increased--to
bring in more of the bumps distortion-- I began to notice that the entire
distorted isosurface was shifting its position in space(!), along the vector
direction of <-1,-1,-1>. I didn't know if that was a result of something
specific to my current code; I had never noticed such movement before in a
normal isosurface. My 'informed guess' of using the *changing* -.5*MAG for the
bias eliminated that movement.

Now I see that the extra parentheses would have made -0.5 work as planned.
Thanks for pointing this out! It simply didn't occur to me... and would have
saved me a lot of coding grief.

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> ...
> > in detecting a substitution for it, then how does it work successfully?
>
> "at some point in the code, have to be replaced with some actual value or other
> pre-#declared variable"
> ...
> Then you can invoke the macro code using:
>
> PerformTaskRegarding (TdG) or PerformTaskRegarding (jr) or PerformTaskRegarding
> (Bill) or EVEN PerformTaskRegarding (Kenneth)

so.  we're all just .. "scalar values"?!  (wondering, I do have a sense of
direction, will that make me a vector?  </grin>)


regards, jr.

Post a reply to this message

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> >
> > In my current real scene...here is a somewhat simplified version of a
> > problem I had:
> >...
> > #declare OBJ_PATTERN_FUNC = function{pigment{object{MY_OBJECT rgb 0 rgb 1}}}

>
> I recommend that you use pattern functions here instead of pigment
> functions...
>
> You can then write your declared functions like this:
>
> #declare OBJECT_FUNC =
>     function {
>         pattern {
>             object { MY_OBJECT }
>         }
>     }

You are correct...as I have just discovered(!)-- not because I didn't try using
'pattern' there (which I did) but because it outright failed for me. The syntax
was not accepted. HOWEVER, this is because I actually did not write my real
scene's object pattern/function code like the one-line example I gave, but
instead split-up the code into two parts, for no real reason:

#declare OBJ_PATTERN = pigment{object{MY_OBJECT rgb 0 rgb 1}}

#declare OBJ_PATTERN_FUNC = function{pigment{OBJ_PATTERN}}

When OBJ_PATTERN is written this way--initially without a function wrapper--
POV-ray does not accept 'pattern' as a valid parameter, only 'pigment' and
'density'. So, I thought that this was the only way to write it. If I had
thought to combine the two operations into one, 'pattern' would have been
accepted! This is one of several undocumented syntax-rule quirks of the 'object
pattern'; there are others too, as I keep discovering. The docs say that it is a
color-list pattern, so I guess it has special rules and limitations like similar
patterns.

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> >
> > "at some point in the code, have to be replaced with some actual
> > value or other pre-#declared variable"
>
> Well, yes and no.
> [snip]
> I hope that is clear enough and helps.
>

Wow. That is a really brilliant presentation. (Or maybe I should say that it's a

that I appreciate all of the info and your time in writing it is an
understatement-- it is so in-depth, especially about 'placeholders' in
functions, which has always been mysterious to me and a real stumbling block.

It's no wonder that I was flummoxed by W. Pokorny's masterful code that I
referenced earlier-- it probably makes use of *all* of the various function
rules and different 'namespace' conventions that you mentioned.


the wall in front of my computer to stare at for hours at a time so that I can
absorb it all. Through osmosis! At some point, I am going to have to carve out
the time to concentrate on *just* function use and experiments, and compare my
older (and current!) trial-and-error scene successes to the actual methodology
and your very helpful notes (from both here and in the past).

Thanks, as always. You would be a good teacher of this stuff.

------
An actual function named after ME?! (**blushes**) I am thrilled and humbled. I
shall invoke it many times in the future as a mark of distinction. I shall name
my first child "function{Kenneth,2}" to carry on the tradition (?? Uh-oh, maybe
that was bad function syntax?? I'm still learning...)
------
"Bald Eagle Smashes Window at Virginia Tax Office"
Good work, ha!  But you forgot to say HELLO as you passed through!

Post a reply to this message

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
>
> I suspect that the reason that the "skew" disappears when using your
> "desperation" code is that there you are "sampling" the
> PIG_DISTORTION_FUNC at different locations in 3D space for each of
> the red, green and blue components (.x .y .z), This causes the 3
> components to have different values.

That is a very interesting and subtle point, and I think I grasp the idea. I can
sort of visualize this effect 'writ large' if I had used, say, the bozo pattern
for my 'distortion' function-- it has very distinct primary colors, and thus
three distinctly different grayscale values when made into a function. But in my
case I used the bumps pigment, which is grayscale to begin with...so all the
color channels are the same, as you mentioned-- and should(?) all be 'sampled'
in the same 3D space location.

[conjecture]
Or maybe your point is that even grayscale 'bumps' has dark-to-light
variations... and it is *those* variations that are sampled in different 3D
space?

Hmm, much food for thought. Thanks for the intriguing explanation.

(BTW: Using the bumps pigment, I scaled it *very* small to be almost like noise,
and its 'skew' still showed up and was even more obvious...until I fixed it of
course.)

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > "Kenneth" <kdw### [at] gmailcom> wrote:
> > >
> > > "at some point in the code, have to be replaced with some actual
> > > value or other pre-#declared variable"
> >
> > Well, yes and no.
> > [snip]
> > I hope that is clear enough and helps.
> >
>
> Wow. That is a really brilliant presentation. (Or maybe I should say that it's a
>
> that I appreciate all of the info and your time in writing it is an
> understatement--

Hmm. My post got screwed up and truncated :-(  I've never had that happen
before.

Anyway, a big thank-you.

Post a reply to this message

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

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> In case you want to try the quick test (no need for 'high-quality' settings
> here):
> -----------
> #declare BUMPS_F =
> function{pattern{bumps scale .2}}
>
> #declare GRANITE_F =
> function{pattern{granite scale 3}}
>
> #declare SIN_F = function(x){sin(7*pi*x)}
>
> isosurface{
>  function { sqrt(pow(x,2)+pow(y,2)+pow(z,2))-.7 // sphere
>
>           // switch these around...
>             + BUMPS_F(x,y,z)*.5
>
>             - GRANITE_F(x,y,z)*.5
>
>             - SIN_F(x)*.2
>
>   }
>
>  threshold 0
>  accuracy .01
>  max_gradient 8
>
> contained_by{box{-1.1,1.1}}
> pigment{ rgb 1}
> }

Just to be complete:
Here is an instance where the order of functions does matter, *when* using
additional parentheses. This is to be expected of course. As Alain pointed out
earlier (paraphrasing),
                 +(A - B) is different from -(B + A)

+ (BUMPS_F(x,y,z)*.5
- GRANITE_F(x,y,z)*.5)

- SIN_F(x)*.2

vs.

- (GRANITE_F(x,y,z)*.5)
+ (BUMPS_F(x,y,z)*.5)

- SIN_F(x)*.2

Post a reply to this message