"Bald Eagle" <cre### [at] netscapenet> wrote:

Alright kids,
I puzzled out the basic conversion from cpp to SDL, and then had to envision how
POV-Ray computes the isosurface (notice the whole internal function just returns
a single scalar value) and emulate that.

First off, this following bit seems to be related to the culprit:

> I'd say that the very last r defines sqrt of x-squared + y-squared + z-squared -
> which is the implicit / closed form of the surface of a sphere.
> So, I'd start looking there....

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.

ALSO notice that that last parameter is what is used to determine the
cross-sectional shape of the spiral.

> Maybe rewrite it out in SDL so it's easier to play with.

I did, and I will post the results in p.b.i to show the difference between the
round cross section (0) and the square (1)

Other things to notice to get a basic understanding about how the isosurface
gets plotted, is that the code loops/steps through "all" the points in the box
and evaluates the isosurface function.  If that value is zero (or less than
'epsilon' (STEP) ) then it applies the designated texture, lighting, etc (plots
a sphere)

The bigger the box, the more points have to be looped through to run through the
isosurface formula, and the longer the loop takes.
The more complicated / slower the formula is to evaluate, the longer the loop
takes.

That's the basis of why isosurfaces are so slow to evaluate.

If I have more time, I'll see if I can refine it a bit, and maybe do a Paul
Nylander meshification version, and perhaps a wireframe version or two.

Post a reply to this message

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.

Post a reply to this message

On 30-9-2017 8:24, clipka wrote:
> 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.
> 

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

-- 
Thomas

Post a reply to this message

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