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