I've played around a bit with some of these in order to make some smoother, more
flowing images.

I have a few questions, and a request.

Does anyone know how to generate an isobar map/plane such as Mike Williams has
on his tutorial introduction?
http://www.econym.demon.co.uk/isotut/isobars2.jpg

It would be nice to have a robust system for making something like this,
generating the numeric grid, drawing the isobar lines, etc.

It seems to me that some objects can be described by either a parametric, an
"implicit" isosurface, or both.

I think I can somehow "get" the isosurface intuitively, but I seem to have some
difficulty translating certain equations into parametric form.

Does anyone have any tips, pointers, advice, or references to help working out
how x, y, and z are described by 3 different functions derived from one overall
equation?


***   With regard to the parametric object, is there any way to introduce a RHO
parameter?  I use u and v like THETA and PHI, but I've come across instances
where an additional parameter is thrown in to vary a radius or some other aspect
of the shape.


Many thanks as always!

Post a reply to this message

Am 01.08.2016 um 23:41 schrieb Bald Eagle:

> ***   With regard to the parametric object, is there any way to introduce a RHO
> parameter?  I use u and v like THETA and PHI, but I've come across instances
> where an additional parameter is thrown in to vary a radius or some other aspect
> of the shape.

Can you give an example?

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

> Can you give an example?

I'll try.  It's something I'm exploring, so I'm no expert.
But there seemed to be a lot of RHO's being used, and when I thought about an
easy way to do certain things, having a third changing variable seemed like it
would be useful, and I wasn't sure how else I'd go about it.

x = ρcos(θ)sin(Φ)
y = ρsin(θ)sin(Φ)
z = ρcos(Φ)



http://www.microscopy-uk.org.uk/mag/imgjan06/Image13.jpg


ρ = sqrt(x^2+y^2+z^2), tan(θ) = y/x, tan(Φ) = sqrt(x^2+y^2)/z

r = ρ sin Φ, θ = θ, z = ρ cos Φ

ρ = sqrt(r^2+z^2), θ = θ, tan(θ) = r/z


ρ = 1 + 1/5*sin(6θ)*sin(5Φ)


r = rho.*sin(theta);
x = r.*cos(phi);
y = r.*sin(phi);
z = rho.*cos(theta);

Post a reply to this message

Am 02.08.2016 um 04:13 schrieb Bald Eagle:

> I'll try.  It's something I'm exploring, so I'm no expert.
> But there seemed to be a lot of RHO's being used, and when I thought about an
> easy way to do certain things, having a third changing variable seemed like it
> would be useful, and I wasn't sure how else I'd go about it.
[...]
> http://www.microscopy-uk.org.uk/mag/imgjan06/Image13.jpg

That image does not show a single three-parameter parametric surface,
but rather a "family" of parametric surfaces: Their parametric equations
are similar, but differ in a certain constant.

In a technical sense, this constant (c) can be considered another
parameter, but it differs fundamentally from the two parameters (u,v)
that every parametric has: While u and v are varied within an individual
instance of the parametric surface and in a contiguous fashion to create
a contiguous set of points (the surface), c is varied only between
different instances of the parametric surface and only in discrete steps.

Due to this property of the c parameter, there is no need to implement
it within POV-Ray's parametric surface primitive itself: You can simply
use multiple parametrics instead, using equations with different
constants. Of course nothing stops you from defining those equations in
terms of a common three-parameter function, and possibly using a loop to
vary the third parameter, like so:

    // The common function set
    #declare BaseFnX = function(u,v,c) {...}
    #declare BaseFnY = function(u,v,c) {...}
    #declare BaseFnZ = function(u,v,c) {...}

    // The parametric family
    union {
      #for(C,C1,C2,CStep)
        // An individual parametric
        parametric {
          // The actual functions to use
          function { BaseFnX(u,v,C) }
          function { BaseFnY(u,v,C) }
          function { BaseFnZ(u,v,C) }
          <U1,V1>, <U2,V2>
          ...
        }
      #end
    }

Post a reply to this message

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

For the time being, I'm assuming Legendre (degree, ....) and Ymn (order+1, ...)
are P6 and P2 which are the the polynomial equations here:

http://mathworld.wolfram.com/LegendrePolynomial.html

I populate an array with the results of these polynomials across 0 to pi or 0 to
2*pi.   I now want to use a RHO value to vary the radius as POV-Ray's parametric
evaluates the spherical coordinates across Theta and Phi (u and v).

r = rho.*sin(theta);
x = r.*cos(phi);    % spherical coordinate equations
y = r.*sin(phi);
z = rho.*cos(theta);


I'm trying to calculate a rho or an r value that smoothly varies with u.
As you can see below, I figured that defining a spline based on the polynomial
evaluations was a logical way to do this, but the parser complained when I tried
to use RhoSpline(u) in my functions, and still complains when I try to use a
user-defined function that returns a spline value.
"expected 'operand', but spline identifier found instead"

Maybe this is an inherent limitation of the parametric, maybe it's my continuing
struggle with using functions, or maybe it's a legit example of needing a RHO
term.

//##########################################################################

#version 3.7;
global_settings {assumed_gamma 1.0}
#include "colors.inc"
#include "textures.inc"
#include "shapes3.inc"

camera { location <0, 5, -20>
  look_at <0, 0, 0>}

light_source {<40, 30, -20> White}

background {Black}

#declare Degree = 6;
#declare Order = 1;
#declare Delta = pi/40;


// Legendre polynomials
#declare P_0 = function (T) {1};
#declare P_1 = function (T) {T};
#declare P_2 = function (T) {1/2 * (  3 * pow (T,2) -   1) };
#declare P_3 = function (T) {1/2 * (  5 * pow (T,3) -   3*T) };
#declare P_4 = function (T) {1/8 * ( 35 * pow (T,4) -  30 * pow(T,2) + 3) };
#declare P_5 = function (T) {1/8 * ( 63 * pow (T,5) -  70 * pow(T,3) + 15*T) };
#declare P_6 = function (T) {1/16* (231 * pow (T,6) - 315 * pow(T,4) + 105 *
pow(T,2) - 5) };

#declare RESULT = array [41][5];
#declare Element = 0;
#for (Theta, 0, pi-Delta, Delta)
#debug concat( " Theta = ", str(Theta, 3, 1),  " Element = ", str(Element, 3,
1), "\n")
 #declare RESULT [Element][0] = P_6 (cos(Theta));
 #declare RESULT [Element][1] = P_2 (cos(Theta));
 #declare Element = Element + 1;
#end // end for Theta

#declare Element = 0;
#declare Order = 0;
#for (Phi, 0, 2*pi-2*Delta, 2*Delta)
 // populate the
 #declare RESULT [Element][2] = RESULT [Element][0] * cos(Order*Phi);
 #declare RESULT [Element][3] = RESULT [Element][1] * cos(Order*Phi);
 #declare RESULT [Element][4] = max (abs(RESULT [Element][2]), abs(RESULT
[Element][3]));
 #declare Order = max (Order, RESULT [Element][4]);  // overall max
 #declare Element = Element + 1;
#end // end for Phi

#declare RhoSpline =
spline {
  cubic_spline
    -Delta, 0,  // Control point
 #for (S, 0, pi-Delta, Delta)
  S, RESULT [S/Delta][4]
 #end // end for S
     pi+Delta, 0  // Control point
    }

#declare R = function (T) {abs(RhoSpline(T))};

#declare W = 10; //contained_by box size

parametric {
 // RHO = (5+2*RESULT[u*pi][4]/Order)
 // r   = (5+2*RESULT[u*pi][4]/Order) * sin(u)
 // R() is function defined above
  function { (5+2*RhoSpline(u)/Order) * sin(u) * cos(v) }, // x-axis
  function { (5+2*R(u)/Order) * sin(u) * sin(v) }, // y-axis
  function { (5+2*R(u)/Order) * cos(u) }   // z-axis
  <0, 0>, <pi, 2*pi>         // <Umin, Vmin>, <Umax, VMax>  (Theta, Phi =
Altitude, Azimuth)

  //contained_by { sphere { 0,1 } } // texturing problem, use box instead to
see!
  contained_by { box { <-1,-1,-1>*W, <1,1,1>*W } }
  // max_gradient 2
  accuracy 0.005        // 0.001 default, lower slower but better
  precompute 15 x,y,z   // precompute [x,y,z] normally gives faster rendering
(<=20)
  scale 1
  texture {pigment {color White } }
  //translate<0,1,0>
}

Post a reply to this message

If I try to use:
  function { (5+2*RESULT[int(u/Delta)][4]/Order) * sin(u) * cos(v) }, // x-axis

I get "Float expected but vector or color expression found"

Are u and v not scalar values?

(apparently not, since using u.gray gets me through the parsing...)

(all I get is a sphere)
If anyone uses MatLab, perhaps they can illuminate me on what I'm missing.

Post a reply to this message

....aaaaand embedding

#debug concat( " u = ", vstr(2, u, ", ", 0, 3), " v = ", vstr(2, v, ", ", 0, 3),
"\n")

into the parametric definition yields
u = 1.000, 0.000 v = 0.000, 1.000
and that's the one and only line of output I get.

So, this leads me to ask, "sin and cos can work on 2-element vectors?"

I'm curious to learn more about the internal workings of the parametric - and
how I can bend it to my will....  :D

Post a reply to this message

Am 06.08.2016 um 22:23 schrieb Bald Eagle:
> If I try to use:
>   function { (5+2*RESULT[int(u/Delta)][4]/Order) * sin(u) * cos(v) }, // x-axis
> 
> I get "Float expected but vector or color expression found"
> 
> Are u and v not scalar values?
> 
> (apparently not, since using u.gray gets me through the parsing...)

The problem here is that the function evaluation engine cannot access
any scene-level variables whatsoever. Therefore, whenever you specify
such a variable in a function, POV-Ray immediately evaluates it while
parsing the function, expecting to get a float, which it will insert
into the function as a constant.

This attempt at immediate evaluation also includes access to array
elements. However, the parsing of the array indices is done by the
parser for generic SDL code, /not/ the parser for user-defined
functions. Thus, in the sub-expression

    RESULT[int(u/Delta)][4]

the `u` is /not/ interpreted as the function's first parameter, but as
the vector constant `<1,0>`; this ultimately leads to a parse error,
since the int() function expects a float but encounters a vector.

Post a reply to this message

Am 06.08.2016 um 21:35 schrieb Bald Eagle:

> I'm trying to calculate a rho or an r value that smoothly varies with u.
> As you can see below, I figured that defining a spline based on the polynomial
> evaluations was a logical way to do this, but the parser complained when I tried
> to use RhoSpline(u) in my functions, and still complains when I try to use a
> user-defined function that returns a spline value.
> "expected 'operand', but spline identifier found instead"

There are a few things that you can do in POV-Ray's regular SDL, but
which don't work in functions.

I'm a bit surprised about this myself, but using splines in place of
functions seems to be one of those things.

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.

Post a reply to this message

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. "

What's an example of a working "function spline"?

Post a reply to this message

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