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