So, I looped over x, y, and z and sent the evaluated function result to the
debug stream.   Massive delay from sending 8000 points to the text stream
later...
 and I get values in the hundreds, less, less, less, and maybe a min of 0 or so.

I then plotted points with a value of 10 or less with spheres.

There's definitely an elliptical shape in there somewhere....

Post a reply to this message

Attachments:
Download 'implicitellipticaltorus.png' (119 KB)

Preview of image 'implicitellipticaltorus.png'

Oh look:
If I clean up my sloppy code and cease engaging in flagrant dumbassery.....

Post a reply to this message

Attachments:
Download 'implicitellipticaltorus.png' (148 KB)

Preview of image 'implicitellipticaltorus.png'

And wow - wouldn't you know - when you actually do the math correctly, it comes
out dead-on.

:)

f_elliptical_torus in the proper x-z plane

Post a reply to this message

Attachments:
Download 'implicitellipticaltorus.png' (93 KB)

Preview of image 'implicitellipticaltorus.png'

On 5/4/20 8:08 PM, Bald Eagle wrote:
> And wow - wouldn't you know - when you actually do the math correctly, it comes
> out dead-on.
> 
> :)
> 
> f_elliptical_torus in the proper x-z plane
> 

Cool! :-)

I'm going make another attempt at an inbuilt function for this. If 
you've tweaked something in the code from the previous few posts, please 
let me know.

More ReL (Real Life) than RaL (Ray Life) today - so likely later this 
week before I get to it.

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:

> I'm going make another attempt at an inbuilt function for this. If
> you've tweaked something in the code from the previous few posts, please
> let me know.

Nope - Just been playing around with it a bit to make sure the outer and inner
shapes are truly elliptical (they are).

I know we have a vlength() - but it can't be used in functions (vector
argument).
Maybe if there was a way to just do a Vlength (x,y,z) to get around that...


I was also thinking that non-circular cross sections would be something nice to
have - something like the form factors for the helix functions.  I have one
function that I'll try to work out for that, but other functions similar to the
superellipsoid, "squircle", and rounded box seem like they would have utility
for povvers as well.

Conversely, It would be great to have a "torus" that was spherical or
ellipsoidal - but could follow the shape of some other function or spline.


With regard to dot notations and vectors - what is the "native form" for a
pigment pattern?  Is it an "rgb" vector where each component simply has the same
value unless modified by a color_map?

And is it therefore slower to use .gray or .hf?


> More ReL (Real Life) than RaL (Ray Life) today - so likely later this
> week before I get to it.

So much ReL.  Juggling Arduino, work, home, and COVID ridiculousness.
No worries - take your time.  :)

Post a reply to this message

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

> I was also thinking that non-circular cross sections would be something nice to
> have - something like the form factors for the helix functions.  I have one
> function that I'll try to work out for that, but other functions similar to the
> superellipsoid, "squircle", and rounded box seem like they would have utility
> for povvers as well.

I made excellent progress in translating the function of main interest to into a
pattern and an isosurface.   I think in order to make it function as a
cross-sectional term, it needs to "translate its frame of reference to the
origin", and so I might need to convert the atan2 function to a polynomial.
But I might be wrong about that.

Essentially, I need to calculate the _angle_ that I'm at around the cross
section using x and y....
So I'd need to do something like this, only in SDL.


from:

https://stackoverflow.com/questions/11930594/calculate-atan2-without-std-functions-or-c99


float normalized_atan2( float y, float x )
{
    static const uint32_t sign_mask = 0x80000000;
    static const float b = 0.596227f;

    // Extract the sign bits
    uint32_t ux_s  = sign_mask & (uint32_t &)x;
    uint32_t uy_s  = sign_mask & (uint32_t &)y;

    // Determine the quadrant offset
    float q = (float)( ( ~ux_s & uy_s ) >> 29 | ux_s >> 30 );

    // Calculate the arctangent in the first quadrant
    float bxy_a = ::fabs( b * x * y );
    float num = bxy_a + y * y;
    float atan_1q =  num / ( x * x + bxy_a + num );

    // Translate it to the proper quadrant
    uint32_t uatan_2q = (ux_s ^ uy_s) | (uint32_t &)atan_1q;
    return q + (float &)uatan_2q;
}

Post a reply to this message

Scratch that initial misconception.

> Essentially, I need to calculate the _angle_ that I'm at around the cross
> section using x and y....

Which means that I need to unravel the dot product between two vectors.
The first vector being the normalized blue segment in the drawing.
The second vector being the normalized radial vector in the vertical plane of
the blue vector.

Got some cool screw-ups, and have some visual confirmation that I can get a nice
non-circular/elliptic shape to the R of the torus.

Maybe I'll get it before tomorrow afternoon.

Post a reply to this message

Grrr.

Tried like 5 different ways, and wrote functions for cos, vlength, norm, dot,
and angle.

I just get the same results - modification of the R, not the r.

Maybe it will come to me with more sleep.


The rear row are single instances of the shapes - like the spherical pattern,
instead of multiple level sets of the isosurfaces like the onion.

Anyway, here's a preview to show the direction I'm heading.

Post a reply to this message

Attachments:
Download 'ngonisosurface.png' (175 KB)

Preview of image 'ngonisosurface.png'

On 5/5/20 1:34 PM, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
...
> With regard to dot notations and vectors - what is the "native form" for a
> pigment pattern?  Is it an "rgb" vector where each component simply has the same
> value unless modified by a color_map?
> 
> And is it therefore slower to use .gray or .hf?
> 

You got it. Yes, it's slower to use .gray or .hf if, say, .red will do. 
However, often not by enough you can really tell given the volatility of 
today's CPU performance.

We also have the issue POV-Ray's .gray, .grey and .hf functions not 
being quite the norm. Somewhere there are posts from Christoph - and 
maybe Cousin Ricky - on this IIRC. I have notes somewhere...

I've been staying away from .gray, .grey and .hf and output to grey file 
formats for a while.

I think so long as all rgb values match exactly the difference in 
POV-Ray's conversion to a gray value doesn't matter - but that statement 
should be thoroughly tested before being set in stone.

Bill P.

Post a reply to this message

On 5/5/20 1:34 PM, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
>> I'm going make another attempt at an inbuilt function for this. If
>> you've tweaked something in the code from the previous few posts, please
>> let me know.
> 
> Nope - Just been playing around with it a bit to make sure the outer and inner
> shapes are truly elliptical (they are).
> 
...
> 

A quick note and image.

I ran at an f_elliptical_torus() again today and again failed. Ended up 
almost exactly where I did last time for result. :-(

My implementation of your recent code worked straight up with different 
a=b sizes this time. When a=b we match Bruno's result - and that of 
f_torus() for that matter. When A close to B results is pretty close as 
in the top row, but if A and B much different it falls apart.

FYI. I'm comparing against Bruno's sphere_sweep version which looks good 
to me for shape and OK for comparisons. However, the sphere_sweep itself 
won't render at all cleanly in some orientations / sizes due bugs with 
the sphere_sweep if using v37 / v38. My povr updates mostly work with 
the orthographic camera - except for some speckles you can see in the 
comparisons.

Aside: The orthographic rays to a flat sphere_sweep the worst case 
solver wise because the two roots collapse to a multiple with which 
solvers struggle. I have a patch in TCL for some of these (missed roots 
after polynomial deflation), but not yet found myself putting it in.

If the mood hits me, I'll spend some time trying to digest what Bruno 
really did. Review too my version of your code, but this time not too 
different from yours. Might try your SDL straight up - I didn't do that 
this time... Work for another day.

Bill P.

Post a reply to this message

Attachments:
Download 'eltorusfail.jpg' (91 KB)

Preview of image 'eltorusfail.jpg'