|
 |
In math.inc it says :
"Clamps a number (x) to the range [Min, Max] ([y, z]).
Values outside this range wrap around."
That last bit is a problem imo. It should not wrap around. As an example
of why it should not wrap an implementation of the Smoothstep function.
Render the scene as is and then with the ifdef section uncommented.
I would rename the existing function to clamp_wrap and add the one below
as clamp as that is what one would expect.
ingo
---%<------%<------%<---
#version 3.8;
#include "math.inc"
// +a0.1 +w400 +h400
global_settings {assumed_gamma 1.0}
#default{ finish{ ambient 0.1 diffuse 0.9 }}
camera {
orthographic
location <0.5,0.5,-.1>
look_at <0.5,0.5,0>
right x*image_width/image_height
}
/*
#ifdef (clamp)
#undef clamp
#end
#declare clamp = function(x,y,z){select((x<=y),-1,select((x>=z),-
1,x,z),y)};
*/
#declare Smoothstep = function(x,y,z){
(3*pow(clamp((x - y) / (z - y), 0.0, 1.0),2))-
(2*pow(clamp((x - y) / (z - y), 0.0, 1.0),3))
}
#for (I,0,1,0.001)
sphere{<I, Smoothstep(I,0.2,0.8), 0>,0.01 pigment{rgb x}}
#end
box {
<0, 0, 0>, <1, 1, 1>
texture {
pigment {
function{Smoothstep(x,0.2,0.8)}
}
finish {
ambient 1.0
diffuse 0.0
}
}
}
Post a reply to this message
|
|
|
|
Am 07.01.2019 um 20:39 schrieb ingo:
> In math.inc it says :
> "Clamps a number (x) to the range [Min, Max] ([y, z]).
> Values outside this range wrap around."
>
> That last bit is a problem imo. It should not wrap around. As an example
> of why it should not wrap an implementation of the Smoothstep function.
> Render the scene as is and then with the ifdef section uncommented.
>
> I would rename the existing function to clamp_wrap and add the one below
> as clamp as that is what one would expect.
Who is "one"?
There is a function in math.inc that does what is described above. The
author happens to have decided that `clamp` was a reasonable name for
it. End of story.
While it is true that nowadays the function name `clamp` happens to have
come to be associated with a different operation, that does not
necessarily mean that association is the only natural, compelling or
even sensible one. It just means that it is the one that - over time -
has proven more useful.
And it appears to me that the prevalence of this association is
comparatively new. For instance, there is as yet no `clamp` function in
standard C, standard C++ has only just added such a function in C++17,
and even the arguably most extensive library collection for C++ ever,
boost, only has it since 2012.
The `clamp` function in `math.inc` dates back to at least 2002, when the
file was included in POV-Ray v3.5. Changing it to match the now-commonly
associated behaviour would break existing scenes, and is therefore out
of the question. Even if the name already was a misnomer in 2002, it is
here to stay.
If there should be general consensus that the function name was
excessively misleading, the proper way to deal with it would be to
declare it as deprecated (POV-Ray v3.7 introduced a formal mechanism to
do just that, generating a warning if the function is used), and
duplicate it under a new name (e.g. `wrap`).
If there should be general consensus that the now-commonly associated
behaviour was important enough to add a corresponding function to
`math.inc`, the proper way to deal with it would be to introduce it
under a yet-different name (e.g. `clip`).
Post a reply to this message
|
|
