Some information I've not seen anywhere about f_torus equivalents for a 
couple of the new v38 torus spindle modes. The merge and intersection 
spindle modes have long existed with the f_torus, but via value 
arguments. See the attached image.

So, you can get a couple of the spindle tori with isosurfaces and 
f_torus in versions prior to v38.

While at it, some timing information from povr with new solver branch 
updates.

torus regular to sturm solver  2.070 -> 2.393  +15.60%
torus sturm to f_torus         2.393 -> 3.605  +50.65%

Bill P.

Question. Does anyone know why f_torus2() exists? Best I can tell it's a 
much, much, less efficient implementation with an additional capability 
to tweak the values. That last can be done faster in other ways. Current 
plan is to delete f_torus2() in povr.

Post a reply to this message

Attachments:
Download 'story_torus_vs_f_torus.png' (46 KB)

Preview of image 'story_torus_vs_f_torus.png'

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

> Question. Does anyone know why f_torus2() exists? Best I can tell it's a
> much, much, less efficient implementation with an additional capability
> to tweak the values. That last can be done faster in other ways. Current
> plan is to delete f_torus2() in povr.

Damned if I know.
Probably like some of those mapping types that never got defined...
http://news.povray.org/povray.binaries.images/message/%3C5438051b%241%40news.povray.org%3E/#%3C5438051b%241%40news.povr
ay.org%3E

the only thing I've found is what you're likely already aware of.

http://www.povray.org/documentation/view/3.7.0/448/
f_torus2(x,y,z, P0, P1, P2). This is different from the f_torus function which
just has the major and minor radii as parameters.

P0 : Field Strength (Needs a negative field strength or a negated function)
P1 : Major radius
P2 : Minor radius


http://www.f-lohmueller.de/pov_tut/addon/00_Basic_Templates/41_Isosurfaces_function.inc/__index.htm


Any ideas about Cousin Ricky's "elliptical torus"?
That could mean any of 3 or 4 different things to me, and searching yielded a
ton of different options.

Speculating here:
Perhaps it might be best to treat all tori as Clifford tori and use the Dupin
cyclide code in the source - which would allow geometric inversion?
But then again the one-size fits all option might not be very efficient...?

Post a reply to this message

On 2020-04-30 2:15 PM (-4), Bald Eagle wrote:
> 
> Any ideas about Cousin Ricky's "elliptical torus"?
> That could mean any of 3 or 4 different things to me, and searching yielded a
> ton of different options.

My requirements are specific:
   - The innermost curve must be an ellipse.
   - The outermost curve must be an ellipse.
   - The central curve must be an ellipse.
   - The cross sections must be circular at the elliptical vertices and
     co-vertices.
   - The gradients must be close to linear and preferably close to 1.0.

The first three requirements are necessary to fit in with the theme of 
the RoundEdge module.  The last two are necessary for well-behaved 
isosurface blobbing--and are the reason that simply scaling f_torus() is 
insufficient.

Others may have different requirements.

> Speculating here:
> Perhaps it might be best to treat all tori as Clifford tori and use the Dupin
> cyclide code in the source - which would allow geometric inversion?
> But then again the one-size fits all option might not be very efficient...?

That math is beyond me.  You should have caught me back in 1990, before 
my brain turned on me.  (But then, there was no POV-ray yet, was there?)

Post a reply to this message

On 5/1/20 12:41 AM, Cousin Ricky wrote:
> On 2020-04-30 2:15 PM (-4), Bald Eagle wrote:
>>
>> Any ideas about Cousin Ricky's "elliptical torus"?
>> That could mean any of 3 or 4 different things to me, and searching 
>> yielded a
>> ton of different options.
> 
> My requirements are specific:






> 
> The first three requirements are necessary to fit in with the theme of 

> isosurface blobbing--and are the reason that simply scaling f_torus() is 
> insufficient.
> 
> Others may have different requirements.
> 
>> Speculating here:
>> Perhaps it might be best to treat all tori as Clifford tori and use 
>> the Dupin
>> cyclide code in the source - which would allow geometric inversion?
>> But then again the one-size fits all option might not be very 
>> efficient...?
> 



Ideas...

Not off the top of my head. I'll keep the question in mind, but I've got 
significant todo list.

Bill

Post a reply to this message