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