Campbell Barton wrote: > While not against this (in general), keeping them fast is very > important since they can be evaluated 100's (even 1000's) of times a > second when running an animation on a complex rig. > Since 2.4x, drivers compile their expressions giving ~15-25x, As well > as caching the namespace (also gives some speedup), so I'd not accept > a solution that is significantly slower.
This was part of the reason I thought a "nodes to Python subset" (& it's inverse) would be beneficial. A Python subset can still be compiled by the Python runtime and run just as fast as previously but, being a subset with known limitations, it removes the need to try drastic solutions such as hacking the runtime or replacing Python completely. Obviously any subset would need to be simple yet expressive enough to make it useful. I reckon simple conditionals, mathematical expressions and built-in functions (for math & scene/property access) would suffice. I don't think we need the ability to create new functions nor advanced data types like dictionaries, lists, or objects. The idea would need some buy in from the "decision makers" (as they shall henceforth be known *grin*), but being able to access properties in the scene and have basic conditionals (if not loops) would alleviate, I think, issues about a lack of expressiveness. _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
