|
 |
On 4/18/20 4:12 PM, jr wrote:
> hi,
>
> William F Pokorny <ano### [at] anonymous org> wrote:
>> ...
>> Trick helps enough, I wonder if some other inbuilts could benefit from a
>> float over double option too.
>
> does the .. cost of extra speed, in context, matter so much? asking because
> (and perhaps I'm completely off-track) only today was a post (by user 'guarnio')
> where the problem is/was the range of float not being enough.
>
Not trying to be flippant, but I think it does when it does, and doesn't
when it doesn't. It's a judgement.
The scale and range of a scene with respect to accuracy as an issue is
always there relative to the accuracy you have available.
With functions and isosurfaces, the speed of even very fast inbuilt
functions matters because you mostly want to combine them with other
functions to create whatever. The performance of all those functions
mixed together mathematically is what can quickly get out of hand to the
point of being practically unusable performance wise.
With functions and isosurfaces, we already have an object with user
variable accuracy via the accuracy value passed which is often << 7/8
digits (I typically use 0.0005). I've done some limited testing and the
isosurface solver and - partly due the types of functional input - it
cannot deliver more than 6-7 digits of accuracy max as a rule sometimes
less. With other object types and solvers you can get up in the 11/12
digit ranges though often less. All at doubles.
Relatedly, I believe in going after better performance continually in
software tools - otherwise you're on the slippery slope to poky. :-)
Bill P.
Post a reply to this message
|
|
