Am 07.08.2016 um 01:57 schrieb clipka:

> You'll therefore have to find a different approach to implement your
> spherical harmonics -- pre-computing sample points of the polynomials
> and approximating the whole thing with splines won't work.

BTW, I suspect that evaluating the sample-based splines wouldn't even be
much more performant than evaluating the base polynomials on the fly.

However, I presume that a naive implementation of the final function
would cause unnecessary double-evaluation of the base polynomials.
Consider the following (simplified) example:

  #declare fn1 = function(x) { ... }
  #declare fn2 = function(x) { ... }
  #declare fn3 = function(x) { ... }

  #declare fnA = function(x) { fn1(x) + fn2(x) }
  #declare fnB = function(x) { fn2(x) + fn3(x) }
  #declare fnC = function(x) { fn3(x) + fn1(x) }

  #declare fn = function(x)
    { A*fnA(x) + B*fnB(x) + C*fnC(x) }

Note how in this case each call to `fn` will evaluate all of the basic
functions twice.

One way to avoid this multiple evaluation of the basic functions is to
re-write the intermediate-level functions as taking not x as parameter,
but the results of the basic functions, like so:

  #declare fn1 = function(x) { ... }
  #declare fn2 = function(x) { ... }
  #declare fn3 = function(x) { ... }

  #declare fnA_ = function(fn1,fn2) { fn1 + fn2 }
  #declare fnB_ = function(fn2,fn3) { fn2 + fn3 }
  #declare fnC_ = function(fn3,fn1) { fn3 + fn1 }

  #declare fn_ = function(fn1,fn2,fn3)
    { A*fnA_(fn1,fn2) + B*fnB_(fn2,fn3) + C*fnC(fn3,fn1) }

  #declare fn = function(x) { fn_(fn1(x),fn2(x),fn3(x)) }

Not sure if this approach is applicable to your problem though, since I
only had a cursory glace at what the formulae in your code are actually
doing.

Post a reply to this message

Am 07.08.2016 um 02:17 schrieb Bald Eagle:
> Thanks - I do understand and appreciate that there are a lot of things that are
> intertwined and virtually inextricably embedded in POV-Ray, and would take a
> major rewrite to fix, or add.
> I'll keep plugging away at it. :)
> 
> Can you explain what the following excerpt from the docs _means_ ?
> 
> "Also, function splines take the vector size into account. That is, a function
> containing a spline with five components will also return a five component
> vector (aka a color), a function containing a spline with two components will
> only return a two component vector and so on. "

Ah -- that explains why I was surprised that splines didn't work in
functions.

Having read the relevant portions of the docs again, it turns out you
can do the following:

  // Declare a normal spline.
  #declare MySpline = spline {
    ...
  }

  // Declare a spline function.
  // (Note that this returns a vector, not a float.)
  #declare MySplineFn = function { spline { MySpline } }

  // Use the spline function in a regular function.
  // (Note the `.x` to access the spline function result's
  // first coordinate; don't confuse it with the `x` denoting
  // the function's first parameter.)
  #declare MyFn = function(x) { ... MySplineFn(x).x ... }

(You can also place the actual definition of the spline into the spline
function itself.)

Post a reply to this message

Op 2016-08-06 om 21:35 schreef Bald Eagle:
> So, here's an example I'm currently grappling with.
>
> I'd like to use a parametric to make a spherical harmonic following the MatLab
> code here:
> http://148.204.81.206/matlab/examples/spherical-surface-harmonic.html

You can do that using the Meshmaker.inc, the win-POV insert menu has 
some examples Insert > SpecialShapes > Meshes by meshmaker.inc

Ingo (sorry for the accidental e-mail)

Post a reply to this message

ingo <ing### [at] gmailcom> wrote:

> You can do that using the Meshmaker.inc, the win-POV insert menu has
> some examples Insert > SpecialShapes > Meshes by meshmaker.inc
>
> Ingo (sorry for the accidental e-mail)

Hello Ingo,

I've known OF you for quite some time by reputation, but haven't had the
pleasure of corresponding with you directly.  It's good to see that you still
make it by here from time to time.

I've noticed the meshmaker in the past, but never had time to investigate it.

Thanks for the tip - I'll look into it along with everything else I'm juggling
:)

(no worries about the email)

Post a reply to this message

In an unrelated search I came across Mike William's code that he posted here:

http://203.29.75.35/povray.general/thread/%3Cweb.4864e13d83231c9ec59235590@news.povray.org%3E/?ttop=333125&toff=400

(answering part of my original question)

Two things struck me as I played with the code last night (don't worry - I was
not injured  ;) )

1)  Using the original #version 3.5, I got a very dim image.   I wondered why he
was using "rgb 4" in the colour_map.  When I edited that to #version 3.7, it got
MUCH brighter / whiter

2)  I would have probably tried to achieve something like this with a vertical
color map applied as a y-gradient pigment.
Surprisingly, Mike's method of implementing the contour lines seems to be
completely orthogonal to that, and instead uses the x&z components of the
function to generate vertical "cylinders" which are visible at the "y-surface"
of the isosurface.   Ingenious and unexpected.

I had some fun converting this to a noise-perturbed sphere, and then getting the
contour / isobar / isometric lines to be spherical shells as well.

But that process also highlighted the fact that I often have a hard time getting
a clear understanding of how certain functions work, and how their values play
out in 3D space.

While the isosurface documentation is clear and easy to _follow_, I think I
require a bit more instruction and learning to be able to create certain
constructs from scratch.

I'm currently having a devil of a time getting this converted to 3.7 syntax:

http://news.povray.org/povray.general/message/%3ChKu%24tCAgdR04EwN%24%40econym.demon.co.uk%3E/#%3ChKu%24tCAgdR04EwN%24%
40econym.demon.co.uk%3E

Post a reply to this message