Hello,
It seems to me that in fg_property_scale, it would be more useful if the
power was applied after the linear scaling.
The problem I have is to map the radar range axis, from [-1.0,+1.0]
to [5.0,200.0]. But a linear scale is not too nice, so I'd want to
apply a power 2.5 or 2.7. Unfortunately the current implementation
applies the power before the linear scale.
In practice, this tends to neutralize the linear scaling. If you check
the existing uses, most of the time when there's a power different from
the unit, the factor is left to 1 and the offset is 0 or close.
I would propose to use instead:
static bool
do_property_scale (const SGPropertyNode * arg)
{
SGPropertyNode * prop = get_prop(arg);
double setting = arg->getDoubleValue("setting");
double offset = arg->getDoubleValue("offset", 0.0);
double factor = arg->getDoubleValue("factor", 1.0);
bool squared = arg->getBoolValue("squared", false);
double power = arg->getDoubleValue("power", (squared ? 2.0 : 1.0));
return prop->setDoubleValue(powl((setting+offset)*factor,power));
}
This should not impact a lot of existing configurations (as mentionned,
most of them have neutral linear parameters when they use power), and
this would allow better transformation curves.
(defun property-scale (value &key (offset 0.0) (factor 1.0) (power 1.0))
(expt (* (+ value offset) factor) scale))
(defun solve-property-scale (omin omax tmin tmax &key (power 1))
(flet ((solve (omin omax tmin tmax)
(list :factor (/ (- tmax tmin) (- omax omin))
:offset (/ (- (* tmax omin) (* tmin omax))
(- tmin tmax)))))
(if (= 1 power)
(solve omin omax tmin tmax)
(solve omin omax (expt tmin (/ power)) (expt tmax (/ power))))))
(loop
with power = 2.5
with solution = (solve-property-scale -1.0 +1.0 5.0 200.0 :power power)
with offset = (getf solution :offset)
with factor = (getf solution :factor)
for setting from -1.0 to +1.01 by 0.1
do (format t "~10,3F --> ~10,3F~%" setting (expt (abs (* factor (+ offset
setting))) power)))
-1.000 --> 5.000
-0.900 --> 7.382
-0.800 --> 10.341
-0.700 --> 13.917
-0.600 --> 18.147
-0.500 --> 23.067
-0.400 --> 28.712
-0.300 --> 35.113
-0.200 --> 42.301
-0.100 --> 50.307
0.000 --> 59.160
0.100 --> 68.887
0.200 --> 79.515
0.300 --> 91.071
0.400 --> 103.580
0.500 --> 117.067
0.600 --> 131.556
0.700 --> 147.071
0.800 --> 163.635
0.900 --> 181.271
1.000 --> 200.000
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
------------------------------------------------------------------------------
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now! http://p.sf.net/sfu/ibm-webcastpromo
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
