

Changeing the radius of the internal f_sphere function has less effect
than I expected.
from the source fnintern.cpp:
DBL f_sphere(FPUContext *ctx, DBL *ptr, unsigned int) // 61
{
return (PARAM(0) + sqrt(PARAM_X * PARAM_X + PARAM_Y * PARAM_Y +
PARAM_Z * PARAM_Z));
}
maybe something like:
return (sqrt(PARAM_X * PARAM_X + PARAM_Y * PARAM_Y + PARAM_Z *
PARAM_Z)/PARAM(0));
Scene for comparing:
#version 3.7;
global_settings{ assumed_gamma 1.0 }
#default{ finish{ ambient 1 diffuse 0 emission 0}}
#include "functions.inc"
camera {
orthographic
location <0,0,1>
look_at <0,0,0>
right x*image_width/image_height
}
// +w200 +h200
#declare Fn_Sphere = function(x,y,z,R){sqrt(pow(x,2)+pow(y,2)+pow(z,2))/R}
box {
<.5,.5,0>, <.5,.5,0>
texture {
pigment {
//expect to see two full circles
function{f_sphere(x,y,z,0.25)}
//function{Fn_Sphere(x,y,z,0.25)}
color_map {
[0.0 color rgb 0.0 ]
[1.0 color rgb 1.0 ]
}
scale 1
}
}
}
ingo
Post a reply to this message




Am 10.01.2019 um 11:58 schrieb ingo:
> Changeing the radius of the internal f_sphere function has less effect
> than I expected.
>
> from the source fnintern.cpp:
>
> DBL f_sphere(FPUContext *ctx, DBL *ptr, unsigned int) // 61
> {
> return (PARAM(0) + sqrt(PARAM_X * PARAM_X + PARAM_Y * PARAM_Y +
> PARAM_Z * PARAM_Z));
> }
>
> maybe something like:
>
> return (sqrt(PARAM_X * PARAM_X + PARAM_Y * PARAM_Y + PARAM_Z *
> PARAM_Z)/PARAM(0));
Ingo, the things you are complaining about here have been around for ages.
 The newsgroup povray.betatest isn't really the right place, as it is
intended for discussion about stuff that's specific to the testing of
development versions, such as new features to be tested or new bugs
found in testing of the development versions.
 As long as they are not outright bugs, changing these things is out of
the question because they would break existing scenes, period.
 With functions this is especially true, as they can be trivially
replaced by you as a user if the predefined ones happen to not fit your
needs.
As for this particular function, it works as advertised for the default
threshold value in isosurfaces (which is what it was designed for). For
nondefault threshold values it can be argued whether its behaviour is
intuitive, but it is what it is.
Post a reply to this message

