<---------------------- References. Twelve previous posts

http://news.povray.org/povray.beta-test.binaries/thread/%3C5ee4b9e3%40news.povray.org%3E/

and

http://news.povray.org/povray.beta-test.binaries/thread/%3C5ee4dc4b%241%40news.povray.org%3E/


To povr adding new f_elliptical_sphrswp(). As Cousin_Ricky has 
mentioned, it is not a match for an elliptical torus (supertoroid 1,1 
asymmetric a,b), but probably something useful. See attached images.

Of note the implementation is testing out a torus pre-filter - my f_dual 
idea to improve isosurface performance. Idea works for performance, but 
it introduces a gradient change away from the surface so there are 
always max gradient warnings. The actual gradient to use is always 
around 1.0 for the sweep itself. So, need to figure out smarter max 
gradient determination (near roots); Create a warning on/off option for 
isosurfaces(1) - or do both.

(2) - IIRC. Megapov had a warning on/off thingy.

#declare angleStart = 153;
#declare angleArc   = -137;

#declare Iso98 = isosurface {
     function {
         f_elliptical_sphrswp(x,y,z,ax,bz,r,angleStart,angleArc,0)
     }
...

#declare Pig00 = pigment {
     function {
         f_elliptical_sphrswp(x,y,z,ax,bz,r,angleStart,angleArc,1)
      }


f_elliptical_sphrswp()
----------------------
Parameters: x, y, z

Six extra parameter required:

1. The traditional a multiplier of the x axis.

2. The traditional b multiplier of the z axis.

3. The minor radius, r.

4. The starting angle. 0 to 360.

5. The arc angle from the start angle. -360 to 360.

6. 0 = sweep with optimization. 1 = return 0 to 1 map value matched to 
angular rotation of arc.  2 = skip up front in torus filter. (e.g. Using 
sweep values for map control)

Notes. Like the f_torus() function the f_elliptical_sphrswp() sits 
around the y axis at the origin.  In other words, it is sitting in the 
x,z plane.  Angles and directional angles are left handed about y.

With respect to isosurfaces; Gradients are decent, but due the internal 
method of calculation, performance is somewhat volatile. Larger r values 
tend to run more slowly. Rays more orthogonal to the y axis are slower - 
sometimes slower than a parametric representation.

The function is close to that of an elliptical torus - supertoroid with 
e1,e2 at 1.0 (spherical) and asymmetric x,z axis values.  Also this 
method has start and end points - arcs - there is less continuity / 
smoothness at the cap spheres than elsewhere in each arc.

Bill P.

Post a reply to this message

Attachments:
Download 'storyellipsphswp.jpg' (63 KB) Download 'storysupertoroidtoesweep.jpg' (35 KB)

Preview of image 'storyellipsphswp.jpg'

Preview of image 'storysupertoroidtoesweep.jpg'

Le 2020-06-13 à 15:32, William F Pokorny a écrit :
> <---------------------- References. Twelve previous posts
> 
>
http://news.povray.org/povray.beta-test.binaries/thread/%3C5ee4b9e3%40news.povray.org%3E/

> 
> 
> and
> 
>
http://news.povray.org/povray.beta-test.binaries/thread/%3C5ee4dc4b%241%40news.povray.org%3E/

> 
> 
> 
> To povr adding new f_elliptical_sphrswp(). As Cousin_Ricky has 
> mentioned, it is not a match for an elliptical torus (supertoroid 1,1 
> asymmetric a,b), but probably something useful. See attached images.
> 
> Of note the implementation is testing out a torus pre-filter - my f_dual 
> idea to improve isosurface performance. Idea works for performance, but 
> it introduces a gradient change away from the surface so there are 
> always max gradient warnings. The actual gradient to use is always 
> around 1.0 for the sweep itself. So, need to figure out smarter max 
> gradient determination (near roots); Create a warning on/off option for 
> isosurfaces(1) - or do both.
> 

> Bill P.

Assuming a threshold of zero, using min(f_elliptical_sphrswp() , 1)
should clamp out the areas of high gradient.
If the threshold is, or need to be, around 1, use something like 1.5 to 
2 as the clamping value.

May be worth a try.

Post a reply to this message

On 6/14/20 12:29 PM, Alain Martel wrote:
...
> 
> Assuming a threshold of zero, using min(f_elliptical_sphrswp() , 1)
> should clamp out the areas of high gradient.
> If the threshold is, or need to be, around 1, use something like 1.5 to 
> 2 as the clamping value.
> 
...

That sort of clamping does sometimes work.

Here, what's happening is I'm using two functions with good/low 
gradients. The container function is cheap to compute - a scaled torus. 
The sweep is expensive to compute. If either is run alone there are no 
gradient warnings - and there's a switch to turn off the torus 
pre-filter so folks can, for example, use the sweep function with 
pigment maps or whatever.

The problem comes on the switch from the larger containing function to 
the elliptical sweep function. It's there that we 'generate' the larger 
gradient values. To the overall functionality & result those 
discontinuities don't matter.

The gradients are not matched/aligned during the switch and how much 
misaligned isn't constant. Blending the functions would fix the gradient 
warnings, but then I lose the performance benefit. So, at least at the 
moment, I think I'm stuck needing to change how the gradient warnings 
are reported or how generated.

Aside: As you and Bald Eagle suggested, it's now on my near term list to 
try and implement 3d vector<->double encode and decode functions. I'm 
thinking each encoded vector value at 21 bits and 1 bit, combined 
exponent switching from a +-1.0 range to a +-10 range at 5 or 6 digits 
of accuracy.

In working on the elliptical sphere sweep function, I got to thinking a 
+-10 range at 5-6 digits is plenty of both range and accuracy in many 
situations. With spline control points, for example. We'll see.

Bill P.

Post a reply to this message

Le 2020-06-15 à 07:07, William F Pokorny a écrit :
> On 6/14/20 12:29 PM, Alain Martel wrote:
> ...
>>
>> Assuming a threshold of zero, using min(f_elliptical_sphrswp() , 1)
>> should clamp out the areas of high gradient.
>> If the threshold is, or need to be, around 1, use something like 1.5 
>> to 2 as the clamping value.
>>
> ...
> 
> That sort of clamping does sometimes work.
> 
> Here, what's happening is I'm using two functions with good/low 
> gradients. The container function is cheap to compute - a scaled torus. 
> The sweep is expensive to compute. If either is run alone there are no 
> gradient warnings - and there's a switch to turn off the torus 
> pre-filter so folks can, for example, use the sweep function with 
> pigment maps or whatever.
> 
> The problem comes on the switch from the larger containing function to 
> the elliptical sweep function. It's there that we 'generate' the larger 
> gradient values. To the overall functionality & result those 
> discontinuities don't matter.
> 
> The gradients are not matched/aligned during the switch and how much 
> misaligned isn't constant. Blending the functions would fix the gradient 
> warnings, but then I lose the performance benefit. So, at least at the 
> moment, I think I'm stuck needing to change how the gradient warnings 
> are reported or how generated.
> 
> Aside: As you and Bald Eagle suggested, it's now on my near term list to 
> try and implement 3d vector<->double encode and decode functions. I'm 
> thinking each encoded vector value at 21 bits and 1 bit, combined 
> exponent switching from a +-1.0 range to a +-10 range at 5 or 6 digits 
> of accuracy.
> 
> In working on the elliptical sphere sweep function, I got to thinking a 
> +-10 range at 5-6 digits is plenty of both range and accuracy in many 
> situations. With spline control points, for example. We'll see.
> 
> Bill P.
> 
I see, huge gradient similar to what we can expect when using the 
gradient or radial patterns in an isosurface.

Post a reply to this message

On 6/15/20 11:44 AM, Alain Martel wrote:
> Le 2020-06-15 à 07:07, William F Pokorny a écrit :
...
> I see, huge gradient similar to what we can expect when using the 
> gradient or radial patterns in an isosurface.
> 

Yes, suppose similar if using POV-Ray gradient, radial and seeing the 
clamp. Povr if the normal 0-1 fmod-ish clamping is on, and your 
isosurface is catching the fmod clamping so to speak(1).

Where off in povr the gradient pattern's 'gradient', for example, is 
good/linear.

Bill P.

(1) And not using a wave modifier like triangle... It depends. General, 
simple statements/rules are hard to come by with isosurfaces. With our 
current solver low gradients being key for good performance is one. 
Gradient warnings have always been iffy, though often enough helpful.

Change a set of rays approach to an isosurface and the gradients are 
often different. Tighter bounding helps for both the usual ray misses / 
hits the bounding box reasons - and that smaller dimension(s) along the 
ray help with the 'effective' gradients.

Post a reply to this message