That’s what I actually was initially considering.
The only real difficulty using C introduces is data structure, which environments like Python simplify for you. Hence in Python you can consider more what it is that you are doing, and less how you organize the encumbant data.
The main reasons for going straight to blender source are:
- data structure is already provided (so I can think less about it and more about what I’m doing)
- softbody calculations may provide most of the routines needed (so I don’t have to build a new wheel)
- direct data manipulation
- no porting into blender needed when done
What the python intermediary would be spending a lot of time and structure doing would just be sending mesh data back and forth between the executable and blender. This would involve a lot of string to/from float conversions, which would cripple any possible speed gained from compiled calculations. If I can directly link into blender via python that would be very convenient (i.e. does python provide shared memory for two separate processes?)
However, I haven’t yet had time to examine the blender source very carefully yet, so the final decision has yet to be firmly made. I’ll look into those modules you suggested. Thanks.
As for optimizations, bit-twaddling will not make so great a difference here as algorithm implementation. The thing that slows down math on modern systems isn’t the calculations but what is done between each one. For example, in Tcl, each expr is preceed by lexing and parsing and succeeded by printing to strings. Even high-level languages like C can get you behind the scenes as each float can be converted to a double before sending through some function or to the FPU (though this isn’t a problem in blender since it uses double internally).
Clothing simulation is actually fairly straight-forward. It is parallel only in that a piece of cloth is considered as a single system; each point is updated based only on its nearest neighbors’ attributes --but this can be done without regard to order. The main difficulty comes from the size of the step you can take as each one plus failures require multiple integrations.
The data to be stored between ‘steps’ is:
- initial mesh (used for detangling and for obtaining natural spring lengths)
- current mesh
- previous mesh (used to get the current mesh’s velocity)
Each mesh involved (more than one object can be a mesh, and they can all be set to mutually interact) will also have various vertex groups attached allowing specific values to be overridden such as friction and mass.
What I would like to have is an ability to write, in python, functions which look something like:
gravity( frame_number, mesh_name, position )
which will provide the greatest user control over these things. But again, this introduces a layer between the value and its use for each point and each integration.
Well, I’m still learning how I want to do all this… This weekend probably I’ll spend some time getting my system set up to compile blender and start looking through the softbodies.
Oh yeah, will the Python install stomp all over my ActiveTcl?