This is the same design philosophy I brought to my current system, which arose from the introduction of Transform constraints. Now it seems the next generation of features is nearly ready for a similar development cycle – get to work guys! 
Probably, but that involves math and screw math! I want to do this with constraints because it’s easier for my small brain to handle. 
Oh come one ! 
Given the choice of writing a two-variable expression & managing the relationship between the two variables & their influence, and entering values in constraint fields, I figure about 99% of Blender users would prefer the latter. Expressions can be powerful but they can also be both byzantine and opaque to those not intimately familiar with Blender’s API.
So I started this thread because I have a kickstarter project that I want to launch that will require a muscle rigging system to do properly. I tried to find developer contact information, but the best I could find was a mailing list; which didn’t help.
Long story short; I’m willing to expand the projects budget to include developing something in the way of muscle rigging, but I need development guidelines to pass to the programmer so that the work is not thrown out after for not meeting trunk standards.
Also, as I’ve been thinking about rigging more and more, really rigging is nothing more than glorified proportional editing with specialized management tools. There’s no reason why regular meshes can not double as bones with various properties; the code is already there.
I can sort of understand the first part of this statement, although dynamic influences that are not possible with proportional editing are inherent in a skeletal rig system, and animation is all about dynamics. Maybe that’s what you mean by “glorified.”
But I can’t see the point of the second part of the statement. What benefit do you see using meshes as bones? Are you thinking of a “self-rigged” mesh? I see problems in dealing with the inherent properties (and problems) of meshes while simultaneously trying to get them to act as bones. Many deformation issues are not amenable to single-bone or paired-bone solutions, which is why correctives of one sort or another are often necessary. Volume control & many degrees of freedom come to mind. How would a “mesh-as-bones” concept address these kinds of issues (there are others, but let’s start with only a couple of common examples).
A major benefit of skeletal rigs is that they operate regardless of mesh topology issues. Poor topology means poor deformations, but that can be remedied apart from any rigging considerations. With “mesh-as-bones” I can imagine serious problems arising from less than perfect topology, because editing the mesh would likely alter the rigging as well, making these two aspects of prepping a mesh for animation too intimately linked for practical use. Keeping such functionality separate increases overall fine control over the system.
It has nothing to do with the api, I don’t know anything about it myself - an expression is just (var1*var2)/2 for instance (that’s for an average).
It has everything to do with the API, because the expression has to operate on some aspect of Blender’s coded virtual reality, which the API describes. An expression all by itself is basically meaningless in terms of practical usage. In your example, what do the variables represent? In situations involving rigging, they might be returns from API functions describing bone rotation or some other transform. To obtain such data to be used or operated on in an expression, one needs to know the API. The constraints were coded to make such variables easily accessible in the interface, and the values for expressions the constraints use are entered in convenient and easily understood value fields. They expose the API in a very accessible manner. Driver expressions need to be constructed from the ground up, so to speak. I’m not denying their usefulness, but it isn’t as simple as just plugging in an expression, because the expression itself requires knowledge and/or research to be properly constructed.
Fair enough, I may have oversimplified.
I definitely would like to get a Blender developer involved in this discussion, so that we can what it’s like on the other side, regarding implementation and other programming issues.
That would be (var1 + var2) / 2.0
:eek:
Oops that’s right