Erik Hofman wrote: > Even for (say) a dozen of simultaneously active dynamic models? I'm > not sure, but it would be a good thing to look into.
Even for hundreds. The overhead for a property tie is pretty close to zero. You pay the cost only when the property is accessed -- to your internal C++ code, it's still just a variable. The only way to get into performance difficulties is if you are setting the values repeatedly (every frame, for instance) from a script. Nasal isn't terribly slow, but spinning in an interpreter like that is just a bad idea. :) There's a similar issue with the current bo105.nas script -- it hooks a timer at 20Hz to do a rear door animation. For just one of these, it's obviously not a problem. For dozens or hundreds of animated objects, this is likely to be suboptimal. For situations like this, I'm working on (actually almost done -- just need to find time to test) a "SGInterpolator" subsystem which can be used from either Nasal or C++. The idea is that you pass it a property node, and a list of "target value"/"delta time" pairs. It then smoothly interpolates the property value each frame, with no input needed from user code. This is basically as efficient (one 10-line function call per frame per interpolant) as you can get without ditching the property system entirely. And it enables a lot of stuff that used to be difficult: I know Lee has hooked the YASim gear up/down property to drive animations, but this is limited. Having an interpolator that you can drive from a script means that you can do stuff like variable-speed gear retraction (one wheel first, etc...), light pulsing (off for a long time, interpolate to bright over .25sec, then off again...), etc... All of it with no dependency on frame rate. :) Andy _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
