On 20200416 8:38 AM (-4), William F Pokorny wrote:
> 
> I didn't post details, but I've played with alternate methods to code, 
> f_sphere, for example. Something to avoid the sqrt() because it's 
> expensive CPU wise. The other forms have higher gradients and we always 
> lose big in isosurface time. In other words the gradient is king with 
> our current solver.

I have found non-linear gradients to be more expensive than sqrt() 
calls.  If I have a quadratic isosurface function (which is the case 
with RE_fn_Blob2() in the Object Collection), I will use a sqrt() 
without hesitation in my SDL to flatten out the gradient.  I imagine 
that the contrast would be even greater with native sqrt() calls, since 
they would not have to go through an interpreter.

Post a reply to this message