"Kenneth" <kdw### [at] gmailcom> wrote:

> Good idea; although in my case it's more of a visual result-- like the bumps
> pattern affecting an isosurface. I have no clue as to how debug might be used
> there.

Well, there are a number of ways that you can do these things.
you always do #declare A = function {pigment {bumps}}
and then use that to calculate numbers for your debug stream.

Another I do a lot is make a graph along one axis (usually x).
That way I can cycle through X with a loop, calculate the result, and make a
little sphere at <X, Result, 0> to see WTH is going on.


> That's really neat, and useful. I *still* struggle with understanding the finer
> points of function use. Your examples (here and through the years) have been a
> godsend...if I can only remember them!

Well, thanks - but remember, the only reason I got "this good" is because jr had
that media project, and Bill Pokorny walked me through a lot of the practical
details of using functions, and then I just practiced, practiced, practiced.

> In my current code project, many are the
> times that I came up with a workable solution only by sheer trial-and-error,
> discarding one failed attempt after another. It's like trying to discern the
> finer points of a 'foreign language' when I don't know or remember the subtle
> underlying rules, from lack of practice.

Absolutely.   Don't think that I don't do exactly the same thing ALL THE TIME.

The key, really, is looking at any given function and asking "what do the things
inside the curly braces need to be fully evaluated"?
And often, that's a matter of going back one daisy-chained function and asking
the same thing.   And then doing that again.

Because if you have A which needs X, and B which needs Y, and C which needs Z,
and D which needs W, then if you have A(B(C(D()))), your function A needs:  A
(X, Y, Z, W) {}, and so on, as you go further down into the curly braces.

It can be mind-bending, and a real mess on the screen, but going through the
simpler functions and making the mistakes that are easier to track down because
there are fewer places for the error to be allows you to learn to "think ahead"
and keep a running tab of things that could/usually go wrong.  Notes in the code
or on paper usually help me remember what the cryptic POV-Ray error heiroglyphs
actually MEAN in a practical sense.

The other thing that helps to work this all out in your head is to not delete
code that doesn't work.   Otherwise you wind up coding the same mistakes over
and over again.

Do a #switch #case #break #end block, and copy-paste #case 1 into #case 2 and
then edit case 2.  If that fails, work on case 3.   That way you have a running
documentation of what you've tried, what the results look like, notes on why it
failed, what worked, etc.

You can then copy-paste the working code into a new scene that just works, but
retain that developmental test scene for your records.  Heck, post it here, so
that people struggling with the same issues can follow along and really see how
one goes from fail to success.  What doesn;t work is often more important to
know than what does, since there's so much more of it to go wading through.

Glad you're getting it all to work out.

- BW

Post a reply to this message