Thomas de Groot <tho### [at] degrootorg> wrote:

>
> That sounds like a Black Hole singularity to me ;-)
>

My thought exactly ;-) I had a sneaking suspicion that the sphere is a kind of
'kludge' (and I use that word respectfully!), to keep some other kind of problem
from occurring at the exact center of the spiral.

To Bald Eagle:
That's some nice detective work with the source code; way beyond my skills.
Currently, the center sphere size seems(?) to be 'coupled' to the spiral's
thickness parameter, as part of the same code(?) (I thought the sphere was
simply an added object!) I wonder if its size/diameter could be 'un-coupled' in
some way-- so that it *maintains* a much smaller and visually less obtrusive
size, no matter what the spiral thickness is-- while still serving its original
purpose.

Post a reply to this message

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

> To Bald Eagle:
> That's some nice detective work with the source code; way beyond my skills.

Thanks, Kenneth - I could probably use a LOT more practice in working with cpp -
I've only had the opportunity to dabble a tiny bit with Perl, cpp, C#, python,
BASIC (of course), and maybe one or two other languages.
Someone probably tried to show me Pascal in the 80's....

It's usually just a matter of copy/paste, reformatting to figure out the large
brush strokes and indenting them properly to keep everything straight, and then
fiddling with syntax differences and doing some searching to figure out "Now WTF
is _THAT_ mathematical / function / logical operator ????  Does POV-Ray even
HAVE that???"

> Currently, the center sphere size seems(?) to be 'coupled' to the spiral's
> thickness parameter, as part of the same code(?) (I thought the sphere was
> simply an added object!) I wonder if its size/diameter could be 'un-coupled' in
> some way-- so that it *maintains* a much smaller and visually less obtrusive
> size, no matter what the spiral thickness is-- while still serving its original
> purpose.

Yes.  And at this point I believe that it has something to with:

#declare r2 = mod (r, Spacing) - (Spacing/2);
and then
#declare r2 = sqrt(r2*r2 + Y*Y);
or
#declare r2 = pow( (pow(abs(r2), temp) + pow(abs(Y), temp)), 1/temp);


Why: because the whole point of the code is to finally spit out:

#declare VALUE = -min( Dia - r, Thickness - min(r2, r) );

So, the first half of the min comparison is just a limitation of the major
radius r so that it doesn't overrun the maximum diameter parameter that the user
passes to the isosurface function.
r2 is sort of like the minor radius for a torus.

So, with:
Thickness - min(r2, r)

it can't be Thickness, because that's a parameter, it can't be r - because
that's just where on the spiral you are, so it has to be r2 being way out of
scale with the other values at/near the origin.

Unary negative of a LARGE r2 subtracted from a smaller scalar (Thickness) gives
- a positive value.

picture making circles with some calculated radius.  You can keep making the
radius smaller, until it hits zero, and then --- becomes increasingly negative.
Which is just the same circles, only "inside out" - but they can still get
large.
And I believe that somewhere in that logic and the calculations, that
subtraction of r2 from thickness is sufficiently "inside out" to make a
spherical bulge near the origin - where r is very small.

Got a bunch to do today / this weekend, so I dunno if I'll get to this, but I'm
thinking:
plot out the values of those parts of the equations relative to Thickness and r.
  Throw some abs()'s in there and see if it fixes anything.

*** See what the exact radius of that sphere is - I'll bet that would be an
important datum to have.


Hope this helps some.

:)

Post a reply to this message

Aaaannd....
my initial instinct seems to be right.

Commenting out that equation for a sphere ... gets rid of the sphere.

No idea why they have that in there - r isn't redefined in any of the other
sections.

     #else
          #declare r2 = max (abs(r2), abs(Y));
          //#declare r = sqrt(X*X + Y*Y + Z*Z);  <<< comment out

 #end

I'd say if someone can recompile their source code with that one line edited
out, and see if the isosurface for that function works fine without it, then

"It's a bug".


(I think that my preceding post still has some valid points, because there's the
selection that takes place between r and r2 - and r2 is dependent on Thickness.
So although the sphere is a result of the redefinition of r, the value of r2
influences the appearance of that sphere.

Hope that makes some sense.

Post a reply to this message

Le 17-09-30 à 02:24, clipka a écrit :
> Am 30.09.2017 um 05:16 schrieb Bald Eagle:
> 
>> If you take a look over at
>> http://www.econym.demon.co.uk/isotut/builtin1.htm
>> at
>> http://www.econym.demon.co.uk/isotut/std007.jpg
>> you'll see that Mike Williams' render of this function shows the same odd sphere
>> at the center.
> 
> Judging from those images, my guess would be that the sphere constitutes
> an intentional hack, to prevent the gradient from exploding at the
> coordinate origin.
> 
> However, I would also guess that the hack was designed with a circular
> cross-section in mind, and that it might be worth changing the code so
> that it adapts to the cross-section of the spiral.
> 

That's my guess to. It's coherent with my experience using spiral1 to 
create an isosurface. The gradient tend to infinity near the center and 
the isosurface breaks down.

Post a reply to this message

Am 30.09.2017 um 21:10 schrieb Bald Eagle:
> 
> Aaaannd....
> my initial instinct seems to be right.
> 
> Commenting out that equation for a sphere ... gets rid of the sphere.
> 
> No idea why they have that in there - r isn't redefined in any of the other
> sections.
> 
>      #else
>           #declare r2 = max (abs(r2), abs(Y));
>           //#declare r = sqrt(X*X + Y*Y + Z*Z);  <<< comment out
> 
>  #end
> 
> I'd say if someone can recompile their source code with that one line edited
> out, and see if the isosurface for that function works fine without it, then
> 
> "It's a bug".

No, I don't think so.

My guess is that it was added deliberately, but that the person who
added it wasn't aware of all the different spirals that can be created
by the function, and therefore only regarded one special case.

Look again at this spiral:

http://www.econym.demon.co.uk/isotut/std007.jpg

Now imagine this with a circular (rather than diamond-shaped) cross section.

In that case, the sphere would seem to serve as a neat inner end for the
spiral.


I'd say, "It /is/ not a bug - it /has/ a bug." It probably needs to be
modified to fit different cross sections, and it should be suppressed
for non-equidistant spirals because for those the "natural" behaviour at
the center is for the cross-section to approach zero size.

Post a reply to this message

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


> >      #else
> >           #declare r2 = max (abs(r2), abs(Y));
> >           //#declare r = sqrt(X*X + Y*Y + Z*Z);  <<< comment out

I did a small bit more experimenting.
As previously posted, I got rid of the sphere, but the rest of the spiral became
malformed and had strange discontinuities.

If I _changed_ that line to read #declare r = r2, I got what seemed at this
stage to be acceptable results.

Maybe if I'm able to explore this further in something like Euler math toolbox
or Processing, or K3DSurf, or something else, I'd be able to better see what was
going on and come up with a nicer shape/solution.

> My guess is that it was added deliberately, but that the person who
> added it wasn't aware of all the different spirals that can be created
> by the function, and therefore only regarded one special case.
>
> Look again at this spiral:
>
> http://www.econym.demon.co.uk/isotut/std007.jpg
>
> Now imagine this with a circular (rather than diamond-shaped) cross section.
>
> In that case, the sphere would seem to serve as a neat inner end for the
> spiral.

Yes - I see what you're saying, I just find it a bit odd that it's a sphere of
such different radius than the rest of the spiral.

The comments in the source indicate that the original code was of course written
by Suzuki, and then ported to POV-Ray by F. Lohmueller.  Not sure at what point
the sphere got added in as that central "feature".
Gerd Platl has some archimedian spirals done with K3DSurf that don't seem to
require the sphere - so perhaps it's not really needed.

http://k3dsurf.s4.bizhat.com/k3dsurf-ftopic30-0-asc-30.html

Post a reply to this message

So, I just wanted to mention a few other odd things I noticed in the internal
function code and my SDL emulation:

#declare Theta = atan2 (Z, X);
This returns an angle in RADIANS. I'm sure this is fine for the POV-Ray
isosurface code, but nowhere in my code do I see where I converted this to
DEGREES before rotating my spheres.  Oops.  :O

This little bit doesn't seem to need a special case for Shape = 1.

#if (Shape = 1)
  #declare r2 = sqrt(r2*r2 + Y*Y);

     #elseif (Shape != 0)
          #declare temp = 2/Shape;
          #declare r2 = pow( (pow(abs(r2), temp) + pow(abs(Y), temp)), 1/temp);

Because it seems to me they give the same result?


Anyway, I did the bleeding obvious, and just defined a function {} to be
rendered as an isosurface and noodled out ways to adjust the thickness of the
spirals, adjust the frequency of the spirals, and render multiple spirals.

As you can see, the regions near the origin get pinched, but I haven't had an
epiphany about how to address that (yet).  One of the mathemagicians here can
probably jump in with, "Oh! 'All you've got to do is' ...."

I left in the original function and a few of my experimental modifications.  The
straightforward spiral code is the uncommented line, and should run fine as-is.

I haven't implemented anything to adjust the cross-sectional shape of the spiral
arms (yet), but maybe this ought to be a good enough start for others to dabble
with.

I should probably add an evaluate directive in there just as a matter of good
habit...

==================================================================

#version 3.7;
//------------------------------------------
// SDL for isosurface spiral[s] based on equations by Gerd Platl
// http://k3dsurf.s4.bizhat.com/k3dsurf-ftopic30-0-asc-30.html
// Bill Walker - October 2017
//------------------------------------------
global_settings {assumed_gamma 1}
#include "colors.inc"

light_source { <-1,8,2> color White}

camera {
 location <0, 10, -10>
 look_at  <0, 0, 0>
}

plane {y, -1 pigment { checker Grey, White }}

#declare RADIUS = 5;
#declare Thickness = 0.1;
#declare Freq = 2;
#declare Spirals = 5;

isosurface {
 //function {Thickness - y*y - pow(sin((sqrt(x*x+z*z) - 0.5*atan2(z,x))),2)}
 //function {Thickness - max (y*y, x*z) - pow(sin((sqrt(x*x+z*z) -
0.5*atan2(z,x))),2)}
 //function {Thickness - y*y*Freq - pow(sin((sqrt(x*x+z*z)*Freq -
0.5*atan2(z,x))),2)}

 function {(Thickness - y*y*Freq - pow(sin(sqrt(x*x+z*z)*Freq -
(0.5*Spirals*atan2(z,x)) ),2))}
 //function {(Thickness - y*y*Freq - pow(sin(max(sqrt(x*x+z*z), 1)*Freq -
(0.5*Spirals*atan2(z,x)) ),2))}
 //function {(Thickness - y*y*Freq -
pow(sin(max(sqrt(x*x+z*z),1/sqrt(x*x+z*z))*Freq - (0.5*Spirals*atan2(z,x))
),2))}
 //function {0.05 - y*y - pow(sin((sqrt(x*x+z*z))),2) + pow(sin((sqrt(x*x+z*z) -
(11*atan2(z,x)))),2) }

 accuracy 0.01
 threshold 0 // default value
 max_gradient 102
 contained_by {sphere {<0,0,0>, RADIUS}}
 open
 texture {pigment {Red} finish {specular 0.4}}
   }


//sphere {<0,0,0>, RADIUS pigment {rgbt <0, 0.5, 0, 0.9>} no_shadow}  // show
contained_by sphere

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> Anyway, I did the bleeding obvious, and just defined a function {} to be
> rendered as an isosurface and noodled out ways to adjust the thickness of the
> spirals, adjust the frequency of the spirals, and render multiple spirals.
>
> I left in the original function and a few of my experimental modifications.
> The straightforward spiral code is the uncommented line, and should run
> fine as-is.
> [code]

I'm having fun playing around with this (the various constants, multipliers and
exponents in the functions; even adding multiple functions together!) It's like
a basic 'spiral workshop', with seven 'preset' spiral shapes to examine. Thanks
for taking the time to work it out. I do notice that the functions don't yet
produce 'tapering' of the spiral at the start and end points (i.e, tapering to a
fine point)-- but that's a minor quibble right now, and actually gives us more
opportunities for experimentation, function-wise. And, so far, I haven't seen a
need for a sphere shape at the center; only a bit of isosurface accuracy
adjustment instead. Perhaps the sphere requirement applies to other more complex
spiral cross-sections (or tapering).

Meanwhile... here's a spiral doodle just for the fun of it, that looks like a
rubber mat, draped over an invisible rod.

------
#version 3.71; // or 3.7

global_settings {assumed_gamma 1}
#include "colors.inc"

light_source { <-3,8,2> color .7*White}
light_source { <3,8,-4> color .7*White}
light_source { <0,.5,-1> color .4*White}

camera {
 location <-2, 10, -10>
 look_at  <0, 2, 0>
 angle 50
}

plane {y, -1 pigment { checker Grey, White }}

#declare RADIUS = 4;
#declare Thickness = 0.2;
#declare Freq = 8;
#declare Spirals = 2;

isosurface {
 function {Thickness - y*y*Freq - pow(sin((sqrt(x*x+z*z)*Freq -
 0.5*atan2(z,x))),2) + 5 - pow(x,3)}

 accuracy 0.01
 threshold 0
 max_gradient 107
 contained_by {sphere {<0,0,0>, RADIUS}}
 open
 texture {pigment {Red} finish {specular 0.4}}
 rotate 90*z
 rotate -30*y
 translate 3.2*y
   }

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> Thanks
> for taking the time to work it out.

Sure thing.  It wasn't too bad once I had enough time to look it over from a
fresh perspective.

> I do notice that the functions don't yet
> produce 'tapering' of the spiral at the start and end points (i.e, tapering to a
> fine point)-- but that's a minor quibble right now, and actually gives us more
> opportunities for experimentation, function-wise. And, so far, I haven't seen a
> need for a sphere shape at the center; only a bit of isosurface accuracy
> adjustment instead. Perhaps the sphere requirement applies to other more complex
> spiral cross-sections (or tapering).

Well, the thing that I did notice, is that there IS tapering - x-z-wise.  The
y-component remains constant, but the spirals get pinched off so that you have a
vertical y-edge.  If you closely, I believe the same thing happens with the
original function, which is presumably what the sphere was intended to cover up.

I haven't experimented enough to gain enough perspective on the various parts of
the function[s] to see why, or how it get changed - if it can.  But have some
vague ideas for further experiments.

> Meanwhile... here's a spiral doodle just for the fun of it, that looks like a
> rubber mat, draped over an invisible rod.

Ha!  That's excellent.  I played around with trying to cram everything into one
super-function using select(), and I got something similar, but it's symmetric
around the axis of rotation and looks like yours - where the tubes blend
together.

I'm wondering if the idiosyncrasies of this shape are best addressed by a
parametric rather than an isosurface.  Implicit / closed form equations can be
pretty difficult to grapple with sometimes, whereas separating the x, y, and
z-components can be easier, more tunable, and seem to be a lot more readable /
intuitive.

I'm glad you're having fun and producing some fun-looking shapes.  I'll bet
they'd look great in glass.  A light probe, radiosity and photons would probably
make for long render times, but pretty sharp looking scenes.

Also, I was looking at some seashell sites, and taking a slice out of your open
surface might be something to try, as would wireframing / grid-texturing it,
either with uv-mapping or tightly-banded color/texture/material maps (with rbgt
1).

Post a reply to this message

You might also be interested in a completely different way of producing a spiral
image:

https://swiftcoder.wordpress.com/2010/06/21/logarithmic-spiral-distance-field/

I though the fading effect was pretty cool.  I don't understand it yet, but I
got it to work after fixing something positively ridiculous.

Just thought I'd post it here since it's such a radically different way of
visualizing it.


#version 3.7;
//------------------------------------------
// SDL for spiral distance field
// Bill Walker - October 2017
//------------------------------------------
global_settings {assumed_gamma 1}

#include "colors.inc"
#include "consts.inc"

light_source { <-1,8,2> color White}

camera {
 orthographic
 location <0, 0, -100>
 look_at  <0, 0,   0>
 right x*image_width
 up y*image_height
}

plane {z, 1 pigment {checker Gray20, White} scale 10}
light_source {<0, 10, -500> color White*0.5}

#macro Spiral (X, Y)
 #declare a=1;
 #declare b=0.5;
 // calculate the target radius and theta
  #local R = sqrt (X*X +Y*Y);

   // early exit if the point requested is the origin itself
 // to avoid taking the logarithm of zero in the next step
 #if (R = 0)
  0
 #else
  #local T = atan2 (Y, X);
  // calculate the floating point approximation for n
  #local n = (log(R/a)/b - T)/(tau);

  // find the two possible radii for the closest point
  #local upper_r = a * pow(e, b * (T + tau*ceil(n)));
  #local lower_r = a * pow(e, b * (T + tau*floor(n)));

  // return the minimum distance to the target point
  min (abs(upper_r - R), abs(R - lower_r))
 #end
#end


#for (i, -image_width/2, image_width/2)
 #for (j, -image_height/2, image_height/2)
  box { -0.5, 0.5 translate <i, j, 0> pigment {color rgb min(1, Spiral(i, j)/255
)} }
 #end
#end

Post a reply to this message